Looks like a bug in the 7300 disk driver

[a.b.sherman]

In article <1360 at mtunb.ATT.COM> jcm at mtunb.UUCP (was-John McMillan) writes:
>In article <813 at ttrde.UUCP> pfales at ttrde.UUCP (Peter Fales) writes:
>>
>>I have discovered what appears to be a bug in the hard disk device driver
>>for the unix-pc.
(R) UNIX is a registered trademark of AT&T
>...
>It's a FEATURE, not a bug.  Moreover, this feature will never be changed ;^}
>

It is *NOT* a feature it's a bug.  See below.

>Consider TAPE drives: in many systems, you can only communicate to the
>drive in EVEN byte multiples -- unless things have changed in the last
>twenty years since I've used a tape drive %v).  Is this an error?

You might be excessively DEC oriented.  Stuff for the PDP-11 and VAX
does its DMA based on a *WORD* count, hence even numbers of bytes
are required.  This is not exclusive to tape.  Actually, since most
tape is 9-track, the drive reads a byte at a time. (8 bits + parity).
>
>In the UNIX-PC, the RAW -- read that "character-device" -- interface
>to the disk directly maps transfers into user RAM.  Therefore, since
>transfers to/from the disk are in 512 byte blocks, ya can only read
>in 512-byte multiples.
>

Why a CHARACTER device must program its DMA device in BLOCK
multiples escapes me.  Regardless of the block size, you can always
tell a DMA controller to transfer X bytes or X words.

>In some other systems, boundary cases -- un-aligned first and last blocks
>-- are read into kernel buffers and NOT into user-space.  This permits
>Peter's anticipated results.
>

Which, the 512 byte read on rfd000 or the 4 byte read on fd000?

>Finally (fat chance of this ;-):
>1)	TSK-TSK -- users are NOT supposed to be accessing the RAW disk
>	at all.  And if this is permitted... the special characteristics
>	of the RAW driver have to be coped with!

Why shouldn't I do raw I/O on the disk?  Maybe I want to make a raw
slice for my own special purposes, like building a TUXEDO database.
Why put the driver entry there if it's not to be used?  Features
that are not intended to be used do not belong in the system.

>
>2)	I believe I've seen this feature documented -- and isn't that
>	enough to satisfy everyone?

Where is it documented?  It is not on the manual pages for read(2),
open(2), gd(7).  Even so, documented brain damage is still brain
damage.

>
>3)	Lord[s], let us not descend into the hell of other groups that
>	have wasted untold kilo-bucks thrashing unresolvable differences
>	of opinion over system features -- not to mention address-to-index
>	computations by name.
>

Again I repeat, this is a bug.  Calling a feature doesn't make it
any less a bug.

>PS: I haven't pursued the above issue through the source code so the above
>drivel may be the first flawed argument of my life -- oops, I meant HOUR.
>
>jc mcmillan	-- att!mtunb!jcm	-- just frothing for myself, not THEM.


-- 
andy sherman / at&t bell laboratories (medical diagnostic systems)
room 2e-108 / 185 monmouth pkwy / west long branch, nj 07764-1394
(201) 870-7018 / andys at shlepper.ATT.COM
...The views and opinions are my own.  Who else would want them?