> H> - Permanent attributes are kludged on
> attributes are managable in a scalable way.
By recompiling the kernel for each combination?
> H> - Breaks filesystem semantics in several ways, makes it very hard to check
> H> ramifications
> H> - Impacts system administration, making device managing a lot less Unixy
> I haven't noticed it being harder or less Unixy.
Device names, permissions, ownership won't stay put unless extra steps are
taken. Adds fragile mechanisms to get back what you already get from
handling a device as a plain file. Need to remember to either recompile the
kernel or edit a configuration file for permissions.
> 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.
Yes, but it has mostly been changes, not gratuitous additions. The head
hackers probably won't use devfs anyway, so the changes in the driver's
interface (registration) will accumulate. Then, three cycles of patches
later, some newbie needs that device under defvs, which now crashes.
> Besides, the changes for most drivers seem to be mostly the addition
> of a parameter to the registration call. And it puts the knowledge
> for creating devinces in the one place that knows it -- the driver.
It has to be done for _each_ driver. I'm not saying that this should never
be done, just that the cost isn't worth the gains in this particular case.
> 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.
MAKEDEV works. No, I don't hot-plug stuff all day. But then again, nobody
I've ever met does either, so the point is moot.
> 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? Then don't configure it in on your machines.
I haven't met _anybody_ that does what is touted as THE case in which devfs
is the ideal solution, so I'll stay unconvinced.
> H> Reasons for devfs:
> H> - Makes handling hot-plug easier, but marginally so
> H> - Unclutters /dev
> A static /dev doesn't scale. That's why IRIX 6.4+ uses a hybrid
> dynamic /dev. I presume that Sun does it for similar reasons.
>
> The size of /dev isn't really disk space, it is congnitive space.
Bingo! And devfs won't enlarge my mind, it will at most shrink /dev. But
that I can do by hand, or even automatically: Write a scriptlet that checks
each device in /dev; if it isn't there, delete it.
> 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).
mount(8), particularly "mount -L label", "mout -U uuid"
> 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.
> H> Weighting the above, the answer for me is clearly "no".
> And given my experience, including devfs in the standard kernel src
> is a no-brainer. Sure, it's a little rough around the edges, but it
> won't get better until it is a standard part of the kernel source.
"It will get better when in the kernel" isn't the right way to advocate a
patch. This assumes innocent third parties will have to take over the work
of getting it right.
There are many things that have to be thought out carefully, before any
deep-cutting change is considered:
- Impact on security: What if the permission handling machinery goes
missing or breaks? What new kinds of attacks does this make possible?
Ways to fix them?
- Impact on administration: "For Linux, unlike any other Unix system,
devices are managed by...". This hinders people portability.
- Impact on software portability: What if this cool foo package needs to
change permissions on the bar device? On installation? During operation?
- Impact on kernel drivers (discussed above)
- Impact on future developments: Say capability-enabled root-less Linux
distributions. How will capabilities be handled for devices? Now there
will have to be an all-powerful device manager... want to bet what
crackers will start to try at after getting into your system?
Again, /dev might not scale well, but it is a non-problem. I have yet to
see a machine with hundreds of devices. And the network around here, that
is certainly made of hundreds of devices, isn't reconfigured willy-nilly.
Each change does take some work figuring out how it works and then changing
it. Naming issues (and that is the _only_ thing a devfs can solve) is a
very minor part here.
And yet again, I do see some advantages in a devfs type system. It's just
that they are very minor, IMO, and just not worth the extra hassle. No, not
extra hassle for the systems user or even administration, hassle for the
developers. But that one, soner or later, translates into extra hassle for
the former. Software systems developments in general have shown time and
again that "just a few percent here" ends adding up to a huge, unmanageable
ammount. Just read Fred Brook's "The Mythical Man Month", or closer to hand
look at into what sorry state the neverending quest for new features got
the mass software industry in general. Linus has taken this to hearth, he
won't allow "a few percent less here for a possible gain there", or "cool
features, just for their coolness" into the kernel.
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513- 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/