>>>>> "Jens" == Jens Axboe <jens.axboe@xxxxxxxxxx> writes: Jens> On Mon, Aug 03 2009, John Stoffel wrote: >> >>>>> "James" == James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> writes: >> James> On Mon, 2009-08-03 at 13:52 -0400, John Stoffel wrote: >> >> >>>>> "James" == James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> writes: >> >> James> It seems I got unsubscribed from linux-scsi last week while I was on James> holiday and I've likely missed a slew of patches, it seems like an James> appropriate time to remind everyone how the SCSI trees work. >> >> James> --- >> >> James> There are two git based scsi trees: >> >> James> http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git >> >> James> called the scsi-misc tree for patches being collected for the James> next merge window. And >> >> >> >> I don't see my patch to block/Kconfig to make BLK_DEV_BSG be enabled >> >> by default. Is this going to be pushed for 2.6.32-rc1 when the merge >> >> window opens up? >> >> >> >> I've attached the patch, just to make sure. Let me know if I should >> >> send it in properly. >> >> >> >> Thanks! >> >> John >> >> >> >> >> >> Make Block Layer SG support v4 the default, since recent udev versions >> >> depend on this to access serial numbers and other low level info >> >> properly. >> >> >> >> This should be backported to older kernels as well, since most distros >> >> have >> >> enabled this for a long time. >> >> >> >> Signed-off-by: John Stoffel <john@xxxxxxxxxxx> >> >> --- >> >> block/Kconfig | 11 +++++++---- >> >> 1 files changed, 7 insertions(+), 4 deletions(-) >> >> >> >> diff --git a/block/Kconfig b/block/Kconfig >> >> index e7d1278..55bbefc 100644 >> >> --- a/block/Kconfig >> >> +++ b/block/Kconfig >> James> Actually, this one isn't really SCSI; it's block (Jens cc'd). >> >> Thanks for the cc to Jens. I'd argue that it is SCSI, since it's >> about enbabling the Generic SCSI v4 stuff. But hey, I'd be happy to >> see this enabled by default no matter how it goes into the kernel. >> James> It's Jens call on the backport, but my feeling is that removing James> a feature from experimental is really an enhancement not a bug James> fix, so it's not really eligible under the backport rules. >> >> Sure, I can understand this, but since the feature has been around for >> quite a while, and since most (as I understand it, but haven't >> confirmed) distros enable it by default, I think the risk is low. >> >> But again, it's not clear to me whether you think A) this should go >> into 2.6.32 and B) whether it will go through your tree or if I should >> try to push it through Jens. >> >> I await the discussion. It's really a trivial change, and its makes a >> huge difference to people using Udev to manage devices properly. Jens> Principally, I completely agree with James assessment that it Jens> doesn't meet normal stable rules as such. It's not fixing a bug Jens> or oops, it's a feature addition. But since this is rather Jens> trivial and bsg has been around for ages (and is on in distro Jens> kernels), I'm OK with making an exception in this case. So you'd be happy to see it pushed to stable@xxxxxxxxxx for back porting, as well as sending it into the 2.6.32 tree when it opens? What about 2.6.31? Just trying to nail down the flow here. Thanks, John -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
