Brian F. G. Bidulock wrote:
Because it is has many races, is not thread safe, and locks on SMP
kernels. Running unlocked ioctls would like introduce an additional
set of problems in this regard that might negatively affect existing
drivers.
Thanks Brian. I had mis-guessed from your last e-mail that the use
of the kernel lock around the LiS ioctl was by specific design and wanted
to understand that design.
What about using compat_ioctl() for LiS and have the underlying function
grab the kernel lock before it does anything else?
Because the locked ioctl path does not need to release the kernel lock
in the first place.
I don't think I follow this one. I was wondering about the idea of
adding the acquiring/releasing of the kernel lock around the
compat_ioctl(), not the locked ioctl path. Given the above, I guess
it's moot now.
Also because I don't care to do too much work on
LiS as Linux Fast-STREAMS is superior.
Just looking for information, not code.
Besides, the RH EL4 2.6.9 kernel is here to stay for quite a while and it
does not support compat_ioctl.
Ah, I didn't know that. I was aiming to use compat_ioctl() since
register_ioctl32_conversion() is deprecated and sheduled for removal
(though it's already past the scheduled date).
Steve
------------------------------------------------------------------------
Steve Schefter phone: +1 705 725 9999 x26
The Software Group Limited fax: +1 705 725 9666
642 Welham Road, email: [EMAIL PROTECTED]
Barrie, Ontario CANADA L4N 9A1 Web: www.wanware.com
_______________________________________________
Linux-streams mailing list
[email protected]
http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
