Hello all,
I would like to introduce the ALSA kernel patches URL:
ftp://ftp.alsa-project.org/pub/kernel-patches
The latest patch is alsa-2002-01-06-1-linux-2.5.2pre9.patch.gz and
contains:
* moved linux/drivers/sound directory to linux/sound/oss
* moved sound core files to linux/sound
* integrated ALSA kernel code
- linux/include/sound - sound header files
- linux/sound/core - midlevel (no hw dependent) code
- linux/sound/drivers - generic drivers (no arch dependent)
- linux/sound/i2c - reduced I2C core and drivers
- linux/sound/isa - ISA sound hardware drivers
- linux/sound/pci - PCI sound hardware drivers
- linux/sound/ppc - PowerPC sound hardware drivers
- linux/sound/synth - generic synthesizer support code
We appreciate any comments regarding directory structure (not being
finally approved by Linus due a lot of work on new BIO) or the ALSA
code itself. We are trying to separate the compatibility code for 2.2 and
2.4 kernels to other location in our CVS so the Linux kernel will
not be messed with this stuff.
If you post a reply or comment regarding ALSA to lkml, please, CC: me
directly or to our development mailing list <[email protected]>.
Yours,
Jaroslav
-----
Jaroslav Kysela <[email protected]>
SuSE Linux http://www.suse.com
ALSA Project http://www.alsa-project.org
In article <[email protected]> you wrote:
> The latest patch is alsa-2002-01-06-1-linux-2.5.2pre9.patch.gz and
> contains:
> * moved linux/drivers/sound directory to linux/sound/oss
> * moved sound core files to linux/sound
> * integrated ALSA kernel code
> - linux/include/sound - sound header files
> - linux/sound/core - midlevel (no hw dependent) code
> - linux/sound/drivers - generic drivers (no arch dependent)
> - linux/sound/i2c - reduced I2C core and drivers
> - linux/sound/isa - ISA sound hardware drivers
> - linux/sound/pci - PCI sound hardware drivers
> - linux/sound/ppc - PowerPC sound hardware drivers
> - linux/sound/synth - generic synthesizer support code
> We appreciate any comments regarding directory structure
linux/sound is silly. It's drivers so put it under linux/drivers/sound.
Everything else seems to be sane to me.
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
On Mon, Jan 07, 2002 at 03:32:18PM +0100, Christoph Hellwig wrote:
> In article <[email protected]> you wrote:
> > The latest patch is alsa-2002-01-06-1-linux-2.5.2pre9.patch.gz and
> > contains:
>
> > * moved linux/drivers/sound directory to linux/sound/oss
> > * moved sound core files to linux/sound
> > * integrated ALSA kernel code
> > - linux/include/sound - sound header files
> > - linux/sound/core - midlevel (no hw dependent) code
> > - linux/sound/drivers - generic drivers (no arch dependent)
> > - linux/sound/i2c - reduced I2C core and drivers
> > - linux/sound/isa - ISA sound hardware drivers
> > - linux/sound/pci - PCI sound hardware drivers
> > - linux/sound/ppc - PowerPC sound hardware drivers
> > - linux/sound/synth - generic synthesizer support code
>
> > We appreciate any comments regarding directory structure
>
> linux/sound is silly. It's drivers so put it under linux/drivers/sound.
> Everything else seems to be sane to me.
One question: What happens with hardware both available in both isa & pci
versions (or any other combination that doesn't fit into this
sorting?!)
/David
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
On Mon, 7 Jan 2002, Christoph Hellwig wrote:
>
> linux/sound is silly. It's drivers so put it under linux/drivers/sound.
That was my initial reaction too, but Jaroslav clearly wants a
higher-level generic hierarchy. Which means that we're not talking about
_drivers_ any more, we're talking about something that is much more
closely related to a "networking" kind of thing.
So we could have a net-based setup, where there would be a totally
separate "linux/sound" and "linux/drivers/sound". Which doesn't seem to
make much sense either.
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.
Linus
On Mon, Jan 07, 2002 at 09:02:39AM -0800, Linus Torvalds wrote:
> > linux/sound is silly. It's drivers so put it under linux/drivers/sound.
>
> That was my initial reaction too, but Jaroslav clearly wants a
> higher-level generic hierarchy. Which means that we're not talking about
> _drivers_ any more, we're talking about something that is much more
> closely related to a "networking" kind of thing.
If you look at the code it clearly is driver code.
> So we could have a net-based setup, where there would be a totally
> separate "linux/sound" and "linux/drivers/sound". Which doesn't seem to
> make much sense either.
If really wants that I'd go for this.
> Or we could just have a really _deep_ hierarchy, and put everything under
> "linux/drivers/sound/..",
Yes. From a maintaince view that is no different from the same
hierarchy under linux/sound, but introducing drivers (_lots_ of drivers)
outside linux/drivers is very stupid.
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
On Mon, 7 Jan 2002, David Weinehall wrote:
> On Mon, Jan 07, 2002 at 03:32:18PM +0100, Christoph Hellwig wrote:
> > In article <[email protected]> you wrote:
> > > The latest patch is alsa-2002-01-06-1-linux-2.5.2pre9.patch.gz and
> > > contains:
> >
> > > * moved linux/drivers/sound directory to linux/sound/oss
> > > * moved sound core files to linux/sound
> > > * integrated ALSA kernel code
> > > - linux/include/sound - sound header files
> > > - linux/sound/core - midlevel (no hw dependent) code
> > > - linux/sound/drivers - generic drivers (no arch dependent)
> > > - linux/sound/i2c - reduced I2C core and drivers
> > > - linux/sound/isa - ISA sound hardware drivers
> > > - linux/sound/pci - PCI sound hardware drivers
> > > - linux/sound/ppc - PowerPC sound hardware drivers
> > > - linux/sound/synth - generic synthesizer support code
> >
> > > We appreciate any comments regarding directory structure
> >
> > linux/sound is silly. It's drivers so put it under linux/drivers/sound.
> > Everything else seems to be sane to me.
>
> One question: What happens with hardware both available in both isa & pci
> versions (or any other combination that doesn't fit into this
> sorting?!)
Right, the directory structure is mostly informative only, because it is
possible to get parts from single directories. For example: ALS4000 driver
uses pci/als4000.c and isa/sb/sb_common.c code. Both source files are
used for compilation. We can optimize Makefiles further for an exact
specification of such hardware cross-references and reduce directory
passes when cross-references are not active.
If you look to the Makefiles, there is (for ALS4000):
linux/sound/isa/sb/Makefile:
obj-$(CONFIG_SND_ALS4000) += snd-sb-common.o
linux/sound/pci/Makefile:
obj-$(CONFIG_SND_ALS4000) += snd-als4000.o
If something does not fit: we can create a new subdirectory.
Jaroslav
-----
Jaroslav Kysela <[email protected]>
SuSE Linux http://www.suse.com
ALSA Project http://www.alsa-project.org
> 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
On Mon, 7 Jan 2002, Linus Torvalds wrote:
> So we could have a net-based setup, where there would be a totally
> separate "linux/sound" and "linux/drivers/sound". Which doesn't seem to
> make much sense either.
If I want to find the code for an emu10k1 driver, intuition tells me
its a sound _driver_, so drivers/ would be the first place I (and no
doubt others) would look.
'core' sound stuff in linux/sound, with _driver_ specifics in
drivers/sound sounds perfectly sensible to me.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Mon, 7 Jan 2002, Christoph Hellwig wrote:
> On Mon, Jan 07, 2002 at 09:02:39AM -0800, Linus Torvalds wrote:
> > > linux/sound is silly. It's drivers so put it under linux/drivers/sound.
> >
> > That was my initial reaction too, but Jaroslav clearly wants a
> > higher-level generic hierarchy. Which means that we're not talking about
> > _drivers_ any more, we're talking about something that is much more
> > closely related to a "networking" kind of thing.
>
> If you look at the code it clearly is driver code.
What is code in linux/sound/core then? This midlevel code is shared
with all drivers and definitely belongs to same place like
linux/net/core.
Jaroslav
-----
Jaroslav Kysela <[email protected]>
SuSE Linux http://www.suse.com
ALSA Project http://www.alsa-project.org
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
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
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:[email protected]
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!
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
Hi,
There's a compile error in the "RTC Timer Support"
See below for details
Bye
[...]
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O6 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -DKBUILD_BASENAME=rtctimer -DEXPORT_SYMTAB -c rtctimer.c
rtctimer.c:75: parse error before `rtc_task'
rtctimer.c:75: warning: type defaults to `int' in declaration of `rtc_task'
rtctimer.c:75: warning: data definition has no type or storage class
rtctimer.c: In function `rtctimer_start':
rtctimer.c:99: `rtc_task_t' undeclared (first use in this function)
rtctimer.c:99: (Each undeclared identifier is reported only once
rtctimer.c:99: for each function it appears in.)
rtctimer.c:99: `rtc' undeclared (first use in this function)
rtctimer.c:101: warning: implicit declaration of function `rtc_control'
rtctimer.c: In function `rtctimer_stop':
rtctimer.c:110: `rtc_task_t' undeclared (first use in this function)
rtctimer.c:110: `rtc' undeclared (first use in this function)
rtctimer.c: In function `rtctimer_interrupt':
rtctimer.c:123: warning: implicit declaration of function `tasklet_hi_schedule' rtctimer.c: In function `rtctimer_private_free':
rtctimer.c:143: `rtc_task_t' undeclared (first use in this function)
rtctimer.c:143: `rtc' undeclared (first use in this function)
rtctimer.c:145: warning: implicit declaration of function `rtc_unregister'
rtctimer.c: In function `rtctimer_init':
rtctimer.c:174: warning: implicit declaration of function `tasklet_init'
rtctimer.c:182: request for member `func' in something not a structure or union rtctimer.c:183: request for member `private_data' in something not a structure or union
rtctimer.c:184: warning: implicit declaration of function `rtc_register'
rtctimer.c: At top level:
rtctimer.c:79: storage size of `rtc_tq' isn't known
make[3]: *** [rtctimer.o] Fehler 1
[...]
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:[email protected]
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!
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
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:[email protected]
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!
> 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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
Sebastian Dr?ge <[email protected]> writes:
> There's a compile error in the "RTC Timer Support"
> See below for details
needed patch is in utils/patches
In article <[email protected]> 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.
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:[email protected]
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
On Monday 07 January 2002 15:25, Christoph Hellwig wrote:
> In article <[email protected]> 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
--
[email protected].
On Mon, 2002-01-07 at 10:00, 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).
I like the layout proposed by Alan. All the other device-specific
drivers I use are under linux/drivers. Doing something else with
the sound drivers 1) breaks with the OSS layout, which we are
used to, and 2) would be an anomaly within the tree. Confusion
would definitely follow for newbie kernel builders and people
transitioning to 2.6, when it is released.
One additional change that might help make the nature of the
linux/net and linux/sound directories more obvious could be
to move them both into linux/system/. That way the hierarchy
indicates the purpose and similar nature of code in these
two directories.
Miles
On Mon, 2002-01-07 at 13:25, Christoph Hellwig wrote:
> In article <[email protected]> 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
> 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) ?
> 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
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
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
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.