Hello,
The original question:
> I wanted to use DU box as an NFS server for Linux diskless clients.
> However, devices' major/minor numbers encoding differs between the two.
> Anybody knows how DU is enconding major/minor numbers for
> character/block devices.
It seems that this wasn't clear enough, so I'll try to clarify
things here and give the solution as well.
Sorry for such a long summary, but I hope somebody will find
the following story interesting.
I was trying to boot a diskless Linux station (aka
PC-that-escaped-Gates) from OSF/1 server and mount all of
it's filesystems over the NFS. No ramdisk, no swap (Linux
can live without one)--all memory available to processes.
Everything was fine with a notable exception of /dev
directory containing device special files. The major/minor
numbers were all mixed up.
The problem is with NFS's v2 inability to transfer rdev
field of an inode's stat structure in a "portable" way.
rdev is an unsigned quantity containing major and minor
numbers of a device special file. It is system dependent
and makes sense only on machine where it was created.
Still, what if some fool (like me) wants to mount a file
which is a special device over the NFS. This is what RFC
1094 (NFS Protocol Specification) states about the topic:
The "rdev" field in the attributes structure is an operating
system specific device specifier. It will be removed and
generalized in the next revision of the protocol.
So it was (generalized) in NFS version 3 and this version
handles a rdev field in a meaningful manner, i.e. decoding
it on the server and transferring it to the client as a pair
of numbers. Digital UNIX has a version 3 NFS server
implemented, but, unfortunately, there's no NFS v3 client on
Linux.
The solution
As Alan Rollow and Tom Blinn suggested (and they were right)
I would have been better off with a ramdisk containing these
little devils in /dev directory. The other way around would
be to use the same architecture (Linux) as an NFS server,
but this was not an option for me. Anyway, being such a
stubborn guy, I managed to persuade DU and Linux to
interoperate on the matter.
Linux encodes major/minor number in a 16 bit number like
this: xxxxxxxx yyyyyyyy (x is major, y is minor), and DU is
using 32 bits: xxxxxxxx xxxxyyyy yyyyyyyy yyyyyyyy (this is
what I asked originally). It seemed to be enough to encode
Linux's major/minor with DU's minor, e.g. to use (0,256*4+1)
on DU for Linux device (4,1). That's what mathematics says,
but, somehow, all (0,whatever) were decoded on Linux as
(0,0) (sigh). What does work is the combination (1,256*x+y)
which yields correct results on Linux. The explanation
would be somewhat technical--suffice it to say that the
following two commands
# mknod file c 1 1
# mknod file c 0 257
give exactly the same result on Digital UNIX. So, I
"ported" Linux's MAKEDEV to Digital UNIX, changed the
calling sequence for mkdev and all special device files
where fine.
BTW, Linux on PC (I think 286 would do too) running telnet
client and lpd server along with NFS is using only around
1MB of memory, is up and running within 15 seconds and it's
probably the thinnest client on earth.
Thank you Tom Blinn and Alan Rollow for helpful suggestions
which gave me clues to solving this problem.
Sincerelly,
Dejan Muhamedagic dejan_at_yunix.co.yu
Received on Mon Mar 16 1998 - 12:01:47 NZST