On Wed, May 07 2003, Linus Torvalds wrote:
> On Wed, 7 May 2003, Jens Axboe wrote:
> > I did a patch for 2.4 some weeks ago that added (what I consider) proper
> > 48-bit lba usage to ide-disk.
> Ok, let me disagree a bit.
> At least if I read the patch correctly, theer's no way for upper layers to
> say "I want 48-bit addressing" - it's just turned on automatically for
> high sectors (or big transfers).
> Well, you can mark the drive itself as wanting 48-bit transfers, but
> you can't do it on a per-request basis.
> And I think this is 100% equivalent to the 6 vs 10 vs 16-byte SCSI
> command issue, and I really think it should b esolved the same way.
> Namely, you should be able to (on a "struct request" level) explicitly
> say that you want the big requests, and then the default prep_fn()
> would do roughly what you do now by default.
I dunno what the purpose of that would be exactly, I guess to cater to
some hardware odditites?
> That way something like a SG_IO interface could force one mode or the
> other on a per-request basis.
Doesn't make a lot of sense in this case I think, because the command
associated with the SG_IO request would implicitly be either a 28-bit or
48-bit command based on the opcode of the request.
You haven't really convinced me yet. Is there some hardware out there
that requires to be addressed in 48-bit mode? If that is the case, then
yes a bit is missing to fully support that. We'd probably have a forced
addressing flag in the hwif, and the drive->addressing would inherit
that. So instead of
const int lba48 = rq_lba48(rq);
it would be
const int lba48 = rq_lba48(rq) || drive->addressing == FORCED_48;
(forgive the ugliness of the above construct, it's just meant to below
operation of it, rq_lba48 would probably just take both drive and rq as
-- Jens Axboe
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.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 May 07 2003 - 22:00:32 EST