On Tue, 2008-09-23 at 14:47 +0200, Lennart Poettering wrote:
On Tue, 23.09.08 14:38, Ralf Corsepius (rc040203(a)freenet.de) wrote:
>
> On Tue, 2008-09-23 at 14:21 +0200, Lennart Poettering wrote:
> > On Tue, 23.09.08 10:54, Dominik 'Rathann' Mierzejewski
(dominik(a)greysector.net) wrote:
>
> > Oh my. So you know someone who thinks that ioctl()s are ingenious API
> > design?
> What do ioctls and files/stream not provide that you are missing?
>
> ioctls essentially are "descriptor"/"tag"/"arbitrary
argument".
> An interface can hardly be more generic than this.
Yes, and the fact that it is that generic is the weakness.
You know, we have this wonderful language called C. It's all about
tape-safety and having nice names for things and having proper
signatures for functions and being descriptive. ioctl()s go against
all that. They are not type-safe, have unreadable names, have no
signatures and are everthing but descriptive.
Let's say every single libc call would have been mutlipexed by a
single function call. i.e. instead of calling malloc() like this:
a = malloc(4711);
you'd call:
a = (void*) libc(LC_MLLC, 4711);
Now think of hwo your program would look like in its entirety:
unreadable. Absolutely crazy and unreadable.
Now ioctl() does exactly this: a vast number of function calls are
multiplexed via a single function call. Big fuckup. And everyone who
claims that that would be good API design is just wrong, really,
really wrong. It's not good. It's a fuckup. It's terrible.
And I tell you: You are wrong, plain wrong.
ioctl's are a well defined _low level_ interface, providing a clean and
"natural" separation between kernel and userspace.
To make them easily applicable in high-level userspace applications,
they are supposed to be wrapped.