[patch 20/28] drivers/message/fusion/linux_compat.h Removal of old code

[patch 20/28] drivers/message/fusion/linux_compat.h Removal of old code

[akpm]

From: Michal Piotrowski <michal.k.k.piotrowski@gmail.com>

Signed-off-by: Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Acked-by: "Moore, Eric Dean" <Eric.Moore@lsil.com>
Cc: James Bottomley <James.Bottomley@steeleye.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 drivers/message/fusion/linux_compat.h |    9 ---------
 1 file changed, 9 deletions(-)

diff -puN drivers/message/fusion/linux_compat.h~drivers-message-fusion-linux_compath-removal-of-old-code drivers/message/fusion/linux_compat.h
--- a/drivers/message/fusion/linux_compat.h~drivers-message-fusion-linux_compath-removal-of-old-code
+++ a/drivers/message/fusion/linux_compat.h
@@ -6,13 +6,4 @@
 #include <linux/version.h>
 #include <scsi/scsi_device.h>
 
-#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,6))
-static int inline scsi_device_online(struct scsi_device *sdev)
-{
-	return sdev->online;
-}
-#endif
-
-
-/*}-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
 #endif /* _LINUX_COMPAT_H */
_

RE: [patch 20/28] drivers/message/fusion/linux_compat.h Removal of old code

[Moore, Eric]

On Monday, September 25, 2006 5:59 PM, Andrew Morton wrote: 

> 
> From: Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
> 
> Signed-off-by: Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
> Acked-by: "Moore, Eric Dean" <Eric.Moore@lsil.com>
> Cc: James Bottomley <James.Bottomley@steeleye.com>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
> ---
> 
>  drivers/message/fusion/linux_compat.h |    9 ---------
>  1 file changed, 9 deletions(-)
> 
> diff -puN 
> drivers/message/fusion/linux_compat.h~drivers-message-fusion-l
> inux_compath-removal-of-old-code drivers/message/fusion/linux_compat.h
> --- 
> a/drivers/message/fusion/linux_compat.h~drivers-message-fusion
> -linux_compath-removal-of-old-code
> +++ a/drivers/message/fusion/linux_compat.h
> @@ -6,13 +6,4 @@
>  #include <linux/version.h>
>  #include <scsi/scsi_device.h>
>  
> -#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,6))
> -static int inline scsi_device_online(struct scsi_device *sdev)
> -{
> -	return sdev->online;
> -}
> -#endif
> -
> -
> -/*}-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> -=-=-=-=-=-=-=-=*/
>  #endif /* _LINUX_COMPAT_H */
> _
>


James, pls apply. 

However pls don't remove this file from the tree.

Eric 

Re: [patch 20/28] drivers/message/fusion/linux_compat.h Removal of old code

[Jeff Garzik]

Moore, Eric wrote:
> However pls don't remove this file from the tree.

Why?  That's against the general kernel policy...

As an example, when maintaining libata for 2.4 kernels as well as 2.6 
kernels, I had a libata-compat.h file, and always just patched the 
include into the kernel source at the same time I patched in the 
libata-compat.h contents.

	Jeff

RE: [patch 20/28] drivers/message/fusion/linux_compat.h Removal of old code

[Moore, Eric]

Jeff Garzik wrote:

> 
> Why?  That's against the general kernel policy...
> 
> As an example, when maintaining libata for 2.4 kernels as well as 2.6 
> kernels, I had a libata-compat.h file, and always just patched the 
> include into the kernel source at the same time I patched in the 
> libata-compat.h contents.
> 

This is merely a request is all.
Supporting Red Hat and SuSE distro's is why I ask. 
I don't care about 2.4 kernel.  My compatibility 
changes I support occur between 2.6 kernels releases, 
such example is 2.6.17 and 2.6.18; e.g. SLES10 versus RHEL5
with sas transport changes.  And they pull from upstream, 
and I support them with interim bug fix's.

Eric

Re: [patch 20/28] drivers/message/fusion/linux_compat.h Removal of old code

[Jeff Garzik]

Moore, Eric wrote:
> Jeff Garzik wrote:
> 
>> Why?  That's against the general kernel policy...
>>
>> As an example, when maintaining libata for 2.4 kernels as well as 2.6 
>> kernels, I had a libata-compat.h file, and always just patched the 
>> include into the kernel source at the same time I patched in the 
>> libata-compat.h contents.
>>
> 
> This is merely a request is all.
> Supporting Red Hat and SuSE distro's is why I ask. 
> I don't care about 2.4 kernel.  My compatibility 
> changes I support occur between 2.6 kernels releases, 
> such example is 2.6.17 and 2.6.18; e.g. SLES10 versus RHEL5
> with sas transport changes.  And they pull from upstream, 
> and I support them with interim bug fix's.

I'm not talking specifically about the 2.4 kernel, but making a 
comparison between upstream, and non-upstream back compat.  My example 
is clearly the same as your current situation.

I think most kernel devs would NAK keeping around an empty kernel header 
just for the sake of forked distro kernels.

	Jeff