ALSA patch for 2.5.2pre9 kernel
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 10 lines · On 20020108 Linus Torvalds wrote:
Quoted 8 lines · Alan Cox
Quoted 7 lines
Would't it be better to split drivers:
sound/core.csound/alsa/alsa-core.csound/alsa/drivers/alsa-emu10k.csound/oss/oss-core.csound/oss/drivers/oss-emu10k.c
Quoted 5 lines
Quoted 2 lines
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.csound/drivers/alsa-driver.c
By
/juan
Signature · 4 lines
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-pre2-beo #1 SMP Tue Jan 8 03:18:18 CET 2002 i686
Quoted 25 lines · J.A. Magallon
Quoted 10 lines · On 20020108 Linus Torvalds wrote:
Quoted 8 lines · Alan Cox
Quoted 7 lines
Would't it be better to split drivers:
sound/core.csound/alsa/alsa-core.csound/alsa/drivers/alsa-emu10k.csound/oss/oss-core.csound/oss/drivers/oss-emu10k.cQuoted 5 lines
Quoted 2 lines
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
Quoted 2 lines
sound/alsa-core.csound/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_nativesound/oss_emulsound/synthsound/includedrivers/sound/i2cdrivers/sound/isadrivers/sound/pcidrivers/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? ;-)
Signature · 8 lines
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!
At Tue, 08 Jan 2002 10:52:16 +0100,
Quoted 33 lines · Abramo
Quoted 25 lines · J.A. Magallon
Quoted 10 lines · On 20020108 Linus Torvalds wrote:
Quoted 8 lines · Alan Cox
Quoted 7 lines
Would't it be better to split drivers:
sound/core.csound/alsa/alsa-core.csound/alsa/drivers/alsa-emu10k.csound/oss/oss-core.csound/oss/drivers/oss-emu10k.cQuoted 5 lines
Quoted 2 lines
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 withQuoted 2 lines
sound/alsa-core.csound/drivers/alsa-driver.cI 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).
Quoted 10 lines
So we'd have:
sound/sound/oss_nativesound/oss_emulsound/synthsound/includedrivers/sound/i2cdrivers/sound/isadrivers/sound/pcidrivers/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?
Quoted 8 lines
I still have some doubts about hardware specific include files:
a)sound/include
b)drivers/sound/{i2c,isa,pci,ppc}
c)drivers/sound/includeCurrently 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
Quoted 61 lines · Takashi Iwai
At Tue, 08 Jan 2002 10:52:16 +0100,
Quoted 33 lines · Abramo
Quoted 25 lines · J.A. Magallon
Quoted 10 lines · On 20020108 Linus Torvalds wrote:
Quoted 8 lines · Alan Cox
Quoted 7 lines
Would't it be better to split drivers:
sound/core.csound/alsa/alsa-core.csound/alsa/drivers/alsa-emu10k.csound/oss/oss-core.csound/oss/drivers/oss-emu10k.cQuoted 5 lines
Quoted 2 lines
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 withQuoted 2 lines
sound/alsa-core.csound/drivers/alsa-driver.cI 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).
Quoted 10 lines
So we'd have:
sound/sound/oss_nativesound/oss_emulsound/synthsound/includedrivers/sound/i2cdrivers/sound/isadrivers/sound/pcidrivers/sound/ppcOn 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 intodrivers/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/genericfor generic hardware codes such asac97_codec.c?Quoted 5 lines
I still have some doubts about hardware specific include files:
a)sound/include
b)drivers/sound/{i2c,isa,pci,ppc}
c)drivers/sound/include
Quoted 6 lines
Quoted 3 lines
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 <[email protected]>
SuSE Linux http://www.suse.com
ALSA Project http://www.alsa-project.org
At Tue, 8 Jan 2002 11:18:34 +0100 (CET),
Quoted 13 lines · Jaroslav
Quoted 10 lines · Takashi Iwai
Quoted 9 lines
I still have some doubts about hardware specific include files:
a)sound/include
b)drivers/sound/{i2c,isa,pci,ppc}
c)drivers/sound/includeCurrently 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)
Quoted 5 lines
Quoted 2 lines
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
Quoted 8 lines · Jaroslav Kysela
Quoted 2 lines · Takashi Iwai
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).
Signature · 8 lines
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!
Quoted 10 lines · Abramo Bagnara
Quoted 8 lines · Jaroslav Kysela
Quoted 2 lines · Takashi Iwai
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.
Quoted 7 lines
Don't you think it's better to split this in "external" headers (placed in
include/soundtogether withasound.h) and "internal" ones (placed indrivers/*/)?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 <[email protected]>
SuSE Linux http://www.suse.com
ALSA Project http://www.alsa-project.org
Quoted 16 lines · Takashi Iwai
At Tue, 08 Jan 2002 10:52:16 +0100,
Quoted 12 lines · Abramo
So we'd have:
sound/sound/oss_nativesound/oss_emulsound/synthsound/includedrivers/sound/i2cdrivers/sound/isadrivers/sound/pcidrivers/sound/ppc
Quoted 2 lines
On the list above, to where OSS (hw specific) codes come? Into a single directory,
sound/oss_native?
Yes
Quoted 4 lines
Or both ALSA and OSS drivers are
mixed intodrivers/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?
Quoted 3 lines
And how about
drivers/sound/genericfor generic hardware codes such asac97_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).
Signature · 8 lines
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!
Quoted 6 lines · Abramo Bagnara
Quoted 2 lines
And how about
drivers/sound/genericfor generic hardware codes such asac97_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 <[email protected]>
SuSE Linux http://www.suse.com
ALSA Project http://www.alsa-project.org