> 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?
>
How about using /etc/rc.d/rc.local? Or /etc/inittab?
At boot time: chmod 660 /dev/fd0
That is what rc files are there for. This works with devfs
without a necessity for devfsd.
We already have dynamic /dev, but there is no standard for it,
there are a dozen groups doing it in as many ways. We have UUID's,
/proc/sound/dev (path?), /dev/pts, SCSI, PCMCIA, USB. I'm sure there
are others that I'm not familiar with. We have network devices that do
not have entries in /dev because they are dynamic and /dev isn't, so we
have a seperate mechanism for dealing with them...very unUnixlike.
I think devfs can fix a lot more problems than people give it
credit for.
> > H> - Breaks filesystem semantics in several ways, makes it very hard
> > H> 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.
>
You are assuming that "permanent permissions" is a benefit you
really have, and that it is desirable.
I disagree on both counts.
>
> 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.
>
Thinkpad 600. Moot this.
> > 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.
>
Buy an iBook, in 6 months you'll be trying to convince us.
> > 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.
>
I would say that the above paragraph says it all.
Of course the proposed course of action would break a system
that uses modules, like OSS.
> > 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?
>
Seems to fail safe to me, failure or non-use of permission handling
machinery would result in default permissions. These tend to be
_more_secure_ than modified permissions.
> - Impact on administration: "For Linux, unlike any other Unix system,
> devices are managed by...". This hinders people portability.
>
Right, like any 2 Unix systems manage their devices in the same way.
Irix, AIX, Openserver, SVR4, QNX, BSD, pick 2 that have the same
device management mechanism out of that list, I dare you.
> - Impact on software portability: What if this cool foo package needs to
> change permissions on the bar device? On installation? During operation?
>
It does so. Just expect a consistent set of permissions at boot time.
> - Impact on kernel drivers (discussed above)
>
None.
> - 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?
>
That would be how capabilities are managed. That thread convinced me
that capabilities are enforced in kernel space, but held in user
space. And this is worse than the current system in what way?
> Again, /dev might not scale well, but it is a non-problem. I have yet to
For you.
> see a machine with hundreds of devices. And the network around here, that
I have.
> is certainly made of hundreds of devices, isn't reconfigured willy-nilly.
Some need to be.
> 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.
devfs solves so many more problems than "naming issues" that this isn't
even funny.
>
> 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.
>
devfs stands to _save_ a lot of work for developers by freeing them up
from how to manage the next set of dynamic devices. The people that seem
to be arguing against it the loudest are the Admins who would have
to change a few lines in their scripts to account for a consistent
/dev at boot time.
-- Daniel Taylor Senior Test Engineer Digi International danielt@digi.com Open systems win.
- 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/