On Fri, Sep 18, 2009 at 5:36 AM, Peter Teoh <htmldevelo...@gmail.com> wrote:
> > > > 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 > Peter, You explained the first part in a fantastic way! But I am not sure about the second para, in/out-band stuff. -Leo
