From owner-freebsd-current Wed Jun 3 16:44:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA01711 for freebsd-current-outgoing; Wed, 3 Jun 1998 16:44:49 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp02.primenet.com (daemon@smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA01603 for ; Wed, 3 Jun 1998 16:44:27 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id QAA20063; Wed, 3 Jun 1998 16:44:23 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp02.primenet.com, id smtpd019959; Wed Jun 3 16:44:17 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id QAA08803; Wed, 3 Jun 1998 16:44:10 -0700 (MST) From: Terry Lambert Message-Id: <199806032344.QAA08803@usr04.primenet.com> Subject: Re: I see one major problem with DEVFS... To: bag@sinbin.demos.su (Alex G. Bulushev) Date: Wed, 3 Jun 1998 23:44:10 +0000 (GMT) Cc: mike@smith.net.au, tlambert@primenet.com, eivind@yes.no, sepotvin@videotron.ca, current@FreeBSD.ORG In-Reply-To: <199806030915.NAA15706@sinbin.demos.su> from "Alex G. Bulushev" at Jun 3, 98 01:15:14 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > {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