From owner-freebsd-current Fri May 29 22:25:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA21983 for freebsd-current-outgoing; Fri, 29 May 1998 22:25:41 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA21965 for ; Fri, 29 May 1998 22:25:37 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id WAA22013; Fri, 29 May 1998 22:25:45 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Mike Smith cc: Eivind Eklund , current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... In-reply-to: Your message of "Fri, 29 May 1998 21:14:32 PDT." <199805300414.VAA00432@antipodes.cdrom.com> Date: Fri, 29 May 1998 22:25:44 -0700 Message-ID: <21984.896505944@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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). Well, the way I figured it, devfs is going to have a mechanism for creating aliases anyway (for ln and friends), so an attempt to mknod something would result in devfs doing a reverse-lookup on the major/minor pair and creating an alias for the entry found. If none is found at all, you treat the mknod as a bogus operation and punt it. At last, a version of mknod which checks all of its arguments! :-) :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message