lkml.org 
[lkml]   [2004]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ioctl assignment strategy?
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.

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/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.126 / U:0.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site