[alsa-devel] HG vs GIT

Tobin Davis tdavis at dsl-only.net
Fri Feb 8 02:09:05 CET 2008


On Fri, 2008-02-08 at 00:42 +0000, Mark Brown wrote:

> On Thu, Feb 07, 2008 at 09:36:15PM +0100, Takashi Iwai wrote:
> > Mark Brown wrote:
> 
> > > 	make M=${PWD} -C /lib/modules/$(uname -r)/build
> 
> > The external build itself is relatively easy.  We have already such
> > stuff in alsa-driver tree.  Just needs a slight change to remap the
> > directories properly in linux kernel tree instead of alsa-kernel
> > tree.
> 
> > What I mentioned is to merge changesets properly from one tree to
> > another old tree.  Maybe a kind of cherry picking would do that.
> 
> The thing I was thinking of above was taking a vanilla kernel tree and
> building a subdirectory of that as though it were out of tree.  This
> lets you use a vanilla git tree with the headers and config of a second
> kernel tree (eg, a distro supplied one), meaning that from a revision
> control point of view there's nothing fancy going on.


One problem with this approach is insuring that you get the current alsa
headers.  If these were kept in the alsa-driver tree, it might be more
manageable.   The alsa-driver tree is specifically for doing out-of-tree
builds, and includes workarounds for older kernels that would be missed
otherwise.

One reason for building against older distro kernels is that
corporations may continuously roll out new hardware on older distro's.
They need to be able to back port some drivers for hardware
compatibility without breaking their image.  Where I work, the corporate
IT image is Suse 9.3 based (ancient in Linux terms).  I believe it came
with alsa 1.0.6 or 1.0.7.  Won't work on the newer HD Audio hardware,
guaranteed.

My current work involves multiple spins of Ubuntu, RedFlag, and to a
small degree Fedora.  This is where the out-of-tree environment really
works well.


-- 
Tobin Davis 

My opinions always matter :-)

	- Dan Malek on the linuxppc-embedded list


More information about the Alsa-devel mailing list