[alsa-devel] Moving sound/* to drivers/ ?
While we are at the issue ALSA HG <-> GIT transition...
One thing that annoys me sometimes is that the sound driver codes are on a different subdirectory than other normal drivers, namely under /sound. I don't remember exactly why it came there, but this often makes people forget to change the necessary code for the sound subsystem, or slip from the statistics (I'm not sure whether Linus counted sound/* with recent his posts).
If I understand correctly, with git, we can move the files in relatively little costs. So, what about moving sound/* back to drivers/sound/* or drivers/media/sound/*?
Of course, the primary question is whether it's really worth. The obvious drawback is that patches won't be applicable after the move. So, if we do it, doing at the last seems practical. But, this can be a bit problem with keeping such a change on linux-next until the next merge...
And, another question is to where. drivers/sound or drivers/media/sound, or whatever.
Any comments appreciated.
thanks,
Takashi
On Wed, 21 May 2008, Takashi Iwai wrote:
One thing that annoys me sometimes is that the sound driver codes are on a different subdirectory than other normal drivers, namely under /sound.
I would certainly personally like drivers/sound more, and the placement at the top level is actually because the sound maintainers wanted it that way, probably to avoid the confusion with the old OSS drivers that used to live in drivers/sound.
I forget the exact details. It's been many many years, and there may have been some real technical issues too. But basically sound/ was created when ALSA was first merged, and we had a lot of renames from drivers/sound/xyz to sound/oss/xyz.
(It may have been that it was simply easier to have a new subdirectory than it was to re-use the old one. In fact, with BK and patches, that was generally the best way to guarantee that the rename-tool did the right thing, so details like that may have been part of it. I forget).
So I would personally certainly not mind somebody doing a
git mv sound drivers/sound .. edit makefiles and Kconfig files appropriately .. git commit -a
and it wouldn't be a problem for git (ie the repository wouldn't grow or anything like that).
And doing pure renames (and not editing up a lot of actual files) would make rename detection easy for subsequent merges. The only real pain of renames is the efficiency of detection when you have lots and lots of files, but if the SHA1 of the file stays the same for the big bulk of them, that makes the problem basically go away (it becomes a much more interesting problem when you move hundreds of files around and _also_ edit the bulk of them - even if the edits are trivial, now you need to actually look at the contents to figure out the renames).
If I understand correctly, with git, we can move the files in relatively little costs. So, what about moving sound/* back to drivers/sound/* or drivers/media/sound/*?
I'd personally prefer just drivers/sound - no point in making it any deeper than that.
But I'd not be much affected myself, so I don't much care. I do agree that it would fit better under drivers/, but it's really mostly up to you guys.
Of course, the primary question is whether it's really worth. The obvious drawback is that patches won't be applicable after the move.
Well, git merging is actually pretty good at this, so you can apply the patches to the old release and then merge it, and it will do the right thing (perhaps not for newly created files, but that's pretty easy to fix up).
Also, even if you keep it as patches, as long as you move the whole subdirectory, then fixing up the patch is just a trivial search-and-replace, so I doubt it would be a big issue.
But it's really up to you guys.
Me personally, I've been more irritated by include/asm-xyz vs arch/xyz. It would be so nice if all the arch-specific changes woudl always show up under arch/ (both from a statistics standpoint, and just because then a diffstat really shows arch-specific stuff really obviously, and sorts all the arch-specific stuff together).
Linus
Me personally, I've been more irritated by include/asm-xyz vs arch/xyz. It would be so nice if all the arch-specific changes woudl always show up under arch/ (both from a statistics standpoint, and just because then a diffstat really shows arch-specific stuff really obviously, and sorts all the arch-specific stuff together).
Something like: include/asm-$ARCH/ => arch/$ARCH/include/asm/* ?
I can cook up something simple so kbuild will try both so we can move the archs that do symlinks later than the rest.
I really like to keep the 'asm' directory so we can kill the asm symlink.
Sam
On 21-05-08 23:44, Linus Torvalds wrote:
So I would personally certainly not mind somebody doing a
git mv sound drivers/sound .. edit makefiles and Kconfig files appropriately .. git commit -a
and it wouldn't be a problem for git (ie the repository wouldn't grow or anything like that).
I'd personally like the net/ structure more. So subsystem code under sound/ and drivers moved to drivers/sound/.
Of course, the primary question is whether it's really worth. The obvious drawback is that patches won't be applicable after the move.
Well, git merging is actually pretty good at this, so you can apply the patches to the old release and then merge it, and it will do the right thing (perhaps not for newly created files, but that's pretty easy to fix up).
And a few symlinks will do wonders as well. I do/did that when I "port" patches developped against mainline to the alsa-kernel HG repo. Not a problem that way. Apply and rediff to get the new paths.
Me personally, I've been more irritated by include/asm-xyz vs arch/xyz. It would be so nice if all the arch-specific changes woudl always show up under arch/ (both from a statistics standpoint, and just because then a diffstat really shows arch-specific stuff really obviously, and sorts all the arch-specific stuff together).
And one would not forget to add the include directory to a "git log" or "git bisect" path specification...
Rene.
On 21-05-08 23:58, Rene Herman wrote:
On 21-05-08 23:44, Linus Torvalds wrote:
So I would personally certainly not mind somebody doing a git mv sound drivers/sound .. edit makefiles and Kconfig files appropriately .. git commit -a
and it wouldn't be a problem for git (ie the repository wouldn't grow or anything like that).
I'd personally like the net/ structure more. So subsystem code under sound/ and drivers moved to drivers/sound/.
Suggestion for sound/drivers: drivers/sound/generic :-)
Rene.
On Wed, May 21, 2008 at 11:20:50PM +0200, Takashi Iwai wrote:
While we are at the issue ALSA HG <-> GIT transition...
One thing that annoys me sometimes is that the sound driver codes are on a different subdirectory than other normal drivers, namely under /sound. I don't remember exactly why it came there, but this often makes people forget to change the necessary code for the sound subsystem, or slip from the statistics (I'm not sure whether Linus counted sound/* with recent his posts).
If I understand correctly, with git, we can move the files in relatively little costs. So, what about moving sound/* back to drivers/sound/* or drivers/media/sound/*?
Sounds good.
Of course, the primary question is whether it's really worth. The obvious drawback is that patches won't be applicable after the move. So, if we do it, doing at the last seems practical. But, this can be a bit problem with keeping such a change on linux-next until the next merge...
And, another question is to where. drivers/sound or drivers/media/sound, or whatever.
Under drivers/media/ it would only generate confusion regarding who's responsible for what.
But drivers/sound/ sounds good.
The only possible problem that comes into my mind is to check what happens with the link order.
Any comments appreciated.
thanks,
Takashi
cu Adrian
At Thu, 22 May 2008 01:23:57 +0300, Adrian Bunk wrote:
The only possible problem that comes into my mind is to check what happens with the link order.
Yes, it's also my slight concern, too. I vaguely remember a bug related with the link order of the sound... But, it's certainly fixable.
thanks,
Takashi
Takashi Iwai wrote:
While we are at the issue ALSA HG <-> GIT transition...
One thing that annoys me sometimes is that the sound driver codes are on a different subdirectory than other normal drivers, namely under /sound. I don't remember exactly why it came there, but this often makes people forget to change the necessary code for the sound subsystem, or slip from the statistics (I'm not sure whether Linus counted sound/* with recent his posts).
If I understand correctly, with git, we can move the files in relatively little costs. So, what about moving sound/* back to drivers/sound/* or drivers/media/sound/*?
Of course, the primary question is whether it's really worth. The obvious drawback is that patches won't be applicable after the move. So, if we do it, doing at the last seems practical. But, this can be a bit problem with keeping such a change on linux-next until the next merge...
And, another question is to where. drivers/sound or drivers/media/sound, or whatever.
Speaking as a former OSS driver maintainer, I always preferred drivers/sound.
Though Rene's suggestion (use both sound/ and drivers/sound/) might make sense if the subsystem code is huge -- I supported the drivers/block/ -> block/ code movement for example.
Jeff
On 22-05-08 01:37, Jeff Garzik wrote:
Speaking as a former OSS driver maintainer, I always preferred drivers/sound.
Though Rene's suggestion (use both sound/ and drivers/sound/) might make sense if the subsystem code is huge -- I supported the drivers/block/ -> block/ code movement for example.
Well, not _huge_ but ALSA is very much structured like that; large middle layer with "miniport" drivers (I do by the way expect this was also Takashi plan originally due to him using sound/* and not just "sound/"; that is, I took the * to be shorthand for isa, pci, usb and so on)
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.
Rene.
On Thu, 22 May 2008, Rene Herman wrote:
On 22-05-08 01:37, Jeff Garzik wrote:
Speaking as a former OSS driver maintainer, I always preferred drivers/sound.
Though Rene's suggestion (use both sound/ and drivers/sound/) might make sense if the subsystem code is huge -- I supported the drivers/block/ -> block/ code movement for example.
Well, not _huge_ but ALSA is very much structured like that; large middle layer with "miniport" drivers (I do by the way expect this was also Takashi plan originally due to him using sound/* and not just "sound/"; that is, I took the * to be shorthand for isa, pci, usb and so on)
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.
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...
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Thu, May 22, 2008 at 08:26:39AM +0200, Jaroslav Kysela wrote:
On Thu, 22 May 2008, Rene Herman wrote:
On 22-05-08 01:37, Jeff Garzik wrote:
Speaking as a former OSS driver maintainer, I always preferred drivers/sound.
Though Rene's suggestion (use both sound/ and drivers/sound/) might make sense if the subsystem code is huge -- I supported the drivers/block/ -> block/ code movement for example.
Well, not _huge_ but ALSA is very much structured like that; large middle layer with "miniport" drivers (I do by the way expect this was also Takashi plan originally due to him using sound/* and not just "sound/"; that is, I took the * to be shorthand for isa, pci, usb and so on)
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).
That out-of-tree stuff could mirror the kernel directory layout - no? Then you could have both drivers/ and sound/ in that tree.
We should try to opimize the kernel directory layout to fit the kernel best and then adapt the out-of-tree stuff to the kernel (IMHO).
Sam
On Thu, 22 May 2008, Sam Ravnborg wrote:
On Thu, May 22, 2008 at 08:26:39AM +0200, Jaroslav Kysela wrote:
On Thu, 22 May 2008, Rene Herman wrote:
On 22-05-08 01:37, Jeff Garzik wrote:
Speaking as a former OSS driver maintainer, I always preferred drivers/sound.
Though Rene's suggestion (use both sound/ and drivers/sound/) might make sense if the subsystem code is huge -- I supported the drivers/block/ -> block/ code movement for example.
Well, not _huge_ but ALSA is very much structured like that; large middle layer with "miniport" drivers (I do by the way expect this was also Takashi plan originally due to him using sound/* and not just "sound/"; that is, I took the * to be shorthand for isa, pci, usb and so on)
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).
That out-of-tree stuff could mirror the kernel directory layout - no? Then you could have both drivers/ and sound/ in that tree.
We already translate Documentation/sound/alsa/ to Documentation/ and include/sound/ to include/ directories in our mirror tree. So adding one more exception is not a big deal.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
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.
At Thu, 22 May 2008 01:53:06 +0200, Rene Herman wrote:
On 22-05-08 01:37, Jeff Garzik wrote:
Speaking as a former OSS driver maintainer, I always preferred drivers/sound.
Though Rene's suggestion (use both sound/ and drivers/sound/) might make sense if the subsystem code is huge -- I supported the drivers/block/ -> block/ code movement for example.
Well, not _huge_ but ALSA is very much structured like that; large middle layer with "miniport" drivers (I do by the way expect this was also Takashi plan originally due to him using sound/* and not just "sound/"; that is, I took the * to be shorthand for isa, pci, usb and so on)
Well, no, I originally thought moving all $LINUX/sound to $LINUX/drivers/sound. The sound core stuff is already in sound/core, so it can be peacefully in drivers/sound/core, just like other drivers like USB, V4L, etc.
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.
I think it's a question of the balance. The net stuff is huge, 10 times more codes than the sound core.
An argument for keeping the sound core in /sound is that this is used not only by sound drivers but also by some video drivers.
Takashi
On Thursday 2008-05-22 10:27, Takashi Iwai wrote:
Speaking as a former OSS driver maintainer, I always preferred drivers/sound.
Though Rene's suggestion (use both sound/ and drivers/sound/) might make sense if the subsystem code is huge -- I supported the drivers/block/ -> block/ code movement for example.
Well, not _huge_ but ALSA is very much structured like that; large middle layer with "miniport" drivers (I do by the way expect this was also Takashi plan originally due to him using sound/* and not just "sound/"; that is, I took the * to be shorthand for isa, pci, usb and so on)
Well, no, I originally thought moving all $LINUX/sound to $LINUX/drivers/sound. The sound core stuff is already in sound/core, so it can be peacefully in drivers/sound/core, just like other drivers like USB, V4L, etc.
I am in favor of keeping /sound around with the non-hardware-dependent code, much like /block does with regard to /drivers/block.
So that's /sound for PCM/mixer etc. and /drivers/sound with the actual driver parts like cs46xx.
Just like:
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.
I think it's a question of the balance. The net stuff is huge, 10 times more codes than the sound core.
An argument for keeping the sound core in /sound is that this is used not only by sound drivers but also by some video drivers.
PS. But then again, I could also imagine /block (core) /block/drivers (drivers) /net (core) /net/drivers /sound /sound/drivers And the sound parts are already mostly there.
On Thu, 22 May 2008, Jan Engelhardt wrote:
I am in favor of keeping /sound around with the non-hardware-dependent code, much like /block does with regard to /drivers/block.
I'd personally *much* rather have just one subdirectory.
I realize that block/ and drivers/block/ (and net/ vs drivers/net/) has come up several times as an example that isn't that way, BUT:
- that's actually the odd man out. It's more common to do it the other way (and examples have already been given: drivers/usb/core, just plain drivers/base, drivers/scsi/ (where it's all mixed up and a lot of low-level drivers are in subdirectories of their own), etc etc.
- perhaps more importantly, it's totally different from 'sound' in that the block/ and drivers/block/ maintainership is actually *separate*.
The same is actually true of net/ and drivers/net/ too. It so happens that within the last few months, drivers/net/ gets merged through the same maintainer as net/, but they really end up being maintained separately other than that.
So the block/ and net/ layers have very much a higher level of separation from their drivers. sound has always been very much _maintained_ as a block, even if it then internally may be separate pieces. Partly this is from historical reasons, I'm sure, but it's true none-the-less.
So from an outside view, having a single subdirectory makes sense, because that's how it has always been maintained.
So I'd personally much rather see just one drivers/sound/ than have this split up.
Linus
On Thursday 2008-05-22 17:04, Linus Torvalds wrote:
On Thu, 22 May 2008, Jan Engelhardt wrote:
I am in favor of keeping /sound around with the non-hardware-dependent code, much like /block does with regard to /drivers/block.
I'd personally *much* rather have just one subdirectory. [...] BUT:
- perhaps more importantly, it's totally different from 'sound' in that the block/ and drivers/block/ maintainership is actually *separate*.
[...] So I'd personally much rather see just one drivers/sound/ than have this split up.
Surveille et rapport.
I took a look at how FreeBSD does this, just for comparison. They have a single ${src}/dev/sound, but also no split "net" otoh afaics. As always, if you think Linux should have a drivers/sound/, just direct your lieutenants to do so.
On 22-05-08 17:04, Linus Torvalds wrote:
On Thu, 22 May 2008, Jan Engelhardt wrote:
I am in favor of keeping /sound around with the non-hardware-dependent code, much like /block does with regard to /drivers/block.
I'd personally *much* rather have just one subdirectory.
Then I'd agree/suggest ALSA move to drivers/sound. I brought it up but both Jaroslav and Takashi agree with you. For me it was more a "nicely reflects the design of things" issue than anything else...
I do agree that the drivers are better of in drivers/ and they are 10 times the size of the sound core.
Rene.
On 22-05-08 10:27, Takashi Iwai wrote:
At Thu, 22 May 2008 01:53:06 +0200, Rene Herman wrote:
Well, not _huge_ but ALSA is very much structured like that; large middle layer with "miniport" drivers (I do by the way expect this was also Takashi plan originally due to him using sound/* and not just "sound/"; that is, I took the * to be shorthand for isa, pci, usb and so on)
Well, no, I originally thought moving all $LINUX/sound to $LINUX/drivers/sound.
Oh okay, misinterpreted that.
This "net model" of sound/ and drivers/sound/ would be cleanest I feel.
I think it's a question of the balance. The net stuff is huge, 10 times more codes than the sound core.
Indeed, but then again, block/ is 3 times as small. Don't actually know what the rationale was for that one but I'd expect some of the same reasons for that split to apply here.
Yes, there's more non driver work under drivers already but this might be something to try to minimise. Drivers are really sort of special in their nicely defined and limited impact and statistics such as the percentage of updates that are in drivers are used in that way.
An argument for keeping the sound core in /sound is that this is used not only by sound drivers but also by some video drivers.
Mm, right. In a sense the snd-pcsp thing might be an argument even. There really wants to be one driver for the PC speaker which doesn't want to live in (drivers/)sound/ due to it being generic hardware but which does want to use sound/ to pretend it is.
In that sense, the sound core is shared infrastructure...
Rene.
On Thu, May 22, 2008 at 10:27:55AM +0200, Takashi Iwai wrote:
At Thu, 22 May 2008 01:53:06 +0200, Rene Herman wrote: ... An argument for keeping the sound core in /sound is that this is used not only by sound drivers but also by some video drivers.
Same goes for e.g. some of the USB or PCI code.
We could start splitting stuff like crazy, but what would we really gain by doing it?
Takashi
cu Adrian
participants (9)
-
Adrian Bunk -
Jan Engelhardt -
Jaroslav Kysela -
Jeff Garzik -
Linus Torvalds -
Rene Herman -
Sam Ravnborg -
Takashi Iwai -
Timur Tabi