Date: Tue, 17 Feb 1998 02:45:43 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: julian@whistle.com (Julian Elischer) Cc: current@FreeBSD.ORG Subject: Re: devfs persistence Message-ID: <199802170245.TAA06039@usr04.primenet.com> In-Reply-To: <Pine.BSF.3.95.980216153712.8949V-100000@current1.whistle.com> from "Julian Elischer" at Feb 16, 98 04:45:53 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > >Not entirely; you *don't* have the capacity to specify what a new
> > >device node should look like when it's created. Because you're not
> > >there waiting for it when it appears, there needs to be a mechanism
> > >whereby you can specify in advance what it should look like.
> >
> > In todays system, if a "new device arrives", I hook it up to my machine,
> > and expect to perform some amount of configuration to make that new device
> > work. This could include adding kernel device support for it, adding the
> > device to a cron job or other script, telling the user community about it,
> > etc. In the world without DEVFS, this would also include the necessity of
> > running MAKEDEV to create the node and, if the permissions weren't adequate,
> > chmod/chown type operations. The only difference in this scenario with
> > DEVFS is that the default node comes into existence automatically, but the
> > user will still expect to have to modify permissions before the device is
> > guaranteed to be completely usable. The only issue I see, is one of
> > security with DEVFS. Some admins may not want new device arrivals to show
> > up auto-magically.
"Some admins" should change the default permissions and ownership in
the source for the device before they link it into their kernel, then.
> Part of the 'charm' of a devfs is that you never have to do a
> mknod because sensibly defaulted devices will turn up as th ehardware
> does. At least in /dev. This may not be true in a chroot where
> using -ono_new_dev in the mount is probably a good idea.
And go away when the hardware does. This is at least as important.
> The persistance problem is more likely for a few devices
> that the operator wants to do something funny with. I think that for
> individual devices, once the operator has run 'chmod' on them they can
> grow an inode in the backing layer. This unfortunatly means that all ttys
> would grow such nodes.
> There are problems with this however.
> If a user renames the device, where is the info stored?
> what if htere are multiple links?
> The same problems hold for storing the info in files in general.
>
> Is /dev/fd0 the same device as /dev/fd/fd0?
> generally each node doesn't have a very clear idea of it's global name.
> just it's name in the current directory, and it may have several of those.
I think this is more of a call for a data interface to be applied to
device objects.
Consider a kernel with a linker set that contains the default schema
for all devices in the linker set, as well as the pointers that let
the kernel find the devices from the linker set data.
If this data is in a well known location (the linker set symbol is
known), then it's possible to edit this data in an unlinked shared
object (KLD), or in a post-link kernel.
The one missing piece is per device instance controls, which are
an odd thing indeed.
One of the few places where I could see this being an issue is
for something like a serial printer that is not accessed through
a daemon. This is an incorrect paradigm for accessing such a
device.
Another might be for dialout modem access. Default access controls
for group access can, however, be specified in the template device.
If this is too onerous, well, then rc.local, rc.shutdown, and mtree
are your friend.
> > >The specific problem with using nothing but nodes behind the DEVFS
> > >entries is that you can never provide for all the entries that might
> > >appear without, you guessed it, a *script* that creates all these
> > >backing nodes. Doesn't that sound familiar?
>
> If it were to just replace MAKDEV, devfs would not be worth it.
> but it comes from the many cleanups that become possible after it has
> arrived that it derives it worth.
Not to mention the fact that you could then netboot a FreeBSD box
from another UNIX system that can't NFS export 32 bit minor numbers...
> > This is not a problem unless there is a security issue, and I have already
> > proposed a method for dealing with security issues with an option to only
> > allow devices to show up that have a backing object. The user community
> > already expects to have to modify the permissions of new device nodes if
> > the defaults don't suit their needs... why is this any different.
>
> That does beg the question of "how do you make the backing node
> initially.." but that is soluble. How does a naive home-sysad
> know what to do with the new devices? We need to assume that newly
> arriving devices have secure parmissions.
There is also the concept of a device whose ownership follows that of
the console. This is probably a necessary extension to the schema
(mouse, keyboard, sound card, etc.).
> > >> Sounds much more complicated and space consumptive than it has to be.
> > >
> > And saying, "If you mount your DEVFS on a directory that just happens to
> > have a 'devinfo' file, you get magical DEVFS properties", is intuitive?
>
> If you specified the file in the mount options it get's more intuitive.
> but this is not the same as persistance, which is making the results of
> setattr() stick across reboots. do we watn reanmes to stick too?
> that would be REAL persistance. Personally I think that
> making the rule simple.. ("DEVFS is not persistant") it makes it a lot
> more intuitive.
Persistance is futile, you will be assimilated. 8-).
My personal take is that persistance is not a good idea. Say I set
a persistant permission on a transiently connected device. What
happens when I disconnect that device? Does the persistance make
the node stay around after it's gone? How is this better than the
MKDEV case where you have a stale device after rebuilding a kernel
without the device to which the node maps?
> I'd say it's 1% who actually want the permissions to STICK.
>
> > The first person I heard voice a desire to do this was PHK. I like Poul a
> > lot, but I don't think we should put every feature Poul wants into FreeBSD.
> > You have since taken on his argument too, but who else? The other people
> > I've heard in this discussion have voiced concerns about being able to
> > do what they can do today without DEVFS, with DEVFS.
You can shoot yourself in the foot with stale devices today; I suppose
you *could* argue that you should be able to shoot yourself in the foot
in the same way using a DEVFS -- but you won't get many takers. 8-).
> > I already proposed one. The "backing store only" option prevents new
> > device arrival from perturbing the "state of the world" the admin
> > setup. The only difference is that you must explicitly specify the
> > devices you want, not the devices you don't want.
>
> I think this is an easier problem to solve.
> I mentionned 3 mount options in an easier message.
If you are going to use an FS backing store (which I still think is a
mistake because of NFS and other FS's, like MSDOSFS, which can't handle
FreeBSD's idea of a minor number -- which you will have to have to uniqify
nodes), then here is how you should do it:
1) mount devfs as root:
/
\
\
/dev
2) Do *not* allow structure changes to the devfs. In effect, it
will appeart to be a read-only FS in terms of structure.
3) Union mount the root FS over top of the dev FS's "/".
4) Use whiteout nodes in the root FS to affect devfs structure,
create hard links, directories, etc..
This is real gross (well, #1 is a bit clever, actually 8-)), but it
satifies the backing store requirement as well as anything else.
> just look at this argument between two intelligent people on the topic..
>
> >
> > >Which just puts the
> > >bloat in swap space, along with yet another copy of large parts of the C
> > >library.
> >
> > Disk space is still much cheaper than RAM.
> >
> > >I don't buy the trivial size reduction as a benefit outweighing the
> > >drawbacks, and in the few cases where bloat is actually an issue, the
> > >size of the daemon's executable would be more of a penalty than the
> > >extra code growth in the kernel.
> >
> > The kernel can't be swapped out.
Magic ELF's. 8-).
#pragma swappable(0)
... everything in the code path for swapping ...
#pragma swappable(1)
...Fix you right up. 8-).
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802170245.TAA06039>