Re: Ioctls for data transfer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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

[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux