Re: Development tree, PLEASE?

[Greg KH <greg@kroah.com>]

On Fri, Jan 20, 2006 at 01:56:12PM -0700, Michael Loftis wrote:
> 
> 
> --On January 20, 2006 11:43:31 AM -0800 Greg KH <greg@kroah.com> wrote:
> 
> >On Fri, Jan 20, 2006 at 10:14:15AM -0700, Michael Loftis wrote:
> >>The problem here is I'm spending a lot of my time lately fixing things
> >>that  shouldn't need fixing.  Things that are/were developed against
> >>what was  supposed to be a stable major version and has been turned into
> >>a  development version.
> >
> >What specifically are you "fixing"?
> 
> At this point I'm looking at bugs in the aic7xxx driver, it mostly works in 
> 2.6.8, occasionally locking up my tape subsystem, it's apparently fixed in 
> 2.6.15 or 2.6.15.1, I need to look closer into that, and backport it 
> because of the devfs issue I don't think I can take 2.6.15/2.6.15.1 whole 
> hog.

devfs is long dead and gone.  It's going to be much easier for you to
probably just change your userspace config to handle this.

If you need any help doing this, please ask on the linux-hotplug-devel
mailing list, where lots of people can help you out.

Or, just add the CONFIG_DEVFS config option to your .config, and build
devfs into the 2.6.15 release.  The code is still there...

> As far as fixing there are modules that have been developped to run various 
> embedded peripherals that must be reworked to use the newer kernel 
> versions, which wouldn't be a problem if there weren't various other fixes 
> that were needed which means moving up point revs.  Most of these other 
> bugs are external to my work, but they affect my work.  The modules are 
> completely isolated from the rest of the kernel though and they're for very 
> particular hardware for different clients.

There's nothing we can do about out-of-the-tree kernel versions, see
Documentation/stable_api_nonsense.txt about why you should get those
modules into the main kernel tree.

And before you say, "but they are only for some very odd and not popular
devices, no one would want them in the kernel tree!", remember that we
have whole arches that are only run by about 2 users.  I know
specifically about a few drivers that only work on 1 device in the whole
world.  So this isn't a good excuse :)

Your other issues sound like they will be fixed with the latest kernel
version, if not, please let us know.

> I think I have more kernel bugs and can go on, but I'll just be told 
> 'upgrade to 2.6.15' which is not an option in many cases if these are 
> indeed development releases, if only 'politically', but there are often 
> real costs involved.

Then what do you expect us to do?  And what are those costs?

> And with nowhere to put patches that end up in maintenance releases
> we're forced to maintain our own private forks, and likely, because of
> the GPL, also publish these forks and incur all the costs associated
> with that directly, and hope they don't become popular/wanted outside
> of the customer base they're intended for, or skirt the GPL, and only
> allow customers access to this stuff.

I hear sf.net hosts patches for free :)  I know of a specific big distro
vendor that likes to burry their patches there to apease the letter of
the GPL, and make it hard for others to figure out where the code is...

thanks,

greg k-h