> On Wed, 13 Mar 2002, Jens Axboe wrote:
>
> > On Wed, Mar 13 2002, Andre Hedrick wrote:
> > >
> > > Jens,
> > >
> > > Please try again because that is not the real problem.
> > > All you have shown is that we disagree on the method of page walking
> > > between BLOCK v/s IOCTL. This is very minor and I agreed that it is
> > > reasonable to map the IOCTL buffer in to BH or BIO so this is a net zero
> > > of negative point.
> >
> > No this is two issues -- you (ab)using request interface for ioctls is
> > one thing, I don't care too much about that (although it spreads
> > confusion and I've already seen at least one copy this code). The other
> > is that the task handlers are now forced to be separate and the legacy
> > handlers in ide-disk used.
>
> Well, now that you see a little more.
>
> The reason for segmenting the data handlers to separate and isolate the
> errors and flaws in the Linus failed attempt to push forward multimode io.
> Also it is not isolated to writes, it is a read issue too.
> Since this is now moving to the technical asspect I wanted you to go,
> please go on to the third point below.
>
> > > How about attempting to describe the differences between the atomic and
> > > what is violated by who and where. I will help you later if you get
> > > stuck.
> >
> > and bingo, here comes a third issue. Please stay on track.
>
> Please go on on the third point because coming full circle to see an error.
Well I promised to help you if you got stuck, so here is a hint.
Describe the variations between the hardware atomic segment wrt to the
bh/bio OS atomic segment. Then explain the event ordering of the state
diagram. Be specific when bh/bio's should be updated and reported to
block as complete. Finally then explain where things are wrong and why it
is wrong and a solution to fix it. You should note the policy which is
wrong belongs to Linus and not you, but you are charge to make it happen.
Cheers,
Andre Hedrick
-
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/