Moving sound/* to drivers/ ?

Moving sound/* to drivers/ ?

[Takashi Iwai]

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

Re: Moving sound/* to drivers/ ?

[Linus Torvalds]

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

Re: Moving sound/* to drivers/ ?

[Sam Ravnborg]

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

Re: [alsa-devel] Moving sound/* to drivers/ ?

[Rene Herman]

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.

Re: [alsa-devel] Moving sound/* to drivers/ ?

[Rene Herman]

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.

Moving include/asm-* [was: Re: Moving sound/* to drivers/ ?]

[Paul Mackerras]

Linus Torvalds writes:

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

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.

Re: Moving include/asm-* [was: Re: Moving sound/* to drivers/ ?]

[Linus Torvalds]

On Thu, 22 May 2008, Paul Mackerras wrote:
>
> Linus Torvalds writes:
> 
> > 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).
> 
> We could git mv include/asm-xyz arch/xyz/asm and then arrange to pass
> -Iarch/$(ARCH) to gcc.

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

Re: Moving include/asm-* [was: Re: Moving sound/* to drivers/ ?]

[Al Viro]

On Wed, May 21, 2008 at 04:51:57PM -0700, Linus Torvalds wrote:

> So the trivial alternative is to just do
> 
> 	git mv include/asm-xyz arch/xyz/include

Careful - arch/um/include/ exists, so that'll get interesting.

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

Eh?  git mv include/asm-$i arch/$i/include/asm, then?

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

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

Re: Moving include/asm-* [was: Re: Moving sound/* to drivers/ ?]

[Linus Torvalds]

On Thu, 22 May 2008, Al Viro wrote:
> 
> Eh?  git mv include/asm-$i arch/$i/include/asm, then?

Yeah, sorry, I dropped an "include/" there. 

> 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

Re: Moving include/asm-*

[David Miller]

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed, 21 May 2008 18:20:27 -0700 (PDT)

> On Thu, 22 May 2008, Al Viro wrote:
> > 
> > Eh?  git mv include/asm-$i arch/$i/include/asm, then?
> 
> Yeah, sorry, I dropped an "include/" there. 
> 
> > 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.

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.

Re: Moving include/asm-*

[Andreas Schwab]

David Miller <davem@davemloft.net> writes:

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

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

Re: Moving include/asm-*

[David Miller]

From: Andreas Schwab <schwab@suse.de>
Date: Thu, 22 May 2008 10:09:51 +0200

> David Miller <davem@davemloft.net> writes:
> 
> > 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.
> 
> The dependencies file contains the exact list of used files.

That doesn't make it any more intuitive.

Re: Moving include/asm-*

[Andreas Schwab]

David Miller <davem@davemloft.net> writes:

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

Re: Moving include/asm-*

[David Miller]

From: Andreas Schwab <schwab@suse.de>
Date: Thu, 22 May 2008 18:32:29 +0200

> David Miller <davem@davemloft.net> writes:
> 
> > That doesn't make it any more intuitive.
> 
> Flexibility comes with some cost.

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.

Re: Moving include/asm-* [was: Re: Moving sound/* to drivers/ ?]

[Harvey Harrison]

On Wed, 2008-05-21 at 18:20 -0700, Linus Torvalds wrote:
> 
> On Thu, 22 May 2008, Al Viro wrote:
> > 
> > Eh?  git mv include/asm-$i arch/$i/include/asm, then?
> 
> Yeah, sorry, I dropped an "include/" there. 
> 
> > 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.
> 

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

Harvey

Re: Moving include/asm-*

[David Miller]

From: Harvey Harrison <harvey.harrison@gmail.com>
Date: Wed, 21 May 2008 18:23:39 -0700

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

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

Re: Moving include/asm-* [was: Re: Moving sound/* to drivers/ ?]

[Linus Torvalds]

On Wed, 21 May 2008, Harvey Harrison wrote:
> 
> What about say, sparc64 that has a lot of #include <asm-sparc/foo.h>

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

Re: Moving include/asm-* [was: Re: Moving sound/* to drivers/ ?]

[Al Viro]

On Wed, May 21, 2008 at 06:29:43PM -0700, Linus Torvalds wrote:
> 
> 
> On Wed, 21 May 2008, Harvey Harrison wrote:
> > 
> > What about say, sparc64 that has a lot of #include <asm-sparc/foo.h>
> 
> 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.

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

Re: Moving include/asm-* [was: Re: Moving sound/* to drivers/ ?]

[Jeff Dike]

On Wed, May 21, 2008 at 06:29:43PM -0700, Linus Torvalds wrote:
> > 
> > What about say, sparc64 that has a lot of #include <asm-sparc/foo.h>
> 
> 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.

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

Re: Moving include/asm-* [was: Re: Moving sound/* to drivers/ ?]

[Al Viro]

On Thu, May 22, 2008 at 12:20:59AM -0400, Jeff Dike wrote:
> On Wed, May 21, 2008 at 06:29:43PM -0700, Linus Torvalds wrote:
> > > 
> > > What about say, sparc64 that has a lot of #include <asm-sparc/foo.h>
> > 
> > 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.
> 
> 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.

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                               |    1 +
 include/asm-um/fixmap.h                            |    2 +-
 include/asm-um/hw_irq.h                            |    2 +-
 include/asm-um/ldt.h                               |    2 +-
 include/asm-um/module.h                            |    1 +
 include/asm-um/processor.h                         |    1 +
 include/asm-um/ptrace.h                            |    1 +
 include/asm-um/sigcontext-generic.h                |    6 ------
 include/asm-um/sigcontext.h                        |    1 +
 include/asm-um/string.h                            |    2 +-
 include/asm-um/system.h                            |    1 +
 include/asm-um/vm-flags.h                          |    1 +
 36 files changed, 17 insertions(+), 31 deletions(-)
 rename include/asm-um/archparam-i386.h => arch/um/include/sysdep-i386/archparam.h (100%)
 rename include/asm-um/elf-i386.h => arch/um/include/sysdep-i386/elf.h (100%)
 rename include/asm-um/host_ldt-i386.h => arch/um/include/sysdep-i386/host_ldt.h (100%)
 rename include/asm-um/module-i386.h => arch/um/include/sysdep-i386/module.h (100%)
 rename include/asm-um/processor-i386.h => arch/um/include/sysdep-i386/processor.h (98%)
 rename include/asm-um/ptrace-i386.h => arch/um/include/sysdep-i386/ptrace-full.h (100%)
 rename include/asm-um/sigcontext-i386.h => arch/um/include/sysdep-i386/sigcontext-full.h (66%)
 rename include/asm-um/system-i386.h => arch/um/include/sysdep-i386/system.h (100%)
 rename include/asm-um/vm-flags-i386.h => arch/um/include/sysdep-i386/vm-flags.h (100%)
 rename include/asm-um/archparam-ppc.h => arch/um/include/sysdep-ppc/archparam.h (100%)
 rename include/asm-um/elf-ppc.h => arch/um/include/sysdep-ppc/elf.h (100%)
 rename include/asm-um/processor-ppc.h => arch/um/include/sysdep-ppc/processor.h (100%)
 rename include/asm-um/sigcontext-ppc.h => arch/um/include/sysdep-ppc/sigcontext-full.h (76%)
 rename include/asm-um/system-ppc.h => arch/um/include/sysdep-ppc/system.h (100%)
 rename include/asm-um/archparam-x86_64.h => arch/um/include/sysdep-x86_64/archparam.h (100%)
 rename include/asm-um/elf-x86_64.h => arch/um/include/sysdep-x86_64/elf.h (100%)
 rename include/asm-um/host_ldt-x86_64.h => arch/um/include/sysdep-x86_64/host_ldt.h (100%)
 rename include/asm-um/module-x86_64.h => arch/um/include/sysdep-x86_64/module.h (100%)
 rename include/asm-um/processor-x86_64.h => arch/um/include/sysdep-x86_64/processor.h (100%)
 rename include/asm-um/ptrace-x86_64.h => arch/um/include/sysdep-x86_64/ptrace-full.h (98%)
 rename include/asm-um/sigcontext-x86_64.h => arch/um/include/sysdep-x86_64/sigcontext-full.h (93%)
 rename include/asm-um/system-x86_64.h => arch/um/include/sysdep-x86_64/system.h (100%)
 rename include/asm-um/vm-flags-x86_64.h => arch/um/include/sysdep-x86_64/vm-flags.h (100%)
 create mode 100644 include/asm-um/elf.h
 create mode 100644 include/asm-um/module.h
 create mode 100644 include/asm-um/processor.h
 create mode 100644 include/asm-um/ptrace.h
 delete mode 100644 include/asm-um/sigcontext-generic.h
 create mode 100644 include/asm-um/sigcontext.h
 create mode 100644 include/asm-um/system.h
 create mode 100644 include/asm-um/vm-flags.h

diff --git a/arch/um/Makefile b/arch/um/Makefile
index dbeab15..4dd57c9 100644
--- a/arch/um/Makefile
+++ b/arch/um/Makefile
@@ -18,18 +18,13 @@ core-y			+= $(ARCH_DIR)/kernel/		\
 			   $(ARCH_DIR)/drivers/		\
 			   $(ARCH_DIR)/os-$(OS)/
 
-# Have to precede the include because the included Makefiles reference them.
-SYMLINK_HEADERS := archparam.h system.h sigcontext.h processor.h ptrace.h \
-	module.h vm-flags.h elf.h host_ldt.h
-SYMLINK_HEADERS := $(foreach header,$(SYMLINK_HEADERS),include/asm-um/$(header))
-
 # XXX: The "os" symlink is only used by arch/um/include/os.h, which includes
 # ../os/include/file.h
 #
 # These are cleaned up during mrproper. Please DO NOT fix it again, this is
 # the Correct Thing(tm) to do!
 ARCH_SYMLINKS = include/asm-um/arch $(ARCH_DIR)/include/sysdep $(ARCH_DIR)/os \
-	$(SYMLINK_HEADERS) $(ARCH_DIR)/include/uml-config.h
+	$(ARCH_DIR)/include/uml-config.h
 
 MODE_INCLUDE	+= -I$(srctree)/$(ARCH_DIR)/include/skas
 
@@ -143,16 +138,6 @@ archclean:
 	@find . \( -name '*.bb' -o -name '*.bbg' -o -name '*.da' \
 		-o -name '*.gcov' \) -type f -print | xargs rm -f
 
-$(SYMLINK_HEADERS):
-	@echo '  SYMLINK $@'
-ifneq ($(KBUILD_SRC),)
-	$(Q)mkdir -p $(objtree)/include/asm-um
-	$(Q)ln -fsn $(srctree)/include/asm-um/$(basename $(notdir $@))-$(SUBARCH)$(suffix $@) $@
-else
-	$(Q)cd $(srctree)/$(dir $@) ; \
-	ln -sf $(basename $(notdir $@))-$(SUBARCH)$(suffix $@) $(notdir $@)
-endif
-
 include/asm-um/arch:
 	@echo '  SYMLINK $@'
 ifneq ($(KBUILD_SRC),)
diff --git a/include/asm-um/archparam-i386.h b/arch/um/include/sysdep-i386/archparam.h
similarity index 100%
rename from include/asm-um/archparam-i386.h
rename to arch/um/include/sysdep-i386/archparam.h
diff --git a/include/asm-um/elf-i386.h b/arch/um/include/sysdep-i386/elf.h
similarity index 100%
rename from include/asm-um/elf-i386.h
rename to arch/um/include/sysdep-i386/elf.h
diff --git a/include/asm-um/host_ldt-i386.h b/arch/um/include/sysdep-i386/host_ldt.h
similarity index 100%
rename from include/asm-um/host_ldt-i386.h
rename to arch/um/include/sysdep-i386/host_ldt.h
diff --git a/include/asm-um/module-i386.h b/arch/um/include/sysdep-i386/module.h
similarity index 100%
rename from include/asm-um/module-i386.h
rename to arch/um/include/sysdep-i386/module.h
diff --git a/include/asm-um/processor-i386.h b/arch/um/include/sysdep-i386/processor.h
similarity index 98%
rename from include/asm-um/processor-i386.h
rename to arch/um/include/sysdep-i386/processor.h
index a2b7fe1..64c1978 100644
--- a/include/asm-um/processor-i386.h
+++ b/arch/um/include/sysdep-i386/processor.h
@@ -7,7 +7,7 @@
 #define __UM_PROCESSOR_I386_H
 
 #include "linux/string.h"
-#include "asm/host_ldt.h"
+#include "sysdep/host_ldt.h"
 #include "asm/segment.h"
 
 extern int host_has_cmov;
diff --git a/include/asm-um/ptrace-i386.h b/arch/um/include/sysdep-i386/ptrace-full.h
similarity index 100%
rename from include/asm-um/ptrace-i386.h
rename to arch/um/include/sysdep-i386/ptrace-full.h
diff --git a/include/asm-um/sigcontext-i386.h b/arch/um/include/sysdep-i386/sigcontext-full.h
similarity index 66%
rename from include/asm-um/sigcontext-i386.h
rename to arch/um/include/sysdep-i386/sigcontext-full.h
index b88333f..588d58c 100644
--- a/include/asm-um/sigcontext-i386.h
+++ b/arch/um/include/sysdep-i386/sigcontext-full.h
@@ -1,6 +1,6 @@
 #ifndef __UM_SIGCONTEXT_I386_H
 #define __UM_SIGCONTEXT_I386_H
 
-#include "asm/sigcontext-generic.h"
+#include <asm/arch/sigcontext.h>
 
 #endif
diff --git a/include/asm-um/system-i386.h b/arch/um/include/sysdep-i386/system.h
similarity index 100%
rename from include/asm-um/system-i386.h
rename to arch/um/include/sysdep-i386/system.h
diff --git a/include/asm-um/vm-flags-i386.h b/arch/um/include/sysdep-i386/vm-flags.h
similarity index 100%
rename from include/asm-um/vm-flags-i386.h
rename to arch/um/include/sysdep-i386/vm-flags.h
diff --git a/include/asm-um/archparam-ppc.h b/arch/um/include/sysdep-ppc/archparam.h
similarity index 100%
rename from include/asm-um/archparam-ppc.h
rename to arch/um/include/sysdep-ppc/archparam.h
diff --git a/include/asm-um/elf-ppc.h b/arch/um/include/sysdep-ppc/elf.h
similarity index 100%
rename from include/asm-um/elf-ppc.h
rename to arch/um/include/sysdep-ppc/elf.h
diff --git a/include/asm-um/processor-ppc.h b/arch/um/include/sysdep-ppc/processor.h
similarity index 100%
rename from include/asm-um/processor-ppc.h
rename to arch/um/include/sysdep-ppc/processor.h
diff --git a/include/asm-um/sigcontext-ppc.h b/arch/um/include/sysdep-ppc/sigcontext-full.h
similarity index 76%
rename from include/asm-um/sigcontext-ppc.h
rename to arch/um/include/sysdep-ppc/sigcontext-full.h
index 2467f20..c02555d 100644
--- a/include/asm-um/sigcontext-ppc.h
+++ b/arch/um/include/sysdep-ppc/sigcontext-full.h
@@ -3,7 +3,7 @@
 
 #define pt_regs sys_pt_regs
 
-#include "asm/sigcontext-generic.h"
+#include <asm/arch/sigcontext.h>
 
 #undef pt_regs
 
diff --git a/include/asm-um/system-ppc.h b/arch/um/include/sysdep-ppc/system.h
similarity index 100%
rename from include/asm-um/system-ppc.h
rename to arch/um/include/sysdep-ppc/system.h
diff --git a/include/asm-um/archparam-x86_64.h b/arch/um/include/sysdep-x86_64/archparam.h
similarity index 100%
rename from include/asm-um/archparam-x86_64.h
rename to arch/um/include/sysdep-x86_64/archparam.h
diff --git a/include/asm-um/elf-x86_64.h b/arch/um/include/sysdep-x86_64/elf.h
similarity index 100%
rename from include/asm-um/elf-x86_64.h
rename to arch/um/include/sysdep-x86_64/elf.h
diff --git a/include/asm-um/host_ldt-x86_64.h b/arch/um/include/sysdep-x86_64/host_ldt.h
similarity index 100%
rename from include/asm-um/host_ldt-x86_64.h
rename to arch/um/include/sysdep-x86_64/host_ldt.h
diff --git a/include/asm-um/module-x86_64.h b/arch/um/include/sysdep-x86_64/module.h
similarity index 100%
rename from include/asm-um/module-x86_64.h
rename to arch/um/include/sysdep-x86_64/module.h
diff --git a/include/asm-um/processor-x86_64.h b/arch/um/include/sysdep-x86_64/processor.h
similarity index 100%
rename from include/asm-um/processor-x86_64.h
rename to arch/um/include/sysdep-x86_64/processor.h
diff --git a/include/asm-um/ptrace-x86_64.h b/arch/um/include/sysdep-x86_64/ptrace-full.h
similarity index 98%
rename from include/asm-um/ptrace-x86_64.h
rename to arch/um/include/sysdep-x86_64/ptrace-full.h
index 4c47535..4dacb69 100644
--- a/include/asm-um/ptrace-x86_64.h
+++ b/arch/um/include/sysdep-x86_64/ptrace-full.h
@@ -9,7 +9,7 @@
 
 #include "linux/compiler.h"
 #include "asm/errno.h"
-#include "asm/host_ldt.h"
+#include "sysdep/host_ldt.h"
 
 #define __FRAME_OFFSETS /* Needed to get the R* macros */
 #include "asm/ptrace-generic.h"
diff --git a/include/asm-um/sigcontext-x86_64.h b/arch/um/include/sysdep-x86_64/sigcontext-full.h
similarity index 93%
rename from include/asm-um/sigcontext-x86_64.h
rename to arch/um/include/sysdep-x86_64/sigcontext-full.h
index b600e0b..b8a0d68 100644
--- a/include/asm-um/sigcontext-x86_64.h
+++ b/arch/um/include/sysdep-x86_64/sigcontext-full.h
@@ -6,7 +6,7 @@
 #ifndef __UM_SIGCONTEXT_X86_64_H
 #define __UM_SIGCONTEXT_X86_64_H
 
-#include "asm/sigcontext-generic.h"
+#include <asm/arch/sigcontext.h>
 
 #endif
 
diff --git a/include/asm-um/system-x86_64.h b/arch/um/include/sysdep-x86_64/system.h
similarity index 100%
rename from include/asm-um/system-x86_64.h
rename to arch/um/include/sysdep-x86_64/system.h
diff --git a/include/asm-um/vm-flags-x86_64.h b/arch/um/include/sysdep-x86_64/vm-flags.h
similarity index 100%
rename from include/asm-um/vm-flags-x86_64.h
rename to arch/um/include/sysdep-x86_64/vm-flags.h
diff --git a/include/asm-um/elf.h b/include/asm-um/elf.h
new file mode 100644
index 0000000..8ea111f
--- /dev/null
+++ b/include/asm-um/elf.h
@@ -0,0 +1 @@
+#include <sysdep/elf.h>
diff --git a/include/asm-um/fixmap.h b/include/asm-um/fixmap.h
index 9d2be52..a846653 100644
--- a/include/asm-um/fixmap.h
+++ b/include/asm-um/fixmap.h
@@ -4,7 +4,7 @@
 #include <asm/processor.h>
 #include <asm/system.h>
 #include <asm/kmap_types.h>
-#include <asm/archparam.h>
+#include <sysdep/archparam.h>
 #include <asm/page.h>
 
 /*
diff --git a/include/asm-um/hw_irq.h b/include/asm-um/hw_irq.h
index 1cf84cf..f2feb14 100644
--- a/include/asm-um/hw_irq.h
+++ b/include/asm-um/hw_irq.h
@@ -2,6 +2,6 @@
 #define _ASM_UM_HW_IRQ_H
 
 #include "asm/irq.h"
-#include "asm/archparam.h"
+#include <sysdep/archparam.h>
 
 #endif
diff --git a/include/asm-um/ldt.h b/include/asm-um/ldt.h
index 52af512..a7f999a 100644
--- a/include/asm-um/ldt.h
+++ b/include/asm-um/ldt.h
@@ -9,7 +9,7 @@
 #define __ASM_LDT_H
 
 #include <linux/mutex.h>
-#include "asm/host_ldt.h"
+#include <sysdep/host_ldt.h>
 
 extern void ldt_host_info(void);
 
diff --git a/include/asm-um/module.h b/include/asm-um/module.h
new file mode 100644
index 0000000..4b3bdf0
--- /dev/null
+++ b/include/asm-um/module.h
@@ -0,0 +1 @@
+#include <sysdep/module.h>
diff --git a/include/asm-um/processor.h b/include/asm-um/processor.h
new file mode 100644
index 0000000..476d55f
--- /dev/null
+++ b/include/asm-um/processor.h
@@ -0,0 +1 @@
+#include <sysdep/processor.h>
diff --git a/include/asm-um/ptrace.h b/include/asm-um/ptrace.h
new file mode 100644
index 0000000..8530714
--- /dev/null
+++ b/include/asm-um/ptrace.h
@@ -0,0 +1 @@
+#include <sysdep/ptrace-full.h>
diff --git a/include/asm-um/sigcontext-generic.h b/include/asm-um/sigcontext-generic.h
deleted file mode 100644
index 1645870..0000000
--- a/include/asm-um/sigcontext-generic.h
+++ /dev/null
@@ -1,6 +0,0 @@
-#ifndef __UM_SIGCONTEXT_GENERIC_H
-#define __UM_SIGCONTEXT_GENERIC_H
-
-#include "asm/arch/sigcontext.h"
-
-#endif
diff --git a/include/asm-um/sigcontext.h b/include/asm-um/sigcontext.h
new file mode 100644
index 0000000..f05c67e
--- /dev/null
+++ b/include/asm-um/sigcontext.h
@@ -0,0 +1 @@
+#include <sysdep/sigcontext-full.h>
diff --git a/include/asm-um/string.h b/include/asm-um/string.h
index 9a0571f..9ca64af 100644
--- a/include/asm-um/string.h
+++ b/include/asm-um/string.h
@@ -2,6 +2,6 @@
 #define __UM_STRING_H
 
 #include "asm/arch/string.h"
-#include "asm/archparam.h"
+#include <sysdep/archparam.h>
 
 #endif
diff --git a/include/asm-um/system.h b/include/asm-um/system.h
new file mode 100644
index 0000000..ad45077
--- /dev/null
+++ b/include/asm-um/system.h
@@ -0,0 +1 @@
+#include <sysdep/system.h>
diff --git a/include/asm-um/vm-flags.h b/include/asm-um/vm-flags.h
new file mode 100644
index 0000000..dd5a8a6
--- /dev/null
+++ b/include/asm-um/vm-flags.h
@@ -0,0 +1 @@
+#include <sysdep/vm-flags.h>
-- 
1.5.3.GIT

Re: Moving include/asm-* [was: Re: Moving sound/* to drivers/ ?]

[Jeff Dike]

On Thu, May 22, 2008 at 06:26:07AM +0100, Al Viro wrote:
> 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.?

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

Re: Moving include/asm-* [was: Re: Moving sound/* to drivers/ ?]

[Sam Ravnborg]

On Thu, May 22, 2008 at 06:26:07AM +0100, Al Viro wrote:
> On Thu, May 22, 2008 at 12:20:59AM -0400, Jeff Dike wrote:
> > On Wed, May 21, 2008 at 06:29:43PM -0700, Linus Torvalds wrote:
> > > > 
> > > > What about say, sparc64 that has a lot of #include <asm-sparc/foo.h>
> > > 
> > > 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.
> > 
> > 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.
> 
> 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.?
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

Re: Moving include/asm-* [was: Re: Moving sound/* to drivers/ ?]

[Al Viro]

On Wed, May 21, 2008 at 06:20:27PM -0700, Linus Torvalds wrote:
> 
> 
> On Thu, 22 May 2008, Al Viro wrote:
> > 
> > Eh?  git mv include/asm-$i arch/$i/include/asm, then?
> 
> Yeah, sorry, I dropped an "include/" there. 
> 
> > 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.

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

Re: Moving include/asm-* [was: Re: Moving sound/* to drivers/ ?]

[Arnd Bergmann]

On Thursday 22 May 2008, Al Viro wrote:

> On Wed, May 21, 2008 at 06:20:27PM -0700, Linus Torvalds wrote:
> > On Thu, 22 May 2008, Al Viro wrote:
> > 
> > > 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.
> 
> 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

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

Re: [alsa-devel] Moving sound/* to drivers/ ?

[Timur Tabi]

Takashi Iwai wrote:

> 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/*?

That gets my vote.

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: Moving sound/* to drivers/ ?

[Adrian Bunk]

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

-- 

       "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

Re: Moving sound/* to drivers/ ?

[Takashi Iwai]

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

Re: Moving sound/* to drivers/ ?

[Jeff Garzik]

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

Re: Moving sound/* to drivers/ ?

[Rene Herman]

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.

Re: Moving sound/* to drivers/ ?

[Jaroslav Kysela]

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.

Re: Moving sound/* to drivers/ ?

[Sam Ravnborg]

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

Re: Moving sound/* to drivers/ ?

[Jaroslav Kysela]

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.

Re: Moving sound/* to drivers/ ?

[Rene Herman]

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.

Re: Moving sound/* to drivers/ ?

[Takashi Iwai]

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

Re: Moving sound/* to drivers/ ?

[Jan Engelhardt]

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.

Re: Moving sound/* to drivers/ ?

[Linus Torvalds]

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

Re: Moving sound/* to drivers/ ?

[Jan Engelhardt]

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.

Re: Moving sound/* to drivers/ ?

[Rene Herman]

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.

Re: Moving sound/* to drivers/ ?

[Rene Herman]

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.

Re: Moving sound/* to drivers/ ?

[Adrian Bunk]

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

-- 

       "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