Messages in this thread | | | Subject | Re: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device a lloc ation) ) | Date | Fri, 08 Oct 1999 10:08:18 -0400 | From | Horst von Brand <> |
| |
Scott Henry <scotth@sgi.com> said: > >>>>> "H" == Horst von Brand <vonbrand@inf.utfsm.cl> writes: > H> Reasons against devfs:
> 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/
| |