Xref: utzoo unix-pc.general:2061 comp.sys.att:5226
Path: utzoo!utgpu!watmath!uunet!labrea!agate!bionet!csd4.milw.wisc.edu!bbn!mit-eddie!andante!att!lzaz!lznh!wfl
From: wfl@lznh.UUCP (<10000>Bill Lanky)
Newsgroups: unix-pc.general,comp.sys.att
Subject: Re: Looks like a bug in the 7300 disk driver
Summary: Not a 7300 bug; it's a UNIX feature
Message-ID: <1993@lznh.UUCP>
Date: 13 Jan 89 21:19:14 GMT
References: <813@ttrde.UUCP> <1360@mtunb.ATT.COM> <983@mstar.UUCP> <186@ecicrl.UUCP>
Organization: AT&T
Lines: 25




If the 7300 raw disk driver always transferred blocks but other UNIX systems'
raw disks could transfer smaller units, you would have a "7300 device driver
bug".  However, the 7300 disk driver actually works the same way that raw
disks do in all other UNIX systems, so it cannot be called a 7300 bug.

This behavior of the UNIX raw disk driver is neither unknown nor undocumented;
ask any kernel guru, or see M. Bach's book "Design of the UNIX Operating
System" for example.  The raw driver brings you closer to the disk hardware
for potentially better performance, but being close to the hardware means
you have to become aware of the disk block size (which incidentally is NOT
always 512 bytes on every UNIX system.)  By designing the raw disk interface
in this way, the developers of UNIX have provided a means for low-level
disk access which is the same across all UNIX implementations, regardless
of whether they have intelligent or dumb hardware disk controllers.
(Note that write() and lseek() behave consistently, too).

In short, since it was designed and documented to do what it does,
it cannot be called a bug.  If some UNIX version had a security loophole
associated with this feature, the bug would be that the implementors
did not provide enough security checks when they coded it.

Bill Linke