Re: problem in building 4.8.0: references to non-existent util CLANG

[L A Walsh]

Randy Dunlap wrote:

On 08/18/2018 05:48 PM, Linda Walsh wrote:
  

Is CLANG required for building now?


Looks like this patch should fix it:
https://marc.info/?l=linux-kbuild=153447099313149=2
  

---
 Thanks much!

Re: problem in building 4.8.0: references to non-existent util CLANG

[L A Walsh]

Randy Dunlap wrote:

On 08/18/2018 05:48 PM, Linda Walsh wrote:
  

Is CLANG required for building now?


Looks like this patch should fix it:
https://marc.info/?l=linux-kbuild=153447099313149=2
  

---
 Thanks much!

Re: RFC: Revert move default dialect from CIFS to to SMB3

[L. A. Walsh]

Linus Torvalds wrote:

On Thu, Aug 31, 2017 at 2:36 PM, Thorsten Leemhuis  wrote:
  

Lo! To give a bit more background to this (the mail I reply to was the
first I sent with git send-email and I missed some details): Maybe I'm
over stretching my abilities/position as regression tracker with this
RFC for a revert, but I hope it at least triggers a discussion if such a
revert should be done or not.



I don't think that a revert is appropriate.

But perhaps just a single printk() or something if the user does *not*
specify the version explicitly? Just saying something like

  We used to default to 1.0, we now default to 3.0, if you want old
defaults, use "vers=1.0"
  


   Why be incompatible with the majority of Windows installations?
I.e.  If you really want to up security from 1.0 (not adverse to that),
then why not go to 2.1 as used by Win7?  Win7 is still in support
from MS -- and they haven't indicated a need to upgrade to 3.x for
security reasons.  3.x may have new security features, no argument, but
that doesn't mean 2.1, is insecure.



I do *not* believe that "default to version 1" is acceptable.
  

---
   But does it have to jump to 3?  I.e. Why not go a more middle
route of 2.1 -- as it is still security-supported by MS.  Ideally
MS would find some bug in 2.1 and allow 3.x to be an upgrade to Win7,
but until then...

Linda

Re: RFC: Revert move default dialect from CIFS to to SMB3

[L. A. Walsh]

Linus Torvalds wrote:

On Thu, Aug 31, 2017 at 2:36 PM, Thorsten Leemhuis  wrote:
  

Lo! To give a bit more background to this (the mail I reply to was the
first I sent with git send-email and I missed some details): Maybe I'm
over stretching my abilities/position as regression tracker with this
RFC for a revert, but I hope it at least triggers a discussion if such a
revert should be done or not.



I don't think that a revert is appropriate.

But perhaps just a single printk() or something if the user does *not*
specify the version explicitly? Just saying something like

  We used to default to 1.0, we now default to 3.0, if you want old
defaults, use "vers=1.0"
  


   Why be incompatible with the majority of Windows installations?
I.e.  If you really want to up security from 1.0 (not adverse to that),
then why not go to 2.1 as used by Win7?  Win7 is still in support
from MS -- and they haven't indicated a need to upgrade to 3.x for
security reasons.  3.x may have new security features, no argument, but
that doesn't mean 2.1, is insecure.



I do *not* believe that "default to version 1" is acceptable.
  

---
   But does it have to jump to 3?  I.e. Why not go a more middle
route of 2.1 -- as it is still security-supported by MS.  Ideally
MS would find some bug in 2.1 and allow 3.x to be an upgrade to Win7,
but until then...

Linda

Re: RFC: Revert move default dialect from CIFS to to SMB3"

[L. A. Walsh]

Thorsten Leemhuis wrote:

This reverts commit eef914a9eb5eb83e60eb498315a491cd1edc13a1 (
[SMB3] Improve security, move default dialect to SMB3 from old CIFS), 
as it confuses users: https://bugzilla.kernel.org/show_bug.cgi?id=196599


It was a patch to improve security by switching to SMB3 by default and
support SMB1 (aka CIFS) only when explicitly requested, as the latter
is not considered secure anymore (see below for details). This is one of
the rare cases where regressions are unavoidable and accepted in Linux.
  


   Why not SMB2.1?  Win7 is still in support and getting security updates.
MS has not issued any updates for Win7 upgrading it to SMB3.0 for any
reason (that I'm aware of) -- including security. 


   If there were security problems in Win7 w/SMB2.1, wouldn't MS
issue patches -- as they did for WinXP just recently for a severe
SMB1 bug?

   Seems like if they are willing to patch "out of support" XP, for
a serious problem, then they would be more likely to patch Win7 for
lesser problems.

   Seems like jumping the default to MS's latest and greatest puts
linux on MS's OS-release schedule -- especially when they haven't declared
SMB2.1 as "bad"...  From what I understand, most of the new security
features in 3.0 when into SMB2.1 or 2.0.


SMB3 is both secure and widely available: in Windows 8 and later,
Samba and Macs.



   I can't find more recent stats than last Dec, but Win7 had between
2-3X the number of Win8 users AND Win7 had between 40-100% more uses
than Win10.  Win 8 was pretty much a non-starter.
(http://www.zdnet.com/article/windows-10-versus-windows-7-whose-numbers-do-you-trust/)

As of March 2017, another article showed Win7 growing w/r/t Win10:
(https://www.theinquirer.net/inquirer/news/3005602/windows-7-market-share-rises-at-the-expense-of-windows-10)

   I can't say moving the default away from SMB1 seems like a bad thing 
-- especially if the error messages can be improved.  Besides security, its

notably slower, but many home devices still use SMB1 -- which is *fine*,
if they are not exposed to the outside net.  Then again, I've never
put a Windows machine facing the internet -- don't think they are security
enough -- use linux for that.




  

Re: RFC: Revert move default dialect from CIFS to to SMB3"

[L. A. Walsh]

Thorsten Leemhuis wrote:

This reverts commit eef914a9eb5eb83e60eb498315a491cd1edc13a1 (
[SMB3] Improve security, move default dialect to SMB3 from old CIFS), 
as it confuses users: https://bugzilla.kernel.org/show_bug.cgi?id=196599


It was a patch to improve security by switching to SMB3 by default and
support SMB1 (aka CIFS) only when explicitly requested, as the latter
is not considered secure anymore (see below for details). This is one of
the rare cases where regressions are unavoidable and accepted in Linux.
  


   Why not SMB2.1?  Win7 is still in support and getting security updates.
MS has not issued any updates for Win7 upgrading it to SMB3.0 for any
reason (that I'm aware of) -- including security. 


   If there were security problems in Win7 w/SMB2.1, wouldn't MS
issue patches -- as they did for WinXP just recently for a severe
SMB1 bug?

   Seems like if they are willing to patch "out of support" XP, for
a serious problem, then they would be more likely to patch Win7 for
lesser problems.

   Seems like jumping the default to MS's latest and greatest puts
linux on MS's OS-release schedule -- especially when they haven't declared
SMB2.1 as "bad"...  From what I understand, most of the new security
features in 3.0 when into SMB2.1 or 2.0.


SMB3 is both secure and widely available: in Windows 8 and later,
Samba and Macs.



   I can't find more recent stats than last Dec, but Win7 had between
2-3X the number of Win8 users AND Win7 had between 40-100% more uses
than Win10.  Win 8 was pretty much a non-starter.
(http://www.zdnet.com/article/windows-10-versus-windows-7-whose-numbers-do-you-trust/)

As of March 2017, another article showed Win7 growing w/r/t Win10:
(https://www.theinquirer.net/inquirer/news/3005602/windows-7-market-share-rises-at-the-expense-of-windows-10)

   I can't say moving the default away from SMB1 seems like a bad thing 
-- especially if the error messages can be improved.  Besides security, its

notably slower, but many home devices still use SMB1 -- which is *fine*,
if they are not exposed to the outside net.  Then again, I've never
put a Windows machine facing the internet -- don't think they are security
enough -- use linux for that.




  

Re: RFC: 2.6.release.patchlevel: Patch against 2.6.release[.0] ?

[L. A. Walsh]

Chris Wright wrote:
The patches on kernel.org in v2.6/ are already against the base (i.e.
patch-2.6.11.6.bz2 is against 2.6.11).  The patches in v2.6/incr/
are incremental between -stable releases (i.e. patch-2.6.11.5-6.bz2 is
against 2.6.11.5).

	I see.  I had looked at the "Changelog" page on the www.kernel.org home
page and only saw changes from 2.6.11.5->2.6.11.6 documented.  I thought that 
the Changelog documented the changes that were in the patch.

	Maybe Changlog's that only document the current increment should be in the 
"incr" directory as well and be named "Changelog-2.6.11.5-6" (for the current 
change log, while a cumulative change log from the base version should
be kept in the v2.6 dir?

I think having the Changelog link on the main page only documenting
the latest "incr", but having the patch containing everything from the base is
confusing.  Am I the only one who might expect the Changelog to document what is
in the given increment, but the associated patch includes everything since the 
base?
	It's a "nit", I know, but I prefer having the change-log and patch to match 
w/respect to content.

Linda
-
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/

Re: RFC: 2.6.release.patchlevel: Patch against 2.6.release[.0] ?

[L. A. Walsh]

Chris Wright wrote:
The patches on kernel.org in v2.6/ are already against the base (i.e.
patch-2.6.11.6.bz2 is against 2.6.11).  The patches in v2.6/incr/
are incremental between -stable releases (i.e. patch-2.6.11.5-6.bz2 is
against 2.6.11.5).

	I see.  I had looked at the Changelog page on the www.kernel.org home
page and only saw changes from 2.6.11.5-2.6.11.6 documented.  I thought that 
the Changelog documented the changes that were in the patch.

	Maybe Changlog's that only document the current increment should be in the 
incr directory as well and be named Changelog-2.6.11.5-6 (for the current 
change log, while a cumulative change log from the base version should
be kept in the v2.6 dir?

I think having the Changelog link on the main page only documenting
the latest incr, but having the patch containing everything from the base is
confusing.  Am I the only one who might expect the Changelog to document what is
in the given increment, but the associated patch includes everything since the 
base?
	It's a nit, I know, but I prefer having the change-log and patch to match 
w/respect to content.

Linda
-
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/

RFC: 2.6.release.patchlevel: Patch against 2.6.release[.0] ?

[L. A. Walsh]

Given the frequency with which stabilization patches may be released, it
may not be practical to expect users to catch each release announcement
and download each patch.
Especially if small patches are released for stability, as one might
(hopefully) expect.  Assuming that stability and "fix-it" patches will
generally be small (I'd hope).  Seeing that the latest "fix-it" patch
is already at ".6", I'd have to load multiple patches to catch up from
2.6.11.  I blinked my eyes and missed a few or 5 previous stability
patches, so I just downloaded the entire bzip...not a biggie, but
might create less load on servers if I didn't need to go through 6
patch applications to get current.
What do people think?  Would it be desirable to have the stability
patchsets based against the base release (2.6.11 in this case)?  I'll
already have downloaded 2.6.11 or the previous base release, but
with the frequency of patch releases, it might be more reasonable to
have patch revisions all patch against a base release rather than
having to download and apply what may grow to be a large number (but
small diff) against a base release?
Do people think patch-releases will get too big, or might it not
be easier to apply them to a constant downloaded copy of the base?
It's a bit amusing since I was one of those that complained about the
kernel stability, but 2.6.11 has been fairly solid for me, so, of course,
I'm 6 patches behind -- I don't think the patch release notifications
are getting as wide-spread press (or at least not reaching "/." :-)) as
the main releases get.
Linda
-
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/

RFC: 2.6.release.patchlevel: Patch against 2.6.release[.0] ?

[L. A. Walsh]

Given the frequency with which stabilization patches may be released, it
may not be practical to expect users to catch each release announcement
and download each patch.
Especially if small patches are released for stability, as one might
(hopefully) expect.  Assuming that stability and fix-it patches will
generally be small (I'd hope).  Seeing that the latest fix-it patch
is already at .6, I'd have to load multiple patches to catch up from
2.6.11.  I blinked my eyes and missed a few or 5 previous stability
patches, so I just downloaded the entire bzip...not a biggie, but
might create less load on servers if I didn't need to go through 6
patch applications to get current.
What do people think?  Would it be desirable to have the stability
patchsets based against the base release (2.6.11 in this case)?  I'll
already have downloaded 2.6.11 or the previous base release, but
with the frequency of patch releases, it might be more reasonable to
have patch revisions all patch against a base release rather than
having to download and apply what may grow to be a large number (but
small diff) against a base release?
Do people think patch-releases will get too big, or might it not
be easier to apply them to a constant downloaded copy of the base?
It's a bit amusing since I was one of those that complained about the
kernel stability, but 2.6.11 has been fairly solid for me, so, of course,
I'm 6 patches behind -- I don't think the patch release notifications
are getting as wide-spread press (or at least not reaching /. :-)) as
the main releases get.
Linda
-
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/

Re: [PATCH] typo fix in Documentation/eisa.txt

[L. A. Walsh]

Rolf Eike Beer wrote:
Typo fixes.
Thanks to Randy Dunlap and Jean Delvare.
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
--- linux-2.6.11/Documentation/eisa.txt 2005-03-02 08:38:12.0 +0100
+++ linux-2.6.12-rc1/Documentation/eisa.txt 2005-03-27 21:58:04.0 
+0200
@@ -171,9 +171,9 @@
virtual_root.force_probe :
Force the probing code to probe EISA slots even when it cannot find an
-EISA compliant mainboard (nothing appears on slot 0). Defaultd to 0
-(don't force), and set to 1 (force probing) when either
-CONFIG_ALPHA_JENSEN or CONFIG_EISA_VLB_PRIMING are set.
+EISA compliant mainboard (nothing appears on slot 0). Defaults to 0
+(don't force) and set to 1 (force probing) when either
+CONFIG_ALPHA_JENSEN or CONFIG_EISA_VLB_PRIMING is set.
---
01234567890123456789012345678901234567890123456789012345678901234567890123456789
   My expertise is limited by a fuzzy memory, and I know it's bad form to
comment much on english usage or spelling as they are often tangential to
the issue at hand, but as long as we are on the topic, I think you had it
right the first time.
   I believe the comment, properly used the "imperative":
declaring intended usage of the variable, i.e. - "Do this or do
that"; "Default to 0 or set to 1".  To use a perl like example:
  # set probe action:
probe=0;   # default to 0 (don't force)
probe=1 if (X || Y);   # and set to 1 (force), if either X or Y is set
   If you use "Defaults", then I think that's an implied 3rd person
singular usage and for correct parallelism, the parallel clause (after
the "and") should use the same tense.  Third person tense for "set"
would use "is" as a passive-voice auxiliary: "[it] is set to 1..."
   Saying "default to 0" is like the perlism:
   setup values of v:
   v=0;   # default to 0
   v=1 if (X || Y);   # and set to 1 if X or Y is set
   I can't believe we are discussing grammer concerns in comments in
the linux-kenel.  :-) (!).
-linda
-
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/

Re: Do not misuse Coverity please (Was: sound/oss/cs46xx.c: fix a check after use)

[L. A. Walsh]

Adrian Bunk wrote:
On Sun, Mar 27, 2005 at 11:21:58PM +0200, Jean Delvare wrote:
 

There are two cases:
1. NULL is impossible, the check is superfluous
2. this was an actual bug
In the first case, my patch doesn't do any harm (a superfluous isn't a 
real bug).

In the second case, it fixed a bug.
It might be a bug not many people hit because it might be in some error 
path of some esoteric driver.

If a maintainer of a well-maintained subsystem like i2c says
"The check is superfluous." that's the perfect solution.
But in less maintained parts of the kernel, even a low possibility that 
it fixes a possible bug is IMHO worth making such a riskless patch.
 

---
   I'd agree in [al]most any part of the kernel.  Unless it
is extremely time critical code, subroutines should expect
possible garbage from their callers.
   Just because it may be perfect today doesn't mean someone down
the line won't call the routine with less than perfect parameters.
   It used to be called "defensive" programming.
   However, in this case, if the author is _certain_ the
pointer can never be NULL, than an "ASSERT(card!=NULL);" might
be appropriate, where ASSERT is a macro that normally compiles
in the check, but could compile to "nothing" for embedded or
kernels that aren't being developed in.
-linda
 

Thanks,
Jean Delvare
   

cu
Adrian
 

-
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/

Re: Do not misuse Coverity please (Was: sound/oss/cs46xx.c: fix a check after use)

[L. A. Walsh]

Adrian Bunk wrote:
On Sun, Mar 27, 2005 at 11:21:58PM +0200, Jean Delvare wrote:
 

There are two cases:
1. NULL is impossible, the check is superfluous
2. this was an actual bug
In the first case, my patch doesn't do any harm (a superfluous isn't a 
real bug).

In the second case, it fixed a bug.
It might be a bug not many people hit because it might be in some error 
path of some esoteric driver.

If a maintainer of a well-maintained subsystem like i2c says
The check is superfluous. that's the perfect solution.
But in less maintained parts of the kernel, even a low possibility that 
it fixes a possible bug is IMHO worth making such a riskless patch.
 

---
   I'd agree in [al]most any part of the kernel.  Unless it
is extremely time critical code, subroutines should expect
possible garbage from their callers.
   Just because it may be perfect today doesn't mean someone down
the line won't call the routine with less than perfect parameters.
   It used to be called defensive programming.
   However, in this case, if the author is _certain_ the
pointer can never be NULL, than an ASSERT(card!=NULL); might
be appropriate, where ASSERT is a macro that normally compiles
in the check, but could compile to nothing for embedded or
kernels that aren't being developed in.
-linda
 

Thanks,
Jean Delvare
   

cu
Adrian
 

-
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/

Re: [PATCH] typo fix in Documentation/eisa.txt

[L. A. Walsh]

Rolf Eike Beer wrote:
Typo fixes.
Thanks to Randy Dunlap and Jean Delvare.
Signed-off-by: Rolf Eike Beer [EMAIL PROTECTED]
--- linux-2.6.11/Documentation/eisa.txt 2005-03-02 08:38:12.0 +0100
+++ linux-2.6.12-rc1/Documentation/eisa.txt 2005-03-27 21:58:04.0 
+0200
@@ -171,9 +171,9 @@
virtual_root.force_probe :
Force the probing code to probe EISA slots even when it cannot find an
-EISA compliant mainboard (nothing appears on slot 0). Defaultd to 0
-(don't force), and set to 1 (force probing) when either
-CONFIG_ALPHA_JENSEN or CONFIG_EISA_VLB_PRIMING are set.
+EISA compliant mainboard (nothing appears on slot 0). Defaults to 0
+(don't force) and set to 1 (force probing) when either
+CONFIG_ALPHA_JENSEN or CONFIG_EISA_VLB_PRIMING is set.
---
01234567890123456789012345678901234567890123456789012345678901234567890123456789
   My expertise is limited by a fuzzy memory, and I know it's bad form to
comment much on english usage or spelling as they are often tangential to
the issue at hand, but as long as we are on the topic, I think you had it
right the first time.
   I believe the comment, properly used the imperative:
declaring intended usage of the variable, i.e. - Do this or do
that; Default to 0 or set to 1.  To use a perl like example:
  # set probe action:
probe=0;   # default to 0 (don't force)
probe=1 if (X || Y);   # and set to 1 (force), if either X or Y is set
   If you use Defaults, then I think that's an implied 3rd person
singular usage and for correct parallelism, the parallel clause (after
the and) should use the same tense.  Third person tense for set
would use is as a passive-voice auxiliary: [it] is set to 1...
   Saying default to 0 is like the perlism:
   setup values of v:
   v=0;   # default to 0
   v=1 if (X || Y);   # and set to 1 if X or Y is set
   I can't believe we are discussing grammer concerns in comments in
the linux-kenel.  :-) (!).
-linda
-
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/

Re: Linux 2.6.11.1

[L. A. Walsh]

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 @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/
 

-
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/

Re: Linux 2.6.11.1

[L. A. Walsh]

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/
 

-
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/