ioctls vs syscalls once again

[Christoph Hellwig <hch@infradead.org>]

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

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

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

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

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.