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

--