Ross Harvey <ross@ghs.com> writes:
> I have to say, I've never seen this. I'm sure Chris and the other CMU
> folks understood this in detail -- I understand that they did patch the
> OSF/1 source to deal with this ...

It was probably just me, and it's definitely "understood" -- i don't
remember many of the details at all.

In a nutshell, i _think_ it was something like:

	you create a device node under NetBSD booted diskless or with
	tar xf or whatever.

	you ls the device node under the server

	as part of doing the ls, the kernel would invoke the bad
	conversion-unconversion code, and you'd end up with a
	no longer correct device node.

I don't quite recall, though.  it's been a while.  Also, i seem to
recall that the original problem was noticed with OSF/1 2.x.  I don't
recall if it persisted into 3.x, but i seem to recall that the UFS
code which called the conversion functions was identical in 3.x so I
patched around it on our NFS servers for 3.x as well.

It might also have happened when doing remote lookups/stats via NFS,
but I forget.
 

> I think there is a subtle issue there .. the problem only occurs if you
> run mknod(8) on OSF/1 ^W DU ^W Tru64, or something like that.

That won't work, for a different reason (IIRC): the major/minor split
is different.


> I've been
> told that if you use gtar under DU to unpack the sets, or, if you (like
> me) run our tar or pax from NetBSD over an NFS-mounted drive, then the
> nodes you get back will work just fine.

Right, those'd work, until the kernel went and stomped on them when
you did <the operations that i forget, that triggered the problem>.
8-)



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.