tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: write alignment matters?



On 27 Jun 2011, at 10:27 , der Mouse wrote:

>>> That "what it is reasonable for a disk to do" consensus *is* the
>>> interface spec I was talking about, not the de-jure non-spec of "you
>>> get whatever the device (via its driver) feels like giving you".
> 
>> That's sort of the point.  If you want "what it is reasonable for a
>> disk to do" you should be using the block device [...].
> 
>> The raw device is supposed to be just that: a raw interface to the
>> device.  It gives you access to all the mis-behavior of the device
>> with all its gory niggling little details.
> 
> That's a nice theory.  But it's not the historical practice.
> 
> Typically raw device drivers do a nontrivial amount of cleaning up of
> the hardware's interface, such as dealing with bounce buffers and
> poking device registers.

I suspect bounce buffers don't have that long a history.  When we began to
run V7 on LSI-11's I distinctly remember having to chuck out third-party
DMA controllers which only did 16-bit addressing on the Qbus because we
needed to run with 18 bits worth of memory and there was no way to deal
with DMA controllers which couldn't reach it all (I think you could use
controllers that lacked address bits in a Vax, but only because there
was a memory mapping unit between the bus and the memory.  Software didn't
try to fix this).

I guess it is also worth pointing out that there is a lot of space between
having to know everything about the raw device down to its register formats,
and being able to treat the raw device just like a block device.  There are
choices in between.  Traditionally the device driver fiddled with the
registers, so you didn't have to, but raw DMA I/O was directly between the
device and the userspace memory buffer, so constraints imposed by the device's
DMA controller were often visible.  Address alignment constraints were really
common, with a need to make the I/O size a multiple of the device's hardware
block size somewhat less so.  If you couldn't live with the device's 
constraints,
like my 16 bit Qbus cards, you didn't use them.  There was no architectural
imperative to make everything work, let alone work the same, in every situation.

Of course, that was then and this is now.  Just because this is the way
it used to work doesn't necessarily make it right.

Dennis Ferguson


Home | Main Index | Thread Index | Old Index