Messages in this thread | | | Date | Mon, 20 Dec 2004 23:48:42 +0100 | From | Pjotr Kourzanov <> | Subject | Re: ioctl assignment strategy? |
| |
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/ >
- 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/
| |