On Mon, 27 Feb 2006, Greg KH wrote:
> On Mon, Feb 27, 2006 at 02:36:54PM -0500, Benjamin LaHaise wrote:
> > On Mon, Feb 27, 2006 at 11:01:50AM -0800, Greg KH wrote:
> > > --- /dev/null
> > > +++ gregkh-2.6/Documentation/ABI/private/alsa
> > > @@ -0,0 +1,8 @@
> > > +What: Kernel Sound interface
> > > +Date: Feburary 2006
> > > +Who: Jaroslav Kysela <[email protected]>
> > > +Description:
> > > + The use of the kernel sound interface must be done
> > > + through the ALSA library. For more details on this,
> > > + please see http://www.alsa-project.org/ and contact
> > > + <[email protected]>
> >
> > How can something as widely used as sound not work from one kernel version
> > to the next, as seems to be implied with the "private" nature of the ABI?
> > This is a total cop-out and is IMHO very amateur of the developers. If
> > something like this is to be the case, at the very least the alsa libraries
> > need to provide a stable ABI and be shipped with the kernel.
>
> Then I suggest you work with the ALSA developers to come up with such a
> "stable" api that never changes. They have been working at this for a
> number of years, if it was a "simple" problem, it would have been done
> already...
I really don't much like the "private" and "unstable" subdirectories.
They seem to be just excuses for bad habits. And the notion of a "private"
interface is insane anyway, since it doesn't matter - the only thing that
matters is whether it breaks existing binaries or not, and being "private"
in no way makes any difference to that. If you need to compile or link
against a new library, it's broken - whether it was "private" or not makes
no difference.
The ALSA development model is in my opinion pretty broken (the development
seems to try to be pretty closed-up), but it's (a) gotten better and (b)
the alsa people do not seem to be breaking old binaries and libraries very
much. At least I don't remember seeing all that many problems lately.
So I just don't see any upsides to documenting anything private or
unstable. I see only downsides: it's an excuse to hide behind for
developers.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
