On Tue, Sep 23, 2008 at 02:21:26PM +0200, Lennart Poettering wrote:
> Oh my. So you know someone who thinks that ioctl()s are ingenious API
> design? You probably should choose your friends more carefully, then. ;-)

ALSA's kernel interface is 100% ioctl. It doesn't even use read() or
write().

OG.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, 23.09.08 14:26, Olivier Galibert (galibert@pobox.com) wrote:

>
> On Tue, Sep 23, 2008 at 02:21:26PM +0200, Lennart Poettering wrote:
> > Oh my. So you know someone who thinks that ioctl()s are ingenious API
> > design? You probably should choose your friends more carefully, then. ;-)
>
> ALSA's kernel interface is 100% ioctl. It doesn't even use read() or
> write().

I know. But ALSA hides that in a library, so you never have to deal
with these ugly details. Ain't that great?

OTOH OSS' programmers interface *is* the ioctls themselves. And that's
one reason why its API sucks.

Also, OSS is practically not virtualizable. (LD_PRELOAD and CUSE are
hacks, that only work for the smallest part) The timing model is
broken. The entire design is hardware-specific, and focusses on hw we
had 20 years ago.

OSS as an API is terrible.

Lennart

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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.


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Lennart Poettering wrote:

On Tue, 23.09.08 10:54, Dominik 'Rathann' Mierzejewski (dominik@greysector.net) wrote:


Do you mean Open Source Software or Open Sound System? In case of OSS,
it's realy a shame, because it was (and still is) a great piece of software
with nice API and doesn't require any external libraries like ALSA.
But you can't compare console/X to OSS/ALSA. The latter provide functionality

I must correct you: the OSS API sucks. And ALSA is certainly a far
greater piece of software than OSS ever was, and among the reasons is
precisely the fact that it is a proper library instead of some fucked up kernel
interface based on ioctls().

Everyone hates ioctl()s. The kernel people do. The userspace people
too. An API for application usage that is based around ioctl()s is
thus mandatorily a big failure.

The people whose opinion I value disagree. I have no strong opinion
of my own, because I never wrote code to interface with either ALSA
or OSS.


Oh my. So you know someone who thinks that ioctl()s are ingenious API
design? You probably should choose your friends more carefully, then. ;-)


They are nicely minimalistic in that they permit device-specific
operations to be passed to a driver without waiting for some
overly-bulky generalized intermediate API that thinks it knows what
every device/driver might ever need to do. The down side is that it is
very hard to subsequently decouple the application from the device - for
example to let it use a remote device on a machine with different
bit/byte ordering.


--
Les Mikesell
lesmikesell@gmail.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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

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.





--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, 23.09.08 15:02, Ralf Corsepius (rc040203@freenet.de) wrote:

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

Yepp! That's exactly what I was saying: OSS as an application
programmers interface is a trainwreck because it directly exposes
ioctls.

ioctl as an API for normal programs == bad!

When ioctls are hidden to normal programs like ALSA does it == acceptable!

Lennart

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, Sep 23, 2008 at 02:37:48PM +0200, Lennart Poettering wrote:
> OTOH OSS' programmers interface *is* the ioctls themselves. And that's
> one reason why its API sucks.

Thats a 'nobody wrote the library' case

> Also, OSS is practically not virtualizable. (LD_PRELOAD and CUSE are
> hacks, that only work for the smallest part) The timing model is
> broken. The entire design is hardware-specific, and focusses on hw we

The timing model is crap, but the rest of the design is neither hardware
specific no focussed on twenty year old hardware - in fact todays hardware
looks more and more like the hardware of twenty years ago but with more
channels.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, 23.09.08 09:26, Alan Cox (alan@redhat.com) wrote:

>
> On Tue, Sep 23, 2008 at 02:37:48PM +0200, Lennart Poettering wrote:
> > OTOH OSS' programmers interface *is* the ioctls themselves. And that's
> > one reason why its API sucks.
>
> Thats a 'nobody wrote the library' case

No it's not. The people behind OSS (i.e. Hannu) advertise the kernel
API is the audio API to use for normal programs. Because they do this
they moved mixing and sample type conversion into the kernel in OSS4.

> > Also, OSS is practically not virtualizable. (LD_PRELOAD and CUSE are
> > hacks, that only work for the smallest part) The timing model is
> > broken. The entire design is hardware-specific, and focusses on hw we
>
> The timing model is crap, but the rest of the design is neither hardware
> specific no focussed on twenty year old hardware - in fact todays hardware
> looks more and more like the hardware of twenty years ago but with more
> channels.

Oh, of course it is hardware specific. Stuff like fragments and stuff
are very hardware specific. Software sound servers don't want to
expose fragment-based buffering metrics. Instead a modern sound system
wants to expose latency values and process time values. Then, the fact
that OSS assumes that the DAC reads directly from the hw playback
buffer makes the whole thing questionable already on USB
hardware. That you even get access to the hardware buffer makes it
very hardware-specific. Using OSS for more than 2ch sensibly is
practically not possible. Modern sound systems want to disable sound
card interrupts as far as possible and schedule audio via system
timers, OSS always wants fragment interrupts. Modern sound systems
want huge buffers and the ability to rewind software pointers. OSS
cannot do this (at most partially if you use mmap() which opens a lot
of additional problems and is shaky ground). No decibel information
for mixers. Then, the way fragments work in OSS you couldn't even
express something like "buffer size 200ms, fillup when only 10ms
left". And this list goes on and on.

In short: how modern software wants to drive a sound card has changed
quite a bit. And OSS3 is from the early 90's. So it's focussed on
hardware, and it is focussed on hw and sw from 20y ago. An SB16 is
quite different from a modern HDA sound card.

Lennart

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, Sep 23, 2008 at 04:01:10PM +0200, Lennart Poettering wrote:
> > Thats a 'nobody wrote the library' case
>
> No it's not. The people behind OSS (i.e. Hannu) advertise the kernel
> API is the audio API to use for normal programs. Because they do this
> they moved mixing and sample type conversion into the kernel in OSS4.

Please don't confuse Hannu's later stuff with what the kernel community
accepted.

> In short: how modern software wants to drive a sound card has changed
> quite a bit. And OSS3 is from the early 90's. So it's focussed on
> hardware, and it is focussed on hw and sw from 20y ago. An SB16 is
> quite different from a modern HDA sound card.

Not vastly, its a DMA pipe with a DAC on the end

Alan

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list