elezegarcia at yahoo.com.ar
Thu May 19 13:53:27 EDT 2011
Thanks Dave for your answer. I guess the same question has been answered several times before. For the interest reader, I've found these:
I have a remaining question, though. In the lwn article I read this:
"The ioctl() system call has long been out of favor among the
kernel developers, who see it as a completely uncontrolled entry point into
Is this pointing that ioctl() is planning to get removed from the kernel ? In that case what's the currently preferred mechanism for giving 'control commands' to device drivers ?
Thanks again and greetings,
--- El mié 18-may-11, Dave Hylands <dhylands at gmail.com> escribió:
De: Dave Hylands <dhylands at gmail.com>
Asunto: Re: unlocked_ioctl explanation
Para: "Ezequiel García" <elezegarcia at yahoo.com.ar>
Cc: kernelnewbies at kernelnewbies.org
Fecha: miércoles, 18 de mayo de 2011, 3:20
2011/5/17 Ezequiel García <elezegarcia at yahoo.com.ar>
> I am aware that ioctl has been superseeded by unlocked_ioctl. I've been looking through patches and this seems to be BKL related.
> Could someone explain further the differences and reasons for the new ioctl prototype and name?
> I guess 'unlocked' means BKL is no longer held inside ioctl, right?
> What precautions should we take when using unlocked_ioctl ?
Well, since there is no BKL, your ioctl can get preempted by another
process and that other process just might happen to make an ioctl call
to your driver.
So your driver has to protect itself from being called by 2 threads
simultaneously, if that's a problem.
Some drivers won't need any extra protection. Unfortunately, it really
depends on exactly what your driver code does.
Shuswap, BC, Canada
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Kernelnewbies