Pulseaudio : lots of issues, how can I help?

[Ralf Corsepius]

On Tue, 2008-09-23 at 14:47 +0200, Lennart Poettering wrote:
> On Tue, 23.09.08 14:38, Ralf Corsepius (rc040203 at 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 at 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.