linux-kernel - ioctls vs syscalls once again

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 21 Aug 2009 14:18:23 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: ioctls vs syscalls once again

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/