On Tue, Sep 29, 2009 at 3:34 PM, Leonidas . <leonidas...@gmail.com> wrote:
> > > On Tue, Sep 29, 2009 at 3:31 PM, Nagaprabhanjan Bellari < > nagp....@gmail.com> wrote: > >> If you take /proc filesystem for example, you can write something to it >> and can read something from it depending on what you last wrote. >> -nagp >> >> On Fri, Sep 18, 2009 at 9:46 PM, Peter Teoh <htmldevelo...@gmail.com>wrote: >> >>> On Fri, Sep 18, 2009 at 9:07 PM, Leonidas . <leonidas...@gmail.com> >>> wrote: >>> > >>> > >>> > 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 >>> > >>> >>> ok......by in-band, i mean data + buffer type descriptor (u have 3 >>> types of buffer right) all goes into the same data area, so perhaps >>> 2MB + 1 byte (which will have values of 1,2, or 3 to identify which >>> buffer the current data represent). so basically only ONE device >>> (eg, /dev/myA). >>> >>> by out-of-band, i mean data will go into /dev/myA, and buffer type >>> will go into /dev/myB. so u do ioctl(/dev/myB) to specify the buffer >>> type, and then the entire 2MB will go into /dev/myA. so basically >>> TWO device have to be created. >>> >>> >>> >>> >>> -- >>> Regards, >>> Peter Teoh >>> >>> -- >>> To unsubscribe from this list: send an email with >>> "unsubscribe kernelnewbies" to ecar...@nl.linux.org >>> Please read the FAQ at http://kernelnewbies.org/FAQ >>> >>> >> > > I dont think so.... > > Your kernel module can write to /proc file only when someone has issued a > read on it. > i.e. your kernel module will not know whether to write or not unless > someone tries to > read from /proc file. You cant dump data to a /proc file assuming that > someone will read > it later on. > > -Leo. > Not sure, how what I wrote contradicts with what you said. What I meant was: * write the mode to /proc file - you driver will remember that when somebody reads from it, it will have to return mode specific data * read from /proc file - driver will write mode specific data which is stored. This will behave like a true device - you program it to make it behave in a certain fashion. :-) -nagp
