lkml.org 
[lkml]   [1999]   [Oct]   [10]   [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:
> > 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:

[...]

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

> Bullshit, any time you rebuild /dev you lose permissions.
> If you run "/dev/MAKEDEV floppy" you lose permissions.

Right. But if I do that, it is because I want to _create_ the devices
(nothing to loose there).

> The only difference with devfs is that the "whole package"
> includes a userspace daemon to preserve permissions
> across those boundries since they occur more often.

ext2 does that for free.

[...]

> The whole network architecture as it exists does so because
> classical Major/minor devices are inadequate for the job
> and too difficult to manage for the level of dynamics network
> interfaces can exhibit.

Please explain. How is lo, eth0 and sl0 too dynamic to handle via
major/minor?

Truth is, networking is designed the way it is not because of the
_devices_, but because of the volatility and sheer number of _network
peers_ (both current and potential). Now this might make a good model for
the mythological machine with hundreds of devices coming and going that is
talked so much about here. But there you see that you address a _service_
(device type?) through an _address_ (IP address, for human consumption a
domain name; with a naming service in between) that is unique on the world
(device serial, MAC address, IPv6?). But in the end all this is machinery
that gives a convenient handle that takes you to the _content_ (today's
favorite cartoon). That last is your objective. Don't get hung up on
mechanisms, look for the final end and design a better way to get there.

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

> The same set of problems keep having to be solved in different ways
> BECAUSE we have not had a good dynamic filesystem.

I don't understand this at all.

[...]

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

> Have you tried it? Didn't think so...

Does hda5 appear again? Do the permissions on fd0 stay? Even if I unplug
the system after the calls return? If the system is hopelessly overloaded,
no way to run any daemons at all? If all filessytems are full?

[...]

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

> I have seen more systems broken because some script or sysadmin changed
> permissions on a file than I have seen broken because they couldn't.
> Purely subjective stuff, but I am convinced.

First is obvious. Second one, as permissions on files usually _can_ be
changed by admins, you very rarely will see this. But you very often see
systems broken (into) because some permission wasn't set up right. Don't
make it even harder.

[...]

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

Why? The module will get loaded iff the card is there, and the device will
react as it should. If you plug in various stuff, you need more care, sure.

[...]

> > > It does so. Just expect a consistent set of permissions at boot time.

> > Useless, if I need it at boot.

> Useful, if you are recovering from a security breach and somebody
> helpfully changed all your permissions on you.

Said miscreant could also screw up your /etc/devices.perm file, or "fix"
the kernel so it gives the wrong permissions (and even lies about them).
Might be marginally easier to do via devfs, BTW.

In the current scheme, boot singleuser and rerun /dev/MAKEDEV (or a clean
copy off distribution media).

No advantages either way.
--
Horst von Brand vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Viña del Mar, Chile +56 32 672616

-
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.073 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site