lkml.org 
[lkml]   [1999]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device a lloc ation) )
Date
From
danielt@digi.com said:
> On Fri, 8 Oct 1999, Horst von Brand wrote:
> > 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.

And it works for no devfs _without_ touching any /etc/rc.d files at
all. Why do work when none is enough?

> 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.

OK, agree on a standard then. UUIDs work with IDE, SCSI, ... for disks. OK,
done. Network doesn't need /dev entries. DOne too. Sound needs different
files because devices are different, a dynamic filesystem papers over that
but doesn't allow me to use any program with any device. Then unify the
device nodes.

And dynamic filesystems cease to be a solution at all, because the problems
have been solved...

> I think devfs can fix a lot more problems than people give it
> credit for.

Maybe. What is questioned is that it may very well not be the best solution
in many cases, and isn't by far in the cases bandied around here.

> > > 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.

"rm /dev/hda5" doesn't work; neither does "chmod g-w /dev/fd0".

> > 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.

OK, that is common ground where rational discussion can take place. Why?
BTW, "permanent permissions" are given.

> > 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.

OK, how many _different_ kinds of devices do you plug into it?

> > > 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.

Again, how many _different_ kinds of devices will I be using simultaneously
on it? What kind of iBook devices plug themselves in, just by themselves,
and get instantly useable without any user intervention?

> > > 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.

Irix does it, Solaris does it too, ... I know the Solaris one, and don't
like it: You must reboot to get new devices attached. Also, devices change
their names if I move them around. Kernel mechanism itself seems quite
minimal (run a couple of userspace programs on startup when given '-r', no
big deal). Sure, /dev is uncluttered. As long as you remember doing the
'-r' each time. I just load up the machine, do the '-r' thing and forget
about it. A few files too much inside /dev (where I rarely go) isn't a big
deal. Besides, it is the easiest way to get persistence.

> > > 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.

Strange. I've been running OSS on my PC for quite some time, no problems
there. No devfs in sight, done it way before devfs was dreamed up even.

[...]

> > 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.

All devices 000 by default? What is "paranoid secure permissions" for you
might be "criminal insecurity" for the next guy.

> > - 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.

All of them handle them as files that have persistent permissions, AFAIK.

> > - 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.

Useless, if I need it at boot.

> > - Impact on kernel drivers (discussed above)

> None.

"No changes", "10 extra lines for each driver", "my driver was simpler
because of devfs" are all claims made here. Note the last one: If true,
that driver will _force_ devfs, as it won't work otherwise. So "just #ifdef
it to nil" won't work.

> > - 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?

Capabilities can not be handled in user space. If they are, they are next
to useless: The kernel won't be able to distinguish a faked capability
handler from the real one, and the security you should get goes out the
window. Same with permissions on devices: They have to be handled in the
kernel, as they are way to important to be handled outside by insecure means.

> > Again, /dev might not scale well, but it is a non-problem. I have yet to

> For you.

And everybody else I've ever met.

> > see a machine with hundreds of devices. And the network around here, that

> I have.

Great! How is it handled? What percentage of the admin time goes into
managing devices? 1%? 0.1%? Less? More? 10%? 20%?

> > is certainly made of hundreds of devices, isn't reconfigured willy-nilly.

> Some need to be.

Which ones? Why? How is that managed now? How will a simple naming scheme
for devices make the work simpler? By how much?

> > 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.

WHAT problems, exactly, does devfs (which is just a naming scheme) solve?

> > 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.

There is yet to be the "first set of dynamic devices" (USB), the discussion
started precisely on how to handle them. If devfs really did solve all, the
discussion would not even have started. That it did shows precisely that
devfs does _not_ solve the issues involved.
--
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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.212 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site