Re: Moving sound/* to drivers/ ?

From: Rene Herman
Date: Thu May 22 2008 - 04:09:38 EST


On 22-05-08 08:26, Jaroslav Kysela wrote:

On Thu, 22 May 2008, Rene Herman wrote:

From a structural view, the PCM core is just as much not a driver
as the IP protocol isn't one and moving all of sound/ to drivers/
would trade the current "why are the drivers not under drivers/?"
issue for a "why is all this non-driver code under drivers/?".

This "net model" of sound/ and drivers/sound/ would be cleanest I
feel.

Yes, it was one reason why I used 'sound/' as root of the ALSA tree.
The second reason was to move old OSS tree to new directory to make
less confusion. And the third reason was to just keep ALSA directory
same as in our local development tree (which is out-of-kernel tree -
containing only ALSA parts).

I feel that from the maintenance perspective, having one directory is
a plus. We have already 'drivers/usb/core', 'mmc/core',
'drivers/base' (ALSA toplevel and midlevel modules use functions from
this tree) etc.

Yes, examples of the same thing. drivers/base still sort of fits, but yes.

Would the maintenance be really helped? As you said in another reply, the external tree already shuffles Documentation/sound/alsa and include/sound around anyway.

I don't feel very strongly about it or anything but it's also a kernel statistics issue. Linus for example frequently announces new -rc's with "90% is in drivers" and such and if large(r) parts of drivers/ consist not of driver code that's a less useful metric.

If we have general consensus that sound drivers should go to back to 'drivers/sound' then I would move all code. We can move 'sound/core'
tree to '/sound' in next round later...

I'd expect that if you give up your nice top level directory you're not getting it back later... :-)

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