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.
