"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:[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 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 <[email protected]>
SuSE Linux http://www.suse.com
ALSA Project http://www.alsa-project.org
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
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
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:[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 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 <[email protected]>
SuSE Linux http://www.suse.com
ALSA Project http://www.alsa-project.org