Re: Linux 2.5.3-pre1-aia1

[Jens Axboe <axboe@suse.de>]

On Mon, Jan 21 2002, Andre Hedrick wrote:
> 255 * 512bytes != 128K  BUG
> 256 * 512bytes == 128K
> 
> You insure we will fail on alignemnt.
> 
> You have stated BLOCK can not deal with correct sector alignments, and
> thus 255 so please fix it first.  I have accepted this brokeness in BLOCK
> and dropped to 128 sectors or a clean 64k.

What statement? The block layer gives you the allignment that _you_
need. Heck, all you have to do is make a simple api call and define your
rules. Nobody is trying to cram anything down your throat. 255 is just
the kernel default, nothing more.

> If we restrict multi-sector PIO to 8 sectors we can do multi interrupt
> ATOMIC disk IO on the paging alignments, but you have enforced single
> sector IO in the multi-sector writing and can not see the difference.

False, I've enforced current_nr_sectors transfers in multi-sector write.
But Andre please understand that changes like this are never final, feel
free to alter it and make it work any other way. Fact is, we needed a
change that made pio and multi mode _work_ right now -- my change does
that, and it's not all that bad.

> If rq->current_nr_sectors is less than 8 we do PIO single sector IO, but
> we are doing that now w/ the copy paste changes from the old ide-disk.c
> stuff that we are attempting deleting.

Well I'm sorry for making changes to your isr's, but they were broken.

> You are making mistakes left and right because you think you understand
> the hardware.  I thought we had an agreement, BLOCK stops at DO_REQUEST.
> Now you are altering the driver core, and the ISR's.  BLOCK has no
> business in dictating how to talk to the hardware, especially since it
> violates the specification willfully and without need.

?! I can't do anything but block stuff now, what a pity. Please tell me
where the block layer is dictating what you must do.

> We do a DMA of two PRD's of 128 sectors and 127 sectors, thus a mess.

I can add a

	BUG_ON(rq->nr_sectors == 255);

for you if you want, that will not happen.

> So at this point pull it and put back the munge for before and I will fix
> it completely and return a turn-key, now that I understand the brokeness
> of the interface I am deal w/ on both sides.

What is broken?

> Until you understand the execution of the command block is ATOMIC it will
> never work.  Also when the SCSI-MID Layer is deleted, you will have a
> repeat of this issue on a much grander scale.  Eric was a brilliant to
> hide the nature of the transport layer in the SCSI-MID Layer and return
> back partial completion against his ATOMIC Command IO calls.

Oh like the partial completion I added in ide_end_request?

Please calm down Andre, lets not start another round of flames.

-- 
Jens Axboe