From owner-freebsd-current Sat May 30 12:14:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA18852 for freebsd-current-outgoing; Sat, 30 May 1998 12:14:53 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA18847 for ; Sat, 30 May 1998 12:14:51 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id MAA11174; Sat, 30 May 1998 12:10:00 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd011172; Sat May 30 19:09:54 1998 Date: Sat, 30 May 1998 12:09:51 -0700 (PDT) From: Julian Elischer To: Mike Smith cc: "Jordan K. Hubbard" , Eivind Eklund , current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... In-Reply-To: <199805300414.VAA00432@antipodes.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG yes, and the easiest way of achieving that is to get the device from a temporarily mounted new copy of devfs. do a lookup in there for the device you want mv it to /dev wherever you want ans unmount the temp devfs. I know that at present you can't do that and unmount the 2nd devfs, but that's easily fixable in the code. This lets the kernel do the lookup and the housekeeping. there are a few other things I'm looking at, one of which is a being able to mount a 'blank devfs (useful in some cases) and a mount -u which refreshes deleted devices julian On Fri, 29 May 1998, Mike Smith 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. > > You could make a strong case for having mknod ignore the (dev) argument > and just look the name up in the reference devfs copy, and then > duplicate it at the path given (presuming that's inside a devfs). > > -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ mike@smith.net.au > \\ The race is long, and in the \\ msmith@freebsd.org > \\ end it's only with yourself. \\ msmith@cdrom.com > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message