After re-reading my previous post, I've thought of better ways to
say things. Plus, I should probably finish my thoughts when I write
them... This should be superset of my previous posting, but I won't
cancel it, just in case.
H> Reasons against devfs:
H> - Permanent attributes are kludged on
Attributes are managable in a scalable, programmatic way.
H> - Breaks filesystem semantics in several ways, makes it very hard to check
H> ramifications
Just because unix treats most things as files, doesn't mean that
they have to look just like files. If they were an exact
equivalence, there would be no point. Linux certainly supports
filesystems which don't support full Unix file semantics. FAT/msdos
for example only supports a subset of unix semantics -- only one set
of permission bits, for example. Should Linux not support it?
H> - Impacts system administration, making device managing a lot less Unixy
I haven't noticed it being harder or less Unixy. And always starting
out the devices at a known state on boot I would argue is a good
thing.
H> - Impacts _every_ single driver in the kernel, even if it isn't used
Like Linux hasn't changed driver interfaces before, causing changes
to drivers that wouldn't be otherwise affected.
I went a re-checked the patch source. Aside from renaming the
register_chrdev call, it only adds another setup call. Conceptually,
it could be additional arguments to the register call. It certainly
isn't "needing to maintain 2 different sources for each driver" as I
read (from somebody) previously. It does complicate the registration
process to support 2 different interfaces. But that is a small, and
stable, part of each device driver. SMP is potentially a bigger
burden/change, as is multiple architectures.
H> - What can be done with devfs can be done without it. Granted, it is less
H> convenient. But I add/remove devices from my machines perhaps once a
I haven't seen any other scheme for managing hot-pluggable devices
that isn't more complex and less maintainable than devfs.
They either require kernel support, and/or maintaining detailed
knowledge about the device in 2 or more different places. I submit
that being able to put all the device knowledge in one place is
simpler and more maintainable.
eg: /dev/MAKEDEV is the 2nd location, and any user-mode program to
configure devices would be 3rd (though if it exists, MAKEDEV should
use it, but that is still 3 places).
H> month, so that doesn't cut it for me.
So, just because you don't see any benefit for you, it is a bad idea
for everybody? Should all filesystems that don't support full unix
semantics be ripped out? If you use only uniprocessor machines,
should all SMP code be ripped out? It is far more intrusive code
changes than devfs, and changes some of the historical unix
semantics (though it succeeds very well in hiding that change from
the casual user).
H> Reasons for devfs:
H> - Makes handling hot-plug easier, but marginally so
H> - Unclutters /dev
A static /dev doesn't scale, especially on hardware whose very
architecture can be changed (between boots, with plans to be dynamic
at run time). That's why IRIX 6.4 and 6.5+ uses a hybrid dynamic
/dev -- the topology of the device space is determined dynamically
during boot. I presume that Sun does it for similar reasons.
The size of /dev isn't really disk space, it is congnitive space.
And you are right: the size of /dev on a desktop or small server is
not hard to deal with. With devfs it is easier. Some of the things
that the current devfs patch change could (and IMHO should be)
changed even without devfs (the sd{a,b,c,d,...} brain-damage comes
to mind). Now, you certainly can manage /dev/ manually or
semi-automated (with a static /dev), but why not let the software do
it? The drivers already know which devices are out there!
H> Also: It is extra code, has to be maintained and updated, and has to be
H> accounted for in new driver developments. It _will_ add new bugs, even new
H> classes of bugs. This doesn't come for free.
As "invasive" patches go, it is simple and clean. The parts that I
have looked at appear to have a simple relationship between the
driver and the device. The actual devfs management code appears to
be well centralized, for easy bug triage. There's already a bunch of
stuff driver writers need to do; this is a comparatively minor one,
and it isn't new -- the same info is needed for MAKEDEV.
BTW, MAKEDEV is a prime example of a standard Unix file which
contains ownership and permission information outside of the normal
semantics. It is not normally run on every boot, but the principle
is the same. It is no coincidence that it is for /dev, either.
H> Weighting the above, the answer for me is clearly "no".
Given my experience with devfs-like things, and devfs itself, I
think including it in the standard kernel distribution is a
no-brainer. It's a little rough around the edges yet, and more
elegant solutions for some of the problems may be found. Like /proc,
even with it's faults, it's better than the alternative.
Devfs/devfsd provides us the opportunity to better separate
mechanism and policy for devices. devfs provides the mechanism: the
name space for accessing devices. devfsd (via links) provides policy--
application- or user-centric naming:
/dev/mouse -> /dev/psaux
/dev/sdb -> /dev/dsk/c1s2l0
As it's own filesystem, we have the option to "break" filesystem
semantics in a useful way, to better the separation of mechanism and
policy: enable setting permissions and ownership of symlinks, and
devfs using the symlink's perm/owner when opening. Probably requires
some changes to the VFS layer though...
I think I got it, this time.
-- Scott Henry <scotth@sgi.com> / Help! My disclaimer is missing! IRIX MTS, / GIGO *really* means: Garbage in, Gospel Out Silicon Graphics, Inc / http://reality.sgi.com/scotth/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/