lkml.org 
[lkml]   [2009]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ioctls vs syscalls once again

* 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


\
 
 \ /
  Last update: 2009-08-21 22:39    [W:0.292 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site