Date: Wed, 3 Jun 1998 23:44:10 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: bag@sinbin.demos.su (Alex G. Bulushev) Cc: mike@smith.net.au, tlambert@primenet.com, eivind@yes.no, sepotvin@videotron.ca, current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... Message-ID: <199806032344.QAA08803@usr04.primenet.com> In-Reply-To: <199806030915.NAA15706@sinbin.demos.su> from "Alex G. Bulushev" at Jun 3, 98 01:15:14 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> {nfs_srv}# cat /etc/exports
> /mnt/roots -maproot=0:0 nfs_clnt1 nfs_clnt2 nfs_clnt3 nfs_clnt4
> {nfs_srv}# ls -al /mnt/roots/VM1/dev/null
> crw-rw-rw- 1 root weel 2, 2 3 jun 12:25 /mnt/roots/VM1/dev/null
> {nfs_srv}#
>
> on nfs client we have:
>
> {nfs_clnt1}# mount
> /dev/sd0s1a on / (local, noatime, writes: sync 6436172 async 3495235))
> procfs on /proc (local)
> nfs_srv:/mnt/roots on /mnt/roots
> {nfs_clnt1}# ls -al /mnt/roots/VM1/dev/null
ls: /mnt/roots/VM1/dev/null: No such file or directory
/dev is a seperate fs. It is no more available to your NFS client
machine than any other FS that you haven't mounted locally.
> so we use "nfs mounted devices" localy on nfs clients
No, you *don't*.
You mount your own /dev out of your own kernel's knowledge of your
own machine.
There is no such thing as NFS client access to NFS mounted device
nodes. In point of fact, we should *remove* the specfs references
from the NFS client code at this point. The only value a special
device nod has is as a marker from NFS clients that don't have a
devfs. Specifically, this means non-FreeBSD clients.
The specfs references in client/local media FS's are specifically
tere right now because devfs is not mandatory (yet).
> surely local major/minor for devices mast by the same as on the remote
> server or u mast use device proxy on fs level (not existing now)
No. It would be impossible for me to netboot my HP340 or my Multia
NetBSD off of my Dual P90 FreeBSD box if this were the case, since
FreeBSD and NetBSD don't share node-space.
The point for a client is to have the major/minor pair, which is
interpreted *in the specfs in the client's kernel* to represent a
local device (or not).
NFS mounted /dev directories are, of course, subject to the same
issues of "stalemness" as a local /dev directory in a non-devfs
configuration.
This is one of the reasons non-devfs configurations suck, and one
of the primary spurs to develope devfs in the first place. The /dev
directory of a machine should represent *exactly* what local devices
do or do not exist -- *on the particular client*.
> with "classic" device nodes on file systems it is realy simple
> to use this scheme
Not really. It is a pain, since servers and clients rarely have
precisely the same hardware. It is even *more* of a pain when the
OS environment is heterogeneous between the client and the server.
You *are* aware that it's currently impossible to netboot a FreeBSD
box diskless off a DEC Alpha running OSF/1 at this point because the
OSF/1 FS is incapable of representing the requisite FreeBSD minor
number space, right?
> with dynamic device id and devices only on devfs mounted, it is very hard
> to use devices on nfs, especially if u have several nfs clients vith handreds
> of chrooted "virtual mashines", a lot of mount/unmont devfs and rm/mknod in
> boot time and before/after of delete/create each VM and on each nfs
> server/client kill u system and require a number of custom scripts and
> sync of all manipulation via network (using rsh or other tools)
Not really. The practical fact is that only in special cases would
you *ever* want your client device list to contain something other
than a perfect representation of the devices on the client.
The most common case will be the FTP server that runs in a chroot
environment, and it's acceptable to fire off a script (in the
background), whose last act is to enable the FTP access. It will
most likely be done with the mount / find / grep -v / rm before the
system is up to a point where it is useful in any case... it takes
only the time for the system calls (no disk I/O; it's an in-memory
tree structure) to create the modified chroot environment "/dev".
Frankly, the big issue is local permissions differences on systems
owned by people too stupid to change the default values away from
the defaults in the device descriptor structures, and who want to
use chmod/chown instead, and thus require the commands to be persistant
in some way other than mtree + rc.dev. It would be trivial to modify
the config program (which should die, die, die to be replaced by simple
object file agregation) to take arguments like:
disk wd0 at wdc0 drive 0 owner root group operator mode 0640
to make said weenies happy. Of course, modifying the config program
(which should die, die, die to be replaced by simple object file
agregation) is left as an exercise for the weenies. If they could
justify their permission requirements, the defaults would be their
defaults, and they wouldn't have reason to whine about them. It's only
the unjustifiable permissions changes which cause trouble...
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?199806032344.QAA08803>