Re: ioctl assignment strategy?

[Pjotr Kourzanov]

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@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/