Re: [Bluez-devel] snd-bt-sco development teamup...

[Marcel Holtmann <marcel@holtmann.org>]

Hi James,

> > the point is in writing an ALSA driver and not changing the ALSA
> > subsystem. The SCO driver is part of the Bluetooth subsystem and so it
> > will go in by me. The ALSA subsystem provides an in-kernel API and that
> > can be used without any acknowledge of the ALSA maintainer.
> 
> ALSA is very modularised. This separates the hardware specific driver 
> stuff from the more general alsa kernel code. So, if you write your own 
> ALSA driver hardware module, it will have to depend on other ALSA 
> modules. The only ALSA API that is going to be stable is the user land 
> alsa-lib, which talks to applications. Although the ALSA kernel API and 
> ALSA low level hardware driver API has not changed in some time, the 
> ALSA maintainer reserves the right to change it at any time without 
> having to warn people, as alsa-lib hides all the changes from users.
> It is therefore a good idea to place any ALSA specific code in the ALSA 
> tree, so that the ALSA maintainers keep it's kernel API up to date.
> This would then leave the BlueZ team to only have to worry about the 
> ALSA to BlueZ API.

you don't get my point. The ALSA code in the kernel is the base and if I
want to use that API I don't have to ask anyone for inclusion. The ALSA
subsystem is part of the Linux kernel and so they must take of that
every component is working with their changes. This has nothing to do
with their CVS, because as I said, the kernel counts.

Regards

Marcel




-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel