IRC channel logs
2024-11-13.log
back to list of logs
<solid_black>azert: it was pretty clear to me, they wanted to write a userland block device driver <solid_black>sneek: later tell slex: I know next to nothing about driver development (so better ask someone else), but in my understanding, there are 2 (or 3?) fundamental ways software can interact with hardware. The first is dedicated x86 'in'/'out' insturctions, that IIUC read/write to the ISA bus. You can do them from userland just as you would from kernel land, but you need to ask for permission to do that first by calling ioperm(). Second, there is memory-ma <solid_black>pped I/O (DMA and MM registers); you should be equally able to do that from userspace, perhaps by mmapping /dev/mem (well actually the Mach mem device). The hardware really doesn't care if your logic runs in ring 0 or ring 3. You also need to handle interrupts that the hardware generates; gnumach has some x86-specific API that let you handle those from userland; and damo22 has a library, libirqhelp, that presumably helps you with handling them. <damo22>sneek: later tell slex there is already a userland block device driver called rumpdisk <azert>sneek: later tell slex it is not clear to me what you want to achieve? What block device? What does it do? <etno>What is the difference between storeio's device backend and the devnode translator ? <youpi>devnode does not expose the file rpcs for instance <youpi>it's really just a dumb translator to expose kernel devices in /dev <youpi>(actually the kernel device may then expose the file rpcs, but it's not devnode which implements that) <youpi>"kernel device" can also be served by a bootstrap translator <sneek>Welcome back gnucode, you have 1 message! <sneek>gnucode, nckx says: As you can tell, I haven't been around much but all's good. You?