Re: ioctls vs syscalls once again

[Ingo Molnar <mingo@elte.hu>]

* Christoph Hellwig <hch@infradead.org> wrote:

> [ chaged the subject and droped the cc list down as this is not 
>   about discard support anymore]

( it was a good example though, showing where a new ioctl gets
  introduced/proposed. )

> On Fri, Aug 21, 2009 at 02:46:38PM +0200, Ingo Molnar wrote:
> > > ioctl is per defintion a multiplexer.
> > 
> > Yes, and? There's two variants of multiplexing:
> > 
> >   - multiplex something rather straightforward and related
> >   - multiplex unrelated fields, data, structures
> > 
> > I consider the second one 'ugly', the first one 'ok-ish'. YMMV.
> 
> Exactly.  And ioctl is per defintion the latter. [...]

Just to nitpick: not necessarily. A single-purpose ioctl with no 
parameter is obviously not going to multiplex anything - and we have 
some (although not typical - ioctls are addictive and quickly 
attract messy extensions).

( it might still be considered slightly bad style simply due to the
  generic suckiness of type-opaque ioctls as an interface - but 
  that's another matter. )

> [...]  sys_ioctl is a way to give drivers (and in Linux 
> filesystem, too) a way to implement their own syscall table 
> extension for file descritors they control.  While there might be 
> a few "ok-ish" or "nice" ioctl handlers most of them are ugly.  
> That's why people don't like them too much, btw :)

Can you name a single ok-ish ioctl from the kernel source?

> > I'd like to understand the technical basis of your critisism and 
> > i'd like to address any deficiencies of the perfcounters code. 
> > You said you dont like the ioctl solution we have, but that 
> > you'd like a separate syscall even less.
> 
> I really don't like any ioctl solution very much.  But sometimes 
> it's the lesser of the evils, often by a bug margin.

Well if something is the best possible technical solution, how can 
it be evil? (even if lesser than another evil)

That's what i dont understand about your position: i've yet to see 
you react _positively_ to any perfcounters interface, be that 
syscall, ioctl or any proposed imaginery API. Is there _anything_ 
you would react positively to? :-)

> > Perfcounters are a kernel-wide concept, encompassing 100% of all 
> > Linux installations, not just some special hardware.
> 
> That doesn't really matter.  The tty code is also used by 100% of 
> the Linux installation, and still it implements the tty controls 
> as ioctls.

I consider the tty ioctls rather ugly: they have multiple demux 
layers often hiding important details deep in the bowels of the Nth 
level of obfuscation. The variants go into the several dozens.

But ... the ioctl interface for TTYs was really inherited as an 
external compatibility constraint early on, used by a ton of 
applications, so there was not much to be done about that.

Hindsight is always easy but it might have lead to a cleaner TTY 
subsystem in general, had it gotten its own system calls (i mean, 
controlling/setting details of terminal output and input is 
certainly important enough to be raised to the level of system 
calls), nicely abstracted out.

Not possible for TTY - but for new code there's no such excuse 
though.

> Generally having system calls that don't operate on file 
> descriptor genericly (that doesn't mean implemented everywhere, 
> but beeing a generic concept dispatched through file operations) 
> is pretty ugly. We have a lot of them anyway, e.g. the socket 
> system calls, eventfd, inotify.  They don't really buy us anything 
> over ioctls, but they are accepted.  So if you design a clean 
> system call working on perfcounters file descriptor no one could 
> have hard objection (as in actually saying no).  But if you really 
> just do another stupid muliplexer just go for ioctl instead of 
> reinventing the dispatching and multiplexing.

Well, but that's what we have for perfcounters really: there's a 
clean system call plus an ioctl that multiplexes very simple 
IO-alike ops. (which borderline passes as an 'IO control' as well)

I'm trying to figure out where the boundary is - how long should we 
extend the ioctls and when should we start shuffling that 
functionality into new system calls (cleanly designed and done of 
course).

	Ingo