ioctl assignment strategy?

ioctl assignment strategy?

[Al Hooton]

	It was 6-7 years ago that I last worked on driver level stuff, I expect
I've got a whack with a cluebat coming....

	Do we care about "official" ioctl assignments any more?  Or, am I not
grokking some change that removes the need to submit patched files to
keep externally developed drivers from potentially colliding with their
ioctl's?  

	If we still need to do something to make our ioctl's "official", what
is it?  The comments in Documentation/ioctl-number.txt *can't* still be
accurate, I don't believe.

	I've been through ioctl-number.txt, looked through the various
ioctl(s).h and related kernel source for managing ioctl's, believe I
understand the _IOxx and _IOxx_xxx macros, searched the list archives,
googled, and I'm left with this one answered question...


Thanks,
Al

Re: ioctl assignment strategy?

[Greg KH]

On Tue, Dec 14, 2004 at 03:31:07PM -0800, Al Hooton wrote:
> 	It was 6-7 years ago that I last worked on driver level stuff, I expect
> I've got a whack with a cluebat coming....

Minor one coming, why do you want to use an ioctl?  ioctls are generally
frowned upon these days, and trying to add a new one is a tough and
arduous process, that is not for the weak, or faint of heart.

thanks,

greg k-h

Re: ioctl assignment strategy?

[Chris Friesen]

Greg KH wrote:

> Minor one coming, why do you want to use an ioctl?  ioctls are generally
> frowned upon these days, and trying to add a new one is a tough and
> arduous process, that is not for the weak, or faint of heart.

Just curious--what other options would you suggest for arbitrary char devices to 
allow for control that doesn't fit nicely into the read/write paradigm?

Re: ioctl assignment strategy?

[Greg KH]

On Wed, Dec 15, 2004 at 08:53:46AM -0600, Chris Friesen wrote:
> Greg KH wrote:
> 
> >Minor one coming, why do you want to use an ioctl?  ioctls are generally
> >frowned upon these days, and trying to add a new one is a tough and
> >arduous process, that is not for the weak, or faint of heart.
> 
> Just curious--what other options would you suggest for arbitrary char 
> devices to allow for control that doesn't fit nicely into the read/write 
> paradigm?

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.)

So, what does your ioctls do?

thanks,

greg k-h

Re: ioctl assignment strategy?

[Chris Friesen]

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

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

Re: ioctl assignment strategy?

[Alan Cox]

On Llu, 2004-12-20 at 22:48, Pjotr Kourzanov wrote:
>    /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

Except in the real world when little things come up like 
synchronization or complex API's that don't fit read/write terribly well
(committing sets of changes, synchronous object replies)
 
> 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...

And everything can be implemented in purest lisp on a turing machine.
You forgot the usefulness test.

> > 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.


<rant>

It offends the plan 9 bigots and their pet religion. Not that they don't
have a good point in many cases 8)

Ioctls do have some serious problems that make them nice to avoid

1. Each ioctl handler has its own data structures. While you could write
XML objects to encapsulate this in write() it is also true in many cases
that there is a simple logical expression of the operation - eg
configuration options tend to fit well into files as you can see with
/sysfs - unless they need to be atomic transactions with rollback at
which point the same people who decry ioctl will hate embedding sqlite
in the kernel

Seriously however - multiple structures means multiple validation
functions means more new code and more errors. It's a lot easier to get
ioctls wrong. There are a lot of things that don't need to be ioctl. A
look at security history says in general "ioctls cause bugs"

2. Ioctl structures tend to be binary. Welcome to 32/64bit emulation
hell. Good design can avoid this. Good design is not XML for this
purpose.

3. Ioctl is unstructured and so each ioctl is a new mystery to the
programmer. We all know how write works and in many cases  echo "451" >
/proc/sys/vm/blah is quite obvious.

4. It's hard to ioctl from the command line or scripts

The "ioctls are evil" blind hate department really annoy me however
because like all extreme views the truth very rarely fits their model

</rant>

Re: ioctl assignment strategy?

[Lee Revell]

On Tue, 2004-12-21 at 00:32 +0000, Alan Cox wrote:
> The "ioctls are evil" blind hate department really annoy me however
> because like all extreme views the truth very rarely fits their model

Another objection was that all ioctls take the BKL.  I think you did not
hear this one raised as much because it reflected a deficiency in the
system.  But now at least 2 different solutions have been posted for
BKL-less ioctls so that objection is no longer valid.

Lee

Re: ioctl assignment strategy?

[Olivier Galibert]

On Tue, Dec 21, 2004 at 12:32:11AM +0000, Alan Cox wrote:
> Ioctls do have some serious problems that make them nice to avoid
> [...]

5. ioctls don't have a reliable size information in the call, making
them hard to forward over a network in a generic way, or even pass to
another userspace process.

  OG.

Re: ioctl assignment strategy?

[Greg KH]

On Mon, Dec 20, 2004 at 11:37:54AM -0600, 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.

Multiple files?  One per type of action?  Without a full description of
what you are doing I don't really have a good answer.

> 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.

ioctls are basically a simple way to add any kind of syscall to the
kernel.  They also have nasty 32/64 bit issues.  Because we want to have
well-defined syscalls that work on all platforms, and not any arbitrary
type of call, it is good to restrict ioctls.

See the other comments about this topic in the lkml archives.

thanks,

greg k-h

Re: ioctl assignment strategy?

[Al Hooton]

	With permission from participants, posting the end of this thread back
to the list for the archives... .  a little long, if you're not
interested in strategies to avoid creating new ioctls for calls from
userspace, hit delete now....


On Tue, 2004-12-14 at 16:46 -0800, Greg KH wrote:
> Minor one coming, why do you want to use an ioctl?  ioctls are generally
> frowned upon these days, and trying to add a new one is a tough and
> arduous process, that is not for the weak, or faint of heart.


On Fri, 2004-12-17 at 15:50 -0800, Greg KH wrote:
> > 
> > We use sysfs or individual /dev nodes (now that we have a huge range of
> > major and minor numbers.)  We can also create a filesystem just for an
> > individual driver (takes less than 100 lines of kernel code now.)
> 
> 	Excellent, this is exactly what I needed to know -- architectural-level
> changes in how the kernel architects now expect things to be done.  I
> had not yet discovered the change in major/minor space during this "get
> reacquainted with the kernel" period I'm in, and was still operating
> under the old 256 minors limitation, etc., in my mind.  This is perfect!
> > 
> > What do your ioctls do?  Usually just rethinking about what is really
> > needed from them can show us where to put them.
> 
> 	In the parapin digital I/O kernel module, there are 6 operations:
> 
> - Claim the parallel port
> - Configure individual pins to be either input or output
> - Set pin states (high or low) for one or more pins using a bitmask
> - Get pin states (high or low)
> - Respond to a pin-10 hardware interrupt
> - Release the parallel port
> 
> 	My original device driver implementation uses open() to claim the port,
> close() to release it, and ioctl() for everything except setting up the
> interrupt/handler mechanisms.  Sometime in the near future I will deal
> with interrupts, but not until after I get everything else stabilized.
> 
> 	Thanks to your input, have decided a clean approach would be to use
> read/write for everything I was doing with ioctls (which, obviously,
> would have been possible anyway, but sometimes the whack with the
> cluebat makes the obvious more obvious...).  I plan to set it up such
> that each write() requires two words (a control word specifying the
> operation to perform, and a data word with a bitmask or bit values in
> it.  Each read returns a single word with current pin states, possibly
> masked by a bit mask handed down in the write().  We currently support
> building on 16-bit archs, so I don't want to combine control bits in
> words with data bits, we don't have enough space.  This will be a simple
> interface that is very easy to port to just about any platform.
> 
> 	My plan, now changed, for the interrupts is to not set up a
> signal-based mechanism, at least at first.  Instead, I will define
> another minor on the device for letting apps know an interrupt came in
> on pin 10.  When an interrupt hits, the driver will send up a single
> word to that minor.  Once an app has opened the device, it can check for
> words showing up on it, either blocking or non-blocking.  I realize
> there is increased latency with this approach, but a lot of the folks
> that use parapin are hardware engineers or students in universities with
> relatively little coding background.  Dealing with signals is farther
> down the stack than many of them will ever get.  I will probably add an
> interrupt-driven signal mechanism later for those that want to use it.
> 
> 	I may have another project coming up sometime next year, however, that
> will probably require several hundred minors, and a few majors, which
> can be dynamically defined (another great improvement in device
> interfacing since I was last poking around!).  You don't want to see how
> ugly that interface was planned to be before you pointed me to the
> major/minor improvements...     8^)=
> 
> 	Thanks again!
> 
> Best Regards,
> Al
>