Xref: utzoo unix-pc.general:2016 comp.sys.att:5142 Path: utzoo!utgpu!watmath!clyde!att!mtunb!jcm From: jcm@mtunb.ATT.COM (was-John McMillan) Newsgroups: unix-pc.general,comp.sys.att Subject: Re: Looks like a bug in the 7300 disk driver Summary: O woe... Keywords: fate Message-ID: <1360@mtunb.ATT.COM> Date: 9 Jan 89 21:35:07 GMT References: <813@ttrde.UUCP> Reply-To: jcm@mtunb.UUCP (was-John McMillan) Organization: AT&T ISL Middletown NJ USA Lines: 37 In article <813@ttrde.UUCP> pfales@ttrde.UUCP (Peter Fales) writes: > >I have discovered what appears to be a bug in the hard disk device driver >for the unix-pc. ... It's a FEATURE, not a bug. Moreover, this feature will never be changed ;^} 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? 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. 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. 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! 2) I believe I've seen this feature documented -- and isn't that enough to satisfy everyone? 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. 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.