On Mon, 21 Jan 2002, Vojtech Pavlik wrote:
> On Mon, Jan 21, 2002 at 12:18:21PM -0800, Andre Hedrick wrote:
>
> > > > Again, the HOST(Linux) is not following the device side rules so expect
> > > > difficulty when we depart. The Brain Damage is how to talk to the
> > > > hardware, and it is clear we are not doing it right because we are bending
> > > > the rules stuff it into and API that not acceptable. However we are
> > > > stuck. Again, simplicity works, generate a MEMPOOL for PIO such that the
> > > > buffer pages are contigious and the 4k page dance is a NOOP. Until that
> > > > time we will be fussing about.
> > >
> > > Andre,
> > >
> > > Do you know how to say "I was wrong"? You are walking off-track again.
> > > It's clearly the way that Vojtech and I describe, otherwise current code
> > > would just not work. And 2.4, 2.2, 2.0 neither.
> >
> > I will and have done so in the past when I am, and it would be nice if you
> > and Linus could do the same. However since both are going to enforce the
> > partial completion of IO on page boundaries or 4k, and you are not
> > allowed to pause or stop in the middle of a command execution to play
> > memory games under ATA/IDE PIO rules, period.
>
> Maybe I'm again totally off-the-track, but I see no reason why I
> couldn't stop in the middle of a PIO transfer (that is anytime, not even
> on a sector boundary), do whatever I wish, like change the destination
> buffer or whatever, and then continue. Sure, I can't send ANY commands
> to the drive, and reading the status might not be a good idea either,
> but I believe I can do anything else on the system. Is there a reason
> why this shouldn't be possible?
Okay if the execution of the command block is ATOMIC, and we want to stop
an ATOMIC operation to go alter buffers? But that is not the real
question. The real question is do we stop and ATOMIC process to return
data of a partial completeion, and then return to a HALTED ATOMIC and hope
it will still go?
DEAD Method:
issue atomic write 255 sectors
write 8 sector or 4k or 1 page of memory
interrupt_issued
exit atomic write
update top layer buffers
return;
continue write_loop;
exit on completion and update remainder.
BASTARDIZED Method:
issue write 255 sectors
truncate to max of 8 sectors
issue atomic write 8 sectors
interrupt_issued
end request and notify 4k page complete
make new request and merge and repeat.
note there is a new memcpy fo new request. (max 16 to completion)
OLD Method, with Request Page Walking:
issue atomic write 255 sectors
write sectors
interrupt_issued
walk copy of request
continue write_loop;
exit on completion and request and free local buffer.
CORRECT Method:
collect contigious physical buffer of 255 sectors
memcpy_to_local (one memcpy)
issue atomic write 255 sectors
write sectors
interrupt_issued
update pointer
continue write_loop;
exit on completion and request and free local buffer.
The price of the overhead and the direct flakyness of the driver we are
running from is returning, so the alternative is to disable MULTI-Sector
Operations.
Respectfully,
Andre Hedrick
Linux Disk Certification Project Linux ATA Development
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jan 23 2002 - 21:00:49 EST