Xref: utzoo comp.protocols.nfs:765 comp.unix.i386:3502
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!emory!mephisto!bloom-beacon!eru!luth!sunic!mcsun!ukc!icdoc!qmw-cs!liam
From: liam@cs.qmw.ac.uk (William Roberts)
Newsgroups: comp.protocols.nfs,comp.unix.i386
Subject: Re: statbug.c: Spot a BUG with NFS stat()
Summary: Bug in the eye of beholder
Keywords: dev_t semantics
Message-ID: <1777@sequent.cs.qmw.ac.uk>
Date: 12 Mar 90 12:05:54 GMT
References: <638@hades.OZ>
Reply-To: liam@cs.qmw.ac.uk (William Roberts)
Organization: Computer Science Dept, QMW, University of London, UK.
Lines: 22
Expires:
Sender:
Followup-To:
Distribution:

Your "bug" is complete nonsense. If you can give chapter and
verse for your strange assertion that negative dev_t values are
"garbage", then and only then do you have a bug in your system
rather than a bug in your understanding.

On my system, <sys/types.h> have dev_t as unsigned short
anyway, so no negative numbers there. Since an NFS filestore is
not represented by a local physical device, the dev_t number
isn't required to have a major device number that could be used
as an index into the bdevsw or cdevsw tables.

In fact, most NFS implementations choose to fake a major device
number that is way in excess of the likely valid range to avoid
clashes. It's also a function of the client, because "device
numbers" aren't part of the NFS abstraction.

-- 

William Roberts                 ARPA: liam@cs.qmw.ac.uk
Queen Mary & Westfield College  UUCP: liam@qmw-cs.UUCP
Mile End Road                   AppleLink: UK0087
LONDON, E1 4NS, UK              Tel:  01-975 5250 (Fax: 01-980 6533)