Signed-off-by: John Stoffel <[email protected]>
---
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"
--
1.6.3.3
>>>>> "John" == John Stoffel <[email protected]> writes:
Dammit, I messed up here sending this patch. I've just edited the
subject line and re-sent it with a bit more description. I think this
patch is perfectly good to go into 2.6.31 right now, esp since it's
not changing code, just whether the code is turned on by default from
now on.
Thanks,
John
John> Signed-off-by: John Stoffel <[email protected]>
John> ---
John> block/Kconfig | 11 +++++++----
John> 1 files changed, 7 insertions(+), 4 deletions(-)
John> diff --git a/block/Kconfig b/block/Kconfig
John> index e7d1278..55bbefc 100644
John> --- a/block/Kconfig
John> +++ b/block/Kconfig
John> @@ -45,9 +45,9 @@ config LBD
John> If unsure, say N.
John> config BLK_DEV_BSG
John> - bool "Block layer SG support v4 (EXPERIMENTAL)"
John> - depends on EXPERIMENTAL
John> - ---help---
John> + bool "Block layer SG support v4"
John> + default y
John> + help
John> Saying Y here will enable generic SG (SCSI generic) v4 support
John> for any block device.
John> @@ -57,7 +57,10 @@ config BLK_DEV_BSG
John> protocols (e.g. Task Management Functions and SMP in Serial
John> Attached SCSI).
John> - If unsure, say N.
John> + This option is required by recent UDEV versions to properly
John> + access device serial numbers, etc.
John> +
John> + If unsure, say Y.
John> config BLK_DEV_INTEGRITY
John> bool "Block layer data integrity support"
John> --
John> 1.6.3.3
On 07/13/2009 10:43 PM, John Stoffel wrote:
>>>>>> "John" == John Stoffel <[email protected]> writes:
>
> Dammit, I messed up here sending this patch. I've just edited the
> subject line and re-sent it with a bit more description. I think this
> patch is perfectly good to go into 2.6.31 right now, esp since it's
> not changing code, just whether the code is turned on by default from
> now on.
>
I would like it if you'd also CC [email protected] on this patch. As this
condition is already true for distros in the field.
[Though distros have enabled it for years and every one is using the distro's
.config when compiling their own Kernel, right?]
> Thanks,
> John
>
>
Thanks
Boaz
>>>>> "Boaz" == Boaz Harrosh <[email protected]> writes:
Boaz> I would like it if you'd also CC [email protected] on this
Boaz> patch. As this condition is already true for distros in the
Boaz> field.
I can resend it with that CC, no problem. It's a good experience to
learn git and how to use it properly.
Boaz> [Though distros have enabled it for years and every one is using
Boaz> the distro's .config when compiling their own Kernel, right?]
Umm, no. My main machine for the past six or seven years is Debian
based, and came from the 2.4 era of kernels and has been patched and
upgraded for years by hand. Lots of 'atp-get update'. Whcih works
well. So I've also compiled my own kernels.
The real reason for this patch was finally figuring out that Udev
really really really wants this turned on, but doesn't mention it in
any of it's documentation. So I'm working to update both sides, and
have UDEV mention that it needs this feature, and making the kernel
turn it on by default too.
I'll resend the patch in a few.
John
On Tue, 2009-07-14 at 09:38 +0300, Boaz Harrosh wrote:
> On 07/13/2009 10:43 PM, John Stoffel wrote:
> >>>>>> "John" == John Stoffel <[email protected]> writes:
> >
> > Dammit, I messed up here sending this patch. I've just edited the
> > subject line and re-sent it with a bit more description. I think this
> > patch is perfectly good to go into 2.6.31 right now, esp since it's
> > not changing code, just whether the code is turned on by default from
> > now on.
> >
>
> I would like it if you'd also CC [email protected] on this patch. As this
> condition is already true for distros in the field.
The stable tree is for bug *fixes*. Moving an option out from under
experimental is basically an enhancement, even if it could be argued it
should have been done long ago.
James
On 07/14/2009 04:29 PM, James Bottomley wrote:
> On Tue, 2009-07-14 at 09:38 +0300, Boaz Harrosh wrote:
>> On 07/13/2009 10:43 PM, John Stoffel wrote:
>>>>>>>> "John" == John Stoffel <[email protected]> writes:
>>> Dammit, I messed up here sending this patch. I've just edited the
>>> subject line and re-sent it with a bit more description. I think this
>>> patch is perfectly good to go into 2.6.31 right now, esp since it's
>>> not changing code, just whether the code is turned on by default from
>>> now on.
>>>
>> I would like it if you'd also CC [email protected] on this patch. As this
>> condition is already true for distros in the field.
>
> The stable tree is for bug *fixes*. Moving an option out from under
> experimental is basically an enhancement, even if it could be argued it
> should have been done long ago.
>
wouldn't you consider it a bug if a low-level plumbing like Udev is shipped
with hard dependency on it?
if Udev was part of Kconfig it would have a "depend" on bsg. But because
it's a different product it can only rely on defaults?
> James
>
>
Thanks
Boaz
On Tue, 2009-07-14 at 17:12 +0300, Boaz Harrosh wrote:
> On 07/14/2009 04:29 PM, James Bottomley wrote:
> > On Tue, 2009-07-14 at 09:38 +0300, Boaz Harrosh wrote:
> >> On 07/13/2009 10:43 PM, John Stoffel wrote:
> >>>>>>>> "John" == John Stoffel <[email protected]> writes:
> >>> Dammit, I messed up here sending this patch. I've just edited the
> >>> subject line and re-sent it with a bit more description. I think this
> >>> patch is perfectly good to go into 2.6.31 right now, esp since it's
> >>> not changing code, just whether the code is turned on by default from
> >>> now on.
> >>>
> >> I would like it if you'd also CC [email protected] on this patch. As this
> >> condition is already true for distros in the field.
> >
> > The stable tree is for bug *fixes*. Moving an option out from under
> > experimental is basically an enhancement, even if it could be argued it
> > should have been done long ago.
> >
>
> wouldn't you consider it a bug if a low-level plumbing like Udev is shipped
> with hard dependency on it?
Sure .. file a bug with udev ...
The point is that if you use a feature marked "Experimental, do not use"
it's not a bug in the provider if you use it.
Arguably, all this really shows is that the distros ignore EXPERIMENTAL,
so it's not really serving a useful purpose in the kernel.
> if Udev was part of Kconfig it would have a "depend" on bsg. But because
> it's a different product it can only rely on defaults?
James
>>>>> "James" == James Bottomley <[email protected]> writes:
James> On Tue, 2009-07-14 at 09:38 +0300, Boaz Harrosh wrote:
>> On 07/13/2009 10:43 PM, John Stoffel wrote:
>> >>>>>> "John" == John Stoffel <[email protected]> writes:
>> >
>> > Dammit, I messed up here sending this patch. I've just edited the
>> > subject line and re-sent it with a bit more description. I think this
>> > patch is perfectly good to go into 2.6.31 right now, esp since it's
>> > not changing code, just whether the code is turned on by default from
>> > now on.
>> >
>>
>> I would like it if you'd also CC [email protected] on this patch. As this
>> condition is already true for distros in the field.
James> The stable tree is for bug *fixes*. Moving an option out from
James> under experimental is basically an enhancement, even if it
James> could be argued it should have been done long ago.
I'm not so sure I agree with this, since this feature is used by UDEV
and has been enabled by default on a bunch of distros for ages (as I'm
told, personally I haven't confirmed this).
But if you object to stable back porting, what are you feelings on
this change for 2.6.31-rc* now? Do you think it needs to be held off
and that it's too late to make this change?
Thanks,
John