lkml.org 
[lkml]   [1999]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Migrating to larger numbers
Date
In article <linux.kernel.E10rVMK-0008AR-00@the-village.bc.nu>,
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> > This has led to the current mess with your choice of ESD, OSS, and
>> > ALSALIB as the sound API. If applications had used the theoretical
>> > libsound.so from the start, there wouldn't be this problem.
>>
>> I'm not advocating a kernel-based gpm, but it seems to me that the
>> problem you mention with sound is due to the device semantics. The
>> kernel doesn't impose single-open rules. That's a fault of the driver.
>
>Its nothing to do with open rules (and they do impose single open btw).
>The point is that using a library means you can rip up the underlying code
>freely kernel or otherwise, including changing the kernel API.

Except doing that is A Bad Thing, because if you change the kernel
interface out from under the library the old libraries won't work.
There are certainly times when you have to change the kernel
interfaces (fixing time_t, widening out uid/gids, etc) but, even
if all of the user programs go in through libfoo.a, it's something
that should be done with the knowledge that it's going to throw
many spanners into the works for everyone.

____
david parsons \bi/ not that library interfaces are particular gems of
\/ stability either.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.043 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site