Re: ioctl assignment strategy?

[Pjotr Kourzanov <peter.kourzanov@xs4all.nl>]

Chris Friesen wrote:
> Greg KH wrote:
> 
>> Rethink the way you want to control your device.  Seriously, a lot of
>> ioctls can be broken down into single device files, single sysfs files,
>> or other such things (a whole new fs as a last resort too.)
> 
> 
> Actually, my particular case is likely not a good example.  We've got a 
> misc char driver giving access to a lot of miscellaneous features we've 
> added to the kernel,.  We originally (a few years back) used new 
> syscalls, but then we started supporting a bunch more arches, and having 
> to patch all of them just to add syscall numbers sucked.
> 
> Some of it could easily be moved to /proc or /sys, but if you do it that 
> way, how do you handle returning unusual error values?  Other stuff 
> involves multiple stages of registration, then getting handles returned, 
> and doing new calls with those handles.  I don't see how this would tie 
> nicely into the read/write paradigm.

   /That/ is exactly what FS API is good for: returning error values is 
done via read(/sys/mystuff/errno,&err,4), getting handles is done via 
open(/sys/mystuff/mycomp) and doing new calls is just calling FS API 
with the *file* handle. Registration, depending on your definition of it 
can be viewed as a link(/sys/mystuff/object,/sys/mystuff/subsystem) or 
as a write(/sys/mystuff/subsystem/registered,"object"). Take a peek into 
Plan9 from Bell Labs for inspiration...

> 
> What's the big problem with ioctls anyways?  I mean, in a closed 
> environment where I'm writing both the userspace and the kernelspace 
> side of things.
> 
> Chris
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>