Re: [PATCH] fusion: streamline ->queuecommand

[James Bottomley <James.Bottomley@SteelEye.com>]

On Tue, 2004-10-05 at 18:37, Patrick Mansfield wrote:
> On Tue, Oct 05, 2004 at 06:11:22PM -0500, James Bottomley wrote:
> Yes, we want drivers to move forward, but with our current model, we don't
> have any 2.6.x kernel.org stable kernels. 

>From the API point of view, that's correct

> When we first went to this model I thought it did not matter, you could
> just get stable kernels from a distro, but now I see problems with it.
> 
> If code changes for a mainline kernel scsi driver, there is no place to
> keep a stable driver as part of a stable kernel.org series.

True, but on the other hand no-one really keeps their stable drivers in
vanilla 2.4 either.

> Driver maintainers are getting requests to backport current 2.6.x code to
> distributions in order to support stable kernel series, else they have to
> (effectively) maintain a driver version for each distro.

This is normal.

> When we had 2.4 stable and 2.5 development, there was a single repository
> for stable kernels, and one for development. Maintainers did not have to
> track distros, the distros could (generally) pull from the latest 2.4.x
> tree to sync up with the latest driver fixes.

This isn't really the case.  In the 2.4 timeframe, distribution kernels
were positively awash with backports from 2.5 (and generally different
backports or implementations too) ... you only have to look at something
like the adaptec driver with it's redhat specific pieces to appreciate
this.

A distribution is a snapshot, so there'll always be a backport issue for
vendors who interact directly with distribution kernels.  However, the
difference between sles 9 and the current 2.6 is a lot less than between
sles 8 and 2.5.  So, I accept that there's backport work to be done but
I don't accept necessarily that the situation is worse than what we had
in 2.4 where the amount of distribution patches were bigger and no
vendor tracked the 2.5 tree.

In theory, the vendor promise of "upstream first" means that the vendor
kernels should be tracking 2.6 more closely and thus the backports
should be easier ... and the requirement is that the vendor feature be
in vanilla 2.6 first.

James