SCSI git trees

SCSI git trees

[James Bottomley]

It seems I got unsubscribed from linux-scsi last week while I was on
holiday and I've likely missed a slew of patches, it seems like an
appropriate time to remind everyone how the SCSI trees work.

---

There are two git based scsi trees:

http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git

called the scsi-misc tree for patches being collected for the next merge
window.  And

http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-rc-fixes-2.6.git

called scsi-fixes for bug fixes collected for current linux head.

Both trees are kept rebasable (no merge points) with all patches head at
the tree head (so you can use gitweb to see what's in them easily). Each
of the trees sends email to the author and all of the signoff chains
when a patch is added, so if you sent a patch in and haven't received an
email (and don't see it in either of the trees) I don't have it.

All trees feed into linux-next and all patches in scsi-misc/scsi-fixes
will be tested in linux-next for a few days before being passed on to
Linus (so no more patches get added at that point).

James

Re: SCSI git trees

[John Stoffel]

>>>>> "James" == James Bottomley <James.Bottomley@HansenPartnership.com> 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@stoffel.org>
---
 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
@@ -45,9 +45,9 @@ config LBD
          If unsure, say N.

 config BLK_DEV_BSG
-       bool "Block layer SG support v4 (EXPERIMENTAL)"
-       depends on EXPERIMENTAL
-       ---help---
+       bool "Block layer SG support v4"
+       default y
+       help
          Saying Y here will enable generic SG (SCSI generic) v4
	  support
          for any block device.

@@ -57,7 +57,10 @@ config BLK_DEV_BSG
          protocols (e.g. Task Management Functions and SMP in Serial
          Attached SCSI).

-         If unsure, say N.
+         This option is required by recent UDEV versions to properly
+         access device serial numbers, etc.
+
+         If unsure, say Y.

 config BLK_DEV_INTEGRITY
        bool "Block layer data integrity support"
-- 

Re: SCSI git trees

[Randy Dunlap]

On Mon, 3 Aug 2009 13:52:29 -0400 John Stoffel wrote:

> >>>>> "James" == James Bottomley <James.Bottomley@HansenPartnership.com> 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

James,
Would it help you for patchwork to capture linux-scsi patches?
either patchwork.kernel.org or patchwork.ozlabs.org


> 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@stoffel.org>
> ---
>  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
> @@ -45,9 +45,9 @@ config LBD
>           If unsure, say N.
> 
>  config BLK_DEV_BSG
> -       bool "Block layer SG support v4 (EXPERIMENTAL)"
> -       depends on EXPERIMENTAL
> -       ---help---
> +       bool "Block layer SG support v4"
> +       default y
> +       help
>           Saying Y here will enable generic SG (SCSI generic) v4
> 	  support
>           for any block device.
> 
> @@ -57,7 +57,10 @@ config BLK_DEV_BSG
>           protocols (e.g. Task Management Functions and SMP in Serial
>           Attached SCSI).
> 
> -         If unsure, say N.
> +         This option is required by recent UDEV versions to properly
> +         access device serial numbers, etc.
> +
> +         If unsure, say Y.
> 
>  config BLK_DEV_INTEGRITY
>         bool "Block layer data integrity support"
> -- 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


---
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/

Re: SCSI git trees

[James Bottomley]

On Mon, 2009-08-03 at 11:09 -0700, Randy Dunlap wrote:
> On Mon, 3 Aug 2009 13:52:29 -0400 John Stoffel wrote:
> 
> > >>>>> "James" == James Bottomley <James.Bottomley@HansenPartnership.com> 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
> 
> James,
> Would it help you for patchwork to capture linux-scsi patches?
> either patchwork.kernel.org or patchwork.ozlabs.org

Well, SCSI was supposed to be one of the consumers of patchwork;
evidently we fell through the cracks.

However, it's not really going to help me that much because my MO is to
do most of my tree work offline (while travelling).  Patchwork, being a
web based tool doesn't work well offline, so I need to keep on with my
email based workflow. (On the other hand evolution in its latest
incarnations is taking a very cavalier attitude to the "download
messages for offline use" flag ... if it gets much worse I'll lose my
offline work ability anyway).

James

Re: SCSI git trees

[James Bottomley]

On Mon, 2009-08-03 at 13:52 -0400, John Stoffel wrote:
> >>>>> "James" == James Bottomley <James.Bottomley@HansenPartnership.com> 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@stoffel.org>
> ---
>  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

Actually, this one isn't really SCSI; it's block (Jens cc'd).  It's Jens
call on the backport, but my feeling is that removing a feature from
experimental is really an enhancement not a bug fix, so it's not really
eligible under the backport rules.

James

Re: SCSI git trees

[John Stoffel]

>>>>> "James" == James Bottomley <James.Bottomley@HansenPartnership.com> writes:

James> On Mon, 2009-08-03 at 13:52 -0400, John Stoffel wrote:
>> >>>>> "James" == James Bottomley <James.Bottomley@HansenPartnership.com> 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@stoffel.org>
>> ---
>> 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.

Thanks,
John

Re: SCSI git trees

[Jens Axboe]

On Mon, Aug 03 2009, John Stoffel wrote:
> >>>>> "James" == James Bottomley <James.Bottomley@HansenPartnership.com> writes:
> 
> James> On Mon, 2009-08-03 at 13:52 -0400, John Stoffel wrote:
> >> >>>>> "James" == James Bottomley <James.Bottomley@HansenPartnership.com> 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@stoffel.org>
> >> ---
> >> 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.

Principally, I completely agree with James assessment that it doesn't
meet normal stable rules as such. It's not fixing a bug or oops, it's a
feature addition. But since this is rather trivial and bsg has been
around for ages (and is on in distro kernels), I'm OK with making an
exception in this case.

-- 
Jens Axboe

Re: SCSI git trees

[John Stoffel]

>>>>> "Jens" == Jens Axboe <jens.axboe@oracle.com> writes:

Jens> On Mon, Aug 03 2009, John Stoffel wrote:
>> >>>>> "James" == James Bottomley <James.Bottomley@HansenPartnership.com> writes:
>> 
James> On Mon, 2009-08-03 at 13:52 -0400, John Stoffel wrote:
>> >> >>>>> "James" == James Bottomley <James.Bottomley@HansenPartnership.com> 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@stoffel.org>
>> >> ---
>> >> 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@kernel.org 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

Re: SCSI git trees

[Jens Axboe]

On Mon, Aug 03 2009, John Stoffel wrote:
> >>>>> "Jens" == Jens Axboe <jens.axboe@oracle.com> writes:
> 
> Jens> On Mon, Aug 03 2009, John Stoffel wrote:
> >> >>>>> "James" == James Bottomley <James.Bottomley@HansenPartnership.com> writes:
> >> 
> James> On Mon, 2009-08-03 at 13:52 -0400, John Stoffel wrote:
> >> >> >>>>> "James" == James Bottomley <James.Bottomley@HansenPartnership.com> 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@stoffel.org>
> >> >> ---
> >> >> 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@kernel.org 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.

2.6.31 is a must, which means adding it now. If you send the patch, I
can add it to my pending branch for 2.6.31. Once it's in there, we can
add it to -stable and .32 would happen automatically.

-- 
Jens Axboe

Re: SCSI git trees

[John Stoffel]

Hi Jens,

I've just sent you a copy of the patch, to both axboe@kernel.dk and
this address.  Let me know if you want me to re-spin it or not.

Thanks!
John

Re: SCSI git trees

[Jens Axboe]

On Tue, Aug 04 2009, John Stoffel wrote:
> 
> Hi Jens,
> 
> I've just sent you a copy of the patch, to both axboe@kernel.dk and
> this address.  Let me know if you want me to re-spin it or not.

I've applied it, as I wrote in the other email. You probably want to
check the arch defconfigs though, to see if they enable it by default.
Since the symbol already exists, the default y will have little impact
on what people compiling their own kernels get to select.

-- 
Jens Axboe

Re: SCSI git trees

[John Stoffel]

>>>>> "Jens" == Jens Axboe <jens.axboe@oracle.com> writes:

Jens> On Tue, Aug 04 2009, John Stoffel wrote:
>> 
>> Hi Jens,
>> 
>> I've just sent you a copy of the patch, to both axboe@kernel.dk and
>> this address.  Let me know if you want me to re-spin it or not.

Jens> I've applied it, as I wrote in the other email. You probably
Jens> want to check the arch defconfigs though, to see if they enable
Jens> it by default.  Since the symbol already exists, the default y
Jens> will have little impact on what people compiling their own
Jens> kernels get to select.

Thanks for applyging this.  I'll take a look at the deconfigs and see
if any changes need to be made.  

John

Re: SCSI git trees

[Jens Axboe]

On Tue, Aug 04 2009, John Stoffel wrote:
> >>>>> "Jens" == Jens Axboe <jens.axboe@oracle.com> writes:
> 
> Jens> On Tue, Aug 04 2009, John Stoffel wrote:
> >> 
> >> Hi Jens,
> >> 
> >> I've just sent you a copy of the patch, to both axboe@kernel.dk and
> >> this address.  Let me know if you want me to re-spin it or not.
> 
> Jens> I've applied it, as I wrote in the other email. You probably
> Jens> want to check the arch defconfigs though, to see if they enable
> Jens> it by default.  Since the symbol already exists, the default y
> Jens> will have little impact on what people compiling their own
> Jens> kernels get to select.
> 
> Thanks for applyging this.  I'll take a look at the deconfigs and see
> if any changes need to be made.  

It doesn't look too bad. And x86 and x86-64 already have BSG as y in the
defconfigs, so it should be quite wide spread already. So I'd say we are
fine now.

-- 
Jens Axboe

Re: SCSI git trees

[John Stoffel]

>>>>> "John" == John Stoffel <john@stoffel.org> writes:

>>>>> "Jens" == Jens Axboe <jens.axboe@oracle.com> writes:
Jens> On Tue, Aug 04 2009, John Stoffel wrote:
>>> 
>>> Hi Jens,
>>> 
>>> I've just sent you a copy of the patch, to both axboe@kernel.dk and
>>> this address.  Let me know if you want me to re-spin it or not.

Jens> I've applied it, as I wrote in the other email. You probably
Jens> want to check the arch defconfigs though, to see if they enable
Jens> it by default.  Since the symbol already exists, the default y
Jens> will have little impact on what people compiling their own
Jens> kernels get to select.

John> Thanks for applyging this.  I'll take a look at the deconfigs
John> and see if any changes need to be made.

Looking things over, only the os390 tree sets up a defconfig entry for
the CONFIG_BLK_DEV_BSG symbol and they default to Y.  All the other
archs default to the overall default.  Which should now mean that they
will automatically add this in if not configured.  

John