Xref: utzoo unix-pc.general:2022 comp.sys.att:5166 Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!nrl-cmf!ukma!rutgers!att!genesis!andys From: andys@genesis.ATT.COM (a.b.sherman) Newsgroups: unix-pc.general,comp.sys.att Subject: Re: Looks like a bug in the 7300 disk driver Summary: Not Documented, ergo, a bug Message-ID: <513@genesis.ATT.COM> Date: 10 Jan 89 20:08:31 GMT References: <813@ttrde.UUCP> <1360@mtunb.ATT.COM> Reply-To: andys@shlepper.ATT.COM (a.b.sherman) Organization: AT&T Bell Laboratories, Middletown, N.J. Lines: 77 In article <1360@mtunb.ATT.COM> jcm@mtunb.UUCP (was-John McMillan) writes: >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. (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@shlepper.ATT.COM ...The views and opinions are my own. Who else would want them?