ALSA patch for 2.5.2pre9 kernel

ALSA patch for 2.5.2pre9 kernel

[Jaroslav Kysela]

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 <alsa-devel@alsa-project.org>.

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

[Christoph Hellwig]

In article <Pine.LNX.4.31.0201061814580.545-100000@pnote.perex-int.cz> 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.

Re: ALSA patch for 2.5.2pre9 kernel

[David Weinehall]

On Mon, Jan 07, 2002 at 03:32:18PM +0100, Christoph Hellwig wrote:
> In article <Pine.LNX.4.31.0201061814580.545-100000@pnote.perex-int.cz> 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 <tao@acc.umu.se> /> Northern lights wander      \\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: ALSA patch for 2.5.2pre9 kernel

[Jaroslav Kysela]

On Mon, 7 Jan 2002, David Weinehall wrote:

> On Mon, Jan 07, 2002 at 03:32:18PM +0100, Christoph Hellwig wrote:
> > In article <Pine.LNX.4.31.0201061814580.545-100000@pnote.perex-int.cz> 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 <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA Project  http://www.alsa-project.org

Re: ALSA patch for 2.5.2pre9 kernel

[Linus Torvalds]

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

Re: ALSA patch for 2.5.2pre9 kernel

[Christoph Hellwig]

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.

Re: ALSA patch for 2.5.2pre9 kernel

[Jaroslav Kysela]

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 <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA Project  http://www.alsa-project.org

Re: ALSA patch for 2.5.2pre9 kernel

[Dave Jones]

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

Re: ALSA patch for 2.5.2pre9 kernel

[Alan Cox]

> 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

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: 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: ALSA patch for 2.5.2pre9 kernel

[Sebastian Dröge]

[-- Attachment #1.1: Type: text/plain, Size: 1910 bytes --]

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

[-- Attachment #1.2: .config --]
[-- Type: application/octet-stream, Size: 21355 bytes --]

#
# Automatically generated by make menuconfig: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
CONFIG_M686=y
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_PPRO_FENCE=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=y
# CONFIG_X86_CPUID is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_SMP is not set
CONFIG_X86_UP_APIC=y
# CONFIG_X86_UP_IOAPIC is not set
CONFIG_X86_LOCAL_APIC=y

#
# General setup
#
CONFIG_NET=y
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
CONFIG_PCI_GODIRECT=y
# CONFIG_PCI_GOANY is not set
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_HOTPLUG is not set
# CONFIG_PCMCIA is not set
# CONFIG_HOTPLUG_PCI is not set
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_PM=y
# CONFIG_ACPI is not set
CONFIG_APM=y
CONFIG_APM_IGNORE_USER_SUSPEND=y
CONFIG_APM_DO_ENABLE=y
CONFIG_APM_CPU_IDLE=y
CONFIG_APM_DISPLAY_BLANK=y
# CONFIG_APM_RTC_IS_GMT is not set
# CONFIG_APM_ALLOW_INTS is not set
CONFIG_APM_REAL_MODE_POWER_OFF=y

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play configuration
#
CONFIG_PNP=y
# CONFIG_ISAPNP is not set
CONFIG_PNPBIOS=y

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_BLK_DEV_LOOP=m
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_BLK_DEV_INITRD is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
# CONFIG_BLK_DEV_MD is not set
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID5 is not set
# CONFIG_MD_MULTIPATH is not set
# CONFIG_BLK_DEV_LVM is not set

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
# CONFIG_NETLINK_DEV is not set
# CONFIG_NETFILTER is not set
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_INET_ECN=y
CONFIG_SYN_COOKIES=y
# CONFIG_IPV6 is not set
# CONFIG_KHTTPD is not set
# CONFIG_ATM is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set
# CONFIG_PHONE_IXJ is not set
# CONFIG_PHONE_IXJ_PCMCIA is not set

#
# ATA/IDE/MFM/RLL support
#
CONFIG_IDE=y

#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=y
# CONFIG_BLK_DEV_HD_IDE is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
# CONFIG_BLK_DEV_IDEDISK_VENDOR is not set
# CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set
# CONFIG_BLK_DEV_IDEDISK_IBM is not set
# CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set
# CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set
# CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set
# CONFIG_BLK_DEV_IDEDISK_WD is not set
# CONFIG_BLK_DEV_COMMERIAL is not set
# CONFIG_BLK_DEV_TIVO is not set
# CONFIG_BLK_DEV_IDECS is not set
# CONFIG_BLK_DEV_IDECD is not set
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
CONFIG_BLK_DEV_IDESCSI=y
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
# CONFIG_BLK_DEV_ISAPNP is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_BLK_DEV_ADMA=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_PCI_WIP is not set
# CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_AEC62XX_TUNING is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_WDC_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_AMD74XX_OVERRIDE is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_HPT34X_AUTODMA is not set
# CONFIG_BLK_DEV_HPT366 is not set
CONFIG_BLK_DEV_PIIX=y
CONFIG_PIIX_TUNING=y
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_PDC202XX is not set
# CONFIG_PDC202XX_BURST is not set
# CONFIG_PDC202XX_FORCE is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_IDEDMA_AUTO=y
CONFIG_IDEDMA_IVB=y
# CONFIG_DMA_NONPCI is not set
CONFIG_BLK_DEV_IDE_MODES=y
# CONFIG_BLK_DEV_ATARAID is not set
# CONFIG_BLK_DEV_ATARAID_PDC is not set
# CONFIG_BLK_DEV_ATARAID_HPT is not set

#
# SCSI support
#
CONFIG_SCSI=y
# CONFIG_BLK_DEV_SD is not set
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=y
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_SR_EXTRA_DEVS=2
CONFIG_CHR_DEV_SG=y
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AHA1740 is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_AM53C974 is not set
# CONFIG_SCSI_MEGARAID is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_CPQFCTS is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_DMA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_NCR53C7xx is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_NCR53C8XX is not set
# CONFIG_SCSI_SYM53C8XX is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PCI2000 is not set
# CONFIG_SCSI_PCI2220I is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_SEAGATE is not set
# CONFIG_SCSI_SIM710 is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_DEBUG is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_BOOT is not set
# CONFIG_FUSION_ISENSE is not set
# CONFIG_FUSION_CTL is not set
# CONFIG_FUSION_LAN is not set

#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set
# CONFIG_I2O_PCI is not set
# CONFIG_I2O_BLOCK is not set
# CONFIG_I2O_LAN is not set
# CONFIG_I2O_SCSI is not set
# CONFIG_I2O_PROC is not set

#
# Network device support
#
CONFIG_NETDEVICES=y

#
# ARCnet devices
#
# CONFIG_ARCNET is not set
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_ETHERTAP is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_SUNLANCE is not set
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNBMAC is not set
# CONFIG_SUNQE is not set
# CONFIG_SUNLANCE is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_CS89x0 is not set
# CONFIG_DE2104X is not set
# CONFIG_TULIP is not set
# CONFIG_DE4X5 is not set
# CONFIG_DGRS is not set
CONFIG_DM9102=y
# CONFIG_EEPRO100 is not set
# CONFIG_LNE390 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_NE3210 is not set
# CONFIG_ES3210 is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_VIA_RHINE_MMIO is not set
# CONFIG_WINBOND_840 is not set
# CONFIG_NET_POCKET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_MYRI_SBUS is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_SK98LIN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set
# CONFIG_NET_FC is not set
# CONFIG_RCPCI is not set
# CONFIG_SHAPER is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set

#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Input core support
#
CONFIG_INPUT=y
CONFIG_INPUT_KEYBDEV=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
# CONFIG_SERIAL is not set
# CONFIG_SERIAL_EXTENDED is not set
# CONFIG_SERIAL_NONSTANDARD is not set
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256

#
# I2C support
#
# CONFIG_I2C is not set

#
# Mice
#
# CONFIG_BUSMOUSE is not set
CONFIG_MOUSE=y
CONFIG_PSMOUSE=y
# CONFIG_82C710_MOUSE is not set
# CONFIG_PC110_PAD is not set

#
# Joysticks
#
# CONFIG_INPUT_GAMEPORT is not set
# CONFIG_INPUT_NS558 is not set
# CONFIG_INPUT_LIGHTNING is not set
# CONFIG_INPUT_PCIGAME is not set
# CONFIG_INPUT_CS461X is not set
# CONFIG_INPUT_EMU10K1 is not set
# CONFIG_INPUT_SERIO is not set
# CONFIG_INPUT_SERPORT is not set
# CONFIG_INPUT_ANALOG is not set
# CONFIG_INPUT_A3D is not set
# CONFIG_INPUT_ADI is not set
# CONFIG_INPUT_COBRA is not set
# CONFIG_INPUT_GF2K is not set
# CONFIG_INPUT_GRIP is not set
# CONFIG_INPUT_INTERACT is not set
# CONFIG_INPUT_TMDC is not set
# CONFIG_INPUT_SIDEWINDER is not set
# CONFIG_INPUT_IFORCE_USB is not set
# CONFIG_INPUT_IFORCE_232 is not set
# CONFIG_INPUT_WARRIOR is not set
# CONFIG_INPUT_MAGELLAN is not set
# CONFIG_INPUT_SPACEORB is not set
# CONFIG_INPUT_SPACEBALL is not set
# CONFIG_INPUT_STINGER is not set
# CONFIG_INPUT_DB9 is not set
# CONFIG_INPUT_GAMECON is not set
# CONFIG_INPUT_TURBOGRAFX is not set
# CONFIG_QIC02_TAPE is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_INTEL_RNG is not set
CONFIG_NVRAM=m
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=y
CONFIG_AGP_INTEL=y
# CONFIG_AGP_I810 is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_SWORKS is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# File systems
#
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_ADFS_FS is not set
# CONFIG_ADFS_FS_RW is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EXT3_FS is not set
# CONFIG_JBD is not set
# CONFIG_JBD_DEBUG is not set
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
# CONFIG_UMSDOS_FS is not set
CONFIG_VFAT_FS=m
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
# CONFIG_JFFS2_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_TMPFS is not set
CONFIG_RAMFS=y
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
# CONFIG_MINIX_FS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_NTFS_FS is not set
# CONFIG_NTFS_RW is not set
# CONFIG_HPFS_FS is not set
CONFIG_PROC_FS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVFS_MOUNT is not set
# CONFIG_DEVFS_DEBUG is not set
CONFIG_DEVPTS_FS=y
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX4FS_RW is not set
# CONFIG_ROMFS_FS is not set
CONFIG_EXT2_FS=y
# CONFIG_SYSV_FS is not set
# CONFIG_UDF_FS is not set
# CONFIG_UDF_RW is not set
# CONFIG_UFS_FS is not set
# CONFIG_UFS_FS_WRITE is not set

#
# Network File Systems
#
# CONFIG_CODA_FS is not set
# CONFIG_INTERMEZZO_FS is not set
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_ROOT_NFS is not set
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_SMB_FS=m
# CONFIG_SMB_NLS_DEFAULT is not set
# CONFIG_NCP_FS is not set
# CONFIG_NCPFS_PACKET_SIGNING is not set
# CONFIG_NCPFS_IOCTL_LOCKING is not set
# CONFIG_NCPFS_STRONG is not set
# CONFIG_NCPFS_NFS_NS is not set
# CONFIG_NCPFS_OS2_NS is not set
# CONFIG_NCPFS_SMALLDOS is not set
# CONFIG_NCPFS_NLS is not set
# CONFIG_NCPFS_EXTRAS is not set
CONFIG_ZISOFS_FS=m
CONFIG_ZLIB_FS_INFLATE=m

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_SMB_NLS=y
CONFIG_NLS=y

#
# Native Language Support
#
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=m
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=m
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=m

#
# Console drivers
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VIDEO_SELECT is not set
# CONFIG_MDA_CONSOLE is not set

#
# Frame-buffer support
#
# CONFIG_FB is not set

#
# Sound
#
CONFIG_SOUND=y

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=y
CONFIG_SND_RTCTIMER=y
CONFIG_SND_SEQUENCER=y
# CONFIG_SND_SEQ_DUMMY is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
# CONFIG_SND_SEQUENCER_OSS is not set
# CONFIG_SND_DEBUG is not set
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
# CONFIG_SND_AD1816A is not set
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_ES968 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_INTERWAVE is not set
# CONFIG_SND_INTERWAVE_STB is not set
# CONFIG_SND_OPTI92X_AD1848 is not set
# CONFIG_SND_OPTI92X_CS4231 is not set
# CONFIG_SND_OPTI93X is not set
# CONFIG_SND_SB8 is not set
# CONFIG_SND_SB16 is not set
# CONFIG_SND_SBAWE is not set
# CONFIG_SND_WAVEFRONT is not set
# CONFIG_SND_ALS100 is not set
# CONFIG_SND_AZT2320 is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_DT0197H is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ENS1370 is not set
CONFIG_SND_ENS1371=y
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_VIA686 is not set
# CONFIG_SND_VIA8233 is not set

#
# USB support
#
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_LONG_TIMEOUT is not set
# CONFIG_USB_EHCI_HCD is not set
CONFIG_USB_UHCI_ALT=y
# CONFIG_USB_OHCI is not set
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_BLUETOOTH is not set
# CONFIG_USB_STORAGE is not set
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_HP8200e is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
CONFIG_USB_HID=y
# CONFIG_USB_HIDDEV is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_DC2XX is not set
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_SCANNER is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_HPUSBSCSI is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_CATC is not set
# CONFIG_USB_CDCETHER is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_USS720 is not set

#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set
# CONFIG_USB_SERIAL_GENERIC is not set
# CONFIG_USB_SERIAL_BELKIN is not set
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_EMPEG is not set
# CONFIG_USB_SERIAL_FTDI_SIO is not set
# CONFIG_USB_SERIAL_VISOR is not set
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA28 is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA28X is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA28XA is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA28XB is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA19 is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA18X is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA19W is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA49W is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
# CONFIG_USB_SERIAL_KLSI is not set
# CONFIG_USB_SERIAL_PL2303 is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OMNINET is not set
# CONFIG_USB_RIO500 is not set

#
# Bluetooth support
#
# CONFIG_BLUEZ is not set

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_HIGHMEM is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_IOVIRT is not set
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
# CONFIG_DEBUG_486_STRING is not set

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: ALSA patch for 2.5.2pre9 kernel

[Thierry Vignaud]

Sebastian Dröge <sebastian.droege@gmx.de> writes:

> There's a compile error in the "RTC Timer Support"
> See below for details

needed patch is in utils/patches

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

Re: ALSA patch for 2.5.2pre9 kernel

[Miles Lane]

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

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

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

[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