Date: Sat, 23 Jun 2001 13:51:28 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Zhihui Zhang <zzhang@cs.binghamton.edu> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Confusion with mknod() and devfs Message-ID: <3B350150.E6175A61@mindspring.com> References: <Pine.SOL.4.21.0106231256390.17858-100000@opal>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B350150.E6175A61>