Subject: Re: [linux-audio-dev] Still I cannot understand why...
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue Dec 18 2001 - 03:48:27 EET
>> The only good thing, to me, about "other unices" is that
>> apple had a choice and chose BSD.
>
>Compatibility/portability (read: standards) is the main reason why Linux
>became what it is today. _Do_not_ break this or Linux will lose...
Linux's POSIX compatibility is weak in all kinds of areas. There are
dozens of examples of how POSIX conformant code will not work under
Linux, and just as many of subtle uses of Linux behaviour that, while
conforming to the POSIX API, will not work on other POSIX platforms.
Linux got where it is today by being close enough to the standard that
porting was easy *enough*, plus 100% open so we could read (and fix)
anything even if AT&T didn't bless us.
>Btw. OSS follows the original unix idea and POSIX rule of "everything is a
>file" very well. It works with open()/read()/write()/close() as the other
>devices do. And it's controlled via ioctl() as it should.
Unless you want to put the sound drivers into glibc, or you use a
POSIX variant where open/read/write/close/ioctl can be handed off to
user-space daemons, using open/read/write/close/ioctl *requires* that
100% of an audio API be in the kernel. This is a ridiculous design
decision, for many reasons. SGI don't do it on IRIX. BeOS didn't do
it. Mac OS X doesn't do it. Windows doesn't do it. Can you guess why?
I won't go into the entire callback-related issues that have been
illustrated elsewhere in this thread.
>Windows is good example of total API mess where there is different API for
>all the different twinkles, different error codes, etc.
At least in Windows you can enter single thread blocking routine to
wait for any kind of event (file descriptor ready, semaphore, message,
signal). Under POSIX you can't do this, and you have to use a separate
thread for every type of event. How's that for unified API?
--p [ jeez: he got me defending windows! time to die? ]
This archive was generated by hypermail 2b28 : Tue Dec 18 2001 - 03:43:38 EET