snd_ prefix for module options

snd_ prefix for module options

[Takashi Iwai]

Hi,

so far, all alsa modules use snd_ prefix for each module option.
iirc, there was a problem regarding namespace at the time of 2.0
kernel, and this was some workaround to avoid confliction.
but 2.2 and later kernels have no such a problem at all.

so, i'd like to ask you how do you think to remove this snd_ prefix.
of course, there is one and only big problem - compatibility!


the questions are

- whether we should really do it or not?  is it worthy?

and

- when? now or after 0.9.0-final release?


opinions, please?


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: snd_ prefix for module options

[Peter L Jones]

On Tuesday 08 Oct 2002 15:04, Takashi Iwai wrote:
[snip]
> so, i'd like to ask you how do you think to remove this snd_ prefix.
> of course, there is one and only big problem - compatibility!
>
>
> the questions are
>
> - whether we should really do it or not?  is it worthy?

Yes - I find it confusing: it's not like everything else in the kernel.

>
> and
>
> - when? now or after 0.9.0-final release?

Now, before too many distros have picked up 0.9.0-final.

>
>
> opinions, please?
>
IMHO :-)

-- Peter


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: snd_ prefix for module options

[Florian Bomers]

I like it a lot. Due to the prefix I was able to cleanly remove 0.5.x from my
system, and we might want to do that later on with 0.9, too :)

And since I don't see any benefit in removing the prefix - other than cosmetic -
keeping it will save time for distribution's programmers, sysadmins, writers,
etc. to update their setup routines, configs, howtos, etc. :)

Florian


Takashi Iwai wrote:
> 
> Hi,
> 
> so far, all alsa modules use snd_ prefix for each module option.
> iirc, there was a problem regarding namespace at the time of 2.0
> kernel, and this was some workaround to avoid confliction.
> but 2.2 and later kernels have no such a problem at all.
> 
> so, i'd like to ask you how do you think to remove this snd_ prefix.
> of course, there is one and only big problem - compatibility!
> 
> the questions are
> 
> - whether we should really do it or not?  is it worthy?
> 
> and
> 
> - when? now or after 0.9.0-final release?
> 
> opinions, please?
> 
> Takashi
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel

-- 
Florian Bomers
Java Sound
Java Software/Sun Microsystems, Inc.
http://java.sun.com/products/java-media/sound/


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: snd_ prefix for module options

[Chris Rankin]

 --- Takashi Iwai <tiwai@suse.de> wrote: > Hi,
> so, i'd like to ask you how do you think to remove
> this snd_ prefix.
> of course, there is one and only big problem -
> compatibility!

I think it's a worthy goal. It's just noise in
modules.conf, of course. Irritating, but no more than
that. What concerns me more is when you compile ALSA
directly into the kernel. To pass the options NOW
requires a boot-time parameter list:

alsa-module-name=snd_this=x,snd_that=y,snd_the_other=z

Every "snd_" here wastes 4 precious bytes on the
kernel's command line. Now I don't know what the
maximum length of the command line is, but I'm sure
I've reached it before. (And had the trailing options
silently ignored.) I think economy is only polite with
such a limited resource.

As for "when", I'd say that the longer you wait, the
greater the pain. I have a fairly complicated setup,
and the extent of my pain would be here:

options snd snd_cards_limit=2
options snd-card-0 snd_index=0
options snd-card-1 snd_index=1 snd_mpu_port=0x330

(Aren't PCI devices nice :-)?) I guess the worst hit
would be people with ISA sound cards.

Chris


__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: snd_ prefix for module options

[Florian Bomers]

Sorry guys, I thought you were talking about the snd_ prefix of the module NAMES
:) for the option names, dropping seems the right thing to do - an error message
should be printed when a snd_* option is used.

Florian


Florian Bomers wrote:
> 
> I like it a lot. Due to the prefix I was able to cleanly remove 0.5.x from my
> system, and we might want to do that later on with 0.9, too :)
> 
> And since I don't see any benefit in removing the prefix - other than cosmetic -
> keeping it will save time for distribution's programmers, sysadmins, writers,
> etc. to update their setup routines, configs, howtos, etc. :)
> 
> Florian
> 
> Takashi Iwai wrote:
> >
> > Hi,
> >
> > so far, all alsa modules use snd_ prefix for each module option.
> > iirc, there was a problem regarding namespace at the time of 2.0
> > kernel, and this was some workaround to avoid confliction.
> > but 2.2 and later kernels have no such a problem at all.
> >
> > so, i'd like to ask you how do you think to remove this snd_ prefix.
> > of course, there is one and only big problem - compatibility!
> >
> > the questions are
> >
> > - whether we should really do it or not?  is it worthy?
> >
> > and
> >
> > - when? now or after 0.9.0-final release?
> >
> > opinions, please?
> >
> > Takashi
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/alsa-devel
> 
> --
> Florian Bomers
> Java Sound
> Java Software/Sun Microsystems, Inc.
> http://java.sun.com/products/java-media/sound/
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel

-- 
Florian Bomers
Java Sound
Java Software/Sun Microsystems, Inc.
http://java.sun.com/products/java-media/sound/


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: snd_ prefix for module options

[Jaroslav Kysela]

On Tue, 8 Oct 2002, [iso-8859-1] Chris Rankin wrote:

>  --- Takashi Iwai <tiwai@suse.de> wrote: > Hi,
> > so, i'd like to ask you how do you think to remove
> > this snd_ prefix.
> > of course, there is one and only big problem -
> > compatibility!
> 
> I think it's a worthy goal. It's just noise in
> modules.conf, of course. Irritating, but no more than
> that. What concerns me more is when you compile ALSA
> directly into the kernel. To pass the options NOW
> requires a boot-time parameter list:
> 
> alsa-module-name=snd_this=x,snd_that=y,snd_the_other=z

No, it should be: alsa-module-name=x,y,z . The prefix for alsa-module-name 
is required, because we have collisions with OSS drivers.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: snd_ prefix for module options

[Clemens Ladisch]

Takashi Iwai wrote:
> so, i'd like to ask you how do you think to remove this snd_ prefix.
> of course, there is one and only big problem - compatibility!
>
> the questions are
>
> - whether we should really do it or not?  is it worthy?

I'd say yes.

> - when? now or after 0.9.0-final release?

Better now than later, to minimize the number of installation which must
be changed. But the change will invalidate all modules.conf files and
every piece of documentation about it, so it should be announced loudly
and well in advance (and many people won't notice anyway until their
drivers refuse to load).

IMHO it would be nice if "make install" looks into modules.conf and
complains loudly if old parameters are found. And maybe snd.o should
detect the usage of old parameters, too, at least for some time.


Regards
Clemens



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: snd_ prefix for module options

[Takashi Iwai]

At Wed, 9 Oct 2002 08:03:44 +0200 (CEST),
Jaroslav wrote:
> 
> On Tue, 8 Oct 2002, [iso-8859-1] Chris Rankin wrote:
> 
> >  --- Takashi Iwai <tiwai@suse.de> wrote: > Hi,
> > > so, i'd like to ask you how do you think to remove
> > > this snd_ prefix.
> > > of course, there is one and only big problem -
> > > compatibility!
> > 
> > I think it's a worthy goal. It's just noise in
> > modules.conf, of course. Irritating, but no more than
> > that. What concerns me more is when you compile ALSA
> > directly into the kernel. To pass the options NOW
> > requires a boot-time parameter list:
> > 
> > alsa-module-name=snd_this=x,snd_that=y,snd_the_other=z
> 
> No, it should be: alsa-module-name=x,y,z . The prefix for alsa-module-name 
> is required, because we have collisions with OSS drivers.

yes, the prefix for the module "name" is good, but not for the module
"prefix", which is currently discussed.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: snd_ prefix for module options

[Chris Rankin]

 --- Jaroslav Kysela <perex@suse.cz> wrote: > On Tue,
8
>
alsa-module-name=snd_this=x,snd_that=y,snd_the_other=z
> 
> No, it should be: alsa-module-name=x,y,z . The
> prefix for alsa-module-name 
> is required, because we have collisions with OSS
> drivers.

I'm not talking about "snd" on the alsa-module-name,
which is why I wrote it as "alsa-module-name" in the
above example in the first place. I am referring to
all the options "snd_index", "snd_enabled" etc.

If the option names are not required on the kernel
command line, then can I assume that you can safely
omit any that you don't want to specify by writing:

alsa-module-name=1,0,,,10

for example?

Chris


__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

RE: snd_ prefix for module options

[Karsten Wiese]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="US-ASCII", Size: 1412 bytes --]

> Hi,
> 
> so far, all alsa modules use snd_ prefix for each module option.
> iirc, there was a problem regarding namespace at the time of 2.0
> kernel, and this was some workaround to avoid confliction.
> but 2.2 and later kernels have no such a problem at all.
> 
> so, i'd like to ask you how do you think to remove this snd_ prefix.
> of course, there is one and only big problem - compatibility!
> 
> 
> the questions are
> 
> - whether we should really do it or not?  is it worthy?
> 
leave it like it is.
changing would break lots of users module.conf entries,
which might be the fruits of hours of work.

> and
> 
> - when? now or after 0.9.0-final release?
> 
> 
> opinions, please?
> 
> 
> Takashi
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Yahoo! präsentiert als offizieller Sponsor das Fußball-Highlight des
Jahres: - http://www.FIFAworldcup.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: snd_ prefix for module options

[Takashi Iwai]

At Wed, 9 Oct 2002 12:15:17 +0200,
Karsten Wiese wrote:
> 
> > Hi,
> > 
> > so far, all alsa modules use snd_ prefix for each module option.
> > iirc, there was a problem regarding namespace at the time of 2.0
> > kernel, and this was some workaround to avoid confliction.
> > but 2.2 and later kernels have no such a problem at all.
> > 
> > so, i'd like to ask you how do you think to remove this snd_ prefix.
> > of course, there is one and only big problem - compatibility!
> > 
> > 
> > the questions are
> > 
> > - whether we should really do it or not?  is it worthy?
> > 
> leave it like it is.
> changing would break lots of users module.conf entries,
> which might be the fruits of hours of work.

a convenient method is to check and rewrite /etc/modules.conf
automatically when alsa-driver is installed.  (btw, in the case of
debian, do we need to check another path, too?)

i'm not sure whether it's good manner or not, though.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: snd_ prefix for module options

[Jaroslav Kysela]

On Wed, 9 Oct 2002, [iso-8859-1] Chris Rankin wrote:

>  --- Jaroslav Kysela <perex@suse.cz> wrote: > On Tue,
> 8
> >
> alsa-module-name=snd_this=x,snd_that=y,snd_the_other=z
> > 
> > No, it should be: alsa-module-name=x,y,z . The
> > prefix for alsa-module-name 
> > is required, because we have collisions with OSS
> > drivers.
> 
> I'm not talking about "snd" on the alsa-module-name,
> which is why I wrote it as "alsa-module-name" in the
> above example in the first place. I am referring to
> all the options "snd_index", "snd_enabled" etc.

Ok, the you distict between modules and kernel command line. Both have 
different syntax.

> If the option names are not required on the kernel
> command line, then can I assume that you can safely

Replace required with allowed. You have to specify all parameters "in
order".

> omit any that you don't want to specify by writing:
> 
> alsa-module-name=1,0,,,10
> 
> for example?

It's the right example.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: snd_ prefix for module options

[Jack O'Quin]

> <snip>  (proposal to remove snd_ prefix for each module option)

Takashi Iwai <tiwai@suse.de> writes:

> a convenient method is to check and rewrite /etc/modules.conf
> automatically when alsa-driver is installed.  (btw, in the case of
> debian, do we need to check another path, too?)

Yes.  

I'm a recent (happy) convert to Debian 3.0, Woody.  I'm working at
learning it, but not an expert.  I recently studied the packaging of
ALSA, which is quite complex, and I believe this is correct...

Debian installs pieces of modules.conf in the /etc/modutils
subdirectory on a per-package basis.  The install scripts run
"update-modules" to combine these files into /etc/modules.conf.  In
the case of ALSA, /etc/modutils/alsa is actually a symlink to either
/etc/alsa/modutils/0.9 or /etc/alsa/modutils/0.5 since both ALSA
versions are supported and the contents are incompatible.

Debian has a policy of handling user-editable configuration files
*very* carefully.  When installing an update, the package scripts are
expected to preserve user edits and somehow deal with any format
changes, too.  When a package is removed, the config files are left in
place so user changes will not be lost in case the package is
re-installed in the future.  To actually erase config files, one must
use the --purge option.  In general, every package is expected to be
capable of upgrading both its previous version and the one before
that.

These are far higher standards of compatibility than ALSA has so far
tried to achieve.  My impression is that the Debian maintainers have
been working very hard to deal with ALSA's perennial instability.

> i'm not sure whether it's good manner or not, though.

Best to leave this alone.  Anything else causes many people to hassle
with fixing something that's not broken in the first place.

Regards,
-- 
  Jack O'Quin
  Austin, Texas, USA


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: snd_ prefix for module options

[Florian Bomers]

Takashi Iwai wrote:
> (...)
> a convenient method is to check and rewrite /etc/modules.conf
> automatically when alsa-driver is installed.  (btw, in the case of
> debian, do we need to check another path, too?)
> 
> i'm not sure whether it's good manner or not, though.

I guess providing a script in the utils dir and pointing to it after compilation
would be nice.

Florian


> 
> Takashi
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel

-- 
Florian Bomers
Java Sound
Java Software/Sun Microsystems, Inc.
http://java.sun.com/products/java-media/sound/


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: snd_ prefix for module options

[Peter L Jones]

On Wednesday 09 Oct 2002 11:19, Takashi Iwai wrote:
> At Wed, 9 Oct 2002 12:15:17 +0200,
>
[snip]
>
> a convenient method is to check and rewrite /etc/modules.conf
> automatically when alsa-driver is installed.  (btw, in the case of
> debian, do we need to check another path, too?)

Yes.
/etc/modutils/alsa -> /etc/alsa/modutils/0.9
And then run update-modules.

This would normally be done when upgrading the .deb to the new version, so it 
shouldn't be something the driver or init.d file should worry about.

(My opinion only...)

>
> i'm not sure whether it's good manner or not, though.

I think it's not so nice.  Anyone running ALSA 0.9 should know it's not a 
"release" version and be happy to have (some breakage).  If all that's needed 
is a quick edit of modules.conf, it shouldn't cause too many power-users 
grief.  Those using distro upgrade tools should let their distro maintainer 
sort it out for them.

I don't think it's an ALSA developer problem.

>
>
> Takashi
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: snd_ prefix for module options

[Takashi Iwai]

At Wed, 09 Oct 2002 10:41:18 -0700,
Florian Bomers wrote:
> 
> Takashi Iwai wrote:
> > (...)
> > a convenient method is to check and rewrite /etc/modules.conf
> > automatically when alsa-driver is installed.  (btw, in the case of
> > debian, do we need to check another path, too?)
> > 
> > i'm not sure whether it's good manner or not, though.
> 
> I guess providing a script in the utils dir and pointing to it after compilation
> would be nice.

I second it.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: snd_ prefix for module options

[Jack O'Quin]

Peter L Jones <peter@drealm.org.uk> writes:

> I think it's not so nice.  Anyone running ALSA 0.9 should know it's
> not a "release" version and be happy to have (some breakage).  If
> all that's needed is a quick edit of modules.conf, it shouldn't
> cause too many power-users grief.  Those using distro upgrade tools
> should let their distro maintainer sort it out for them.

This whole thread makes no sense to me at all.

Can someone please explain what terrible problem we're trying to solve
that justifies introducing *any* breakage at all?

I don't mean to single out Peter for this one statement.  But, I am
totally frustrated with the attitude that ALSA is only for power users
and that it's OK to introduce spurious incompatibilities on a whim.

The excuse that 0.9 is not a "release" is wearing thin these days.
Since 0.5, which *is* a release, is "no longer supported", what are
ordinary users expected to run?  OSS?

ALSA is part of the 2.5 kernel now.  It is mainstream Linux software,
good technology, needed by many users.  Isn't it about time to start
thinking and acting that way?
-- 
  Jack O'Quin
  Austin, Texas, USA



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: snd_ prefix for module options

[Peter L Jones]

On Thursday 10 Oct 2002 17:11, Jack O'Quin wrote:
[snip]
> I don't mean to single out Peter for this one statement.  But, I am
> totally frustrated with the attitude that ALSA is only for power users
> and that it's OK to introduce spurious incompatibilities on a whim.
>
> The excuse that 0.9 is not a "release" is wearing thin these days.
> Since 0.5, which *is* a release, is "no longer supported", what are
> ordinary users expected to run?  OSS?
>
> ALSA is part of the 2.5 kernel now.  It is mainstream Linux software,
> good technology, needed by many users.  Isn't it about time to start
> thinking and acting that way?

Hi Jack - don't mind singling me out!

In principle, I'd agree entirely with you but

(a) ALSA 0.9.0-rc3 is not ALSA 0.9.0.  Once it is, it will really be too late 
until ALSA 1.0.0

(b) Kernel 2.5.x is really a poor argument :-).  Again, if ALSA has module 
parms begining snd_ in 2.6.x, then it's stuck with it for a long time.

(I'm hoping (a) == (b) myself.)

I agree, any breakage is bad breakage but waiting will make it worse and I 
think it should be done (should have been done earlier but it should still be 
done).

-- Peter


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: snd_ prefix for module options

[Florian Bomers]

Jack O'Quin wrote:
> 
> (...)
> I don't mean to single out Peter for this one statement.  But, I am
> totally frustrated with the attitude that ALSA is only for power users
> and that it's OK to introduce spurious incompatibilities on a whim.

We'd all be happy if ALSA was already a finalized API and finalized
implementation, established, proven, "mainstream", etc. But it's not! So if you
want it or not, at the moment ALSA 0.9 is NOT meant for mainstream, because it
IS still in development!

> The excuse that 0.9 is not a "release" is wearing thin these days.
> Since 0.5, which *is* a release, is "no longer supported", what are
> ordinary users expected to run?  OSS?

You claim any responsibility of the ALSA developers for linux users. They have
not! This is open source. And I don't see what's wrong with using 0.5 until 0.9
is released.

Florian


> 
> ALSA is part of the 2.5 kernel now.  It is mainstream Linux software,
> good technology, needed by many users.  Isn't it about time to start
> thinking and acting that way?
> --
>   Jack O'Quin
>   Austin, Texas, USA
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel

-- 
Florian Bomers
Java Sound
Java Software/Sun Microsystems, Inc.
http://java.sun.com/products/java-media/sound/


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: snd_ prefix for module options

[Takashi Iwai]

At 10 Oct 2002 11:11:06 -0500,
Jack O'Quin wrote:
> 
> 
> Peter L Jones <peter@drealm.org.uk> writes:
> 
> > I think it's not so nice.  Anyone running ALSA 0.9 should know it's
> > not a "release" version and be happy to have (some breakage).  If
> > all that's needed is a quick edit of modules.conf, it shouldn't
> > cause too many power-users grief.  Those using distro upgrade tools
> > should let their distro maintainer sort it out for them.
> 
> This whole thread makes no sense to me at all.
> 
> Can someone please explain what terrible problem we're trying to solve
> that justifies introducing *any* breakage at all?
 
good to hear the opossite opinion, too.
the compatibility-breakage should be avoided, of course.

> I don't mean to single out Peter for this one statement.  But, I am
> totally frustrated with the attitude that ALSA is only for power users
> and that it's OK to introduce spurious incompatibilities on a whim.
> 
> The excuse that 0.9 is not a "release" is wearing thin these days.
> Since 0.5, which *is* a release, is "no longer supported", what are
> ordinary users expected to run?  OSS?
> 
> ALSA is part of the 2.5 kernel now.  It is mainstream Linux software,
> good technology, needed by many users.  Isn't it about time to start
> thinking and acting that way?

this is the very reason why "now" i asked.
since the ALSA is now on the official kernel tree, we must follow to
the standard rules, too.  and the snd_ prefix is obviously ugly from
this perspective.

if we live alone as external, then we don't have to care - we could do
as we like.  but the mainstream means that such exception has to be
excluded, too, at least before 2.5 turns into the "real mainstream",
i.e. 2.6 (or 3.0).

i guess the pain of this change wouldn't be so much once if there is a
converter-script or if the distributor takes care of it.
but, of course, my guess might be wrong, underestimated.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: snd_ prefix for module options

[Jack O'Quin]

> Jack O'Quin wrote:
> > Can someone please explain what terrible problem we're trying to solve
> > that justifies introducing *any* breakage at all?
>  
> > ALSA is part of the 2.5 kernel now.  It is mainstream Linux software,
> > good technology, needed by many users.  Isn't it about time to start
> > thinking and acting that way?

Takashi Iwai <tiwai@suse.de> writes:

> this is the very reason why "now" i asked.
> since the ALSA is now on the official kernel tree, we must follow to
> the standard rules, too.  and the snd_ prefix is obviously ugly from
> this perspective.
> 
> if we live alone as external, then we don't have to care - we could do
> as we like.  but the mainstream means that such exception has to be
> excluded, too, at least before 2.5 turns into the "real mainstream",
> i.e. 2.6 (or 3.0).

Are you saying that the "snd_" prefix violates standard Linux kernel
rules for device driver options?  Did the kernel developers request
this change?

If so, I withdraw my objection.  

I thought the change was merely cosmetic.  :-)

Regards,
-- 
  Jack O'Quin
  Austin, Texas, USA



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: snd_ prefix for module options

[Jaroslav Kysela]

On 11 Oct 2002, Jack O'Quin wrote:

> 
> > Jack O'Quin wrote:
> > > Can someone please explain what terrible problem we're trying to solve
> > > that justifies introducing *any* breakage at all?
> >  
> > > ALSA is part of the 2.5 kernel now.  It is mainstream Linux software,
> > > good technology, needed by many users.  Isn't it about time to start
> > > thinking and acting that way?
> 
> Takashi Iwai <tiwai@suse.de> writes:
> 
> > this is the very reason why "now" i asked.
> > since the ALSA is now on the official kernel tree, we must follow to
> > the standard rules, too.  and the snd_ prefix is obviously ugly from
> > this perspective.
> > 
> > if we live alone as external, then we don't have to care - we could do
> > as we like.  but the mainstream means that such exception has to be
> > excluded, too, at least before 2.5 turns into the "real mainstream",
> > i.e. 2.6 (or 3.0).
> 
> Are you saying that the "snd_" prefix violates standard Linux kernel
> rules for device driver options?  Did the kernel developers request
> this change?

Well, they had objections but not major to disallow inclusion of ALSA to 2.5.
I think that it would be good to follow standard kernel rules in this 
case.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: snd_ prefix for module options

[Jack O'Quin]

> On 11 Oct 2002, Jack O'Quin wrote:

> > Are you saying that the "snd_" prefix violates standard Linux
> > kernel rules for device driver options?  Did the kernel developers
> > request this change?

Jaroslav Kysela <perex@perex.cz> writes:

> Well, they had objections but not major to disallow inclusion of
> ALSA to 2.5.  I think that it would be good to follow standard
> kernel rules in this case.

I agree.
-- 
  Jack O'Quin
  Austin, Texas, USA


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf