Looks like a bug in the 7300 disk driver

[was-John McMillan]

ASBESTOS-DONNED...

In article <513 at genesis.ATT.COM> andys at shlepper.ATT.COM (a.b.sherman) writes:
...

>You might be excessively DEC oriented.

	... yup... I might be.  Or at least raised thereupon.

>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.

	... maybe... but, when ya buy a tres inexpensive computer -- made
	possible by (supposed) cost savings in every corner they could
	think of -- ya get things like the DMA in the 7300 which is NOT
	TOTALLY GENERAL.  While I think it COULD be trained to transfer
	N-WORDS, I doubt it could do this at anything but a SECTOR
	boundary -- which is a severely non-general case.

>>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?

	Peter: Wasn't your only surprise from "/dev/rfp000" accesses?
		If I missed your point, I apologize profusely.
	Andy:  If the boundary cases are read into temporary kernel
		buffers, then one can permit "N" byte RAW I/O to/from
		user-space by just bcopy-ing across.  The disk still
		requires full PHYSICAL-block writes and SECTOR-aligned
		reads.  Aligned, block transfers better be working!.

>>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.

	I've not the SLIGHTEST concern about your use of RAW disk
	accesses.  "TSK-TSK", as a serious social criticism,
	went out with knickers: I presumed this was a giveaway that
	you can make NON-STANDARD DISK ACCESSES AT YOUR OWN RISK.

	I'm sorry you don't run FSCK, IV, or other system codes that use
	the RAW disk entries.  I do.  And, despite the pain, the system
	codes that do use the RAW entries work!  Mirabile visu!  So,
	I don't think I'll recommend that these features be pulled... yet!

>>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.

	O no.  So much for forgetting the ";^)"  Guess I thought the
	phrasing was, again, a giveaway.  So much for humor, let me
	present, then, a concise synopsis of how I feel about the
	issue of RAW I/O to the 3B1 hard-disk:

	a) It should work reliably.  I believe it does.
	b) It should be documented well: "better" is the operative word.
	c) I'd prefer that it were more general, but accept it as it is.
	d) I note: this is the first time I've heard a complaint on this
		in 4 yrs.
	e) It sounds like the Surprised_Party[0], Peter, has more grace
		than the Surprised_Party[1].
	f) I'd really be surprised if, knowing the limitations, these
		really place a meaningful limit on codes.
	g) I'm inclined to help Peter, if he asks for advice -- I'm just
		quite certain Product Management wouldn't risk diddling
		the disk-driver.

>>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.

	Confusing personal philosophy with critical insight is a curse.
	I wish you a cure, and hope I can offer you a warm blanket on some
	other issue, Andy.

NOMEX OFF -- Sweaty things, but necessary apparel.  Meanwhile, I'll try
to help where I can.

jc mcmillan	-- att!mtunb!jcm	-- speaking for himself, at most.