Re: [RFC] breakage in bsg
[Sorry for breaking threading ... this is a cut and paste from mark
since you didn't post to any list I'm subscribed to]
> * with "bsg: bind bsg to request_queue instead of gendisk" we
> get all requests with NULL ->rq_disk. SCSI can cope with that, anything
> else is not promised to be able to surive that. Indeed, quite a few
> drivers do not.[/color]
That's pretty much by design since we need to allow bsg to be used on
request queues that don't have a gendisk attached (classic example are
the transient queues belonging to SAS expanders). Since drivers have to
actively allow bsg, we can do the local conversions as necessary.
> * WTF are these per-bd flags doing, seeing that you set them
> on every ->read() and ->write()? Just what will happen if you have
> two openers?[/color]
This isn't really my area, but there's only one flag: BSG_F_BLOCK which
is used to signal a temporary blockage of the device ... by definition
that applies to all openers.
> * cmd_filter thing is broken as well (we have no access to
> gendisk in question and there's a lot of obvious issues when you have
> several openers).[/color]
Well, this is philosophical. I've always maintained the command filter
to be broken by design. BSG reinforces that because now we have actual
uses that aren't SCSI (the main use I have is to transmit Management
frames to SAS). You can't filter something if you don't understand the
protocols and protocol independence was a requirement for the next
generation of SG.
> #2 and part of #3 are fixable, but I really don't see what to do with #1.
> If nothing else, it's absolutely incompatible with cmd_filter, even if you
> leave aside the issue with non-IDE/non-SCSI drivers.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]email@example.com[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]