Re: [2.6 patch] schedule obsolete OSS drivers for removal

[Marcin Dalecki <martin@dalecki.de>]

On 2006-01-06, at 21:26, Jaroslav Kysela wrote:
> I got the point, but the audio is very specific that it requires  
> realtime
> scheduling. Even graphics is not so tied with realtime, because a
> scheduling gap does not end with error or very ugly misbehaviour  
> (pops)
> like in audio.

Nonsense. You just got too used to utterly bad behavior imposed by  
the inherently defective
X11 graphics system. Like stuttering mouse movements. Like race  
conditions between popup menus
and background menus and so on and so forth... Hick-ups when suddenly  
the system starts to do some paging...
More staggering examples simply don't occur that obviously in praxis  
because the interface
designers refrain from using some effects like subtly animated icon  
change and menu animations
redrawing. But it's by no way an argument which could be used to  
justify the deficiency of
some audio system. And BTW. A proper user interface system requires  
synchronization between
audio and video.

So there you are - all over the pill - soft real time requirements.  
Actually not that soft at all.
It always surprises me how efficient and demanding the perceptive  
system of a hunter and
gatherer is, which only just recently got the sudden idea that it may  
be nice to spend
his time in front of an engine generating animated images.

> > At least OSS, with all its flaws, is a documented kernel interface.
> > You can static link a oss-using program, whether it uses it directly
> > or through interfaces like sdl-audio, and it will just work.
>
> Please, see your words. You're simply anarchistic. You replaced
> flexibility of dynamic library with a possibility to have static  
> binary.

> Also note, that if OSS had the API in userspace from the first days,
> the emulation or redirection of this API to another API or user space
> drivers wouldn't be so much complicated nowadays. Bummer.

You simply don't get it. On unix like systems the definitive  
interface level is not
a library. It's the system call. Libraries can be helpful as a means  
to make some common
actions a tad bit easier. However even so simple things like state- 
full behavior there
is a complete no go. Get over it. Libraries are just too affine to
compiler releases particular programming languages and many other  
side conditions.
Do your homework and take a serious look at other operating systems  
to see how "fine" the
APIs defined by DLLs (ups) are. As an exercise ask yourself why on  
earth it takes
usually about 2 or 4 times longer to write a windows driver.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/