Subject: Re: mnt_leaf, v_vnlock, VLAYER
To: None <firstname.lastname@example.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 12/05/2005 01:21:50
>> Consider, for example, a layer which does name remapping a la Eunice
> I can't say more about Eunice, though, as we don't have anything like
> it in the tree and all google could tell me was that it seemed like
> unix services for VMS.
Eunice does - or at least did - Unix emulation on VMS. In particular,
it emulates a case-sensitive "any octet but 0x00 or 0x2f can appear in
a component name" filesystem on a case-smashing filesystem whose names
have a whole bunch of syntax - and in early version was severely
limited in length as well.
It did this by representing each Unix-layer file with two VMS-layer
files, one containing the contents and the other containing the name
mapping. They were called things like HSHUECOG.HSN and HSHUECOG.HSH
(details are probably wrong), and, in particular, to use the
terminology somewhat loosely, there were two underneath-layer vnodes
for many mount-point-layer vnodes. (Not all; if the name were all
lowercase, conformed to VMS conventions, and did not collide with the
mapping scheme's names, it was not mapped.) I can see NetBSD use for
such things in, for example, running atop msdosfs....
We (=NetBSD) may decide we don't care about supporting any such
filesystems, but if so, we should make that decision consciously,
rather than by not realizing the possibility exists.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML email@example.com
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B