> > I think you are talking about ioctl on a single minor number device, my > concern is more > about choice here. Meaning whether using ioctls with different commands on a > single dev > node be preferable to issuing reads on 3 different minor number device > nodes. > > > -Leo. > > just take the example of major device no 1: u have /dev/mem, /dev/kmem, /dev/null, /dev/port etc etc....all having same major but different minor number, and implementation functions spilled into mem.c, or random.c etc, ie, more codes, more global variables (the fops structures) and more kernel memory (> 6MB++?). but then u have the simplicity of coding (userspace) as well as asynchronous access to the kernel - ie, all three read() can enter the kernel at the same time. but if u used just one minor for 3 different buffer, and do some sophisticated multiplexing, u saved on memory (2MB++), but programming is more complex (userspace + kernel - those multiplexing stuff). and u need to issue the read() synchronously - and u can either use in-band (or in-channel, hope u know what I mean) signalling (meaning the identifier of the buffer type is inside the buffer itself), or simpler still is out-of-band signalling (or side-channel), so in this case u need another minor device for ioctl purpose, to signal the buffer type to be used for the first minor device. ie, read() for first minor device, and ioctl() for 2nd minor device? does it make any sense? -- Regards, Peter Teoh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
