Future devfs plans

Future devfs plans

[Adam J. Richter]

	Do not delete devfs.

	devfs allows drivers to be loaded when user level programs
need them,

Re: Future devfs plans

[Jim Gifford]

----- Original Message ----- 
From: "Adam J. Richter" <adam@yggdrasil.com>
To: <linux-kernel@vger.kernel.org>
Sent: Monday, July 26, 2004 7:45 AM
Subject: Future devfs plans


> Do not delete devfs.
>
> devfs allows drivers to be loaded when user level programs
> need them,
> -
So will a proper modprobe.conf file. You don't need devfs for autoloading of
modules.

Re: Future devfs plans

[Ed Sweetman]

Jim Gifford wrote:

>----- Original Message ----- 
>From: "Adam J. Richter" <adam@yggdrasil.com>
>To: <linux-kernel@vger.kernel.org>
>Sent: Monday, July 26, 2004 7:45 AM
>Subject: Future devfs plans
>
>
>  
>
>>Do not delete devfs.
>>
>>devfs allows drivers to be loaded when user level programs
>>need them,
>>-
>>    
>>
>So will a proper modprobe.conf file. You don't need devfs for autoloading of
>modules.
>
>  
>


On a different note though, some systems have been made to rely soley on 
devfs, meaning there is no static /dev fs underneath it.  Currently 
there is no documentation in the kernel source for going about migrating 
from a devfs only situation to a static or udev controlled /dev fs.  On 
top of that, MAKEDEV as distributed at least by debian, doesn't create 
alsa devices and there is no script in the kernel source tree that i've 
found that allows the device creation.  One would have to go download 
the alsa-driver package from the alsa-project website and use the 
snddevices.sh script.  Since alsa-driver is integrated with the kernel 
now, this device creation script should be included in the kernel source 
or if that's not the place for such a file, we'll have to get on 
debian's butt to have MAKEDEV updated to actually support it.

Re: Future devfs plans

[Lee Revell]

On Sun, 2004-07-25 at 20:17, Ed Sweetman wrote:
> Jim Gifford wrote:
> MAKEDEV as distributed at least by debian, doesn't create 
> alsa devices

This has been annoying me too.  I am filing a bug report.  This has no
bearing on devfs vs. udev, it is the job of the distribution to keep the
user space tools in sync with the kernel.

Lee

Re: Future devfs plans

[Lee Revell]

On Sun, 2004-07-25 at 20:17, Ed Sweetman wrote:
> Jim Gifford wrote:
> 
> MAKEDEV as distributed at least by debian, doesn't create 
> alsa devices

Filed as Debian Bug #261439 (makedev doesn't know what 'alsa' is).

Lee

Re: Future devfs plans

[Adrian Bunk]

On Sun, Jul 25, 2004 at 08:17:42PM -0400, Ed Sweetman wrote:
>...
> On 
> top of that, MAKEDEV as distributed at least by debian, doesn't create 
> alsa devices and there is no script in the kernel source tree that i've 
> found that allows the device creation.  One would have to go download 
> the alsa-driver package from the alsa-project website and use the 
> snddevices.sh script.  Since alsa-driver is integrated with the kernel 
> now, this device creation script should be included in the kernel source 
> or if that's not the place for such a file, we'll have to get on 
> debian's butt to have MAKEDEV updated to actually support it.



  apt-get install alsa-base


Check

  /var/lib/dpkg/info/alsa-base.postinst

and (surprise, surprise!), you'll note the snddevices script is executed 
when installing the alsa-base package.


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Future devfs plans

[Ed Sweetman]

Adrian Bunk wrote:

>On Sun, Jul 25, 2004 at 08:17:42PM -0400, Ed Sweetman wrote:
>  
>
>>...
>>On 
>>top of that, MAKEDEV as distributed at least by debian, doesn't create 
>>alsa devices and there is no script in the kernel source tree that i've 
>>found that allows the device creation.  One would have to go download 
>>the alsa-driver package from the alsa-project website and use the 
>>snddevices.sh script.  Since alsa-driver is integrated with the kernel 
>>now, this device creation script should be included in the kernel source 
>>or if that's not the place for such a file, we'll have to get on 
>>debian's butt to have MAKEDEV updated to actually support it.
>>    
>>
>
>
>
>  apt-get install alsa-base
>
>
>Check
>
>  /var/lib/dpkg/info/alsa-base.postinst
>
>and (surprise, surprise!), you'll note the snddevices script is executed 
>when installing the alsa-base package.
>
>
>cu
>Adrian
>
>  
>
And someone who compiles the kernel for themselves and never needs the 
alsa-base deb wouldn't have any ability to create the devices.  MAKEDEV 
is the proper place to create devices, not a separate snddevices 
script.  This is still a debian bug.

Re: Future devfs plans

[CaT]

On Mon, Jul 26, 2004 at 05:44:56PM -0400, Ed Sweetman wrote:
> Adrian Bunk wrote:
> > apt-get install alsa-base
> >
> >Check
> >
> > /var/lib/dpkg/info/alsa-base.postinst
> >
> >and (surprise, surprise!), you'll note the snddevices script is executed 
> >when installing the alsa-base package.
>
> And someone who compiles the kernel for themselves and never needs the 

Like I.

> alsa-base deb wouldn't have any ability to create the devices.  MAKEDEV 

alsa-base doesn't supply any modules:

# apt-file list alsa-base
alsa-base: etc/apm/event.d/alsa
alsa-base: etc/devfs/conf.d/alsa
alsa-base: etc/init.d/alsa
alsa-base: usr/share/alsa-base/alsa-base.conf
alsa-base: usr/share/alsa-base/modules-snippet.conf
alsa-base: usr/share/alsa-base/program-wrapper
alsa-base: usr/share/alsa-base/snddevices
alsa-base: usr/share/doc/alsa-base/FAQ
alsa-base: usr/share/doc/alsa-base/NEWS.Debian.gz
alsa-base: usr/share/doc/alsa-base/README
alsa-base: usr/share/doc/alsa-base/README.Debian
alsa-base: usr/share/doc/alsa-base/SOUNDCARDS.gz
alsa-base: usr/share/doc/alsa-base/WARNING
alsa-base: usr/share/doc/alsa-base/changelog.Debian.gz
alsa-base: usr/share/doc/alsa-base/copyright
alsa-base: usr/share/doc/alsa-base/examples/modules-1.0.conf
alsa-base: usr/share/linda/overrides/alsa-base
alsa-base: usr/share/lintian/overrides/alsa-base

And the init.d script doesn't do any loading of modules. It saves and
restores the mixer settings.

> is the proper place to create devices, not a separate snddevices 
> script.  This is still a debian bug.

Correct, for any version of debian where the supplied kernel is >= 2.6
I'd say.

-- 
    Red herrings strewn hither and yon.

Re: Future devfs plans

[Lee Revell]

On Mon, 2004-07-26 at 17:44, Ed Sweetman wrote:
> Adrian Bunk wrote:
> 
> >On Sun, Jul 25, 2004 at 08:17:42PM -0400, Ed Sweetman wrote:
> >     
> >  apt-get install alsa-base
> >
> >  
> >
> And someone who compiles the kernel for themselves and never needs the 
> alsa-base deb wouldn't have any ability to create the devices.  MAKEDEV 
> is the proper place to create devices, not a separate snddevices 
> script.  This is still a debian bug.

Ditto someone hacking on ALSA, or who needs to use ALSA CVS to get some
new feature, who doesn't want to have to build a .deb every time they
recompile.

This is a debian bug and not a valid objection to ditching devfs.

Lee

Re: Future devfs plans

[Adrian Bunk]

On Tue, Jul 27, 2004 at 05:24:15PM -0400, Lee Revell wrote:
> On Mon, 2004-07-26 at 17:44, Ed Sweetman wrote:
> > Adrian Bunk wrote:
> > 
> > >On Sun, Jul 25, 2004 at 08:17:42PM -0400, Ed Sweetman wrote:
> > >     
> > >  apt-get install alsa-base
> > >
> > >  
> > >
> > And someone who compiles the kernel for themselves and never needs the 
> > alsa-base deb wouldn't have any ability to create the devices.  MAKEDEV 
> > is the proper place to create devices, not a separate snddevices 
> > script.  This is still a debian bug.
> 
> Ditto someone hacking on ALSA, or who needs to use ALSA CVS to get some
> new feature, who doesn't want to have to build a .deb every time they
> recompile.
>...

Please check the facts before sending such emails (or read at least all 
mails in this thread).

alsa-base does _not_ contain any modules.

alsa-base only contains some scripts like the one that saves the ALSA 
mixer settings on shutdown and restores them after booting.

> Lee

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Future devfs plans

[Lee Revell]

On Tue, 2004-07-27 at 18:35, Adrian Bunk wrote:
> On Tue, Jul 27, 2004 at 05:24:15PM -0400, Lee Revell wrote:
> > On Mon, 2004-07-26 at 17:44, Ed Sweetman wrote:
> > > Adrian Bunk wrote:
> > > 
> > > >On Sun, Jul 25, 2004 at 08:17:42PM -0400, Ed Sweetman wrote:
> > > >     
> > > >  apt-get install alsa-base
> > > >
> > > >  
> > > >
> > > And someone who compiles the kernel for themselves and never needs the 
> > > alsa-base deb wouldn't have any ability to create the devices.  MAKEDEV 
> > > is the proper place to create devices, not a separate snddevices 
> > > script.  This is still a debian bug.
> > 
> > Ditto someone hacking on ALSA, or who needs to use ALSA CVS to get some
> > new feature, who doesn't want to have to build a .deb every time they
> > recompile.
> >...
> 
> Please check the facts before sending such emails (or read at least all 
> mails in this thread).
> 
> alsa-base does _not_ contain any modules.
> 
> alsa-base only contains some scripts like the one that saves the ALSA 
> mixer settings on shutdown and restores them after booting.
> 

Apologies, I was incorrect.

Lee

Re: Future devfs plans

[Rafael do N. Pereira]

On Mon, 2004-07-26 at 11:45, Adam J. Richter wrote:
> 	Do not delete devfs.
> 
> 	devfs allows drivers to be loaded when user level programs
> need them,


I think it can asnwer your question:

Q: But wait, I really want udev to automatically load drivers when they
   are not present but the device node is opened.  It's the only reason I
   like using devfs.  Please make udev do this.
A: No.  udev is for managing /dev, not loading kernel drivers.

Q: Oh come on, pretty please.  It can't be that hard to do.
A: Such a functionality isn't needed on a properly configured system. All
   devices present on the system should generate hotplug events, loading
   the appropriate driver, and udev will notice and create the
   appropriate device node.  If you don't want to keep all drivers for your
   hardware in memory, then use something else to manage your modules
   (scripts, modules.conf, etc.)  This is not a task for udev.

It was taken from http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ


 Rafael.

Re: Future devfs plans

[Ramón Rey Vicente]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Adam J. Richter wrote:

| 	devfs allows drivers to be loaded when user level programs
| need them,

With udev you can do that, and without important bugs :). And the more
important thing is _udev is in active development_
- --
Ramón Rey Vicente       <ramon dot rey at hispalinux dot es>
jabber ID               <rreylinux at jabber dot org>
GPGid 9F28E377 - 0BC2 8014 2445 51E8 DE87  C888 C385 A9D3 9F28 E377
===================================================================
"Copyright doesn't cover ideas; it's your expression of those
ideas." (Richard M. Stallman)
===================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBBFDJw4Wp058o43cRAvQtAKCs7YamhdOR2CsJVrtESenJ9Wf+JgCgiWfr
PKkTykrzFtze8NPX/1Xnl+g=
=3O07
-----END PGP SIGNATURE-----

Re: Future devfs plans

[Ramón Rey Vicente]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ramón Rey Vicente wrote:
| Adam J. Richter wrote:
|
| |     devfs allows drivers to be loaded when user level programs
| | need them,
|
| With udev you can do that, and without important bugs :). And the more
| important thing is _udev is in active development_

s/udev/hotplug :)
- --
Ramón Rey Vicente       <ramon dot rey at hispalinux dot es>
jabber ID               <rreylinux at jabber dot org>
GPGid 9F28E377 - 0BC2 8014 2445 51E8 DE87  C888 C385 A9D3 9F28 E377
===================================================================
"Copyright doesn't cover ideas; it's your expression of those
ideas." (Richard M. Stallman)
===================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBBFG7w4Wp058o43cRAm4UAKDciSR+94Q293fms/cDSCpT7EsgkwCgrrd0
anawSa53VYLRIIsxe4pTg9s=
=HB57
-----END PGP SIGNATURE-----

Re: Future devfs plans

[Andreas Jellinghaus]

On Mon, 26 Jul 2004 00:34:51 +0000, Ramón Rey Vicente wrote:
> With udev you can do that, and without important bugs :). And the more
> important thing is _udev is in active development_

devfs has the "open /dev/somefile" to load $somedriver
mechanism. it is said to be racy, as far as I know.

udev works very differently. mostly, the idea is kernel detects hardware,
kernel calls hotplug, hotplug loads driver, driver registers device
structure in kernel, kernel calls hotplug for the new device, udev creates
the device in /dev.

with this mechanism, the kernel always has all drivers for hardware
currently available loaded, and udev provides the /dev devices.

devfs allowes you to not have the driver loaded till you try to use it.
so udev _cannot_ do what devfs does.

still I agree that the way kernel/hotplug/udev work is much better and
supporting the old style devfs works is not necessary. but please be
honest about the differences.

Andreas

Re: Future devfs plans

[Erik Steffl]

Andreas Jellinghaus wrote:
> On Mon, 26 Jul 2004 00:34:51 +0000, Ramón Rey Vicente wrote:
> 
>>With udev you can do that, and without important bugs :). And the more
>>important thing is _udev is in active development_
> 
> 
> devfs has the "open /dev/somefile" to load $somedriver
> mechanism. it is said to be racy, as far as I know.
> 
> udev works very differently. mostly, the idea is kernel detects hardware,
> kernel calls hotplug, hotplug loads driver, driver registers device
> structure in kernel, kernel calls hotplug for the new device, udev creates
> the device in /dev.
> 
> with this mechanism, the kernel always has all drivers for hardware
> currently available loaded, and udev provides the /dev devices.
> 
> devfs allowes you to not have the driver loaded till you try to use it.
> so udev _cannot_ do what devfs does.
> 
> still I agree that the way kernel/hotplug/udev work is much better and
> supporting the old style devfs works is not necessary. but please be
> honest about the differences.

   which means that now iPod automatically connects to firewire (and 
looses info on random tracks, sometime some other settings), instead of 
only connecting when I try to actually access it (the device).

   it looks like there is no user level (end user, not admin) control on 
when the device drivers are loaded anymore - or is there?

   Is there any way to load drivers on demand (obviously it's not job of 
udev but whose job it is?). What about unloading them - I unmount the 
disk and i think the iPod is disconnecred but it still says connected - 
is there any way to disconnect it (I guess similar problems arise with 
other hotplug devices)

	erik

Re: Future devfs plans

[David Bryson]

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

On Sun, Jul 25, 2004 at 11:58:32PM -0700 or thereabouts, Erik Steffl wrote:
> >devfs allowes you to not have the driver loaded till you try to use it.
> >so udev _cannot_ do what devfs does.
> >
> >still I agree that the way kernel/hotplug/udev work is much better and
> >supporting the old style devfs works is not necessary. but please be
> >honest about the differences.
> 
>   which means that now iPod automatically connects to firewire (and 
> looses info on random tracks, sometime some other settings), instead of 
> only connecting when I try to actually access it (the device).
> 

I have been using ipods with linux for about 3 years.
And I see that it says "do not disconnect" even after I have unmounted
the file system.  I just disconnect it at this point and have not
had any problems.

>   it looks like there is no user level (end user, not admin) control on 
> when the device drivers are loaded anymore - or is there?
> 
>   Is there any way to load drivers on demand (obviously it's not job of 
> udev but whose job it is?). What about unloading them - I unmount the 
> disk and i think the iPod is disconnecred but it still says connected - 
> is there any way to disconnect it (I guess similar problems arise with 
> other hotplug devices)
> 

This has been discussed in length on lkml many times during the
writing of udev.  IIRC the argument was something like:
 "we shouldn't be unloading modules because the memory taken up by a
 module in memory(a few k) isn't worth writing the code to save"

I also recall there was something about end user behavior, but I don't
remember the details.  Read the archives.

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

Re: Future devfs plans

[Erik Steffl]

David Bryson wrote:
> On Sun, Jul 25, 2004 at 11:58:32PM -0700 or thereabouts, Erik Steffl wrote:
> 
>>>devfs allowes you to not have the driver loaded till you try to use it.
>>>so udev _cannot_ do what devfs does.
>>>
>>>still I agree that the way kernel/hotplug/udev work is much better and
>>>supporting the old style devfs works is not necessary. but please be
>>>honest about the differences.
>>
>>  which means that now iPod automatically connects to firewire (and 
>>looses info on random tracks, sometime some other settings), instead of 
>>only connecting when I try to actually access it (the device).
> 
> I have been using ipods with linux for about 3 years.
> And I see that it says "do not disconnect" even after I have unmounted
> the file system.  I just disconnect it at this point and have not
> had any problems.

   me neither (well, few times iPod locked up and I had to do the two 
finger salute (hold, then menu&play)), I just don't want it to connect 
in the first place, the reason being that once it connects it looses the 
track of random tracks (so that they start from scratch and then i get 
repeated songs) and from time to time contrast (and I almost can't see 
display with default contrast so I have to set the contrast again). not 
really a big deal but inconvenient.

   I know I can just handle the loading of the modules manually but I'd 
rather have it handled by the system (plus loading and unloading of 
modules manually has to be done by admin while automatic load/unload 
works for any user)

   And, of course, what's the point in having drivers loaded for devices 
I only use occasionally (iPod, digital camera)

>>  it looks like there is no user level (end user, not admin) control on 
>>when the device drivers are loaded anymore - or is there?
>>
>>  Is there any way to load drivers on demand (obviously it's not job of 
>>udev but whose job it is?). What about unloading them - I unmount the 
>>disk and i think the iPod is disconnecred but it still says connected - 
>>is there any way to disconnect it (I guess similar problems arise with 
>>other hotplug devices)
> 
> This has been discussed in length on lkml many times during the
> writing of udev.  IIRC the argument was something like:
>  "we shouldn't be unloading modules because the memory taken up by a
>  module in memory(a few k) isn't worth writing the code to save"
> 
> I also recall there was something about end user behavior, but I don't
> remember the details.  Read the archives.

   yeah, I've read some of it on lkml and elsewhere, just don't think 
it's a good idea. Sometime you just don't want the module loaded (one 
example is my usage of iPod), memory is only one (sometime, maybe often, 
negligible) reason.

   This looks like one of those 90% solutions that are so annoying (and 
that are fairly rare in free (libre) software which I personally use in 
large part because of its flexibility).

	erik