From owner-freebsd-current Fri May 29 21:55:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA17977 for freebsd-current-outgoing; Fri, 29 May 1998 21:55:32 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA17970 for ; Fri, 29 May 1998 21:55:30 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id EAA17400; Sat, 30 May 1998 04:55:28 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA04127; Sat, 30 May 1998 06:55:09 +0200 (MET DST) Message-ID: <19980530065508.30647@follo.net> Date: Sat, 30 May 1998 06:55:08 +0200 From: Eivind Eklund To: "Jordan K. Hubbard" Cc: current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... References: <19980530054842.51661@follo.net> <17374.896500321@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <17374.896500321@time.cdrom.com>; from Jordan K. Hubbard on Fri, May 29, 1998 at 08:52:01PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, May 29, 1998 at 08:52:01PM -0700, Jordan K. Hubbard wrote: > > > E.g. I can shoot my foot off, but I can't sew it back on. :-) > > > > Yes, you can. You can mount another devfs and 'mv' a device from it > > (or at least that's the way the specs read - I don't have devfs > > enabled right now, so I can't test). > > That's utterly rude. :-) > > I hope you're not implying that this is going to be the accepted way > for doing this in the future as well. Non-persistence is a big enough > violation of POLA as it is, and not even being able to do mknod(2) > operations on a devfs to replace missing entries would be a POLA > catastrophe. OK, this can be solved in at least these three ways (neither of which are pretty): (1) Add an ioctl() to devfs that does all of this in-kernel, and make mknod use this. (2) Add another layer to devfs that let somebody request by major/minor (requires a lot of hoops for SLICE, and locks us to the present set of majors/minors until the compatibility mode goes away). Call this layer from mknod to get correct device names. (3) Put a table in mknod that tells what owns which majors, and how to parse the minors. Use that to parse majors and minors. For the two latter solutions, mknod would have to mount a temporary devfs somewhere, and hardlink over the correct device node to the name supplied. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message