Re: Future devfs plans (sorry for previous incomplete message)

Re: Future devfs plans (sorry for previous incomplete message)

[Tim Connors]

"Adam J. Richter" <adam@yggdrasil.com> said on Mon, 26 Jul 2004 10:37:41 -0700:
> 	3. hardware that is incidentally plugged in, but which might not
> 	   be used in the current session from boot to shutdown.  With the
> 	   increasing popularity of USB and firewire, a user might have a
> 	   "webcam", a still digital camera, a digital video converter, a
> 	   flash reader, a printer, a scanner and an external disk that
> 	   happen attached to the computer's USB network, with the user
> 	   having no intention of using any of them during the current
> 	   session from boot to shutdown.  This way, the cost of leaving
> 	   some things plugged in for convenience is reduced.

Can udev etc handle the case where you have a parallel zip disk
attached with a passthrough parallel port to the printer?

You can only have one of the lp or ppa drivers loaded at a time, and
that is easy enough to do with autoloading of modules and devfs. It
sounds like this is something which udev wouldn't be able to handle,
and hence would be quite a regression.

(please correct me if I am wrong)

-- 
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
Hacking's just another word for nothing left to kludge.

Re: Future devfs plans (sorry for previous incomplete message)

[Trent Lloyd]

Wouldn't a possible solution to do this to develop an extension to tmpfs to
catch files accessed that don't exist etc and use that in conjuction
with udev?

> 	[Sorry for the previous incomplete message on lkml.  It was
> the first time I've seen xterm segfault in a long time.]
> 
> 	Please do not delete devfs, as it provides important
> functionality unavailable elsewhere, and I have some plans to improve
> its implementation further.
> 
> Part 1: Advantages of devfs
> 
> 	devfs allows for creation of devices when user level programs
> need them rather than based on "hot plug" or modprobe-related events,
> neither of which do not exist for many devices and do not necessarily
> indicate need for the driver.  This allow distributions to include a
> support for many more devices, without wasting a lot of unswappable
> memory, which adds up when there are a lot of potential devices and,
> in some cases, can make Linux perform better on platforms with limited
> RAM.  I can think of four classes of such devices:
> 
> 	1. hardware that does not generate "hot plug" events, such as
> 	   a conventional floppy disk drive.  This way, distributions
> 	   can have support for all of these devices turned on without
> 	   bloating the kernel.
> 
> 	2. software devices, such as /dev/loop.  Again, this way
> 	   distributions can include support for any such devices that
> 	   may be developed without a substantial cost in unswappable RAM.
> 
> 	3. hardware that is incidentally plugged in, but which might not
> 	   be used in the current session from boot to shutdown.  With the
> 	   increasing popularity of USB and firewire, a user might have a
> 	   "webcam", a still digital camera, a digital video converter, a
> 	   flash reader, a printer, a scanner and an external disk that
> 	   happen attached to the computer's USB network, with the user
> 	   having no intention of using any of them during the current
> 	   session from boot to shutdown.  This way, the cost of leaving
> 	   some things plugged in for convenience is reduced.
> 
> 	4. user level disk partitioning, which I've used for years, shrinking
> 	   the kernel a bit, and possibly enabling one to avoid spinning
> 	   up disks that are not going to be used.
> 
> 	In addition, devfs's use of names rather than number for
> device identification in the kernel has the potential in the future to
> help avoid issues of device ID number collisions, the "Linux assigned
> names and numbers authority", and so on.  System administrators that
> do not like using devfs names directly can use the mechanisms provided
> by devfs user level software to map to device names that they do like.
> 
> 	In any software, there is always a limit point to the
> "mechanism versus policy" slogan where the complexity costs of
> providing more generality are believe to outweigh the benefits for the
> near future, especially if further generality could be added later if
> the need were to arrise.  For example, most ethernet devices are named
> "eth%d", although we could conceivably add a translation layer for
> that in the future.  I believe that at some point in the distant
> future, as part of a rearrangement of the distinctions between block
> devices, char devices and device mappers, the method for connecting
> the string passed to devfs_register() and the file name that
> ultimately appears in /dev might change, but removing devfs in the
> meantime would do more to impede such an effort and also would be
> throwing the baby out with the bath water due to other advantages of
> devfs discussed above.
> 
> 
> Part 2: Future plans for devfs
> 
> 	Some time ago, I posted patches to replace the stock devfs
> implementation with a much smaller one based on a specialized fork of
> ramfs, replacing the devfs daemon with a facility for having the
> kernel exec a helper program on devfs events.  The kernel code was
> about a fourth the size of stock devfs, and the user level code was
> also reduced by a similar factor.  I use slightly updated version of
> that system on several systems every day, under 2.6.7.  I can post
> updated patches for this, but I also plan to implement some change
> soon.
> 
> 	I plan to split out the functionality for invoking a user
> level helper program on attempts to find or create a file, which
> should provide the following advantages:
> 
> 	1. non-devfs configurations will be able to have demand loading
> 	   of device drivers that devfs systems currently enjoy.
> 
> 	2. The kernel memory footprint costs of CONFIG_DEVFS will be
> 	   even smaller, although the size of CONFIG_DEVFS +
> 	   CONFIG_lookup_helper will probably be slightly more than
> 	   that of my current mini-devfs.
> 
> 	3. It may provide a daemonless alternative to autofs for some
> 	   simple but common uses.
> 
> 	4. It will probably at least take us a step toward kicking dnotify
> 	   out to a demand loaded module (hey, it's unswappable memory that
> 	   every system currently uses, every byte counts).
> 
> 	5. It will probably provide a more general mechanism for
> 	   implementing dnotify-like systems that people periodically post
> 	   to the linux-kernel mailing list.
> 
> 	I have not yet written this vaporware, partly because I'm still
> pondering the question of whether the facility for exec'ing a user
> level program should be done as a few new lines in ramfs, a fork of
> ramfs, or an extentsion and restructuring of dnotify.  It should not
> be many lines of code.  It's just that I want to get it right.
> 
> 	Doing this as a ramfs variant would seem to contain the
> changes and assure the non-users of this facility that there would be
> no cost to them.  So why not do it as a ramfs variant?  Alas, doing
> the user level helper facility as a ramfs variant would require adding
> a parameter to inode_operations.lookup() because we need to filter out
> the lookup event that occurs when an inode is being created.
> Otherwise, in certain cases, loading a module that registers multiple
> devices can cause a deadlock when the module's initial registration of
> the device causes the devfs helper to block on trying to load the same
> module again.  Also, I wonder if there might be some use for layering
> this facility on top of other file systems, such as /proc or /sys or
> arbitrary storage file systems, but I haven't yet been able to come up
> with any example.  So, I think that making some general interface that
> both dnotify and this facility could be clients of will probably be
> the best approach, but there are definitely pros and cons to this
> choice, and keeping that code small is something that I want to be
> careful about.
> 
> 	I can post a new mini-devfs patch if there is interest,
> although it may be the weekend before I have time to do even that.
> 
> 	In the meantime, please do not delete devfs.  Thanks in
> advance.
> 
>                     __     ______________ 
> Adam J. Richter        \ /
> adam@yggdrasil.com      | g g d r a s i l
> 
> 
> -
> 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/

-- 
Trent Lloyd <lathiat@bur.st>
Bur.st Networking Inc.

Re: Future devfs plans (sorry for previous incomplete message)

[Norberto Bensa]

Trent Lloyd wrote:
> Wouldn't a possible solution to do this to develop an extension to tmpfs to
> catch files accessed that don't exist etc and use that in conjuction
> with udev?

Why would you want to do that? If the device node doesn't exist -> there's no 
hardware -> there's no need to load a driver/module.

udev/hotplug are doing the right thing (tm)

Regards,
Norberto

Re: Future devfs plans (sorry for previous incomplete message)

[Alexander E. Patrakov]

Norberto Bensa wrote:

> Trent Lloyd wrote:
> 
>>Wouldn't a possible solution to do this to develop an extension to tmpfs to
>>catch files accessed that don't exist etc and use that in conjuction
>>with udev?
> 
> 
> Why would you want to do that? If the device node doesn't exist -> there's no 
> hardware -> there's no need to load a driver/module.

Wrong - think about /dev/loop0

> 
> udev/hotplug are doing the right thing (tm)

They are doing the right thing (tm) _only_ in conjunction with this 
bootscript snippet:

	KVERSION=`uname -r`
         for module in `egrep '^alias (char|block)-major' \
             /lib/modules/$KVERSION/modules.alias /etc/modprobe.conf | \
             grep -v 1394 | awk '{print $3;}'`
         do
             modprobe $module
         done

I have, however, posted this snippet to linux-hotplug-devel and they 
rejected it for no apparent reason. This snippet loads exactly the same 
modules as the kernel would autoload with static /dev.

The "grep -v 1394" is due to the kernel bug described in the following 
message: http://lkml.org/lkml/2004/5/30/143

Also the recent "enable all hotplug events" patch 
(http://lkml.org/lkml/2004/7/13/74 + http://lkml.org/lkml/2004/7/20/47) 
with a custom initramfs 
(http://bugs.linuxfromscratch.org/attachment.cgi?id=112&action=view) is 
a very good thing.

-- 
Alexander E. Patrakov

Re: Future devfs plans (sorry for previous incomplete message)

[Måns Rullgård]

Trent Lloyd <lathiat@bur.st> writes:

> Wouldn't a possible solution to do this to develop an extension to tmpfs to
> catch files accessed that don't exist etc and use that in conjuction
> with udev?

There is a problem with that scheme.  Imagine that a program attempts
to access a non-existing device.  The special fs would call modprobe
or similar which would load the correct module.  Loading this module
would cause hotplug events upon which udev would create the device
node.  However, all this is asynchronous.  The special fs could wait
for a while for the device to appear, but this doesn't quite look like
a nice solution.  The exit status of modprobe can't be used, since
even if the module loads perfectly it might not cause the requested
device to be created.  Even if it does, there will be some delay from
the module being loaded to udev creating the device node, so how long
should the kernel wait for the device to appear?  I haven't thought
about it further, but I smell races here.

-- 
Måns Rullgård
mru@kth.se

Re: Future devfs plans (sorry for previous incomplete message)

[Ville Herva]

On Mon, Jul 26, 2004 at 10:37:41AM -0700, you [Adam J. Richter] wrote:
> 
> 	3. hardware that is incidentally plugged in, but which might not
> 	   be used in the current session from boot to shutdown.  With the
> 	   increasing popularity of USB and firewire, a user might have a
> 	   "webcam", a still digital camera, a digital video converter, a
> 	   flash reader, a printer, a scanner and an external disk that
> 	   happen attached to the computer's USB network, with the user
> 	   having no intention of using any of them during the current
> 	   session from boot to shutdown.  This way, the cost of leaving
> 	   some things plugged in for convenience is reduced.

Not only memory, but stability, too. Not all the most exotic USB drivers
etc. are stellar wrt. their stability. If the driver is not loaded unless
the device is used (as opposed to boot-time), it can make the system behave
more stable.


-- v -- 

v@iki.fi

Future devfs plans (sorry for previous incomplete message)

[Adam J. Richter]

	[Sorry for the previous incomplete message on lkml.  It was
the first time I've seen xterm segfault in a long time.]

	Please do not delete devfs, as it provides important
functionality unavailable elsewhere, and I have some plans to improve
its implementation further.

Part 1: Advantages of devfs

	devfs allows for creation of devices when user level programs
need them rather than based on "hot plug" or modprobe-related events,
neither of which do not exist for many devices and do not necessarily
indicate need for the driver.  This allow distributions to include a
support for many more devices, without wasting a lot of unswappable
memory, which adds up when there are a lot of potential devices and,
in some cases, can make Linux perform better on platforms with limited
RAM.  I can think of four classes of such devices:

	1. hardware that does not generate "hot plug" events, such as
	   a conventional floppy disk drive.  This way, distributions
	   can have support for all of these devices turned on without
	   bloating the kernel.

	2. software devices, such as /dev/loop.  Again, this way
	   distributions can include support for any such devices that
	   may be developed without a substantial cost in unswappable RAM.

	3. hardware that is incidentally plugged in, but which might not
	   be used in the current session from boot to shutdown.  With the
	   increasing popularity of USB and firewire, a user might have a
	   "webcam", a still digital camera, a digital video converter, a
	   flash reader, a printer, a scanner and an external disk that
	   happen attached to the computer's USB network, with the user
	   having no intention of using any of them during the current
	   session from boot to shutdown.  This way, the cost of leaving
	   some things plugged in for convenience is reduced.

	4. user level disk partitioning, which I've used for years, shrinking
	   the kernel a bit, and possibly enabling one to avoid spinning
	   up disks that are not going to be used.

	In addition, devfs's use of names rather than number for
device identification in the kernel has the potential in the future to
help avoid issues of device ID number collisions, the "Linux assigned
names and numbers authority", and so on.  System administrators that
do not like using devfs names directly can use the mechanisms provided
by devfs user level software to map to device names that they do like.

	In any software, there is always a limit point to the
"mechanism versus policy" slogan where the complexity costs of
providing more generality are believe to outweigh the benefits for the
near future, especially if further generality could be added later if
the need were to arrise.  For example, most ethernet devices are named
"eth%d", although we could conceivably add a translation layer for
that in the future.  I believe that at some point in the distant
future, as part of a rearrangement of the distinctions between block
devices, char devices and device mappers, the method for connecting
the string passed to devfs_register() and the file name that
ultimately appears in /dev might change, but removing devfs in the
meantime would do more to impede such an effort and also would be
throwing the baby out with the bath water due to other advantages of
devfs discussed above.


Part 2: Future plans for devfs

	Some time ago, I posted patches to replace the stock devfs
implementation with a much smaller one based on a specialized fork of
ramfs, replacing the devfs daemon with a facility for having the
kernel exec a helper program on devfs events.  The kernel code was
about a fourth the size of stock devfs, and the user level code was
also reduced by a similar factor.  I use slightly updated version of
that system on several systems every day, under 2.6.7.  I can post
updated patches for this, but I also plan to implement some change
soon.

	I plan to split out the functionality for invoking a user
level helper program on attempts to find or create a file, which
should provide the following advantages:

	1. non-devfs configurations will be able to have demand loading
	   of device drivers that devfs systems currently enjoy.

	2. The kernel memory footprint costs of CONFIG_DEVFS will be
	   even smaller, although the size of CONFIG_DEVFS +
	   CONFIG_lookup_helper will probably be slightly more than
	   that of my current mini-devfs.

	3. It may provide a daemonless alternative to autofs for some
	   simple but common uses.

	4. It will probably at least take us a step toward kicking dnotify
	   out to a demand loaded module (hey, it's unswappable memory that
	   every system currently uses, every byte counts).

	5. It will probably provide a more general mechanism for
	   implementing dnotify-like systems that people periodically post
	   to the linux-kernel mailing list.

	I have not yet written this vaporware, partly because I'm still
pondering the question of whether the facility for exec'ing a user
level program should be done as a few new lines in ramfs, a fork of
ramfs, or an extentsion and restructuring of dnotify.  It should not
be many lines of code.  It's just that I want to get it right.

	Doing this as a ramfs variant would seem to contain the
changes and assure the non-users of this facility that there would be
no cost to them.  So why not do it as a ramfs variant?  Alas, doing
the user level helper facility as a ramfs variant would require adding
a parameter to inode_operations.lookup() because we need to filter out
the lookup event that occurs when an inode is being created.
Otherwise, in certain cases, loading a module that registers multiple
devices can cause a deadlock when the module's initial registration of
the device causes the devfs helper to block on trying to load the same
module again.  Also, I wonder if there might be some use for layering
this facility on top of other file systems, such as /proc or /sys or
arbitrary storage file systems, but I haven't yet been able to come up
with any example.  So, I think that making some general interface that
both dnotify and this facility could be clients of will probably be
the best approach, but there are definitely pros and cons to this
choice, and keeping that code small is something that I want to be
careful about.

	I can post a new mini-devfs patch if there is interest,
although it may be the weekend before I have time to do even that.

	In the meantime, please do not delete devfs.  Thanks in
advance.

                    __     ______________ 
Adam J. Richter        \ /
adam@yggdrasil.com      | g g d r a s i l

Re: Future devfs plans (sorry for previous incomplete message)

[Matt Mackall]

On Mon, Jul 26, 2004 at 10:37:41AM -0700, Adam J. Richter wrote:
> 	devfs allows for creation of devices when user level programs
> need them rather than based on "hot plug" or modprobe-related events,
> neither of which do not exist for many devices and do not necessarily
> indicate need for the driver.

One wonders if autofs can be made to do the same.

-- 
Mathematics is the supreme nostalgia of our time.

Re: Future devfs plans (sorry for previous incomplete message)

[Trent Lloyd]

I see your point, but I wonder how it differs from the current devfs
implementation (i don't know how it works in these cases)

> Trent Lloyd <lathiat@bur.st> writes:
> 
> > Wouldn't a possible solution to do this to develop an extension to tmpfs to
> > catch files accessed that don't exist etc and use that in conjuction
> > with udev?
> 
> There is a problem with that scheme.  Imagine that a program attempts
> to access a non-existing device.  The special fs would call modprobe
> or similar which would load the correct module.  Loading this module
> would cause hotplug events upon which udev would create the device
> node.  However, all this is asynchronous.  The special fs could wait
> for a while for the device to appear, but this doesn't quite look like
> a nice solution.  The exit status of modprobe can't be used, since
> even if the module loads perfectly it might not cause the requested
> device to be created.  Even if it does, there will be some delay from
> the module being loaded to udev creating the device node, so how long
> should the kernel wait for the device to appear?  I haven't thought
> about it further, but I smell races here.
> 
> -- 
> M?ns Rullg?rd
> mru@kth.se
> 
> -
> 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/

-- 
Trent Lloyd <lathiat@bur.st>
Bur.st Networking Inc.

Re: Future devfs plans (sorry for previous incomplete message)

[Måns Rullgård]

Trent Lloyd <lathiat@bur.st> writes:

>> Trent Lloyd <lathiat@bur.st> writes:
>> 
>> > Wouldn't a possible solution to do this to develop an extension
>> > to tmpfs to catch files accessed that don't exist etc and use
>> > that in conjuction with udev?
>> 
>> There is a problem with that scheme.  Imagine that a program attempts
>> to access a non-existing device.  The special fs would call modprobe
>> or similar which would load the correct module.  Loading this module
>> would cause hotplug events upon which udev would create the device
>> node.  However, all this is asynchronous.  The special fs could wait
>> for a while for the device to appear, but this doesn't quite look like
>> a nice solution.  The exit status of modprobe can't be used, since
>> even if the module loads perfectly it might not cause the requested
>> device to be created.  Even if it does, there will be some delay from
>> the module being loaded to udev creating the device node, so how long
>> should the kernel wait for the device to appear?  I haven't thought
>> about it further, but I smell races here.
>
> I see your point, but I wonder how it differs from the current devfs
> implementation (i don't know how it works in these cases)

I'm speculating somewhat here, but I think the situation with devfs is
different.  Device nodes in devfs are created during module loading,
before modprobe returns.  This means that when modprobe has returned,
the device node will either have been created or never will be.

-- 
Måns Rullgård
mru@kth.se

Re: Future devfs plans (sorry for previous incomplete message)

[Ian Kent]

On Mon, 26 Jul 2004, Matt Mackall wrote:

> On Mon, Jul 26, 2004 at 10:37:41AM -0700, Adam J. Richter wrote:
> > 	devfs allows for creation of devices when user level programs
> > need them rather than based on "hot plug" or modprobe-related events,
> > neither of which do not exist for many devices and do not necessarily
> > indicate need for the driver.
> 
> One wonders if autofs can be made to do the same.

Do what exactly.

There is absolutly no infrastructure in autofs to create device files.

Ian

Re: Future devfs plans (sorry for previous incomplete message)

[Adam J. Richter]

Matt Mackall wrote:
>On Mon, Jul 26, 2004 at 10:37:41AM -0700, Adam J. Richter wrote:
>>       devfs allows for creation of devices when user level programs
>> need them rather than based on "hot plug" or modprobe-related events,
>> neither of which do not exist for many devices and do not necessarily
>> indicate need for the driver.
>
>One wonders if autofs can be made to do the same.

	Although I never experimentally confirmed it, from reading
the autofs and autofs4 sources, it appears that neither of them
provide a mknod operation.  They both use simple_inode_operations,
which has a NULL mknod, which will cause vfs_mknod to return -EPERM.
I believe autofs and autofs4 only allow creation of directories
and symlinks.

	Also, as I mentioned previously, trapping
inode_operations.lookup() can deadlock driver initialization
if it is doing mknod's that would also trigger that lookup
trap.  The VFS interface to lookup() could be changed slightly
via an extra parameter or an extra field in dentry or nameidata
to allow the lookup() trap to skip mknod and mkdir attempts,
but it might require some 1 line changes in a 50 file systems,
and I think doing it as an extension to dnotify might have
other minor benefits, such as demand loading appropriate modules
when files like /proc/apm or /proc/microcode are opened.  However, I
think it's a very close call whether to do the lookup trapping as a
file system modification or a VFS/dnotify modification.

                    __     ______________ 
Adam J. Richter        \ /
adam@yggdrasil.com      | g g d r a s i l