[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Pulseaudio : lots of issues, how can I help?



On Tue, 23.09.08 14:38, Ralf Corsepius (rc040203 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 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.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]