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
[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."
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.
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.
On Fri, Mar 21, 2003 at 01:10:10PM -0800, Adam J. Richter wrote:
> I'm thinking about removing all of the capability raising code
> from devfs and just having the pty code raise the capabilities
> explicitly if allocating and releasing a pseudo-terminal are really
> the only places that ever need it.
My plan is to rip out UNIX98 pty handling copletly out of devfs instead.
We already have a lean, small filesystem exactly for that purpose and
it adds lots of unessecary cruft to devfs (DEVFS_FL_CURRENT_OWNER and
DEVFS_FL_WAIT to be exact). Afterwards devfs would only create /dev/pts/
(and /dev/pty/ as devfs renamed it IIRC) and devfs users would have to
mount devpts aswell.
Thanks for the commentary, Chrisoph. I have implemented most
of your suggested changes to my shrunken devfs. The new patch is
available from the following URL.
ftp://ftp.yggdrasil.com/pub/dist/device_control/devfs/smalldevfs-2.5.65-v13.patch
I'll now comment on each of your suggestions specificially.
On Fri, 21 Mar 2003, Christoph Hellwig wrote:
> - your docs mention devfs_only() buts it's gone for good now
Done. I've removed the reference. By the way, I think devfs_only
may return in the future, but generally I don't believe in including
what is not currently being used, as that tends to just cause confusion
and obscure other opportunities for removing other things.
> - you removed the last users of devfs_alloc_devnum()/devfs_dealloc_devnum(),
> please remove the functionality aswell (not exported anyway)
Done. Thanks for spotting this.
> - 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()
I've added the unlikely() call that you suggest.
Having an explicity point for devfs initialization would be
better, but I think the correct point may move depending on how you've
configured your kernel. For example, the kernel wants to open
/dev/console. Newer kernels also want to create an ersatz namespace
for evaluating "root=" arguments. I'll look into it.
> - 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've changed devfs_mk_dir and devfs_unregister also to raise
CAP_DAC_OVERRIDE. The reason for this is that unprivilidged user
level code can occasionally do things that legitimately cause the
kernel to create a new device. In particular, non-setuid xterm was
failing becuase pseudo-terminal creation was failing. I don't know of
any caller to devfs_mk_dir that needs it, but I might as well have a
uniform policy.
I'm thinking about removing all of the capability raising code
from devfs and just having the pty code raise the capabilities
explicitly if allocating and releasing a pseudo-terminal are really
the only places that ever need it.
> - 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.
OK, I've done this.
Thanks for all of the suggestions.
I've removed linux-hotplug-devel from the cc list, as I only
included that list because of my comments about perhaps replacing
/sbin/hotplug eventually.
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."
On Fri, 21 Mar 2003, Christoph Hellwig wrote:
> - this patch doesn't include notify.c :)
Arg! OK, please try:
ftp://ftp.yggdrasil.com/pub/dist/device_control/devfs/smalldevfs-2.5.65-v14.patch
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."
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=94
:)
thanks,
greg k-h
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=94
> :)
>
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.
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=94
> >:)
> >
>
> 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
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=94
>> :)
>>
>
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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
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
[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."
> 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
> [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
[email protected] wrote:
>>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.
I don't understand the need for this. It seems to me, upon
first inspection, to be another one of those "remove the
code to shave some KB off the kernel source tarball size"
type of things. Even if it isn't that, it sure seems like a
step backwards for linux. I recall that the whole point of
devfs was to eliminate the need for userland programs which
required manual intervention. It also disturbs me that this
so-called userspace program provides less
features/functionality then devfsd did.
Why would I complain? Simple, devfs has been around for
awhile, and IMHO has finally started to settle in as
seasoned means of dealing with /dev. For instance, we
encourage our users to use devfs, because it allows us
greater control and a finer grain of tuning for each users
profile during boot-up. It is rather convienient to have a
silent daemon which handles all the necessary configuration
in the background. It's nice to have something which is
live and can be changed w/o user intervention. Your change
would mean that we'd have to rewrite an entire system just
because you decided that the kernel could do with a few
hundred less KB. It isn't just us, either. I'm sure many
out there in distro/user land might be at least annoyed
about the approach you are taking. There are many other
reasons why this is not a good idea, most of which Jordan
seems to have covered, so I will spare repeating them.
The more reasonable approach, at least to me, is the current
clean up that HCH is doing. He's reducing the devfs impact
on the kernel and centralizing it into private source files
without sacraficing much (if any) compatibility &
functionality. Why not work towards this route instead? At
the very least, give people a choice as to which
implementation (big or small) they want use. If you don't
like it, then don't compile it. But don't remove it for
others just to save some piddling space.
So, I advocate strongly that Linus should not apply this
patch! Of course, feel free to disagree...
Cheers,
Nicholas
P.S. - Not crossposting to hotplug as my discussion doesn't
concern it.