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
--

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




--

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.
--

At Thu, 22 May 2008 01:53:06 +0200,

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

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
--

Same goes for e.g. some of the USB or PCI code.

We could start splitting stuff like crazy, but what would we really 

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

--

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 

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.
--

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.



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.
--

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
--

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.
--

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.
--

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.

--

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 

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

Rene.
--

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
--

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.

--

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 

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

--

At Thu, 22 May 2008 01:23:57 +0300,

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
--

That gets my vote.

-- 
Timur Tabi
Linux kernel developer at Freescale
--

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 

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 

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 
...
[ message continues ]

We could git mv include/asm-xyz arch/xyz/asm and then arrange to pass
-Iarch/$(ARCH) to gcc.  The only downside is that "asm" is a slightly
strange name for a directory of include files, but I assume we don't
want to have to change all the #include <asm/blah.h> lines in all the
*.c files.

Paul.
--

That would work, but there's a few alternatives that I think would work 
even better.

The downside with what you suggest is that I'd like the arch-specific 
include files to be clearly separated (ie I think the naming should be 
"something/include/something", which makes things clearer. 

Also, I hate how doing '-Iarch/$(ARCH)' would basically make any random 
arch/xyz/ subdirectory be a potential location for a header file. I'd hate 
for the include-path to contain subdirectories that simply aren't meant 
for that (ie #include <kernel/tls.h> would now quite by mistake find the 
*private* header file in arch/x86/kernel/tls.h that was never meant to be 
generally visible!)

So the trivial alternative is to just do

	git mv include/asm-xyz arch/xyz/include

and keep the symlink that we already set up (just make it point to 
arch/xyz/include instead of include/asm-xyz). That is conceptually the 
smallest change.

But the alternative I'd actually *prefer* would avoid the symlink, and 
would be roughly:

	for i in $(arch-list)
	do
		mkdir arch/$i/include
		git mv include/asm-$i arch/$i/asm
		
	done
	git mv include/asm-generic include/asm

and then remove the symlink to asm entirely, and instead add a 
-Iarch/xyz/include, and put that as the *first* entry in the include path.

This would mean that:

 - no symlink games

 - if some architecture just uses the generic header file, it doesn't need 
   to do anything: it just wouldn't implement that header file at all, and 
   the next entry in the search-path would just find the generic 
   include/asm entry.

I dunno. It's not a huge deal, but it really would be nice to have all the 
arch/xyz code together for diffstat's etc.

		Linus
--

Nice, but... how do you pull what's currently asm-generic/foo.h from what's
currently asm-bar/foo.h?  #include_next is _ugly_...
--

I was actually going to suggest #include_next, yes. But if people hate it, 
we can certainly just keep the current <asm-generic/xyz.h> approach.

		Linus
--

Another alternative is to replace asm-generic/ with generic/asm and have
-I include -I arch/$ARCH/include -I include/generic. Then we'd have

linux/foo.h => include/linux/foo.h (one lookup)
asm/foo.h => arch/include/asm/foo.h if it exists (negative on include/asm,
                                                  then one lookup)
          => include/generic/asm/foo.h otherwise (negative on include/asm,
                                                  negative lookup,
                                                  lookup)
generic/asm/foo.h => include/generic/asm/foo.h   (one lookup)

No #include_next at all.  Kludgy, though...  Note that arch/um will need
more interesting treatment in any case and so may things like arch/arm
with its include/asm/arch symlink ;-/
--

Neither #include_next nor the generic/asm approach seems to have a
straightforward way of handling exported user space headers.
The current include/asm-generic way of doing this isn't nice either,
but at least it's a known evil.

Since the question of asm-generic is almost entirely independent of 
where the regular arch headers are, I'd vote for leaving asm-generic
alone for now and only doing the obvious move of all other headers to
arch/*/include/asm as a significant step in the right direction.
Nobody seemed to object that part so far, and the only significant
changes it needs are in sparc64, m68knommu and um as well as a few
scripts changes.

	Arnd <><
--

What about say, sparc64 that has a lot of #include <asm-sparc/foo.h>

Harvey

--

Ahh, I didn't realize people did that.

I assume (but am too lazy to check) that UML probably does something 
similar for its arch-specific stuff.

So yeah, it's probably more pain than it _should_ be, for reasons like 
that.

But I suspect that things like <asm-sparc/foo.h> may be because sparc64 
would actually like to add another -Iarch/sparc/include (until it 
eventually can get rid of the thing _entirely_, of course, as it gets 
unified under one architecture)

		Linus
--

Not quite - there's the include/asm-um/arch link, which points to
../asm-foo and a bunch of #include <asm/arch/foo.h>.  Same idea though.

			Jeff

-- 
Work email - jdike at linux dot intel dot com
--

It's a bit worse, though - there is target-dependent stuff in arch/um/include
*and* in include/asm-um; the latter is done in a very painful way - see
include/asm-um/module-i386.h and include/asm-um/module-x86_64.h, etc. and
logics that creates a symlink for each of those.

Is there any reason why module.h is not simply

#include <sysdep/module.h>

with these suckers sitting in arch/um/include/sysdep-{i386,x86_64}/ resp.?
Something like this:

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
 arch/um/Makefile                                   |   17 +----------------
 .../um/include/sysdep-i386/archparam.h             |    0 
 .../um/include/sysdep-i386/elf.h                   |    0 
 .../um/include/sysdep-i386/host_ldt.h              |    0 
 .../um/include/sysdep-i386/module.h                |    0 
 .../um/include/sysdep-i386/processor.h             |    2 +-
 .../um/include/sysdep-i386/ptrace-full.h           |    0 
 .../um/include/sysdep-i386/sigcontext-full.h       |    2 +-
 .../um/include/sysdep-i386/system.h                |    0 
 .../um/include/sysdep-i386/vm-flags.h              |    0 
 .../um/include/sysdep-ppc/archparam.h              |    0 
 .../elf-ppc.h => arch/um/include/sysdep-ppc/elf.h  |    0 
 .../um/include/sysdep-ppc/processor.h              |    0 
 .../um/include/sysdep-ppc/sigcontext-full.h        |    2 +-
 .../um/include/sysdep-ppc/system.h                 |    0 
 .../um/include/sysdep-x86_64/archparam.h           |    0 
 .../um/include/sysdep-x86_64/elf.h                 |    0 
 .../um/include/sysdep-x86_64/host_ldt.h            |    0 
 .../um/include/sysdep-x86_64/module.h              |    0 
 .../um/include/sysdep-x86_64/processor.h           |    0 
 .../um/include/sysdep-x86_64/ptrace-full.h         |    2 +-
 .../um/include/sysdep-x86_64/sigcontext-full.h     |    2 +-
 .../um/include/sysdep-x86_64/system.h              |    0 
 .../um/include/sysdep-x86_64/vm-flags.h            |    0 
 include/asm-um/elf.h     ...
[ message continues ]

If you create a structure along the following lines you can drop
the symlinks:

arch/um/include/{i386,x86_64}/sysdep/
The cost is a directory extra - but I assume we will find
more that fits the {i386,x86_64} folders

And then we just change KBUILD_CFLAGS -I ... depending on target.
All the dependency checks than "just works" and if arch changes
then all the proper files will get rebuild.

	Sam
--

My thinking was that include/asm-um is for stuff that's visible to the
rest of the kernel and arch/um/include is for UML-internal stuff.

Your patch does simplify things somewhat, though.

Would you consider a include/asm-um/$(ARCH) containing all the
foo-$(ARCH) headers to be worse than moving them to
arch/um/include/sysdep-$(ARCH)?

				Jeff

-- 
Work email - jdike at linux dot intel dot com
--

arch/um/include/*.h
arch/um/include/sysdep-<target>/*.h
include/asm-um/*.h

plus

arch/um/include/sysdep -> sysdep-<target>
and
include/asm-um/arch -> ../asm-<target>

Note that uml has two halves - kernel-side and userland-side.  The latter
is build with host search path, etc., with addition of arch/um/include.
The former is normal kernel code, with addition of arch/um/include again.
So some things in that sucker are for kernel-side and some - for userland
side...
--

From: Harvey Harrison <harvey.harrison@gmail.com>

Keep in mind that the eventual intent there is that, like
powerpc, we have one "sparc" arch directory.
--

From: Linus Torvalds <torvalds@linux-foundation.org>

This discussion reminds me of one of my (numerous) pet peeves
about the glibc source tree.

If you want to figure out where something is implemented for a given
target, you have to walk through the tree like a monkey in some
prioritized list of directories to find the source file or header file
that glibc ends up using.

At least with what we're using now, you open up the file for ARCH and
you see the includes so you know exactly where to go.

So I think this "just provide no file to use default implementation"
might not be the best idea in the long term.
--

The dependencies file contains the exact list of used files.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--

From: Andreas Schwab <schwab@suse.de>

That doesn't make it any more intuitive.
--

Flexibility comes with some cost.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--

From: Andreas Schwab <schwab@suse.de>

GLIBC is overly flexible, to the point of being painful.

It is designed in such a way that you cannot even do a fully parallel
build.  It can only parallelize in one directory at a time.

It stats files like crazy, in every subdirectory it visits, in order
to implement this prioritization scheme.

It is the most inefficient build system that I am aware of for such an
important code base.
--

I'd personally like the net/ structure more. So subsystem code under 

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 

And one would not forget to add the include directory to a "git log" or 
"git bisect" path specification...

Rene.
--

Suggestion for sound/drivers: drivers/sound/generic :-)

Rene.
--

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
--