On Wed, 24 Jul 2002, Marcin Dalecki wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > Tue, 23 Jul 2002, Marcin Dalecki wrote:
> >
> >>Bartlomiej Zolnierkiewicz wrote:
> >>
> >>>Martin why aren't you telling people all facts?
> >>>It was the default behaviour before your change in IDE 99.
> >>>This patch in practice reverts IDE 99 change.
> >>>
> >>>You have INTRODUCED a bug and now you try to
> >>>pretend that it wasn't your fault and it was somehow broken before.
> >>
> >>Never said that. Sure it was my fault I looked in the wrong direction
> >>I looked at the ide-tcq code, becouse I still dont like the
> >>idea that we pass a pointer for a struct on the local stack down.
> >>(It's preventing the futile hope to make this thingee somehow
> >>asynchronous form ever taking place.)
> >>
> >>I should have looked at SCSI in first place instead indeed.
> >>
> >>
> >>>Before 2.5.27 code had the same functionality as scsi version.
> >>
> >>That's actually not true... At least the setting of the
> >>request rq->flags is significantly different here and there.
> >
> >
> > You are right here...
> > Actually IDE request should have REQ_BARRIER bit also set for safety
> > and coherency.
> > Without barrier requests added after special command can be merged
> > with requests added before special command.
> >
> >
> >>However I think but I'm not sure that the fact aht we have rq->special
> >>!= NULL here has the hidded side effect that we indeed accomplish the
> >>same semantics.
> >
> >
> > No.
>
> There are some nasty checks for it != NULL in the generic BIO code.
No, there are no checks there.
> And REQ_BARRIER got introduced just recently, so we can see the
> error will have been propagated.
>
> >>>And yes it will be useful to move it to block layer.
> >>
> >>Done. Just needs testing. I have at least an ZIP parport drive, which
> >>allows me to do some basic checks.
> >
> >
> > Test everything on your production machine + main hdd.
> > Will make you care more about code correctness ;-).
>
> Nah... that's just for the SCSI code "move around". The rest
> I usually run continuously on two systems.
>
> >>BTW.> Having a fill up request queue trashing data transfers
> >>is indicating that there may be are bugs in the generic block layer too.
> >>If it gets pushed to boundary conditions it's apparently not very
> >
> >
> > No it wasn't "pushed to boundary conditions", you screwed it, sorry.
> >
> >
> >>robust... BTW.> I never ever will understand why
> >>request_fn returns void instead of an status value.
> >
> >
> > So look at ide.c for example.
>
> So look at drivers which call blk_start_queue() from within
> q->request_fn context, which is, well, causing deliberate *recursion*.
>
Are you sure? If so they should first check whether queue is
started/stopped, if they don't it is a bug.
Look once agin at ide.c, it is called, starts request (if not busy) and
returns, no waiting for finishing request == no return value.
Regards
-- Bartlomiej- 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 : Tue Jul 30 2002 - 14:00:15 EST