Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel

Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel

[J.A. Magallon]

On 20020108 Linus Torvalds wrote:
>
>On Mon, 7 Jan 2002, Alan Cox wrote:
>> > Would't it be better to split drivers:
>> >
>> > sound/core.c
>> > sound/alsa/alsa-core.c
>> > sound/alsa/drivers/alsa-emu10k.c
>> > sound/oss/oss-core.c
>> > sound/oss/drivers/oss-emu10k.c
>>
>> Thats much harder to do randomg greps on and to find stuff,than drivers
>> first
>
>I agree. Put drivers separately, let's not split it up more than that.
>

What would you do with drivers with the same name (source code file)
in alsa and oss ?
Sound is special because you have two implementations of the same subsystem
living together. And eventually in a (near?) future, the oss subtree
will be killed and the alsa one would go up one level, just as is. Much
cleaner. And you will end with

sound/alsa-core.c
sound/drivers/alsa-driver.c

By

/juan

-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.18-pre2-beo #1 SMP Tue Jan 8 03:18:18 CET 2002 i686

Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel

[Abramo Bagnara]

"J.A. Magallon" wrote:
> 
> On 20020108 Linus Torvalds wrote:
> >
> >On Mon, 7 Jan 2002, Alan Cox wrote:
> >> > Would't it be better to split drivers:
> >> >
> >> > sound/core.c
> >> > sound/alsa/alsa-core.c
> >> > sound/alsa/drivers/alsa-emu10k.c
> >> > sound/oss/oss-core.c
> >> > sound/oss/drivers/oss-emu10k.c
> >>
> >> Thats much harder to do randomg greps on and to find stuff,than drivers
> >> first
> >
> >I agree. Put drivers separately, let's not split it up more than that.
> >
> 
> What would you do with drivers with the same name (source code file)
> in alsa and oss ?
> Sound is special because you have two implementations of the same subsystem
> living together. And eventually in a (near?) future, the oss subtree
> will be killed and the alsa one would go up one level, just as is. Much
> cleaner. And you will end with
> 
> sound/alsa-core.c
> sound/drivers/alsa-driver.c

I think it's better to face this big change once and to move the OSS
stuff now in its definitive place (where it might be removed in future).

So we'd have:
sound/
sound/oss_native
sound/oss_emul
sound/synth
sound/include
drivers/sound/i2c
drivers/sound/isa
drivers/sound/pci
drivers/sound/ppc

I still have some doubts about hardware specific include files:
a) sound/include
b) drivers/sound/{i2c,isa,pci,ppc}
c) drivers/sound/include

Currently my vote would go for b), but I see drawbacks for this solution
(for generic chip include files, like ac97 or ak4531 ones). Perhaps it's
better to have a mixed solution (partly b) and partly c)

Will this solution be able to satisfy everybody? ;-)

-- 
Abramo Bagnara                       mailto:abramo@alsa-project.org

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project               http://www.alsa-project.org
It sounds good!

Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel

[Takashi Iwai]

At Tue, 08 Jan 2002 10:52:16 +0100,
Abramo wrote:
> 
> "J.A. Magallon" wrote:
> > 
> > On 20020108 Linus Torvalds wrote:
> > >
> > >On Mon, 7 Jan 2002, Alan Cox wrote:
> > >> > Would't it be better to split drivers:
> > >> >
> > >> > sound/core.c
> > >> > sound/alsa/alsa-core.c
> > >> > sound/alsa/drivers/alsa-emu10k.c
> > >> > sound/oss/oss-core.c
> > >> > sound/oss/drivers/oss-emu10k.c
> > >>
> > >> Thats much harder to do randomg greps on and to find stuff,than drivers
> > >> first
> > >
> > >I agree. Put drivers separately, let's not split it up more than that.
> > >
> > 
> > What would you do with drivers with the same name (source code file)
> > in alsa and oss ?
> > Sound is special because you have two implementations of the same subsystem
> > living together. And eventually in a (near?) future, the oss subtree
> > will be killed and the alsa one would go up one level, just as is. Much
> > cleaner. And you will end with
> > 
> > sound/alsa-core.c
> > sound/drivers/alsa-driver.c
> 
> I think it's better to face this big change once and to move the OSS
> stuff now in its definitive place (where it might be removed in future).
> 
> So we'd have:
> sound/
> sound/oss_native
> sound/oss_emul
> sound/synth
> sound/include
> drivers/sound/i2c
> drivers/sound/isa
> drivers/sound/pci
> drivers/sound/ppc
 
On the list above, to where OSS (hw specific) codes come?  Into a
single directory, sound/oss_native?  Or both ALSA and OSS drivers are
mixed into drivers/sound/*?
I'd like to see ALSA and OSS codes are separated into different
directories...  Otherwise it's too confusing.

And how about drivers/sound/generic for generic hardware codes such as
ac97_codec.c?


> I still have some doubts about hardware specific include files:
> a) sound/include
> b) drivers/sound/{i2c,isa,pci,ppc}
> c) drivers/sound/include
> 
> Currently my vote would go for b), but I see drawbacks for this solution
> (for generic chip include files, like ac97 or ak4531 ones). Perhaps it's
> better to have a mixed solution (partly b) and partly c)

Agreed.  The hw specific header files should be bound with *.c code
together.


Takashi

Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel

[Jaroslav Kysela]

On Tue, 8 Jan 2002, Takashi Iwai wrote:

> At Tue, 08 Jan 2002 10:52:16 +0100,
> Abramo wrote:
> >
> > "J.A. Magallon" wrote:
> > >
> > > On 20020108 Linus Torvalds wrote:
> > > >
> > > >On Mon, 7 Jan 2002, Alan Cox wrote:
> > > >> > Would't it be better to split drivers:
> > > >> >
> > > >> > sound/core.c
> > > >> > sound/alsa/alsa-core.c
> > > >> > sound/alsa/drivers/alsa-emu10k.c
> > > >> > sound/oss/oss-core.c
> > > >> > sound/oss/drivers/oss-emu10k.c
> > > >>
> > > >> Thats much harder to do randomg greps on and to find stuff,than drivers
> > > >> first
> > > >
> > > >I agree. Put drivers separately, let's not split it up more than that.
> > > >
> > >
> > > What would you do with drivers with the same name (source code file)
> > > in alsa and oss ?
> > > Sound is special because you have two implementations of the same subsystem
> > > living together. And eventually in a (near?) future, the oss subtree
> > > will be killed and the alsa one would go up one level, just as is. Much
> > > cleaner. And you will end with
> > >
> > > sound/alsa-core.c
> > > sound/drivers/alsa-driver.c
> >
> > I think it's better to face this big change once and to move the OSS
> > stuff now in its definitive place (where it might be removed in future).
> >
> > So we'd have:
> > sound/
> > sound/oss_native
> > sound/oss_emul
> > sound/synth
> > sound/include
> > drivers/sound/i2c
> > drivers/sound/isa
> > drivers/sound/pci
> > drivers/sound/ppc
>
> On the list above, to where OSS (hw specific) codes come?  Into a
> single directory, sound/oss_native?  Or both ALSA and OSS drivers are
> mixed into drivers/sound/*?
> I'd like to see ALSA and OSS codes are separated into different
> directories...  Otherwise it's too confusing.
>
> And how about drivers/sound/generic for generic hardware codes such as
> ac97_codec.c?
>
>
> > I still have some doubts about hardware specific include files:
> > a) sound/include
> > b) drivers/sound/{i2c,isa,pci,ppc}
> > c) drivers/sound/include
> >
> > Currently my vote would go for b), but I see drawbacks for this solution
> > (for generic chip include files, like ac97 or ak4531 ones). Perhaps it's
> > better to have a mixed solution (partly b) and partly c)
>
> Agreed.  The hw specific header files should be bound with *.c code
> together.

The problem is that we should export some header files to user space as
well to allow access to hardware related features.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA Project  http://www.alsa-project.org

Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel

[Takashi Iwai]

At Tue, 8 Jan 2002 11:18:34 +0100 (CET),
Jaroslav wrote:
> 
> On Tue, 8 Jan 2002, Takashi Iwai wrote:
> 
> >
> > > I still have some doubts about hardware specific include files:
> > > a) sound/include
> > > b) drivers/sound/{i2c,isa,pci,ppc}
> > > c) drivers/sound/include
> > >
> > > Currently my vote would go for b), but I see drawbacks for this solution
> > > (for generic chip include files, like ac97 or ak4531 ones). Perhaps it's
> > > better to have a mixed solution (partly b) and partly c)
> >
> > Agreed.  The hw specific header files should be bound with *.c code
> > together.
> 
> The problem is that we should export some header files to user space as
> well to allow access to hardware related features.

Hmm..  but such programs require the kernel tree anyway, since
/usr/include/linux is ususally no longer symlinked to /usr/src/linux.


Takashi

Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel

[Abramo Bagnara]

Jaroslav Kysela wrote:
> 
> On Tue, 8 Jan 2002, Takashi Iwai wrote:
> 
> > Agreed.  The hw specific header files should be bound with *.c code
> > together.
> 
> The problem is that we should export some header files to user space as
> well to allow access to hardware related features.

Don't you think it's better to split this in "external" headers (placed
in include/sound together with asound.h) and "internal" ones (placed in
drivers/*/)?

To present kernel space struct layout for specific hardware to user
space does not seem a lot sensible to me (and might also give some
errors unless nasty #ifdef __KERNEL__ tricks).

-- 
Abramo Bagnara                       mailto:abramo@alsa-project.org

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project               http://www.alsa-project.org
It sounds good!

Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel

[Jaroslav Kysela]

On Tue, 8 Jan 2002, Abramo Bagnara wrote:

> Jaroslav Kysela wrote:
> >
> > On Tue, 8 Jan 2002, Takashi Iwai wrote:
> >
> > > Agreed.  The hw specific header files should be bound with *.c code
> > > together.
> >
> > The problem is that we should export some header files to user space as
> > well to allow access to hardware related features.
>
> Don't you think it's better to split this in "external" headers (placed
> in include/sound together with asound.h) and "internal" ones (placed in
> drivers/*/)?
>
> To present kernel space struct layout for specific hardware to user
> space does not seem a lot sensible to me (and might also give some
> errors unless nasty #ifdef __KERNEL__ tricks).

I'm open for all cleanups including this. Although I'm not sure about the
right place for shared internal header files. References including the
directory structure layout (like #include "../../generic/ac97/ac97_codec.h")
are not happiest solution in my eyes and creating a new internal directory
with header files definitely breaks the current linux/include directory
structure.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA Project  http://www.alsa-project.org

Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel

[Abramo Bagnara]

Takashi Iwai wrote:
> 
> At Tue, 08 Jan 2002 10:52:16 +0100,
> Abramo wrote:
> >
> >
> > So we'd have:
> > sound/
> > sound/oss_native
> > sound/oss_emul
> > sound/synth
> > sound/include
> > drivers/sound/i2c
> > drivers/sound/isa
> > drivers/sound/pci
> > drivers/sound/ppc
> 
> On the list above, to where OSS (hw specific) codes come?  Into a
> single directory, sound/oss_native?

Yes

> Or both ALSA and OSS drivers are
> mixed into drivers/sound/*?
> I'd like to see ALSA and OSS codes are separated into different
> directories...  Otherwise it's too confusing.

I think that in this way they are separated enough. Do you agree?

> 
> And how about drivers/sound/generic for generic hardware codes such as
> ac97_codec.c?

Currently Jaroslav has put that in alsa-kernel/pci/ac97. If we follow
this guideline they go in drivers/pci/ac97 (although I'm not sure
whether ac97 is PCI only).

-- 
Abramo Bagnara                       mailto:abramo@alsa-project.org

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project               http://www.alsa-project.org
It sounds good!

Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel

[Jaroslav Kysela]

On Tue, 8 Jan 2002, Abramo Bagnara wrote:

> > And how about drivers/sound/generic for generic hardware codes such as
> > ac97_codec.c?
>
> Currently Jaroslav has put that in alsa-kernel/pci/ac97. If we follow
> this guideline they go in drivers/pci/ac97 (although I'm not sure
> whether ac97 is PCI only).

I've not seen using AC97 codec in other hardware than PCI based, but the
design of these codecs is independent on the bus bridge. Note that the
current directory structure is my proposal so it is possible to move ac97
sources to another directory.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA Project  http://www.alsa-project.org

Re: ALSA patch for 2.5.2pre9 kernel

[J.A. Magallon]

On 20020107 Alan Cox wrote:
>
>so by that logic we'd have
>
>	sound/soundcore.c
>	sound/alsa/alsalibcode
>	sound/oss/osscore
>
>	sound/drivers/cardfoo.c
>

Would't it be better to split drivers:

sound/core.c
sound/alsa/alsa-core.c
sound/alsa/drivers/alsa-emu10k.c
sound/oss/oss-core.c
sound/oss/drivers/oss-emu10k.c

low level card drivers are different, and this way oss and alsa are
independent subtrees.

BTW, 2.5.x was born to be broken, so this is the moment to reorganize
the beast (better before than after kbuild 2.5 ?)

By

-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.18-pre1-beo #1 SMP Fri Jan 4 02:25:59 CET 2002 i686

Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel

[Alan Cox]

> Would't it be better to split drivers:
> 
> sound/core.c
> sound/alsa/alsa-core.c
> sound/alsa/drivers/alsa-emu10k.c
> sound/oss/oss-core.c
> sound/oss/drivers/oss-emu10k.c

Thats much harder to do randomg greps on and to find stuff,than drivers
first

Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel

[Linus Torvalds]

On Mon, 7 Jan 2002, Alan Cox wrote:
> > Would't it be better to split drivers:
> >
> > sound/core.c
> > sound/alsa/alsa-core.c
> > sound/alsa/drivers/alsa-emu10k.c
> > sound/oss/oss-core.c
> > sound/oss/drivers/oss-emu10k.c
>
> Thats much harder to do randomg greps on and to find stuff,than drivers
> first

I agree. Put drivers separately, let's not split it up more than that.

		Linus

Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel

[Steven Walter]

I think that if we do not keep all the ALSA stuff together under
linux/sound, I think we should at least refrain from cramming it in with
the OSS drivers in linux/drivers/sound.  Perhaps a linux/drivers/alsa
would be preferable?
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
			-- George Orwell
He's alive.  He's alive!  Oh, that fellow at RadioShack said I was mad!
Well, who's mad now?
			-- Montgomery C. Burns

RE: [s-h] Re: ALSA patch for 2.5.2pre9 kernel

[Dimitrie Paun]

> From: Linus Torvalds [mailto:torvalds@transmeta.com]
> 
> This is my current feeling.
> 
> However, la donna é mobile, and I'm a primus donna, fer 
> shure. So don't take it _too_ seriously, continue to argue 
> the merits of other approaches.

That's good to know. So let's do so:

There is no one grouping: things can be grouped in any number 
of ways, and for this very reason, a strictly hierarchical
grouping does not cut it. What I'm trying to say is that at
certain point, a given grouping characteristics becomes less 
important (say sound) and other (which crosscut other parts of
the source) increase in importance (say drivers).

For this reason, I think the current organization (net/core +
drivers/net) is more practical then the one which initially 
screams at any CompSci guy (net/core + net/drivers). 

Now, whichever one we choose, I'd _hate_ to see net organized
one way and sound the other way. It would be just ugly. That,
together with the fact that I don't think that putting everything
under sound/ is in any way superior to the current method,
I would suggest we stick to: sound/core + drivers/sound.

--
Dimi.

Re: ALSA patch for 2.5.2pre9 kernel

[Arnaldo Carvalho de Melo]

Em Mon, Jan 07, 2002 at 10:00:57AM -0800, Linus Torvalds escreveu:
> 
> On Mon, 7 Jan 2002, Alan Cox wrote:
> > > Or we could just have a really _deep_ hierarchy, and put everything under
> > > "linux/drivers/sound/..", but I'd rather break cleanly with the old.
> >
> > Christoph has an interesting point. Networking is
> >
> > 	net/[protocol]/
> > 	drivers/net/[driver]
> >
> > so by that logic we'd have
> >
> > 	sound/soundcore.c
> > 	sound/alsa/alsalibcode
> > 	sound/oss/osscore
> >
> > 	sound/drivers/cardfoo.c
> >
> > which would also be much cleaner since the supporting crap would be seperate
> > from the card drivers
> 
> I would certainly not oppose that. Look sane to me, although the question
> then ends up being about "drivers/sound" or "sound/drivers" (the latter
> has the advantage that it keeps sound together, the former is more
> analogous to the "net" situation).

One ring^Wlayout to rule them all <stops here ;)> I would not be unhappy if
drivers/net became net/drivers, etc 8)

- Arnaldo

Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel

[Alan Cox]

> One ring^Wlayout to rule them all <stops here ;)> I would not be unhappy if
> drivers/net became net/drivers, etc 8)

Then where do you put the drivers categorized in other ways (multifunction
devices like i2o for example) ?

Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel

[Arnaldo Carvalho de Melo]

Em Mon, Jan 07, 2002 at 09:13:29PM -0500, Alan Cox escreveu:
> > One ring^Wlayout to rule them all <stops here ;)> I would not be unhappy if
> > drivers/net became net/drivers, etc 8)
> 
> Then where do you put the drivers categorized in other ways (multifunction
> devices like i2o for example) ?

misc? Nah, too much work for little gain, and Linus is not willing to
accept patches for such a big change, even if it was interesting, so I think
that the approach you suggested (i.e. sound/{core,oss,alsa}, drivers/sound)
is the way to go.

- Arnaldo

Re: ALSA patch for 2.5.2pre9 kernel

[Linus Torvalds]

On Mon, 7 Jan 2002, Alan Cox wrote:
> > Or we could just have a really _deep_ hierarchy, and put everything under
> > "linux/drivers/sound/..", but I'd rather break cleanly with the old.
>
> Christoph has an interesting point. Networking is
>
> 	net/[protocol]/
> 	drivers/net/[driver]
>
> so by that logic we'd have
>
> 	sound/soundcore.c
> 	sound/alsa/alsalibcode
> 	sound/oss/osscore
>
> 	sound/drivers/cardfoo.c
>
> which would also be much cleaner since the supporting crap would be seperate
> from the card drivers

I would certainly not oppose that. Look sane to me, although the question
then ends up being about "drivers/sound" or "sound/drivers" (the latter
has the advantage that it keeps sound together, the former is more
analogous to the "net" situation).

		Linus

Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel

[Abramo Bagnara]

Linus Torvalds wrote:
> 
> On Mon, 7 Jan 2002, Alan Cox wrote:
> > > Or we could just have a really _deep_ hierarchy, and put everything under
> > > "linux/drivers/sound/..", but I'd rather break cleanly with the old.
> >
> > Christoph has an interesting point. Networking is
> >
> >       net/[protocol]/
> >       drivers/net/[driver]
> >
> > so by that logic we'd have
> >
> >       sound/soundcore.c
> >       sound/alsa/alsalibcode
> >       sound/oss/osscore
> >
> >       sound/drivers/cardfoo.c
> >
> > which would also be much cleaner since the supporting crap would be seperate
> > from the card drivers
> 
> I would certainly not oppose that. Look sane to me, although the question
> then ends up being about "drivers/sound" or "sound/drivers" (the latter
> has the advantage that it keeps sound together, the former is more
> analogous to the "net" situation).

IMO the latter makes much more sense (also for "net" case), but I doubt
you're willing to change current schema.

If you want to keep top level cleaner and avoid proliferation of entries
we might have:

subsys/sound
subsys/sound/drivers
subsys/net
subsys/net/drivers

and so on.

Clean and without ambiguities about stuff location. Unfortunately it's a
*big* change.

-- 
Abramo Bagnara                       mailto:abramo@alsa-project.org

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project               http://www.alsa-project.org
It sounds good!

Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel

[Linus Torvalds]

On Mon, 7 Jan 2002, Abramo Bagnara wrote:
>
> IMO the latter makes much more sense (also for "net" case), but I doubt
> you're willing to change current schema.

Agreed. I do not really think that it makes sense to move "drivers/net" to
"net/drivers" even if it _would_ be the logical way to group all net
things together. Whatever potential incremental advantage (if any) just
isn't worth the disruption.

> If you want to keep top level cleaner and avoid proliferation of entries
> we might have:
>
> subsys/sound
...

No, I hate to create structure abstractions for their own sake, and a
"subsys" kind of abstraction doesn't really add any information.

I have no problems with making the linux "root" directory a bit larger,
it's certainly not problematic (what, 22 entries, and no new ones
generated dynamically - fits on one screen even on an old vt100).

That might change if we end up creating _more_ subdirectories, of course,
although even then I'd really want to group them according to some clear
goal or property of the grouping (ie not "subsys" kinds of things).

		Linus

Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel

[Abramo Bagnara]

Linus Torvalds wrote:
> 
> On Mon, 7 Jan 2002, Abramo Bagnara wrote:
> >
> > IMO the latter makes much more sense (also for "net" case), but I doubt
> > you're willing to change current schema.
> 
> Agreed. I do not really think that it makes sense to move "drivers/net" to
> "net/drivers" even if it _would_ be the logical way to group all net
> things together. Whatever potential incremental advantage (if any) just
> isn't worth the disruption.
> 
> > If you want to keep top level cleaner and avoid proliferation of entries
> > we might have:
> >
> > subsys/sound
> ...
> 
> No, I hate to create structure abstractions for their own sake, and a
> "subsys" kind of abstraction doesn't really add any information.

Ok, I agree.

Just to resume, you think that the way to go is:

1) to have sound/ with *all* sound related stuff inside
2) to leave drivers/net/ and net/ like they are now (because although
it's suboptimal, to change it is a mess we don't want to face now)

Right?

-- 
Abramo Bagnara                       mailto:abramo@alsa-project.org

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project               http://www.alsa-project.org
It sounds good!

Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel

[Linus Torvalds]

On Mon, 7 Jan 2002, Abramo Bagnara wrote:
>
> Just to resume, you think that the way to go is:
>
> 1) to have sound/ with *all* sound related stuff inside
> 2) to leave drivers/net/ and net/ like they are now (because although
> it's suboptimal, to change it is a mess we don't want to face now)

This is my current feeling.

However, la donna é mobile, and I'm a primus donna, fer shure. So don't
take it _too_ seriously, continue to argue the merits of other approaches.

		Linus

Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel

[Abramo Bagnara]

Linus Torvalds wrote:
> 
> On Mon, 7 Jan 2002, Abramo Bagnara wrote:
> >
> > Just to resume, you think that the way to go is:
> >
> > 1) to have sound/ with *all* sound related stuff inside
> > 2) to leave drivers/net/ and net/ like they are now (because although
> > it's suboptimal, to change it is a mess we don't want to face now)
> 
> This is my current feeling.
> 
> However, la donna é mobile, and I'm a primus donna, fer shure. So don't
> take it _too_ seriously, continue to argue the merits of other approaches.

Ehm... Mrs. Prima Donna... just to be pedant, la donna *è* mobile ;-)

``E poi ti metteremo su un piedistallo per adorarti e ti guarderemo con
quello sguardo li' che conosci benissimo, quello sguardo che dice
"Cascherai prima o poi, puttana, e ti romperai il grugno''

Now you still have your antibodies, Linus, will you ever resist to
temptation? ;-)))

-- 
Abramo Bagnara                       mailto:abramo@alsa-project.org

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project               http://www.alsa-project.org
It sounds good!

Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel

[Pozsar Balazs]

> On Mon, 7 Jan 2002, Abramo Bagnara wrote:
> >
> > Just to resume, you think that the way to go is:
> >
> > 1) to have sound/ with *all* sound related stuff inside
> > 2) to leave drivers/net/ and net/ like they are now (because although
> > it's suboptimal, to change it is a mess we don't want to face now)
>
> This is my current feeling.
>
> However, la donna é mobile, and I'm a primus donna, fer shure. So don't
> take it _too_ seriously, continue to argue the merits of other approaches.


Well, I do think that doing a cleanup sooner is better than later as it
always gets bigger and bigger pain (both the change and keeping up the old
situation), so I would suggest to agree on a clear and consistent dirtree
now, and make that change whatever it is.

Though this is really not a big issue, it's still a great moment for this
kind of change imho.

-- 
Balazs Pozsar

Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel

[Jauder Ho]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1336 bytes --]


Well, that's kinda silly to have two different approaches. If the
consensus is to keep net/ and drivers/net/, why not just have sound/ and
drivers/sound/ too?

It is not a big stretch to grab sound/ and drivers/sound/ over just
sound/ and certainly the proposal of having a subsys/ directory is
essentially a rename of drivers/ to subsys/.

so....

net/
sound/
drivers/net/
drivers/sound/

The drivers subdir structure closely follows what happens one level up.
Not a problem and maintains the status quo. QED.

--Jauder

On Mon, 7 Jan 2002, Linus Torvalds wrote:

>
> On Mon, 7 Jan 2002, Abramo Bagnara wrote:
> >
> > Just to resume, you think that the way to go is:
> >
> > 1) to have sound/ with *all* sound related stuff inside
> > 2) to leave drivers/net/ and net/ like they are now (because although
> > it's suboptimal, to change it is a mess we don't want to face now)
>
> This is my current feeling.
>
> However, la donna é mobile, and I'm a primus donna, fer shure. So don't
> take it _too_ seriously, continue to argue the merits of other approaches.
>
> 		Linus
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>

Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel

[Pavel Machek]

Hi!

> > Just to resume, you think that the way to go is:
> >
> > 1) to have sound/ with *all* sound related stuff inside
> > 2) to leave drivers/net/ and net/ like they are now (because although
> > it's suboptimal, to change it is a mess we don't want to face now)
> 
> This is my current feeling.
> 
> However, la donna é mobile, and I'm a primus donna, fer shure. So don't
> take it _too_ seriously, continue to argue the merits of other approaches.

Where does USB soundcard go, then? It should be in drivers/usb by current
standards... Having sound drivers both inside and outside drivers/ seems
ugly to me.
									Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel

[Christoph Hellwig]

In article <3C39E6A0.34A88990@alsa-project.org> you wrote:
> If you want to keep top level cleaner and avoid proliferation of entries
> we might have:
>
> subsys/sound
> subsys/sound/drivers
> subsys/net
> subsys/net/drivers

And what part of the kernel is no subsystem?
Your subsystem directory is superflous.

If, for some reason, we want to move all code in the kernel around
we should do it once and in a planned mannor.

Randomly introducing new and shiny naming schemes sucks.  badly.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel

[Timothy Covell]

On Monday 07 January 2002 15:25, Christoph Hellwig wrote:
> In article <3C39E6A0.34A88990@alsa-project.org> you wrote:
> > If you want to keep top level cleaner and avoid proliferation of entries
> > we might have:
> >
> > subsys/sound
> > subsys/sound/drivers
> > subsys/net
> > subsys/net/drivers
>
> And what part of the kernel is no subsystem?
> Your subsystem directory is superflous.

Umm, the subsys part makes a lot of sense in terms of
logically separating the core of the kernel from the 
architecture part and the subsystem part.    While we 
need a MM to complete a kernel, we certainly don't need 
"subsys/sound/alsa/driver/es1371.c".

.
./arch
./fs
./init
./kernel
./lib
./mm
./include
./ipc
./subsys
./scripts
./Documentation


If this helps make the kernel source more like the modules
and devfs trees, then it makes even it more logically consistant.


Please remember that everyone who compiles a kernel is not
a uber kernel hacker.   Average folks will appreciate some more
structure which helps to explain how things work.

>
> If, for some reason, we want to move all code in the kernel around
> we should do it once and in a planned mannor.
>
> Randomly introducing new and shiny naming schemes sucks.  badly.

It's NOT random and it doesn't suck.

>
> 	Christoph

-- 
timothy.covell@ashavan.org.

Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel

[Miles Lane]

On Mon, 2002-01-07 at 13:25, Christoph Hellwig wrote:
> In article <3C39E6A0.34A88990@alsa-project.org> you wrote:
> > If you want to keep top level cleaner and avoid proliferation of entries
> > we might have:
> >
> > subsys/sound
> > subsys/sound/drivers
> > subsys/net
> > subsys/net/drivers
> 
> And what part of the kernel is no subsystem?
> Your subsystem directory is superflous.

Change subsys/ to some name that means "not device-specific".  
The point is that the net and sound system-level stuff isn't 
composed of device-specific drivers and the other directories 
below linux/ do not have a bunch of device-specific drivers 
associated with them (kernel, fs and mm).

> If, for some reason, we want to move all code in the kernel around
> we should do it once and in a planned manner.

Maybe a better structure is needed, but moving /net alone 
would be a big project.

	Miles