Re: Re: duplicated ioctl32 handler

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