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

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

[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:

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.

-- 
Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

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

[Christoph Hellwig]

On Fri, Mar 21, 2003 at 01:40:48AM -0800, Adam J. Richter wrote:
> 	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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

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

[Kevin P. Fleming]

Adam J. Richter wrote:
> 	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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

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

[Greg KH]

On Fri, Mar 21, 2003 at 01:45:09PM -0700, Kevin P. Fleming wrote:
> Adam J. Richter wrote:
> >	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?

> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

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

[Kevin P. Fleming]

Greg KH wrote:
>>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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

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

[Andrew Walrond]

Sounds wonderful. Any downsides?

Andrew Walrond

Kevin P. Fleming wrote:
> Greg KH wrote:
> 
>>> 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.
> 
> -
> 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/
> 




-------------------------------------------------------
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

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

[Greg KH]

On Fri, Mar 21, 2003 at 04:41:29PM -0700, Kevin P. Fleming wrote:
> Greg KH wrote:
> >>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.

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

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

[Greg KH]

On Fri, Mar 21, 2003 at 11:54:00PM +0000, Andrew Walrond wrote:
> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

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

[Adam J. Richter]

On Fri, 21 Mar 2003, Kevin P. Fleming wrote [lines rewrapped 
to fit 80 columns]:
>Adam J. Richter wrote:
>> 	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?

	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.

>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.

>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.

>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.

>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.

>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.


>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
adam@yggdrasil.com     \ /                  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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

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

[jordan.breeding]

> On Fri, 21 Mar 2003, Kevin P. Fleming wrote [lines rewrapped 
> to fit 80 columns]:
> >Adam J. Richter wrote:
> >
> >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.

> 
> >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.
> 
> >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:
> 
> 	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.

> Adam J. Richter     __     ______________   575 Oroville Road
> adam@yggdrasil.com     \ /                  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 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/

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel