Removal of /proc/asound ?

Removal of /proc/asound ?

[Erik de Castro Lopo]

Hi all, 

I noticed this in a recent post from Takashi Iwai :

> (note that you need to run snddevices script once with the recent cvs
> version, since we removed the dynamic device files on /proc.)

Anybody care to fill me in on :

    0) Why this is being done?
    1) What replaces it?
    2) How do user space programmers ensure backwards and forwards 
       compatibility?

Thanks,
Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"The happiness you have demanded is now mandatory." 
    -- Jello Biafra


-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful, 
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge

Re: Removal of /proc/asound ?

[Jaroslav Kysela]

On Sat, 17 May 2003, Erik de Castro Lopo wrote:

> Hi all, 
> 
> I noticed this in a recent post from Takashi Iwai :
> 
> > (note that you need to run snddevices script once with the recent cvs
> > version, since we removed the dynamic device files on /proc.)
> 
> Anybody care to fill me in on :
> 
>     0) Why this is being done?
>     1) What replaces it?
>     2) How do user space programmers ensure backwards and forwards 
>        compatibility?

I try to explain these things to avoid more confusion.

The dynamic devices created in proc filesystem does things similar as 
DEVFS. We used it, because in design time, we changed minor and major 
numbers for our devices heavily. Once we stabilized our devices, and DEVFS 
obsoleted our code (DEVFS is more generic), there is no reason to maintain 
this code anymore. Also, we are only one project doing this and we had 
requests from the kernel people to remove this code.

The current situation is that used /dev/snd symlink should be replaced
with directory containing static device entries (created by mknod). If you
use DEVFS, there is no difference and no extra steps are required.

If the driver is installed via standard command 'make install' in the 
alsa-driver directory, the snddevices script is run automatically when 
/dev/snd is a symlink. This ensures that ALSA devices are properly 
recreated. If another update mechanism is used, it should be upgraded.

There is no impact for the user space programmers. Because alsa-lib uses 
only device names (/dev/snd/*), there is no difference among DEVFS, 
static mknod device files and proc dynamic devices.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful, 
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge

Re: Removal of /proc/asound ?

[Erik de Castro Lopo]

On Sat, 17 May 2003 13:55:19 +0200 (CEST)
Jaroslav Kysela <perex@suse.cz> wrote:

> I try to explain these things to avoid more confusion.
> 
> The dynamic devices created in proc filesystem does things similar as 
> DEVFS. 

Thats fine, but now many people runnning 2.4 series kernels are using
DEVFS?

> We used it, because in design time, we changed minor and major 
> numbers for our devices heavily. Once we stabilized our devices, and DEVFS 
> obsoleted our code (DEVFS is more generic), there is no reason to maintain 
> this code anymore. Also, we are only one project doing this and we had 
> requests from the kernel people to remove this code.

Was that request from the 2.4 kernel maintainers or the 2.5 people?

If it was a request from the 2.5 kernel people, why is this change impacting
people running 2.4 kernels.

> The current situation is that used /dev/snd symlink should be replaced
> with directory containing static device entries (created by mknod). If you
> use DEVFS, there is no difference and no extra steps are required.
>
> If the driver is installed via standard command 'make install' in the 
> alsa-driver directory, the snddevices script is run automatically when 
> /dev/snd is a symlink. 

How will this work if the user does not have a DEVFS enabled kernel?

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
UNIX *is* user-friendly, just picky about who it 
chooses for friends!


-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful, 
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge

Re: Removal of /proc/asound ?

[Takashi Iwai]

At Sun, 18 May 2003 08:13:31 +1000,
Erik de Castro Lopo wrote:
> 
> On Sat, 17 May 2003 13:55:19 +0200 (CEST)
> Jaroslav Kysela <perex@suse.cz> wrote:
> 
> > I try to explain these things to avoid more confusion.
> > 
> > The dynamic devices created in proc filesystem does things similar as 
> > DEVFS. 
> 
> Thats fine, but now many people runnning 2.4 series kernels are using
> DEVFS?

i guess, no.  AFAIK, mandrake is the only major distributor which uses
devfs as default.

> > We used it, because in design time, we changed minor and major 
> > numbers for our devices heavily. Once we stabilized our devices, and DEVFS 
> > obsoleted our code (DEVFS is more generic), there is no reason to maintain 
> > this code anymore. Also, we are only one project doing this and we had 
> > requests from the kernel people to remove this code.
> 
> Was that request from the 2.4 kernel maintainers or the 2.5 people?
 
from 2.5 people.  ALSA is not in 2.4 kernels.

> If it was a request from the 2.5 kernel people, why is this change impacting
> people running 2.4 kernels.

i also thought of this.  in theory, it's not difficult to implement
the compatible layer.

meanwhile, it's not too hard to create device files, too.  once if you
made them, then the system works like before.

frankly saying, i'm not sure which is the really better way.
if there are MANY demands on the old way, we'll consider to implement
it back again (but not appearing in the 2.5 kernel tree :)


> > The current situation is that used /dev/snd symlink should be replaced
> > with directory containing static device entries (created by mknod). If you
> > use DEVFS, there is no difference and no extra steps are required.
> >
> > If the driver is installed via standard command 'make install' in the 
> > alsa-driver directory, the snddevices script is run automatically when 
> > /dev/snd is a symlink. 
> 
> How will this work if the user does not have a DEVFS enabled kernel?

run snddevices script once.  that's all.


ciao,

Takashi


-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful, 
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge

Re: Removal of /proc/asound ?

[Erik de Castro Lopo]

On Mon, 19 May 2003 11:46:55 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> > If it was a request from the 2.5 kernel people, why is this change impacting
> > people running 2.4 kernels.
> 
> i also thought of this.  in theory, it's not difficult to implement
> the compatible layer.
> 
> meanwhile, it's not too hard to create device files, too.  once if you
> made them, then the system works like before.
> 
> frankly saying, i'm not sure which is the really better way.
> if there are MANY demands on the old way, we'll consider to implement
> it back again (but not appearing in the 2.5 kernel tree :)

There are times when backward compatibility is important and other times
when it is not.

Personally, I quite look forward to using DEVFS and the other 2.5/2.6 
features when I do finally make the switch. Until then, i would like as 
little change as possible.

I therefore strongly urge you to keep 2.4 functionality as it was and feel
free to do whatever is needed for the 2.5/2.6 kernel.

Regards,
Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
Peter F. Curran : Microsoft. Still delivering a text editor with 
    Win95/98 that can only open a max 64K file, despite being on 
    a machine with an 8Gig HD and 64M of ram....
G Cook: Perhaps, but Notepad is still the most functional program 
    in the whole suite!


-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful, 
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge

Re: Removal of /proc/asound ?

[Jaroslav Kysela]

On Mon, 19 May 2003, Erik de Castro Lopo wrote:

> On Mon, 19 May 2003 11:46:55 +0200
> Takashi Iwai <tiwai@suse.de> wrote:
> 
> > > If it was a request from the 2.5 kernel people, why is this change impacting
> > > people running 2.4 kernels.
> > 
> > i also thought of this.  in theory, it's not difficult to implement
> > the compatible layer.
> > 
> > meanwhile, it's not too hard to create device files, too.  once if you
> > made them, then the system works like before.
> > 
> > frankly saying, i'm not sure which is the really better way.
> > if there are MANY demands on the old way, we'll consider to implement
> > it back again (but not appearing in the 2.5 kernel tree :)
> 
> There are times when backward compatibility is important and other times
> when it is not.

Binary compatibility is important, but it's not our case. You can use
older libraries with newer driver without any problems. The change is only
administrative, if you create static device files, everything is ok again.
Simply, new version of driver requires to create new files, but nothing 
else. It can be viewed as "evolution", too. The system call semantics IS 
NOT CHANGED, thus binary compatibility is kept, of course.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful, 
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge

Re: Removal of /proc/asound ?

[Conrad Parker]

On Mon, May 19, 2003 at 08:03:01PM +1000, Erik de Castro Lopo wrote:
> 
> I therefore strongly urge you to keep 2.4 functionality as it was and feel
> free to do whatever is needed for the 2.5/2.6 kernel.

erik, you're hassling the wrong people -- a script exists to make the
devices you want, this is a packaging problem for el Debian ALSA Psychos
(knowing that erik uses debian), and a bog-standard GOTCHA for CVS users,
unless it can be done by make install or something.

-- 
    <K
       <K
 <K


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: Removal of /proc/asound ?

[David B Harris]

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]

On Tue, 20 May 2003 14:40:30 +1000
Conrad Parker <conrad@vergenet.net> wrote:
> On Mon, May 19, 2003 at 08:03:01PM +1000, Erik de Castro Lopo wrote:
> > 
> > I therefore strongly urge you to keep 2.4 functionality as it was and feel
> > free to do whatever is needed for the 2.5/2.6 kernel.
> 
> erik, you're hassling the wrong people -- a script exists to make the
> devices you want, this is a packaging problem for el Debian ALSA Psychos
> (knowing that erik uses debian), and a bog-standard GOTCHA for CVS users,
> unless it can be done by make install or something.

One of the Debian ALSA maintainers here.

The removal of /proc/asound/dev/ has been noted, and shouldn't be a
problem :) Once we actually upload packages within which
/proc/asound/dev/ has been removed, anyways. We haven't yet. I doubt
erik is bitching because of this, he hasn't asked any of us about it.

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

Re: Removal of /proc/asound ?

[Conrad Parker]

On Tue, May 20, 2003 at 01:09:04AM -0400, David B Harris wrote:
> 
> The removal of /proc/asound/dev/ has been noted, and shouldn't be a
> problem :) Once we actually upload packages within which
> /proc/asound/dev/ has been removed, anyways. We haven't yet. I doubt
> erik is bitching because of this, he hasn't asked any of us about it.

coolies. afaik Erik's using ALSA CVS atm, that's why he got bitten :)

hey I was suggesting to^W^Whassling Steve K about using discover or
something to autodetect soundcards, like the xserver-xfree86 package
does (with mdetect and read-edid) to detect the video card, monitor, and
mouse, if those packages are installed. He reckons discover needs some
fixing to work with ALSA, is that something that people on alsa-devel
could work on?

How do other distros autodetect soundcards to set up ALSA?

Conrad.


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: Removal of /proc/asound ?

[Erik de Castro Lopo]

On Tue, 20 May 2003 15:48:35 +1000
Conrad Parker <conrad@vergenet.net> wrote:

> On Tue, May 20, 2003 at 01:09:04AM -0400, David B Harris wrote:
> > 
> > The removal of /proc/asound/dev/ has been noted, and shouldn't be a
> > problem :) Once we actually upload packages within which
> > /proc/asound/dev/ has been removed, anyways. We haven't yet. I doubt
> > erik is bitching because of this, he hasn't asked any of us about it.
> 
> coolies. afaik Erik's using ALSA CVS atm, that's why he got bitten :)

Bingo! The Debian alsa-source package was SEVERLY broken on my iBook
and I still haven't had a chance to look into it properly.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"If dolphins are so smart, why do they live in igloos?" -Eric Cartman


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: Removal of /proc/asound ?

[James Courtier-Dutton]

David B Harris wrote:
> On Tue, 20 May 2003 14:40:30 +1000
> Conrad Parker <conrad@vergenet.net> wrote:
> 
>>On Mon, May 19, 2003 at 08:03:01PM +1000, Erik de Castro Lopo wrote:
>>
>>>I therefore strongly urge you to keep 2.4 functionality as it was and feel
>>>free to do whatever is needed for the 2.5/2.6 kernel.
>>
>>erik, you're hassling the wrong people -- a script exists to make the
>>devices you want, this is a packaging problem for el Debian ALSA Psychos
>>(knowing that erik uses debian), and a bog-standard GOTCHA for CVS users,
>>unless it can be done by make install or something.
> 
> 
> One of the Debian ALSA maintainers here.
> 
> The removal of /proc/asound/dev/ has been noted, and shouldn't be a
> problem :) Once we actually upload packages within which
> /proc/asound/dev/ has been removed, anyways. We haven't yet. I doubt
> erik is bitching because of this, he hasn't asked any of us about it.

I am running Debian with kernel.org kernel 2.4.20 and devfs.
Why does anyone have to wait until kernel 2.5 for devfs.

Cheers
James




-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: Removal of /proc/asound ?

[Patrick Shirkey]

Takashi Iwai wrote:

>>How will this work if the user does not have a DEVFS enabled kernel?
> 
> 
> run snddevices script once.  that's all.
> 

Phew. Picked this thread up late but here you allay my fears. basically 
if you don't run ./snddevices you get devfs and if you do you get proc.

This seems to have been working for a while (like 6 months or more). Is 
there more to this than meets the eye???





-- 
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No! 
We want normal music!", I think that was more like acting than anything 
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman



-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful, 
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge

Re: Removal of /proc/asound ?

[Takashi Iwai]

At Tue, 20 May 2003 01:36:00 +0900,
Patrick Shirkey wrote:
> 
> Takashi Iwai wrote:
> 
> >>How will this work if the user does not have a DEVFS enabled kernel?
> > 
> > 
> > run snddevices script once.  that's all.
> > 
> 
> Phew. Picked this thread up late but here you allay my fears. basically 
> if you don't run ./snddevices you get devfs and if you do you get proc.
> 
> This seems to have been working for a while (like 6 months or more). Is 
> there more to this than meets the eye???

not much.  the only difference is that static files are used instead
of proc fs.  if you install normally via "make install", everything
should work fine.  make will run the snddevices script automatically
if necessary.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge