linux-kernel - Re: Please release a stable kernel Linux 3.0

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <oor483d2nqn6ae728com1v7v56g0ksotov@4ax.com>
Date:	Wed, 27 Jun 2007 07:15:00 -0700
From:	Bill Waddington <william.waddington@...zmo.com>
To:	linux-kernel@...r.kernel.org
Cc:	Al Boldi <a1426z@...ab.com>
Subject: Re: Please release a stable kernel Linux 3.0

On Wed, 27 Jun 2007 13:53:32 UTC, in fa.linux.kernel you wrote:

>Al Viro wrote:
>> On Wed, Jun 27, 2007 at 11:18:36AM +0200, Zolt?n HUBERT wrote:
>> > And as I understand it, this is (was ?) the whole point of
>> > stable/development kernels. "We" can trust a newer stable
>> > kernel to be a drop-in replacement for an older stable
>> > kernel (from the same series), while development kernels
>> > need time to stabilise with the new whizz-bang-pfouit stuff
>> > that you all so nicely add.
>>
>> "Drop-in" in which sense?  That out-of-tree modules keep working?
>> Not really...
>
>Al, be reasonable.  There are many out-of-tree GPL modules that won't be 
>accepted into mainline, never mind those that shouldn't be accepted.  But 
>these modules do have a right to not be obsoleted by constant API changes.
>
>You are effectively inhibiting the development of an out-of-tree GPL module 
>pool, by constantly pulling the rug under that community.
>
>Do you think this is fair?
>
>
>Thanks!

No, thank *you*!  Here I thought I was the only one...

As a low-life out-of-tree maintainer, I would like to plead for at
least a mitigation of the pain of constantly changing kernel/module
APIs.  I realize that an interface freeze is out of the question, but
how about a more formal and regularized way of flagging changes.  The
nasty mess of version checking works (I guess) but it would sure be
nice to have change flags that were actually tied to the changes
themselves.  Consistently.

(And taking my drivers main-line isn't an option.  It would be fine
with me, but there is *zero* chance that my funky code would be
welcomed into the tree.)

Thanks,
Bill (donning asbestos shorts...)
-- 
William D Waddington
william.waddington@...zmo.com
"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/