Messages in this thread | | | From | Bartlomiej Zolnierkiewicz <> | Subject | Re: [PATCH] fix rq->flags use in ide-tape.c | Date | Wed, 5 Nov 2003 16:16:53 +0100 |
| |
On Wednesday 05 of November 2003 14:56, Jens Axboe wrote: > On Wed, Nov 05 2003, Bartlomiej Zolnierkiewicz wrote: > > On Wednesday 05 of November 2003 13:00, Bartlomiej Zolnierkiewicz wrote: > > > On Wednesday 05 of November 2003 09:40, Jens Axboe wrote: > > > > On Tue, Nov 04 2003, Linux Kernel Mailing List wrote: > > > > > ChangeSet 1.1413, 2003/11/04 08:01:30-08:00, > > > > > B.Zolnierkiewicz@elka.pw.edu.pl > > > > > > > > > > [PATCH] fix rq->flags use in ide-tape.c > > > > > > > > > > Noticed by Stuart_Hayes@Dell.com: > > > > > > > > Guys, this is _way_ ugly. We definitely dont need more crap in > > > > ->flags for private driver use, stuff them somewhere else in the rq. > > > > rq->cmd[0] usage would be a whole lot better. This patch should never > > > > have been merged. If each and every driver needs 5 private bits in > > > > ->flags, well... > > > > > > Yeah, it is ugly. Using rq->cmd is also ugly as it hides the problem > > > in ide-tape.c, but if you prefer this way I can clean it up. I just > > > wanted minimal changes to ide-tape.c to make it working. > > > > Also putting these flags in rq->cmd[0] makes it hard to later convert > > ide-tape.c to use rq->cmd[] for storing packet commands. > > What's wrong with just looking at the opcode instead of inventing magic > flags. Seems like _just_ the right thing to do, convert to really using > rq and killing the private command stuff as much as possible. The latter > can wait though, the flag thing really has to go right now.
It is non-trivial cause it seems packet commands are prepared during processing request, not prior to queuing it. Also I still don't fully understand driver inner-workings with respect to DSC, "pipeline" and internal commands processing.
> ide-*.c driver by Gadi are all completely over designed and attempts to > basically implement everything themselves. Horrible.
Yep, but we should be careful in removing cruft. I've already had a hard time fixing it after (totally unnecessary and broken) buffer_head->bio conversion.
cheers, --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/
| |