From owner-freebsd-hackers Sat Jun 23 13:51: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 0E1C437B401 for ; Sat, 23 Jun 2001 13:50:59 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.247.140.184.Dial1.SanJose1.Level3.net [209.247.140.184]) by swan.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id NAA13317; Sat, 23 Jun 2001 13:50:55 -0700 (PDT) Message-ID: <3B350150.E6175A61@mindspring.com> Date: Sat, 23 Jun 2001 13:51:28 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Zhihui Zhang Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Confusion with mknod() and devfs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Zhihui Zhang wrote: > I think you got me wrong. I was talking about a device > with more than one names. So we can have more than one > vnode for the same device. (If there is more than one name > to the same device in the same FS, they can share the vnode, > otherwise, they cannot.) This is not how it works. The specfs/devfs will return the same vnode. A "special device" file type in the traditional sense is a major/minor/{block|character} tuple. The entry in an FS that references this is _not_ where the vnode comes from, it's a hint to tell the system to get the vnode from a single place, instead (specfs in a traditional system, vfs in a less traditional system). > Specifically, I fail to understand why we reload the inode > in ufs_mknod(): Because when you make the node, you may have an exiting open reference to the same major/minor/{block|character} tuple, and you don't want to duplicate it in the ihash cache. The ihash cache is actually pretty useless, but since it's there, it has to remain coherent. A cache entry can point to an associated vnode, and you must only return the same vnode for a device, because it's backed in an exterior FS. > I wonder with the use of DEVFS, the special device aliases > may no longer exist because they are created by kernel > instead of by administrators. Unfortunately, they have not deleted specfs yet, so it is possible to mknod on an FS, and then use that node as a device. Deleting specfs is highly desirable, because of the struct fileops problem, but there are some benefits to having nodes on an FS, if you wish to use directory permissions and exclusion groups to control access to devices, rather than using ownership and multiple devfs mount instances. For example, I could create a "/opdev" directory that was only accessible by people in group operator, and then control access to mode 666 device nodes in there for things like tape drives, etc., which I only allow access to the operators to use. Similarly, I might add a "/graddev", and give them access to some devices that operators don't have access to, and at the same time give them access to only one of the tape drives (maybe they are working on HSM). If I have one student working on HSM, I can create the tape robot device in a subdirectory of their home directory, which no one else can access. I can do these sorts of things using exclusion groups, as well, but that would mean placing everyone into an exclusion group. Personally, I would rather see these problems addressed using "firm" links; hard links can't be made, and soft links don't grant permission. Use of "firm links" to replace soft links entirely would actually have the nice side effect of letting you ask "what is the name of this file I have open?" and actually get an answer. 8-). In any case, the point is that as long as specfs exists, aliases can exist, and need to be taken into account; only when specfs dies, and devfs is mandatory, do things get simpler (and more complicated, as noted above). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message