small devfs patch for 2.5.65, plan to replace /sbin/hotplug

Adam J. Richter

author

2003-03-21 09:40 UTC #0 lore raw

There have been some devfs clean ups in the stock kernels
since 2.5.63, so here is a patch so that people have a version that applies cleanly:

ftp://ftp.yggdrasil.com/pub/dist/device_control/devfs/smalldevfs-2.5.65-v12.patch

There is no change to the optional devfs_helper user level
agent, a reduced-functionality replacement for devfsd (devfsd is not used under under this version of devfs), available here:

ftp://ftp.yggdrasil.com/pub/dist/device_control/devfs/devfs_helper-0.2.tar.gz

I believe that the only change in this version of devfs is
moving the code to invoke the user level devfs_helper program to a separate file, fs/devfs/notify.c. This change will simplify a future code shrink inspired by David Brownell's suggesting that I think about unifying hotplug with devfs. In the future I would like to lift fs/devfs/notify.c out of devfs so that the code that currently invokes user level helpers for hot plug events can be replaced with two calls to a renamed devfs_event() on /sys/bus/<bustype>/devices/<bus#>/<whatever>, one for insertion and one for removal.

This future change would not just be for aesthetics (although
I've worried about potential bugs arising from /sbin/hotplug's pollution of environment variable name space). This change would result in a smaller kernel when both hotplug and devfs are configured, and, hopefully, a kernel that is no larger when only one or neither are configured (if neither are configured, the code would not be compiled in). It should also shrink the amount of user code need to support the combination of hotplug and devfs and slightly reduce the Linux-specific abstractions that system administrators have to track.

Signature · 14 lines

Adam J. Richter     __     ______________   575 Oroville Road
[email protected]     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Christoph Hellwig

2003-03-21 19:16 UTC #1 lore raw

Quoted 3 lines · Adam J. Richter

There have been some devfs clean ups in the stock kernels
since 2.5.63, so here is a patch so that people have a version that applies cleanly:

A bunch of comments:

- your docs mention devfs_only() buts it's gone for good now
- you removed the last users of devfs_alloc_devnum()/devfs_dealloc_devnum(), please remove the functionality aswell (not exported anyway)
- is the conditional call to init_devfs_fs() in devfs_decode() really nessecary? I think one explicit call to it in the early boot process would be much better. If you don't like that at least mark it unlikely()
- why do you raise the capablities in devfs_register() and devfs_mk_symlink() (but not devfs_mk_dir()!). I think any driver code actually calling that must run with raised privilegues already.
- I think renaming base.c to interf{,ace}.c is a good idea. It's more descriptive and will make the diff a lot easier to read.

-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Kevin P. Fleming

2003-03-21 20:45 UTC #2 lore raw

In reply to Adam J. Richter

Quoted 10 lines · Adam J. Richter

I believe that the only change in this version of devfs is
moving the code to invoke the user level devfs_helper program to a separate file, fs/devfs/notify.c. This change will simplify a future code shrink inspired by David Brownell's suggesting that I think about unifying hotplug with devfs. In the future I would like to lift fs/devfs/notify.c out of devfs so that the code that currently invokes user level helpers for hot plug events can be replaced with two calls to a renamed devfs_event() on /sys/bus/<bustype>/devices/<bus#>/<whatever>, one for insertion and one for removal.

Are you still considering smalldevfs for 2.6 inclusion? If not, then I'd like to discuss with you (and Greg KH) the possibility of just eliminating devfs entirely, and moving to a userspace version that is driven entirely by /sbin/hotplug.

There are already adequate hotplug events generated in 2.5.65+ to create and remove all necessary /dev entries, other than /dev/console (and that gets created by the initramfs being unpacked). If the devfs concept of "devfs_only" (no major/minor access to device drivers) is truly gone (as it appears to be), then the userspace variant of devfs would be quite simple: process the hotplug event and read the appropriate information out of sysfs to get the dev_t for the device, then follow user-specified policies to create /dev entries.

Unless I'm missing something obvious, "devfs" could be just a synonym for a specific tmpfs instance, with no built-in behavior at all. At initramfs unpack time it would be mounted on /dev, /dev/console would be created, and then /sbin/hotplug would create/remove entries as the drivers to their thing.

When the real root filesystem gets mounted, devfs could then be mounted again on the new /dev (just like devfs now) and everything's running smoothly.

-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Greg KH

2003-03-21 23:21 UTC #3 lore raw

In reply to Adam J. Richter

Quoted 11 lines · Kevin P. Fleming

Quoted 10 lines · Adam J. Richter
I believe that the only change in this version of devfs is
moving the code to invoke the user level devfs_helper program to a separate file, fs/devfs/notify.c. This change will simplify a future code shrink inspired by David Brownell's suggesting that I think about unifying hotplug with devfs. In the future I would like to lift fs/devfs/notify.c out of devfs so that the code that currently invokes user level helpers for hot plug events can be replaced with two calls to a renamed devfs_event() on /sys/bus/<bustype>/devices/<bus#>/<whatever>, one for insertion and one for removal.

Adam, right now we get /sbin/hotplug events for every device insertion and removal in the kernel. Do you want more than this?

Quoted 4 lines

Are you still considering smalldevfs for 2.6 inclusion? If not, then I'd like to discuss with you (and Greg KH) the possibility of just eliminating devfs entirely, and moving to a userspace version that is driven entirely by /sbin/hotplug.

You mean with something like this:
http://www.linuxsymposium.org/2003/view_abstract.php?talk”
:)

thanks,

greg k-h

-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Kevin P. Fleming

2003-03-21 23:41 UTC #4 lore raw

In reply to Adam J. Richter

Quoted 10 lines · Greg KH

Quoted 4 lines
Are you still considering smalldevfs for 2.6 inclusion? If not, then I'd like to discuss with you (and Greg KH) the possibility of just eliminating devfs entirely, and moving to a userspace version that is driven entirely by /sbin/hotplug.
You mean with something like this:
http://www.linuxsymposium.org/2003/view_abstract.php?talk”
:)

Yep, that's the one. Sounds very simple and straightforward to me. The most complex part will be defining some file structure to define the user's desired naming policy to the agent that handles the hotplug events.

-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Andrew Walrond

2003-03-21 23:54 UTC #5 lore raw

In reply to Adam J. Richter

Sounds wonderful. Any downsides?

Andrew Walrond

Quoted 18 lines · Kevin P. Fleming

Quoted 11 lines · Greg KH
Quoted 4 lines
Are you still considering smalldevfs for 2.6 inclusion? If not, then I'd like to discuss with you (and Greg KH) the possibility of just eliminating devfs entirely, and moving to a userspace version that is driven entirely by /sbin/hotplug.
You mean with something like this:
http://www.linuxsymposium.org/2003/view_abstract.php?talk”
:)
Yep, that's the one. Sounds very simple and straightforward to me. The most complex part will be defining some file structure to define the user's desired naming policy to the agent that handles the hotplug events.

Quoted 6 lines

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Greg KH

2003-03-21 23:55 UTC #6 lore raw

In reply to Adam J. Richter

Quoted 7 lines · Kevin P. Fleming

Quoted 6 lines · Greg KH
Quoted 4 lines
Are you still considering smalldevfs for 2.6 inclusion? If not, then I'd like to discuss with you (and Greg KH) the possibility of just eliminating devfs entirely, and moving to a userspace version that is driven entirely by /sbin/hotplug.

Quoted 8 lines

Quoted 4 lines
You mean with something like this:
http://www.linuxsymposium.org/2003/view_abstract.php?talk”
:)
Yep, that's the one. Sounds very simple and straightforward to me. The most complex part will be defining some file structure to define the user's desired naming policy to the agent that handles the hotplug events.

Exactly. Luckily it looks like I'm starting to get a lot of help with this :)

As I'm still working on providing enough support from within sysfs to export all the data we need, Dan Stekloff (cced) has started to work on a design document for how the userspace stuff will work.

I just need a few more hours per day...

thanks,

greg k-h

-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Greg KH

2003-03-22 00:03 UTC #7 lore raw

In reply to Adam J. Richter

Quoted 1 line · Andrew Walrond

Sounds wonderful. Any downsides?

It's not implemented yet :)

Seriously, there are a few gotchas that need to be worked out (serialization of hotplug events, ordering, and other races), and a few security issues to be addressed. Oh, and we need to finish converting all of the kernel's drivers to export their major/minor number through sysfs to get this to work.

Just a few minor things left...

thanks,

greg k-h

-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Adam J. Richter

author

2003-03-22 03:39 UTC #8 lore raw

In reply to Adam J. Richter

On Fri, 21 Mar 2003, Kevin P. Fleming wrote [lines rewrapped to fit 80 columns]:

Quoted 12 lines

Quoted 10 lines · Adam J. Richter
I believe that the only change in this version of devfs is
moving the code to invoke the user level devfs_helper program to a separate file, fs/devfs/notify.c. This change will simplify a future code shrink inspired by David Brownell's suggesting that I think about unifying hotplug with devfs. In the future I would like to lift fs/devfs/notify.c out of devfs so that the code that currently invokes user level helpers for hot plug events can be replaced with two calls to a renamed devfs_event() on /sys/bus/<bustype>/devices/<bus#>/<whatever>, one for insertion and one for removal.

Quoted 1 line

Are you still considering smalldevfs for 2.6 inclusion?

Yes. Andrew Morton has been very supportive of it and
just wants some more support for backward compatible names, perhaps something as simple as shipping devfs_helper with an optional tar file that could be unpacked in /dev as part of the boot process (along with some documentation on setting this up), or a sample /etc/devfs.conf for creating legacy names dynamically as needed.

Quoted 4 lines

If not, then
I'd like to discuss with you (and Greg KH) the possibility of just eliminating devfs entirely, and moving to a userspace version that is driven entirely by /sbin/hotplug.

Even though I expect small devfs to get into both 2.6 and 2.7,
I would still be interested in discussing a userspace scheme. When and if such a scheme became reasonably reliable working code, I might suppport removing devfs, depending on how it turned out.

Quoted 1 line

There are already adequate hotplug events generated in 2.5.65+

You need lookup events, so that you can, for example, load
the floppy driver when the user looks up "/dev/floppy/0".

Also I believe that the "devfs_event(eventname, dentry)"
syntax will result in slightly smaller kernel code, and the "/sbin/devfs_helper eventname path" program invocation will avoid potential problems with environment variable name space pollution.

So, while perhaps we could eliminate the devfs filesystem in
favor of something driven by /sys, I would like to see something closer to devfs_event() become the standard for notifying user space of these events. Note also that making devfs_event() into some kind of trap facility in the core fs code will not work, because, for hotplug events, you want to send the event *after* the relevant directory has been populated, rather than when the diretory has initially been created and is still empty.

Quoted 3 lines

to
create and remove all necessary /dev entries, other than /dev/console (and that gets created by the initramfs being unpacked).

/dev entries are created by other events than just physical
device insertion. For example, in my version of loop.c, only /dev/loop/0 is initially created. /dev/loop/1 is created when you open /dev/loop/0. /dev/loop/2 is created when you open /dev/loop/1, and so on. There are no corresponding physical insert and remove events.

Quoted 3 lines

If the devfs
concept of "devfs_only" (no major/minor access to device drivers) is truly gone (as it appears to be),

I expect this to come back. I have not complained about
Christoph's changes because I don't believe in leaving unused code in the distribution tree, but I have deliberately kept the extra parameters on devfs_register for this purpose.

Quoted 4 lines

then the userspace variant of devfs
would be quite simple: process the hotplug event and read the appropriate information out of sysfs to get the dev_t for the device, then follow user-specified policies to create /dev entries.

1. There is a chicken-and-egg issue with the initial root device,
you need to be able to unmount and remount /dev without getting a new instance so that "cd /newroot && exec chroot . ./sbin/init" will work

2. I would like to someday eliminate dev_t and have devices
referenced by name to eliminate number assignment problems, among other things. Making user space more aware of dev_t would impede that. A physical device may have many or no dev_t values associted with it, and a dev_t may be associated with a combination of physical devices. Also, there are logical devices that might not have a corresponding physical device.

I think a better approach to a user space devfs driven by /sys
events would be look things up based on file name rather than some kind of dev_t entry. Also, a /sys-driven approach should not be specific to char and block /dev entries, but rather all registrations of software interfaces (block device, char device, network interface, filesystem, etc.) at some new central point, so that registering a new network interface or a new socket type could also be caught.

Quoted 2 lines

Unless I'm missing something obvious, "devfs" could be just a synonym for a specific tmpfs instance, with no built-in behavior at all.

In fs/devfs, I split interface.c from fs.c for this reason.
There is nothing specific to the devfs filesystem implemention in interface.c. You could conceivably set devfs_vfsmnt to any valid vfsmnt, and device nodes would be created and deleted in that file system. The only obstacle with doing that on a disk filesystem is the bootstrapping problem of mounting the filesystem in the first place. I can think of only three special properties that the ramfs variant in fs/defs/fs.c implements:

1. It calls /sbin/devfs_helper for certain events.
2. It can be instantiated early.
3. It implements a single instance filesystem, so that the contents of devfs are remembered if you unmount devfs and remount it somewhere else.

Adam J. Richter     __     ______________   575 Oroville Road
[email protected]     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America

"Free Software For The Rest Of Us."

-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

[email protected]

2003-03-22 15:36 UTC #9 lore raw

In reply to Adam J. Richter

Quoted 5 lines

On Fri, 21 Mar 2003, Kevin P. Fleming wrote [lines rewrapped to fit 80 columns]:
Quoted 2 lines
Adam J. Richter wrote:

Quoted 8 lines

Quoted 1 line
Are you still considering smalldevfs for 2.6 inclusion?
Yes. Andrew Morton has been very supportive of it and
just wants some more support for backward compatible names, perhaps something as simple as shipping devfs_helper with an optional tar file that could be unpacked in /dev as part of the boot process (along with some documentation on setting this up), or a sample /etc/devfs.conf for creating legacy names dynamically as needed.

I would like the idea of a sample /etc/devfsd.conf much better for one reason, the whole point of devfs (at least to me) is to stop cluttering /dev with entries for devices which aren't even present, an /etc/devfsd.conf would still only create compatability file for nodes which are present, unless I am missing something an optional tar file would have to contain every possible compatible device name and would create the same mess which some distros have in /dev right now. That said, I really like the idea of having compatible device names at least for a while so things like cdrdao read-toc --device 2,4,0 toc_file will stop complaining when the version of libscg it is using can't find a /dev/sg? device to play with. Most boot time issues are easy to solve with smalldevfs, but it's the problems like cdrdao which are harder to solve, especially when the real problem is in a library it builds and uses and the library is at least fairly complex.

Quoted 27 lines

Quoted 5 lines
If not, then
I'd like to discuss with you (and Greg KH) the possibility of just eliminating devfs entirely, and moving to a userspace version that is driven entirely by /sbin/hotplug.
Even though I expect small devfs to get into both 2.6 and 2.7,
I would still be interested in discussing a userspace scheme. When and if such a scheme became reasonably reliable working code, I might suppport removing devfs, depending on how it turned out.
Quoted 1 line
There are already adequate hotplug events generated in 2.5.65+
You need lookup events, so that you can, for example, load
the floppy driver when the user looks up "/dev/floppy/0".
<some text cut to keep this short>
In fs/devfs, I split interface.c from fs.c for this reason.
There is nothing specific to the devfs filesystem implemention in interface.c. You could conceivably set devfs_vfsmnt to any valid vfsmnt, and device nodes would be created and deleted in that file system. The only obstacle with doing that on a disk filesystem is the bootstrapping problem of mounting the filesystem in the first place. I can think of only three special properties that the ramfs variant in fs/defs/fs.c implements:

Quoted 6 lines

1. It calls /sbin/devfs_helper for certain events.
2. It can be instantiated early.
3. It implements a single instance filesystem, so that the contents of devfs are remembered if you unmount devfs and remount it somewhere else.

I would like to chime in on the issue of devfs (small or regular) versus doing everything in user-space. It is nice that people are willing to try and shrink the kernel and get some things into user-space, but as long as Linux still has the possibility of build a completely monolithic, non-modular, no initramfs kernel I would like to see devfs hang around as an option for people who like /dev to only contain devices they have. I for one always just build my kernels as monolithic and hate using initramfs (I think changing /etc/fstab and /boot/grub/grub.conf is much easier than also having to rebuild an initrd just to change what type of journaling ext3 is performing on /). I am usually not a big believer in things _needing_ to stay in the kernel but I think that a case can be made that devfs should stay in the kernel so that people can have a choice of whether or not to use initramfs. I think if we could have an in kernel version _and_ a userspace version and allow people to choose one or the other it would probably make the greatest number of people happy in the simplest way. Anyway, just my two cents.

Quoted 9 lines

Adam J. Richter     __     ______________   575 Oroville Road
[email protected]     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
"Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jordan

-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel