On Tue, Sep 29, 2009 at 3:31 PM, Nagaprabhanjan Bellari <nagp.knb@xxxxxxxxx> 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.-nagpOn Fri, Sep 18, 2009 at 9:46 PM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote:
ok......by in-band, i mean data + buffer type descriptor (u have 3On Fri, Sep 18, 2009 at 9:07 PM, Leonidas . <leonidas137@xxxxxxxxx> wrote:
>
>
> On Fri, Sep 18, 2009 at 5:36 AM, Peter Teoh <htmldeveloper@xxxxxxxxx> 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
>
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 ecartis@xxxxxxxxxxxx
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.
