should in-tree kernel source accommodate older kernel versions?

should in-tree kernel source accommodate older kernel versions?

[Robert P. J. Day]

  should kernel source that's in the current source tree still try to
accommodate older kernel versions?  as an example, this is from
drivers/scsi/gdth.c:

/* parameters for modprobe/insmod */
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,11)
module_param_array(irq, int, NULL, 0);
module_param(disable, int, 0);
module_param(reserve_mode, int, 0);
module_param_array(reserve_list, int, NULL, 0);
module_param(reverse_scan, int, 0);
module_param(hdr_channel, int, 0);
module_param(max_ids, int, 0);
module_param(rescan, int, 0);
module_param(virt_ctr, int, 0);
module_param(shared_access, int, 0);
module_param(probe_eisa_isa, int, 0);
module_param(force_dma32, int, 0);
#else
MODULE_PARM(irq, "i");
MODULE_PARM(disable, "i");
MODULE_PARM(reserve_mode, "i");
... etc etc ...

  now, i can see the value in trying to maintain a single source file
(gdth.c) that's compatible with various versions of the kernel.  on
the other hand, this is source that has been accepted into the main
tree.  under those circumstances, it's *irrelevant* whether it's
compatible with older versions.

  it would seem that, if someone wants to maintain a multi-version
source file, they can handle that *outside* the source tree on their
own, and not load the tree with extraneous junk to make *their* job
easier.

  thoughts?

rday
-- 
====================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
====================================

Re: should in-tree kernel source accommodate older kernel versions?

[Matthew Wilcox]

On Tue, Jul 17, 2007 at 05:22:56PM -0400, Robert P. J. Day wrote:
>   should kernel source that's in the current source tree still try to
> accommodate older kernel versions?  as an example, this is from

This has been discussed before, and the current thinking is to remove
support for versions of the kernel older than 2.6.0.

-- 
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: should in-tree kernel source accommodate older kernel versions?

[Robert P. J. Day]

On Tue, 17 Jul 2007, Matthew Wilcox wrote:

> On Tue, Jul 17, 2007 at 05:22:56PM -0400, Robert P. J. Day wrote:
> >   should kernel source that's in the current source tree still try to
> > accommodate older kernel versions?  as an example, this is from
>
> This has been discussed before, and the current thinking is to
> remove support for versions of the kernel older than 2.6.0.

*that* part was self-evident.  i'm talking more specifically about
older versions of 2.6.x, in particular features that aren't even
*supported* anymore in the current tree.

rday
-- 
====================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
====================================

Re: should in-tree kernel source accommodate older kernel versions?

[Matthew Wilcox]

On Tue, Jul 17, 2007 at 05:36:45PM -0400, Robert P. J. Day wrote:
> On Tue, 17 Jul 2007, Matthew Wilcox wrote:
> > On Tue, Jul 17, 2007 at 05:22:56PM -0400, Robert P. J. Day wrote:
> > >   should kernel source that's in the current source tree still try to
> > > accommodate older kernel versions?  as an example, this is from
> >
> > This has been discussed before, and the current thinking is to
> > remove support for versions of the kernel older than 2.6.0.
> 
> *that* part was self-evident.  i'm talking more specifically about
> older versions of 2.6.x, in particular features that aren't even
> *supported* anymore in the current tree.

You'll find people very resistant to patches that remove support for
older 2.6.x kernels.

-- 
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: should in-tree kernel source accommodate older kernel versions?

[Robert P. J. Day]

On Tue, 17 Jul 2007, Matthew Wilcox wrote:

> On Tue, Jul 17, 2007 at 05:36:45PM -0400, Robert P. J. Day wrote:
> > On Tue, 17 Jul 2007, Matthew Wilcox wrote:
> > > On Tue, Jul 17, 2007 at 05:22:56PM -0400, Robert P. J. Day wrote:
> > > >   should kernel source that's in the current source tree still try to
> > > > accommodate older kernel versions?  as an example, this is from
> > >
> > > This has been discussed before, and the current thinking is to
> > > remove support for versions of the kernel older than 2.6.0.
> >
> > *that* part was self-evident.  i'm talking more specifically about
> > older versions of 2.6.x, in particular features that aren't even
> > *supported* anymore in the current tree.
>
> You'll find people very resistant to patches that remove support for
> older 2.6.x kernels.

the reason i'm asking is that this idea of retaining support for older
versions of the kernel is somewhat inconsistent in the source tree.
as an example, one of the video source files also had conditional
support for that obsolete module parameter macro:

#if defined(module_param)     // Showing parameters under SYSFS
module_param(isocMode, int, 0444);
module_param(video_debug, int, 0444);
module_param(PowerOnAtOpen, int, 0444);
...
#else                                                   // Old Style
MODULE_PARM(video_debug, "i");
MODULE_PARM(adjustCompression, "i");
MODULE_PARM(PowerOnAtOpen, "i");
...

  the video folks had no problem applying a patch to toss that
"old-style" stuff for what i think is a simple reason -- that
MODULE_PARM macro isn't even *defined* anymore, so there's no possible
value in keeping that old code around, even if it's protected by a
kernel version check.

  that's the fundamental question here -- what's the inherent value in
protecting kernel code that is based on features that don't even
*exist* in the source tree anymore?  whose benefit does that serve?
it may make things easier for that particular developer, but it
provides no value whatsoever to the kernel itself.

rday
-- 
====================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
====================================