For those of you who haven't waded through the huge "RFD: Kernel release
numbering" thread on lkml to realize that we are now going to start
putting out 2.6.x.y releases, here's the summary:
A few of us $suckers will be trying to maintain a 2.6.x.y set of
releases that happen after 2.6.x is released. It will contain
only a set of bugfixes and security fixes that meet a strict set
of guidelines, as defined by Linus at:
http://article.gmane.org/gmane.linux.kernel/283396
Chris Wright and I are going to start working on doing this work, we
will have a <SOME_ALIAS>@kernel.org to post these types of bug fixes to,
and a set of people we bounce the patches off of to test for "smells
good" validation. We will also have a bk-commits type mailing list for
those who want to watch the patches flow in, and a bk tree from which
changsets can be pulled from.
Chris and I will be hashing all of the details out next Tuesday, and
hopefully all the infrastructure will be in place soon. When that
happens, we will post the full details on how all of this is going to
work. In the meantime, feel free to CC: me and Chris on patches that
everyone thinks should go into the 2.6.11.y releases.
But right now, Chris is on a plane, and we don't have the email alias
set up, or the proper permissions set up on kernel.org to push changes
into the v2.6 directory, but we have a few bugs that are needing to be
fixed in the 2.6.11 release. And since our mantra is, "release early
and often", here's the first release.
---------------
I've released the 2.6.11.1 patch:
kernel.org/pub/linux/kernel/people/gregkh/v2.6.11/patch-2.6.11.1.gz
With a detailed changelog at:
kernel.org/pub/linux/kernel/people/gregkh/v2.6.11/ChangeLog-2.6.11.1
A bitkeeper tree for the 2.6.11.y releases can be found at:
bk://linux-release.bkbits.net/linux-2.6.11
The diffstat and short summary of the fixes are below.
I'll also be replying to this message with a copy of the patch itself,
as it is small enough to do so.
thanks,
greg k-h
-------
Makefile | 2 +-
drivers/input/serio/i8042-x86ia64io.h | 6 +++---
drivers/md/raid6altivec.uc | 4 ++++
3 files changed, 8 insertions(+), 4 deletions(-)
Summary of changes from v2.6.11 to v2.6.11.1
============================================
Dmitry Torokhov:
o Fix keyboards for Dell machines
Greg Kroah-Hartman:
o Linux 2.6.11.1
Olof Johansson:
o Fix for trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
Rene Rebe:
o trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
On Fri, Mar 04, 2005 at 09:53:02AM -0800, Greg KH wrote:
> I'll also be replying to this message with a copy of the patch itself,
> as it is small enough to do so.
Here it is....
diff -Nru a/Makefile b/Makefile
--- a/Makefile 2005-03-04 09:27:15 -08:00
+++ b/Makefile 2005-03-04 09:27:15 -08:00
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 11
-EXTRAVERSION =
+EXTRAVERSION = .1
NAME=Woozy Numbat
# *DOCUMENTATION*
diff -Nru a/drivers/input/serio/i8042-x86ia64io.h b/drivers/input/serio/i8042-x86ia64io.h
--- a/drivers/input/serio/i8042-x86ia64io.h 2005-03-04 09:27:15 -08:00
+++ b/drivers/input/serio/i8042-x86ia64io.h 2005-03-04 09:27:15 -08:00
@@ -88,7 +88,7 @@
};
#endif
-#ifdef CONFIG_ACPI
+#if defined(__ia64__) && defined(CONFIG_ACPI)
#include <linux/acpi.h>
#include <acpi/acpi_bus.h>
@@ -281,7 +281,7 @@
i8042_kbd_irq = I8042_MAP_IRQ(1);
i8042_aux_irq = I8042_MAP_IRQ(12);
-#ifdef CONFIG_ACPI
+#if defined(__ia64__) && defined(CONFIG_ACPI)
if (i8042_acpi_init())
return -1;
#endif
@@ -300,7 +300,7 @@
static inline void i8042_platform_exit(void)
{
-#ifdef CONFIG_ACPI
+#if defined(__ia64__) && defined(CONFIG_ACPI)
i8042_acpi_exit();
#endif
}
diff -Nru a/drivers/md/raid6altivec.uc b/drivers/md/raid6altivec.uc
--- a/drivers/md/raid6altivec.uc 2005-03-04 09:27:15 -08:00
+++ b/drivers/md/raid6altivec.uc 2005-03-04 09:27:15 -08:00
@@ -108,7 +108,11 @@
int raid6_have_altivec(void)
{
/* This assumes either all CPUs have Altivec or none does */
+#ifdef CONFIG_PPC64
return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
+#else
+ return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;
+#endif
}
#endif
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
| For those of you who haven't waded through the huge "RFD: Kernel release
| numbering" thread on lkml to realize that we are now going to start
| putting out 2.6.x.y releases, here's the summary:
|
| A few of us $suckers will be trying to maintain a 2.6.x.y set of
| releases that happen after 2.6.x is released. It will contain
| only a set of bugfixes and security fixes that meet a strict set
| of guidelines, as defined by Linus at:
| http://article.gmane.org/gmane.linux.kernel/283396
|
| Chris Wright and I are going to start working on doing this work, we
| will have a <SOME_ALIAS>@kernel.org to post these types of bug fixes to,
| and a set of people we bounce the patches off of to test for "smells
| good" validation. We will also have a bk-commits type mailing list for
| those who want to watch the patches flow in, and a bk tree from which
| changsets can be pulled from.
|
| Chris and I will be hashing all of the details out next Tuesday, and
| hopefully all the infrastructure will be in place soon. When that
| happens, we will post the full details on how all of this is going to
| work. In the meantime, feel free to CC: me and Chris on patches that
| everyone thinks should go into the 2.6.11.y releases.
|
| But right now, Chris is on a plane, and we don't have the email alias
| set up, or the proper permissions set up on kernel.org to push changes
| into the v2.6 directory, but we have a few bugs that are needing to be
| fixed in the 2.6.11 release. And since our mantra is, "release early
| and often", here's the first release.
First of all, congratulation.
I really think this will be a great improvement to the development process.
I couldn't agree more with this decision, it's really what I suggested a
few months ago:
http://marc.theaimsgroup.com/?l=linux-kernel&m=109882220123966&w=2
Out of curiosity, are you going to include the -as branch ?
Paolo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
iD8DBQFCKLb6xcZDms2c3jQRAkmBAJ9fNXkoo+ATm2wezsRyQzrRxh6siACdFzVo
0cllOTLr40ALnK2S3VJENa0=
=jWOp
-----END PGP SIGNATURE-----
Paolo wrote:
> Out of curiosity, are you going to include the -as branch ?
The -as stuff should be built on top of 2.6.11.X.
2.6.11.X should not be "every fix under the sun, until 2.6.12 is released."
Jeff
On Fri, Mar 04, 2005 at 08:28:58PM +0100, Paolo wrote:
> Out of curiosity, are you going to include the -as branch ?
The whole thing? No, see previous comments about the contents of the
-as and -ac "branches" in the big lkml thread.
But if people will forward on bits and pieces of the -as and -ac tree,
to us, and the patches meet the critera we have set up, then I do not
see any problem with accepting them.
thanks,
gre k-h
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Greg KH wrote:
| On Fri, Mar 04, 2005 at 08:28:58PM +0100, Paolo wrote:
|
|>Out of curiosity, are you going to include the -as branch ?
|
|
| The whole thing? No, see previous comments about the contents of the
| -as and -ac "branches" in the big lkml thread.
Right, the whole -as tree is really too much ;)
| But if people will forward on bits and pieces of the -as and -ac tree,
| to us, and the patches meet the critera we have set up, then I do not
| see any problem with accepting them.
Ok, hopefully that will become reality.
Paolo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
iD8DBQFCKL6VxcZDms2c3jQRAkZ4AKDKk8m3OiBJs5j6WnSIm9jGdnuZogCeIzDE
QeoyAI0JaQzPjZm4UR2q1Oo=
=7dic
-----END PGP SIGNATURE-----
Greg KH <[email protected]> wrote:
>
> A few of us $suckers will be trying to maintain a 2.6.x.y set of
> releases that happen after 2.6.x is released.
Just to test things out a bit...
Here's the list of things which we might choose to put into 2.6.11.2. I was
planning on sending them in for 2.6.12 when that was going to be
errata-only.
>From 2.6.11-mm1:
cramfs-small-stat2-fix.patch
setup_per_zone_lowmem_reserve-oops-fix.patch
dv1394-ioctl-retval-fix.patch
ppc32-compilation-fixes-for-ebony-luan-and-ocotea.patch
nfsd--sgi-921857-find-broken-with-nohide-on-nfsv3.patch
nfsd--exportfs-reduce-stack-usage.patch
nfsd--svcrpc-add-a-per-flavor-set_client-method.patch
nfsd--svcrpc-rename-pg_authenticate.patch
nfsd--svcrpc-move-export-table-checks-to-a-per-program-pg_add_client-method.patch
nfsd--nfs4-use-new-pg_set_client-method-to-simplify-nfs4-callback-authentication.patch
nfsd--lockd-dont-try-to-match-callback-requests-against-export-table.patch
audit-mips-fix.patch
make-st-seekable-again.patch
wrt the nfsd patches, Neil said:
The problem they fix is that currently:
Client A holds a lock
Client B tries to get the lock and blocks
Client A drops the lock
**Client B doesn't get the lock immediately, but has to wait for a
timeout. (several seconds)
On Fri, 2005-03-04 at 09:53 -0800, Greg KH wrote:
> ---------------
>
> I've released the 2.6.11.1 patch:
> kernel.org/pub/linux/kernel/people/gregkh/v2.6.11/patch-2.6.11.1.gz
>
> With a detailed changelog at:
> kernel.org/pub/linux/kernel/people/gregkh/v2.6.11/ChangeLog-2.6.11.1
>
> A bitkeeper tree for the 2.6.11.y releases can be found at:
> bk://linux-release.bkbits.net/linux-2.6.11
>
> The diffstat and short summary of the fixes are below.
I know this is new, but is this going to be posted on http://www.kernel.org?
Like you don't have enough on your plate already!
-- Steve
From a purely process point of view, my concern would be making sure
that everything that goes into 2.6.X.Y (e.g. 2.6.11.1) makes it into
2.6.X+1 (e.g. 2.6.12).
--
========================================================================
Ian Pilcher [email protected]
========================================================================
On Fri, 2005-03-04 at 12:53 -0800, Greg KH wrote:
> See the comments above the part you snipped off, that stated the
> infrastructure is still being worked on :)
>
Damn, I somehow missed that paragraph. Well, I've read the whole darn
thread and still am getting work done. I guess I've overextended a
little.
Hopefully this all works out, and thanks for taking this on.
-- Steve
On Fri, Mar 04, 2005 at 12:44:31PM -0800, Andrew Morton wrote:
> Greg KH <[email protected]> wrote:
> >
> > A few of us $suckers will be trying to maintain a 2.6.x.y set of
> > releases that happen after 2.6.x is released.
>
> Just to test things out a bit...
>
> Here's the list of things which we might choose to put into 2.6.11.2. I was
> planning on sending them in for 2.6.12 when that was going to be
> errata-only.
Ok, care to forward them on?
> From 2.6.11-mm1:
>
> cramfs-small-stat2-fix.patch
> setup_per_zone_lowmem_reserve-oops-fix.patch
> dv1394-ioctl-retval-fix.patch
> ppc32-compilation-fixes-for-ebony-luan-and-ocotea.patch
> nfsd--sgi-921857-find-broken-with-nohide-on-nfsv3.patch
> nfsd--exportfs-reduce-stack-usage.patch
> nfsd--svcrpc-add-a-per-flavor-set_client-method.patch
> nfsd--svcrpc-rename-pg_authenticate.patch
> nfsd--svcrpc-move-export-table-checks-to-a-per-program-pg_add_client-method.patch
> nfsd--nfs4-use-new-pg_set_client-method-to-simplify-nfs4-callback-authentication.patch
> nfsd--lockd-dont-try-to-match-callback-requests-against-export-table.patch
> audit-mips-fix.patch
> make-st-seekable-again.patch
>
> wrt the nfsd patches, Neil said:
>
> The problem they fix is that currently:
> Client A holds a lock
> Client B tries to get the lock and blocks
> Client A drops the lock
> **Client B doesn't get the lock immediately, but has to wait for a
> timeout. (several seconds)
Hm, odds are the nfsd one doesn't fit our list of "acceptable things",
but let's see the patches...
thanks,
greg k-h
fr den 04.03.2005 Klokka 12:44 (-0800) skreiv Andrew Morton:
> nfsd--sgi-921857-find-broken-with-nohide-on-nfsv3.patch
> nfsd--exportfs-reduce-stack-usage.patch
> nfsd--svcrpc-add-a-per-flavor-set_client-method.patch
> nfsd--svcrpc-rename-pg_authenticate.patch
> nfsd--svcrpc-move-export-table-checks-to-a-per-program-pg_add_client-method.patch
> nfsd--nfs4-use-new-pg_set_client-method-to-simplify-nfs4-callback-authentication.patch
> nfsd--lockd-dont-try-to-match-callback-requests-against-export-table.patch
> audit-mips-fix.patch
> make-st-seekable-again.patch
>
> wrt the nfsd patches, Neil said:
>
> The problem they fix is that currently:
> Client A holds a lock
> Client B tries to get the lock and blocks
> Client A drops the lock
> **Client B doesn't get the lock immediately, but has to wait for a
> timeout. (several seconds)
Well, yes, but more importantly, they should also fix a problem with
reboot recovery on the client side.
Currently, if rpc.statd sends an RPC call down to lockd in order to
notify it of a reboot of the server, the sunrpc server code will try to
authenticate that RPC call by doing an upcall to rpc.mountd.... Doh!
Cheers,
Trond
--
Trond Myklebust <[email protected]>
Greg KH <[email protected]> wrote:
>
> > Here's the list of things which we might choose to put into 2.6.11.2. I was
> > planning on sending them in for 2.6.12 when that was going to be
> > errata-only.
>
> Ok, care to forward them on?
Sure. How do they get to Linus?
> Hm, odds are the nfsd one doesn't fit our list of "acceptable things",
Was there such a list? It's kinda what I'm asking about here.
Yes, the NFSD fixes are relatively minor, although Neil did want them in
the 2.6.12 errata kernel.
Perhaps they could be backported to 2.6.11.x in a few weeks ;)
On Fri, Mar 04, 2005 at 01:59:33PM -0800, Andrew Morton wrote:
> Linus Torvalds <[email protected]> wrote:
> >
> >
> >
> > On Fri, 4 Mar 2005, Andrew Morton wrote:
> > > >
> > > > Ok, care to forward them on?
> > >
> > > Sure. How do they get to Linus?
> >
> > I'll just pull from the sucker-tree.
> >
>
> That tree has the not-for-linus raid6 fix and the not-for-linus i8042 fix.
Then when the authors of those patches go to submit the fix to Linus,
they can revert them, or bk can handle the merge properly :)
thanks,
greg k-h
On Fri, Mar 04, 2005 at 12:44:31PM -0800, Andrew Morton wrote:
> Here's the list of things which we might choose to put into 2.6.11.2.
...
> nfsd--exportfs-reduce-stack-usage.patch
...
Different people want different things with our 2.6.x.y.
I would hope that criteria include (i) patch is obvious,
and (ii) patch fixes an embarrassing flaw.
I see no reason to include random small improvements.
(Always some of these small improvements will be a mistake,
so, in .y, when something is not really broken, don't fix it.
Maybe people were actually seeing stack overflows here?)
Andries
>> From: NeilBrown <[email protected]>
>>
>> find_exported_dentry() declares
>> char nbuf[NAME_MAX+1];
>> in 2 separate places, and gcc allocates space on the stack for both
>> of them. Having just one of them will suffice, if we can put put
>> with its scope.
>>
>> Reduces function stack usage on x86-32 from 0x230 to 0x130.
Greg KH <[email protected]> wrote:
>
> On Fri, Mar 04, 2005 at 01:59:33PM -0800, Andrew Morton wrote:
> > Linus Torvalds <[email protected]> wrote:
> > >
> > >
> > >
> > > On Fri, 4 Mar 2005, Andrew Morton wrote:
> > > > >
> > > > > Ok, care to forward them on?
> > > >
> > > > Sure. How do they get to Linus?
> > >
> > > I'll just pull from the sucker-tree.
> > >
> >
> > That tree has the not-for-linus raid6 fix and the not-for-linus i8042 fix.
>
> Then when the authors of those patches go to submit the fix to Linus,
> they can revert them, or bk can handle the merge properly :)
>
Well yeah. That's what I mentioned yesterday - I revert the notfix while
merging up the realfix.
OK for really small stuff, but it could get messy. We'll see.
But we end up with a cset in the permanent kernel history which simply
should not have been there.
On Fri, Mar 04, 2005 at 02:36:14PM -0800, Andrew Morton wrote:
> But we end up with a cset in the permanent kernel history which simply
> should not have been there.
Is this really a big deal?
thanks,
greg k-h
On Fri, 4 Mar 2005, Greg KH wrote:
> On Fri, Mar 04, 2005 at 02:36:14PM -0800, Andrew Morton wrote:
> > But we end up with a cset in the permanent kernel history which simply
> > should not have been there.
>
> Is this really a big deal?
Once? No. If it ends up being "par for the course", it's bad.
Linus
Andrew Morton wrote:
> Greg KH <[email protected]> wrote:
>
>>>Here's the list of things which we might choose to put into 2.6.11.2. I was
>>
>> > planning on sending them in for 2.6.12 when that was going to be
>> > errata-only.
>>
>> Ok, care to forward them on?
>
>
> Sure. How do they get to Linus?
linux-release team should send a "please pull" request to Linus.
Jeff
Greg KH wrote:
> On Fri, Mar 04, 2005 at 02:36:14PM -0800, Andrew Morton wrote:
>
>>But we end up with a cset in the permanent kernel history which simply
>>should not have been there.
>
>
> Is this really a big deal?
If you are pushing linux-release to Linus/Andrew rapidly, quick fixes
will land in linux-2.6 rapidly, and more invasive stuff will land only
in linux-2.6 when the invasive stuff is ready to go. It even takes the
pressure off pushing invasive stuff ASAP.
Have you pushed linux-2.6.11.1 upstream yet? :)
Jeff
On Fri, Mar 04, 2005 at 02:34:22PM -0600, Ian Pilcher wrote:
> From a purely process point of view, my concern would be making sure
> that everything that goes into 2.6.X.Y (e.g. 2.6.11.1) makes it into
> 2.6.X+1 (e.g. 2.6.12).
It will be so.
On Fri, Mar 04, 2005 at 01:54:02PM -0800, Andrew Morton wrote:
> Greg KH <[email protected]> wrote:
> >
> > On Fri, Mar 04, 2005 at 01:15:37PM -0800, Andrew Morton wrote:
> > > Greg KH <[email protected]> wrote:
> > > >
> > > > > Here's the list of things which we might choose to put into 2.6.11.2. I was
> > > > > planning on sending them in for 2.6.12 when that was going to be
> > > > > errata-only.
> > > >
> > > > Ok, care to forward them on?
> > >
> > > Sure. How do they get to Linus?
> >
> > Hm, either he pulls them from our new 2.6.x.y tree, or they go to him
> > through you. Either way, I'd recommend sending them to him for now,
>
> We can do that. As long as the patches remain unaltered I assume that BK
> will recognise that the patch is already there, in a different cset?
Yes, it can handle such a merge just fine.
> > until we get this whole "procedure" worked out.
>
> Yup. That's why I'm running this little experiment. Applying stimuli and
> seeing how we respond. Yum, cheese.
/me scampers off into the corner...
On Fri, 4 Mar 2005, Andrew Morton wrote:
> >
> > Ok, care to forward them on?
>
> Sure. How do they get to Linus?
I'll just pull from the sucker-tree.
Linus
On Fri, Mar 04, 2005 at 01:15:37PM -0800, Andrew Morton wrote:
> Greg KH <[email protected]> wrote:
> >
> > > Here's the list of things which we might choose to put into 2.6.11.2. I was
> > > planning on sending them in for 2.6.12 when that was going to be
> > > errata-only.
> >
> > Ok, care to forward them on?
>
> Sure. How do they get to Linus?
Hm, either he pulls them from our new 2.6.x.y tree, or they go to him
through you. Either way, I'd recommend sending them to him for now,
until we get this whole "procedure" worked out.
> > Hm, odds are the nfsd one doesn't fit our list of "acceptable things",
>
> Was there such a list? It's kinda what I'm asking about here.
There is, I'll post an initial version of it in a bit.
thanks,
greg k-h
Andrew Morton wrote:
> Greg KH <[email protected]> wrote:
>
>>A few of us $suckers will be trying to maintain a 2.6.x.y set of
>> releases that happen after 2.6.x is released.
>
>
> Just to test things out a bit...
>
> Here's the list of things which we might choose to put into 2.6.11.2. I was
> planning on sending them in for 2.6.12 when that was going to be
> errata-only.
>
>
>>From 2.6.11-mm1:
>
> cramfs-small-stat2-fix.patch
> setup_per_zone_lowmem_reserve-oops-fix.patch
> dv1394-ioctl-retval-fix.patch
> ppc32-compilation-fixes-for-ebony-luan-and-ocotea.patch
> nfsd--sgi-921857-find-broken-with-nohide-on-nfsv3.patch
> nfsd--exportfs-reduce-stack-usage.patch
Unless it's crashing for people, stack usage is IMO a wanted-fix not
needed-fix.
> nfsd--svcrpc-add-a-per-flavor-set_client-method.patch
is this critical?
Jeff
Linus Torvalds <[email protected]> wrote:
>
>
>
> On Fri, 4 Mar 2005, Andrew Morton wrote:
> > >
> > > Ok, care to forward them on?
> >
> > Sure. How do they get to Linus?
>
> I'll just pull from the sucker-tree.
>
That tree has the not-for-linus raid6 fix and the not-for-linus i8042 fix.
On Fri, Mar 04, 2005 at 01:51:13PM -0800, Andrew Morton wrote:
> Jeff Garzik <[email protected]> wrote:
> >
> > > cramfs-small-stat2-fix.patch
> > > setup_per_zone_lowmem_reserve-oops-fix.patch
> > > dv1394-ioctl-retval-fix.patch
> > > ppc32-compilation-fixes-for-ebony-luan-and-ocotea.patch
> > > nfsd--sgi-921857-find-broken-with-nohide-on-nfsv3.patch
> > > nfsd--exportfs-reduce-stack-usage.patch
> >
> > Unless it's crashing for people, stack usage is IMO a wanted-fix not
> > needed-fix.
>
> Sure. The patch is bog-obvious though.
>
> >
> > > nfsd--svcrpc-add-a-per-flavor-set_client-method.patch
> >
> > is this critical?
>
> Doubt it, unless the succeeding patches have a dependency on it. But the
> other patches have not been tested without this one being present.
>
>
> These patches have been in mm for four weeks, so it's probably OK from a
> stability POV to take them straight into linux-release. If they were
> fresher then the way to handle them would be to merge them into Linus's
> tree and backport in a couple of weeks time.
Cool, fair enough. linux-release sounds fine.
Jeff
Greg KH <[email protected]> wrote:
>
> On Fri, Mar 04, 2005 at 01:15:37PM -0800, Andrew Morton wrote:
> > Greg KH <[email protected]> wrote:
> > >
> > > > Here's the list of things which we might choose to put into 2.6.11.2. I was
> > > > planning on sending them in for 2.6.12 when that was going to be
> > > > errata-only.
> > >
> > > Ok, care to forward them on?
> >
> > Sure. How do they get to Linus?
>
> Hm, either he pulls them from our new 2.6.x.y tree, or they go to him
> through you. Either way, I'd recommend sending them to him for now,
We can do that. As long as the patches remain unaltered I assume that BK
will recognise that the patch is already there, in a different cset?
> until we get this whole "procedure" worked out.
Yup. That's why I'm running this little experiment. Applying stimuli and
seeing how we respond. Yum, cheese.
On Fri, Mar 04, 2005 at 12:44:31PM -0800, Andrew Morton wrote:
> wrt the nfsd patches, Neil said:
>
> The problem they fix is that currently:
> Client A holds a lock
> Client B tries to get the lock and blocks
> Client A drops the lock
> **Client B doesn't get the lock immediately, but has to wait for a
> timeout. (several seconds)
Sounds like a performance thing than "oh my god the world is falling apart"
type thing. Given it recovers after a few seconds, is it worth it ?
Dave
Jeff Garzik <[email protected]> wrote:
>
> > cramfs-small-stat2-fix.patch
> > setup_per_zone_lowmem_reserve-oops-fix.patch
> > dv1394-ioctl-retval-fix.patch
> > ppc32-compilation-fixes-for-ebony-luan-and-ocotea.patch
> > nfsd--sgi-921857-find-broken-with-nohide-on-nfsv3.patch
> > nfsd--exportfs-reduce-stack-usage.patch
>
> Unless it's crashing for people, stack usage is IMO a wanted-fix not
> needed-fix.
Sure. The patch is bog-obvious though.
>
> > nfsd--svcrpc-add-a-per-flavor-set_client-method.patch
>
> is this critical?
Doubt it, unless the succeeding patches have a dependency on it. But the
other patches have not been tested without this one being present.
These patches have been in mm for four weeks, so it's probably OK from a
stability POV to take them straight into linux-release. If they were
fresher then the way to handle them would be to merge them into Linus's
tree and backport in a couple of weeks time.
On Fri, Mar 04, 2005 at 03:48:20PM -0500, Steven Rostedt wrote:
> On Fri, 2005-03-04 at 09:53 -0800, Greg KH wrote:
>
> > ---------------
> >
> > I've released the 2.6.11.1 patch:
> > kernel.org/pub/linux/kernel/people/gregkh/v2.6.11/patch-2.6.11.1.gz
> >
> > With a detailed changelog at:
> > kernel.org/pub/linux/kernel/people/gregkh/v2.6.11/ChangeLog-2.6.11.1
> >
> > A bitkeeper tree for the 2.6.11.y releases can be found at:
> > bk://linux-release.bkbits.net/linux-2.6.11
> >
> > The diffstat and short summary of the fixes are below.
>
> I know this is new, but is this going to be posted on http://www.kernel.org?
See the comments above the part you snipped off, that stated the
infrastructure is still being worked on :)
So yes, it will get there, hopefully, eventually...
thanks,
greg k-h
Sounds great, I can be a QA resource for what machines I have.
How do people get involved in QAing these releases?
What other help?
Shawn.
> List: linux-kernel
> Subject: Linux 2.6.11.1
> From: Greg KH <greg () kroah ! com>
> Date: 2005-03-04 17:53:02
> Message-ID: <20050304175302.GA29289 () kroah ! com>
> [Download message RAW]
>
> For those of you who haven't waded through the huge "RFD: Kernel release
> numbering" thread on lkml to realize that we are now going to start
> putting out 2.6.x.y releases, here's the summary:
>
> A few of us $suckers will be trying to maintain a 2.6.x.y set of
> releases that happen after 2.6.x is released. It will contain
> only a set of bugfixes and security fixes that meet a strict set
> of guidelines, as defined by Linus at:
> http://article.gmane.org/gmane.linux.kernel/283396
>
> Chris Wright and I are going to start working on doing this work, we
> will have a <SOME_ALIAS>@kernel.org to post these types of bug fixes to,
> and a set of people we bounce the patches off of to test for "smells
> good" validation. We will also have a bk-commits type mailing list for
> those who want to watch the patches flow in, and a bk tree from which
> changsets can be pulled from.
>
> Chris and I will be hashing all of the details out next Tuesday, and
> hopefully all the infrastructure will be in place soon. When that
> happens, we will post the full details on how all of this is going to
> work. In the meantime, feel free to CC: me and Chris on patches that
> everyone thinks should go into the 2.6.11.y releases.
>
> But right now, Chris is on a plane, and we don't have the email alias
> set up, or the proper permissions set up on kernel.org to push changes
> into the v2.6 directory, but we have a few bugs that are needing to be
> fixed in the 2.6.11 release. And since our mantra is, "release early
> and often", here's the first release.
On Fri, 4 Mar 2005, Jeff Garzik wrote:
> On Fri, Mar 04, 2005 at 01:51:13PM -0800, Andrew Morton wrote:
> > Jeff Garzik <[email protected]> wrote:
...
> > > is this critical?
> >
> > Doubt it, unless the succeeding patches have a dependency on it. But the
> > other patches have not been tested without this one being present.
> >
> > These patches have been in mm for four weeks, so it's probably OK from a
> > stability POV to take them straight into linux-release. If they were
> > fresher then the way to handle them would be to merge them into Linus's
> > tree and backport in a couple of weeks time.
>
> Cool, fair enough. linux-release sounds fine.
ok, 4 bits not just 2...
Be frugal with the patches and don't take just *anything* that looks like a
good fix. What you want is a more stable version, meaning less changes as
time goes forward. I know it's the first couple days, but it looks like it
could easily go the other way...
Anyway, I hope this helps.
James
>
> Jeff
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
--
James Bourne | Email: [email protected]
UNIX Systems Administration | WWW: http://www.hardrock.org
Custom UNIX Programming | Linux: The choice of a GNU generation
----------------------------------------------------------------------
"All you need's an occasional kick in the philosophy." Frank Herbert
On Fri, Mar 04, 2005 at 04:28:02PM -0800, Linus Torvalds wrote:
>
>
> On Fri, 4 Mar 2005, Greg KH wrote:
>
> > On Fri, Mar 04, 2005 at 02:36:14PM -0800, Andrew Morton wrote:
> > > But we end up with a cset in the permanent kernel history which simply
> > > should not have been there.
> >
> > Is this really a big deal?
>
> Once? No. If it ends up being "par for the course", it's bad.
The amount of stuff in the sucker tree shouldn't really amount
to /that/ many patches should it ? If it does, then 2.6.x is in
worse shape than we've all been admitting.
Would it be that much work to just send the 'meat' as gnu patches,
and leave the not-for-linus stuff alone ?
Dave
On Fri, Mar 04, 2005 at 02:05:18PM -0800, Greg KH wrote:
> On Fri, Mar 04, 2005 at 01:59:33PM -0800, Andrew Morton wrote:
> > That tree has the not-for-linus raid6 fix and the not-for-linus i8042 fix.
>
> Then when the authors of those patches go to submit the fix to Linus,
> they can revert them, or bk can handle the merge properly :)
How about having two BK trees - one containing "fixes for Linus" and
the other "fixes not for Linus but we really need" ? The "sucker
tree" then becomes the two merged together.
This way, Linus would never see the "fixes not for Linus" at all.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
Russell King wrote:
> On Fri, Mar 04, 2005 at 02:05:18PM -0800, Greg KH wrote:
>
>>On Fri, Mar 04, 2005 at 01:59:33PM -0800, Andrew Morton wrote:
>>
>>>That tree has the not-for-linus raid6 fix and the not-for-linus i8042 fix.
>>
>>Then when the authors of those patches go to submit the fix to Linus,
>>they can revert them, or bk can handle the merge properly :)
>
>
> How about having two BK trees - one containing "fixes for Linus" and
> the other "fixes not for Linus but we really need" ? The "sucker
> tree" then becomes the two merged together.
>
> This way, Linus would never see the "fixes not for Linus" at all.
Yup, BK could definitely handle that...
Jeff
On Sat, 5 Mar 2005, Jeff Garzik wrote:
>
> Yup, BK could definitely handle that...
However, it's also true that the thing BK is _worst_ at is cherry-picking
things, and having a collection of stuff where somebody may end up vetoing
one patch and saying "remove that one".
So it's entirely possible that the proper tool to use for the first level
is not BK at all, but the evolved patch-scripts that Andrew uses, in other
words:
http://savannah.nongnu.org/projects/quilt
may well be a much better thing to use.
I love BK, but what BK does well is merging and maintaining trees full of
good stuff. What BK sucks at is experimental stuff where you don't know
whether something should be eventually used or not.
Linus
On Sat, Mar 05, 2005 at 09:40:59AM -0800, Linus Torvalds wrote:
> I love BK, but what BK does well is merging and maintaining trees full of
> good stuff. What BK sucks at is experimental stuff where you don't know
> whether something should be eventually used or not.
Wait a minute - why would stuff going into 2.6.x.y be "experimental"
stuff? Wasn't stability the whole point of this tree?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
Linus Torvalds wrote:
>
> On Sat, 5 Mar 2005, Jeff Garzik wrote:
>
>>Yup, BK could definitely handle that...
>
>
> However, it's also true that the thing BK is _worst_ at is cherry-picking
> things, and having a collection of stuff where somebody may end up vetoing
> one patch and saying "remove that one".
In general, I agree. Andrew and I mentioned this to BitMover recently
[though its certainly not a new comment], when they asked us why I had
to occasionally blow away the netdev-2.6 tree, and reconstitute it from
scratch.
> I love BK, but what BK does well is merging and maintaining trees full of
> good stuff. What BK sucks at is experimental stuff where you don't know
> whether something should be eventually used or not.
I use BitKeeper to maintain such a tree, "libata-dev". Most stuff in
there will go upstream. Some stuff may never go upstream. Some stuff
needs to simmer for a while before going upstream. So "change streams"
get divided up locally:
[jgarzik@pretzel libata-dev]$ ls -FC
adma/ atapi-enable/ janitor/ remove-one-fix/
adma-mwi/ bridge-detect/ passthru/ sata-sil-irq/
ahci-msi/ chs-support/ pdc2027x/ tf-cleanup/
ahci-tf-read/ ioctl-get-identity/ pdc20619/ via-6421/
iomap/ promise-sata-pata/
and then I cherrypick from that.
netdev-2.6 queue is maintained the same way. It's simply a merge tree
composed of 40+ individual trees, all merged together.
Jeff
Many, many thanks...it's a great idea and seems to go well
with Linus's idea of making even releases "hyper-stable".
This is exactly what I was looking for in
(http://article.gmane.org/gmane.linux.kernel/268836)
Sorry some of you feel like "suckers"...but you're _not_.
You're heroes -- doing the hard sh*t that most programmers
don't want to be bothered with. I salute you!
Linda W.
Greg KH wrote:
>For those of you who haven't waded through the huge "RFD: Kernel release
>numbering" thread on lkml to realize that we are now going to start
>putting out 2.6.x.y releases, here's the summary:
>
> A few of us $suckers will be trying to maintain a 2.6.x.y set of
> releases that happen after 2.6.x is released. It will contain
> only a set of bugfixes and security fixes that meet a strict set
> of guidelines, as defined by Linus at:
> http://article.gmane.org/gmane.linux.kernel/283396
>
>Chris Wright and I are going to start working on doing this work, we
>will have a <SOME_ALIAS>@kernel.org to post these types of bug fixes to,
>and a set of people we bounce the patches off of to test for "smells
>good" validation. We will also have a bk-commits type mailing list for
>those who want to watch the patches flow in, and a bk tree from which
>changsets can be pulled from.
>
>Chris and I will be hashing all of the details out next Tuesday, and
>hopefully all the infrastructure will be in place soon. When that
>happens, we will post the full details on how all of this is going to
>work. In the meantime, feel free to CC: me and Chris on patches that
>everyone thinks should go into the 2.6.11.y releases.
>
>But right now, Chris is on a plane, and we don't have the email alias
>set up, or the proper permissions set up on kernel.org to push changes
>into the v2.6 directory, but we have a few bugs that are needing to be
>fixed in the 2.6.11 release. And since our mantra is, "release early
>and often", here's the first release.
>
>---------------
>
>I've released the 2.6.11.1 patch:
> kernel.org/pub/linux/kernel/people/gregkh/v2.6.11/patch-2.6.11.1.gz
>
>With a detailed changelog at:
> kernel.org/pub/linux/kernel/people/gregkh/v2.6.11/ChangeLog-2.6.11.1
>
>A bitkeeper tree for the 2.6.11.y releases can be found at:
> bk://linux-release.bkbits.net/linux-2.6.11
>
>The diffstat and short summary of the fixes are below.
>
>I'll also be replying to this message with a copy of the patch itself,
>as it is small enough to do so.
>
>thanks,
>
>greg k-h
>
>-------
>
> Makefile | 2 +-
> drivers/input/serio/i8042-x86ia64io.h | 6 +++---
> drivers/md/raid6altivec.uc | 4 ++++
> 3 files changed, 8 insertions(+), 4 deletions(-)
>
>
>Summary of changes from v2.6.11 to v2.6.11.1
>============================================
>
>Dmitry Torokhov:
> o Fix keyboards for Dell machines
>
>Greg Kroah-Hartman:
> o Linux 2.6.11.1
>
>Olof Johansson:
> o Fix for trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
>
>Rene Rebe:
> o trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
Linus Torvalds wrote:
>
> On Sat, 5 Mar 2005, Jeff Garzik wrote:
>
>>Yup, BK could definitely handle that...
>
>
> However, it's also true that the thing BK is _worst_ at is cherry-picking
> things, and having a collection of stuff where somebody may end up vetoing
> one patch and saying "remove that one".
>
> So it's entirely possible that the proper tool to use for the first level
> is not BK at all, but the evolved patch-scripts that Andrew uses, in other
> words:
>
> http://savannah.nongnu.org/projects/quilt
>
> may well be a much better thing to use.
>
> I love BK, but what BK does well is merging and maintaining trees full of
> good stuff. What BK sucks at is experimental stuff where you don't know
> whether something should be eventually used or not.
I almost volunteered (read: suckered) and would use patch-scripts
or quilt to do the job. It (the tool) seems to be a natural fit
for it (the job).
However, I'm happy with Greg and Chris doing it. :) suckers.
--
~Randy
On Sat, 5 Mar 2005, Russell King wrote:
>
> On Sat, Mar 05, 2005 at 09:40:59AM -0800, Linus Torvalds wrote:
> > I love BK, but what BK does well is merging and maintaining trees full of
> > good stuff. What BK sucks at is experimental stuff where you don't know
> > whether something should be eventually used or not.
>
> Wait a minute - why would stuff going into 2.6.x.y be "experimental"
> stuff? Wasn't stability the whole point of this tree?
The point being that _before_ a patch gets accepted, it's in that "limbo"
state, waiting for people to veto it or say "yes".
That limbo state is not well done with BK.
Linus
On Saturday 05 March 2005 16:17, Linus Torvalds wrote:
>On Sat, 5 Mar 2005, Russell King wrote:
>> On Sat, Mar 05, 2005 at 09:40:59AM -0800, Linus Torvalds wrote:
>> > I love BK, but what BK does well is merging and maintaining
>> > trees full of good stuff. What BK sucks at is experimental stuff
>> > where you don't know whether something should be eventually used
>> > or not.
>>
>> Wait a minute - why would stuff going into 2.6.x.y be
>> "experimental" stuff? Wasn't stability the whole point of this
>> tree?
>
>The point being that _before_ a patch gets accepted, it's in that
> "limbo" state, waiting for people to veto it or say "yes".
>
>That limbo state is not well done with BK.
>
> Linus
What he said! Perfectly good patches, which fix real problems would
appear to be sitting in testing/broken_out till bit rot or ???.
If you want a testers testimony, I'm running the bk-ieee1394.patch,
and all I can say at this point is that it Just Works(TM). I have
NDI how it got a yesterdays Mar 4) date in the directory listing
there though, I've had it a bit longer than that by 2-3 days as my
copy shows a Mar 1 date. I first got it via svn fetch at
linux-ieee1394.org or some such in January.
Fixes for real problems that fix real problems should somehow get a
faster track into final. The current firewire in the kernel as of
2.6.11 is still badly borked.
If that diff in the dates means I should update and retest, please
advise.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
On Sat, 2005-03-05 at 16:49 -0500, Gene Heskett wrote:
> What he said! Perfectly good patches, which fix real problems would
> appear to be sitting in testing/broken_out till bit rot or ???.
>
> If you want a testers testimony, I'm running the bk-ieee1394.patch,
> and all I can say at this point is that it Just Works(TM). I have
> NDI how it got a yesterdays Mar 4) date in the directory listing
> there though, I've had it a bit longer than that by 2-3 days as my
> copy shows a Mar 1 date. I first got it via svn fetch at
> linux-ieee1394.org or some such in January.
>
> Fixes for real problems that fix real problems should somehow get a
> faster track into final. The current firewire in the kernel as of
> 2.6.11 is still badly borked.
Driver updates are a hard problem. Nothing annoys users more than
unsupported hardware. But if you aggressively add support for new
devices you can break things that have worked for ages.
A change that makes your hardware work may break someone else's. There
is no such thing as an obviously correct patch when you are flipping
bits in the hardware. You can never eliminate 100% of driver
regressions, all you can do is minimize the impact by getting release
candidates tested on the widest possible range of hardware.
Lee
On Saturday 05 March 2005 17:06, Lee Revell wrote:
>On Sat, 2005-03-05 at 16:49 -0500, Gene Heskett wrote:
>> What he said! Perfectly good patches, which fix real problems
>> would appear to be sitting in testing/broken_out till bit rot or
>> ???.
>>
>> If you want a testers testimony, I'm running the
>> bk-ieee1394.patch, and all I can say at this point is that it Just
>> Works(TM). I have NDI how it got a yesterdays Mar 4) date in the
>> directory listing there though, I've had it a bit longer than that
>> by 2-3 days as my copy shows a Mar 1 date. I first got it via svn
>> fetch at linux-ieee1394.org or some such in January.
>>
>> Fixes for real problems that fix real problems should somehow get
>> a faster track into final. The current firewire in the kernel as
>> of 2.6.11 is still badly borked.
>
>Driver updates are a hard problem. Nothing annoys users more than
>unsupported hardware. But if you aggressively add support for new
>devices you can break things that have worked for ages.
>
>A change that makes your hardware work may break someone else's.
> There is no such thing as an obviously correct patch when you are
> flipping bits in the hardware. You can never eliminate 100% of
> driver regressions, all you can do is minimize the impact by
> getting release candidates tested on the widest possible range of
> hardware.
>
>Lee
True up to a certain extent, Lee. I did not own any firewire stuff
except for a 6 year old firewire card I didn't have anything to plug
into, a TI of some sort that supposedly needed the ti-linx driver,
until I bought this camera. That card quickly proved to be borked
per comments made on the linux-firewire list, and got replaced with a
$25 belkin card from wallyworld. One buys whats available at your
friendly local wallyworld as a first pass at fixing things. That
worked great when it felt like it, which wasn't often. Now, with
this patch, it Just Works(TM).
My point is that if it doesn't get into mainline, how are you going to
know it it breaks something that formerly worked? In my case, it
certainly fixed something that didn't work, and didn't break anything
that I know of *yet*.
I have quite a managerie of accessories hanging off of the various
ports, mostly usb on this box, and I have a regular tour of them I
make when I reboot to a newer kernel, so if something breaks sane, or
printing, networking, x10, what have you, I usually know about it
within 30 minutes of the reboot.
Frankly, I was surprised that this elcheapo belkin card worked so
good! Their bigger ups's, and this card seem to be the exception to
the mainline and very prominent story of all their broken KVM
switches. A pleasant surprise in light of my reticence to even put
fingerprints on many of the belkin boxes on the shelf at Staples et
all.
However, that doesn't address the fact that the patch I grabbed, dated
Mar 1, is apparently older than the one in testing/broken_out dated
Mar 4. Both are 265824 bytes long however, so I'm going to go with
the theory that someone rebuilt the directory on kernel.org.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
On Sat, Mar 05, 2005 at 02:53:43AM -0500, Dave Jones wrote:
> On Fri, Mar 04, 2005 at 04:28:02PM -0800, Linus Torvalds wrote:
> > On Fri, 4 Mar 2005, Greg KH wrote:
> > > On Fri, Mar 04, 2005 at 02:36:14PM -0800, Andrew Morton wrote:
> > > > But we end up with a cset in the permanent kernel history which simply
> > > > should not have been there.
> > >
> > > Is this really a big deal?
> >
> > Once? No. If it ends up being "par for the course", it's bad.
>
> The amount of stuff in the sucker tree shouldn't really amount
> to /that/ many patches should it ? If it does, then 2.6.x is in
> worse shape than we've all been admitting.
>
> Would it be that much work to just send the 'meat' as gnu patches,
> and leave the not-for-linus stuff alone ?
No it would not be, and should be the way this works.
thanks,
greg k-h
On Fri, Mar 04, 2005 at 08:37:28PM -0500, Jeff Garzik wrote:
> Greg KH wrote:
> >On Fri, Mar 04, 2005 at 02:36:14PM -0800, Andrew Morton wrote:
> >
> >>But we end up with a cset in the permanent kernel history which simply
> >>should not have been there.
> >
> >
> >Is this really a big deal?
>
> If you are pushing linux-release to Linus/Andrew rapidly, quick fixes
> will land in linux-2.6 rapidly, and more invasive stuff will land only
> in linux-2.6 when the invasive stuff is ready to go. It even takes the
> pressure off pushing invasive stuff ASAP.
>
> Have you pushed linux-2.6.11.1 upstream yet? :)
Having Linus pull from the 2.6.x.y bk tree, will not work out. We
probably don't want the .1, .2, and so on tags in the tree, as well as
not all fixes in there will be proper for his tree (like the 2 currently
in 2.6.11.1.) The "real" fix will go into his tree through the proper
ways.
But I/we will be sure to pick out the stuff that should go there and
send them to him.
thanks,
greg k-h
On Sat, Mar 05, 2005 at 01:16:10AM -0500, Shawn Starr wrote:
> Sounds great, I can be a QA resource for what machines I have.
>
> How do people get involved in QAing these releases?
Get the last release and test it out. If you have problems, and have
simple/obvious patches, send them on.
thanks,
greg k-h
Sure, I can do this. Wrt to trivial patches, will these patches that go into
rusty's patch bot go into Linus's tree or into the -mm tree?
The reason I ask that is because a trivial patch may fix an oops if there's an
off-by-one problem and typically I'd submit that to the trivial patch bot.
That's why I was wondering about why this tree doesn't except trivial changes.
Thanks,
Shawn.
On March 6, 2005 00:06, you wrote:
> On Sat, Mar 05, 2005 at 01:16:10AM -0500, Shawn Starr wrote:
> > Sounds great, I can be a QA resource for what machines I have.
> >
> > How do people get involved in QAing these releases?
>
> Get the last release and test it out. If you have problems, and have
> simple/obvious patches, send them on.
>
> thanks,
>
> greg k-h
Shawn Starr wrote:
> Sure, I can do this. Wrt to trivial patches, will these patches that go into
> rusty's patch bot go into Linus's tree or into the -mm tree?
>
> The reason I ask that is because a trivial patch may fix an oops if there's an
> off-by-one problem and typically I'd submit that to the trivial patch bot.
No offense intended, but Rusty's trivial bot is often too slow
for critical patches, so trivial-but-critical would be better off
going to thru the x.y tree IMO.
> That's why I was wondering about why this tree doesn't except trivial changes.
It will if they fix real problems that people are experiencing.
The trivil bot and/or kernel-janitors paths for patches are better
used for slow/non-critical patches, not patches that need quick
attention and merging.
> Thanks,
> Shawn.
>
>
> On March 6, 2005 00:06, you wrote:
>
>>On Sat, Mar 05, 2005 at 01:16:10AM -0500, Shawn Starr wrote:
>>
>>>Sounds great, I can be a QA resource for what machines I have.
>>>
>>>How do people get involved in QAing these releases?
>>
>>Get the last release and test it out. If you have problems, and have
>>simple/obvious patches, send them on.
--
~Randy
On Sad, 2005-03-05 at 22:06, Lee Revell wrote:
> Driver updates are a hard problem. Nothing annoys users more than
> unsupported hardware. But if you aggressively add support for new
> devices you can break things that have worked for ages.
You can however plan for them in advance. Guess why the -ac tree has an
ide
option to grab any otherwise unknown ide controller and stuff it in bios
tuned
DMA modes ?
Similarly you can generally apply "just PCI id" patches
On Mon, 2005-03-07 at 17:18 +0000, Alan Cox wrote:
> On Sad, 2005-03-05 at 22:06, Lee Revell wrote:
> > Driver updates are a hard problem. Nothing annoys users more than
> > unsupported hardware. But if you aggressively add support for new
> > devices you can break things that have worked for ages.
>
> You can however plan for them in advance. Guess why the -ac tree has an
> ide
> option to grab any otherwise unknown ide controller and stuff it in bios
> tuned
> DMA modes ?
>
> Similarly you can generally apply "just PCI id" patches
Yup. A much simpler example is my emu10k1 multichannel patches that are
in ALSA CVS now. The function of an (obscure) mixer control changes
subtly, so the control is renamed to guarantee that the user gets the
default setting.
Lee
Jeff Garzik wrote:
> Unless it's crashing for people, stack usage is IMO a wanted-fix not
> needed-fix.
>
>
>> nfsd--svcrpc-add-a-per-flavor-set_client-method.patch
>
>
> is this critical?
Wasn't part of the Linus proposal that it had to fix an oops or
non-functional feature?
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
* Bill Davidsen ([email protected]) wrote:
> Jeff Garzik wrote:
> >>nfsd--svcrpc-add-a-per-flavor-set_client-method.patch
> >
> >is this critical?
>
> Wasn't part of the Linus proposal that it had to fix an oops or
> non-functional feature?
We're working on the criteria, should have some updates posted soon.
One important piece is fixing a critical bug or seriously damaged
feature, and another piece is subsystem maintainer signoff/advocacy.
At first pass, this particular patch certainly does not look critical.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net