All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rene Herman <rene.herman@keyaccess.nl>
To: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.de>,
	ALSA development <alsa-devel@alsa-project.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Jeff Garzik <jeff@garzik.org>
Subject: Re: Moving sound/* to drivers/ ?
Date: Thu, 22 May 2008 10:11:45 +0200	[thread overview]
Message-ID: <48352AC1.9000501@keyaccess.nl> (raw)
In-Reply-To: <Pine.LNX.4.61.0805220809370.1798@tm8103-a.perex-int.cz>

On 22-05-08 08:26, Jaroslav Kysela wrote:

> On Thu, 22 May 2008, Rene Herman wrote:

>> From a structural view, the PCM core is just as much not a driver
>> as the IP protocol isn't one and moving all of sound/ to drivers/
>> would trade the current "why are the drivers not under drivers/?"
>> issue for a "why is all this non-driver code under drivers/?".
>> 
>> This "net model" of sound/ and drivers/sound/ would be cleanest I
>> feel.
> 
> Yes, it was one reason why I used 'sound/' as root of the ALSA tree.
> The second reason was to move old OSS tree to new directory to make
> less confusion. And the third reason was to just keep ALSA directory
> same as in our local development tree (which is out-of-kernel tree -
> containing only ALSA parts).
> 
> I feel that from the maintenance perspective, having one directory is
> a plus. We have already 'drivers/usb/core', 'mmc/core',
> 'drivers/base' (ALSA toplevel and midlevel modules use functions from
> this tree) etc.

Yes, examples of the same thing. drivers/base still sort of fits, but yes.

Would the maintenance be really helped? As you said in another reply, 
the external tree already shuffles Documentation/sound/alsa and 
include/sound around anyway.

I don't feel very strongly about it or anything but it's also a kernel 
statistics issue. Linus for example frequently announces new -rc's with 
"90% is in drivers" and such and if large(r) parts of drivers/ consist 
not of driver code that's a less useful metric.

> If we have general consensus that sound drivers should go to back to 
> 'drivers/sound' then I would move all code. We can move 'sound/core'
> tree to '/sound' in next round later...

I'd expect that if you give up your nice top level directory you're not 
getting it back later... :-)

Rene.

WARNING: multiple messages have this Message-ID (diff)
From: Rene Herman <rene.herman@keyaccess.nl>
To: Jaroslav Kysela <perex@perex.cz>
Cc: Jeff Garzik <jeff@garzik.org>, Takashi Iwai <tiwai@suse.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	ALSA development <alsa-devel@alsa-project.org>
Subject: Re: Moving sound/* to drivers/ ?
Date: Thu, 22 May 2008 10:11:45 +0200	[thread overview]
Message-ID: <48352AC1.9000501@keyaccess.nl> (raw)
In-Reply-To: <Pine.LNX.4.61.0805220809370.1798@tm8103-a.perex-int.cz>

On 22-05-08 08:26, Jaroslav Kysela wrote:

> On Thu, 22 May 2008, Rene Herman wrote:

>> From a structural view, the PCM core is just as much not a driver
>> as the IP protocol isn't one and moving all of sound/ to drivers/
>> would trade the current "why are the drivers not under drivers/?"
>> issue for a "why is all this non-driver code under drivers/?".
>> 
>> This "net model" of sound/ and drivers/sound/ would be cleanest I
>> feel.
> 
> Yes, it was one reason why I used 'sound/' as root of the ALSA tree.
> The second reason was to move old OSS tree to new directory to make
> less confusion. And the third reason was to just keep ALSA directory
> same as in our local development tree (which is out-of-kernel tree -
> containing only ALSA parts).
> 
> I feel that from the maintenance perspective, having one directory is
> a plus. We have already 'drivers/usb/core', 'mmc/core',
> 'drivers/base' (ALSA toplevel and midlevel modules use functions from
> this tree) etc.

Yes, examples of the same thing. drivers/base still sort of fits, but yes.

Would the maintenance be really helped? As you said in another reply, 
the external tree already shuffles Documentation/sound/alsa and 
include/sound around anyway.

I don't feel very strongly about it or anything but it's also a kernel 
statistics issue. Linus for example frequently announces new -rc's with 
"90% is in drivers" and such and if large(r) parts of drivers/ consist 
not of driver code that's a less useful metric.

> If we have general consensus that sound drivers should go to back to 
> 'drivers/sound' then I would move all code. We can move 'sound/core'
> tree to '/sound' in next round later...

I'd expect that if you give up your nice top level directory you're not 
getting it back later... :-)

Rene.

  parent reply	other threads:[~2008-05-22  8:09 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-21 21:20 Moving sound/* to drivers/ ? Takashi Iwai
2008-05-21 21:20 ` Takashi Iwai
2008-05-21 21:44 ` Linus Torvalds
2008-05-21 21:44   ` Linus Torvalds
2008-05-21 21:54   ` Sam Ravnborg
2008-05-21 21:54     ` Sam Ravnborg
2008-05-21 21:58   ` Rene Herman
2008-05-21 21:58     ` [alsa-devel] " Rene Herman
2008-05-21 22:08     ` Rene Herman
2008-05-21 23:21   ` Moving include/asm-* [was: Re: Moving sound/* to drivers/ ?] Paul Mackerras
2008-05-21 23:51     ` Linus Torvalds
2008-05-22  0:56       ` Al Viro
2008-05-22  1:20         ` Linus Torvalds
2008-05-22  1:23           ` Moving include/asm-* David Miller
2008-05-22  8:09             ` Andreas Schwab
2008-05-22 16:12               ` David Miller
2008-05-22 16:32                 ` Andreas Schwab
2008-05-22 17:43                   ` David Miller
2008-05-22  1:23           ` Moving include/asm-* [was: Re: Moving sound/* to drivers/ ?] Harvey Harrison
2008-05-22  1:25             ` Moving include/asm-* David Miller
2008-05-22  1:29             ` Moving include/asm-* [was: Re: Moving sound/* to drivers/ ?] Linus Torvalds
2008-05-22  1:36               ` Al Viro
2008-05-22  4:20               ` Jeff Dike
2008-05-22  5:26                 ` Al Viro
2008-05-22 16:27                   ` Jeff Dike
2008-05-22 17:18                   ` Sam Ravnborg
2008-05-22  1:30           ` Al Viro
2008-05-22 22:52             ` Arnd Bergmann
2008-05-21 22:05 ` Moving sound/* to drivers/ ? Timur Tabi
2008-05-21 22:05   ` [alsa-devel] " Timur Tabi
2008-05-21 22:23 ` Adrian Bunk
2008-05-22  8:22   ` Takashi Iwai
2008-05-22  8:22     ` Takashi Iwai
2008-05-21 23:37 ` Jeff Garzik
2008-05-21 23:53   ` Rene Herman
2008-05-21 23:53     ` Rene Herman
2008-05-22  6:26     ` Jaroslav Kysela
2008-05-22  6:26       ` Jaroslav Kysela
2008-05-22  7:12       ` Sam Ravnborg
2008-05-22  7:12         ` Sam Ravnborg
2008-05-22  7:20         ` Jaroslav Kysela
2008-05-22  7:20           ` Jaroslav Kysela
2008-05-22  8:11       ` Rene Herman [this message]
2008-05-22  8:11         ` Rene Herman
2008-05-22  8:27     ` Takashi Iwai
2008-05-22  8:27       ` Takashi Iwai
2008-05-22  8:55       ` Jan Engelhardt
2008-05-22 15:04         ` Linus Torvalds
2008-05-22 15:04           ` Linus Torvalds
2008-05-22 15:50           ` Jan Engelhardt
2008-05-22 16:40           ` Rene Herman
2008-05-22 16:40             ` Rene Herman
2008-05-22  9:57       ` Rene Herman
2008-05-22  9:57         ` Rene Herman
2008-05-22 14:22       ` Adrian Bunk
2008-05-22 14:22         ` Adrian Bunk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48352AC1.9000501@keyaccess.nl \
    --to=rene.herman@keyaccess.nl \
    --cc=alsa-devel@alsa-project.org \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=tiwai@suse.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.