Re: [PATCH 0/59] Cleanup sysctl

2007-01-17 Thread Eric W. Biederman
Kirill Korotaev <[EMAIL PROTECTED]> writes: > Eric, really good job! > > Patches: 1-13, 15-24, 26-32, 34-44, 46-49, 52-55, 57 (all except below) > Acked-By: Kirill Korotaev <[EMAIL PROTECTED]> > > 14/59 - minor (extra space) > 25/59 - minor note > 33/59 - not sorted sysctl IDs > 45/59 - typo

Re: [PATCH 0/59] Cleanup sysctl

2007-01-17 Thread Kirill Korotaev
Eric, really good job! Patches: 1-13, 15-24, 26-32, 34-44, 46-49, 52-55, 57 (all except below) Acked-By: Kirill Korotaev <[EMAIL PROTECTED]> 14/59 - minor (extra space) 25/59 - minor note 33/59 - not sorted sysctl IDs 45/59 - typo 50/59 - copyright/file note 51/59 - copyright/file

Re: [PATCH 0/59] Cleanup sysctl

2007-01-17 Thread Martin Schwidefsky
On Tue, 2007-01-16 at 09:33 -0700, Eric W. Biederman wrote: > There has not been much maintenance on sysctl in years, and as a result is > there is a lot to do to allow future interesting work to happen, and being > ambitious I'm trying to do it all at once :) s390 parts look good. Kernels boots

Re: [PATCH 0/59] Cleanup sysctl

2007-01-17 Thread Martin Schwidefsky
On Tue, 2007-01-16 at 09:33 -0700, Eric W. Biederman wrote: There has not been much maintenance on sysctl in years, and as a result is there is a lot to do to allow future interesting work to happen, and being ambitious I'm trying to do it all at once :) s390 parts look good. Kernels boots and

Re: [PATCH 0/59] Cleanup sysctl

2007-01-17 Thread Kirill Korotaev
Eric, really good job! Patches: 1-13, 15-24, 26-32, 34-44, 46-49, 52-55, 57 (all except below) Acked-By: Kirill Korotaev [EMAIL PROTECTED] 14/59 - minor (extra space) 25/59 - minor note 33/59 - not sorted sysctl IDs 45/59 - typo 50/59 - copyright/file note 51/59 - copyright/file

Re: [PATCH 0/59] Cleanup sysctl

2007-01-17 Thread Eric W. Biederman
Kirill Korotaev [EMAIL PROTECTED] writes: Eric, really good job! Patches: 1-13, 15-24, 26-32, 34-44, 46-49, 52-55, 57 (all except below) Acked-By: Kirill Korotaev [EMAIL PROTECTED] 14/59 - minor (extra space) 25/59 - minor note 33/59 - not sorted sysctl IDs 45/59 - typo 50/59 -

Re: [PATCH 0/59] Cleanup sysctl

2007-01-16 Thread Andi Kleen
On Wednesday 17 January 2007 03:33, Eric W. Biederman wrote: > There has not been much maintenance on sysctl in years, and as a result is > there is a lot to do to allow future interesting work to happen, and being > ambitious I'm trying to do it all at once :) > > The patches in this series fall

Re: [PATCH 0/59] Cleanup sysctl

2007-01-16 Thread David Howells
The FRV bits look okay. I can't test them until I get back from Australia in Feb. David - 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

Re: [PATCH 0/59] Cleanup sysctl

2007-01-16 Thread Eric W. Biederman
"H. Peter Anvin" <[EMAIL PROTECTED]> writes: > Eric W. Biederman wrote: >>> >>> Agreed. *Furthermore*, if the number isn't in it shouldn't >>> exist anywhere else, either. >> >> That would be a good habit. Feel free to send the patches to ensure that >> is so. >> >> I'm a practical fix it when

Re: [PATCH 0/59] Cleanup sysctl

2007-01-16 Thread H. Peter Anvin
Eric W. Biederman wrote: Agreed. *Furthermore*, if the number isn't in it shouldn't exist anywhere else, either. That would be a good habit. Feel free to send the patches to ensure that is so. I'm a practical fix it when it is in my way kind of guy ;) That's fine. However, I am

Re: [PATCH 0/59] Cleanup sysctl

2007-01-16 Thread Eric W. Biederman
"H. Peter Anvin" <[EMAIL PROTECTED]> writes: > Eric W. Biederman wrote: >>> With "architectural" I mean "guaranteed to be stable" (as opposed to >>> "incidental"). Sorry for the confusion. >> >> Ok. Then largely we are in agreement. To implement that the rule is simple. >> If it isn't

Re: [PATCH 0/59] Cleanup sysctl

2007-01-16 Thread H. Peter Anvin
Eric W. Biederman wrote: With "architectural" I mean "guaranteed to be stable" (as opposed to "incidental"). Sorry for the confusion. Ok. Then largely we are in agreement. To implement that the rule is simple. If it isn't CTL_UNNUMBERED and the number is in Linus's tree, it is our

Re: [PATCH 0/59] Cleanup sysctl

2007-01-16 Thread Eric W. Biederman
"H. Peter Anvin" <[EMAIL PROTECTED]> writes: > Eric W. Biederman wrote: >> >>> I think it would be fair to say that if they're not in > they're >>> not architectural, but that doesn't resolve the counterpositive (are there >>> sysctls in which aren't architectural? From the looks of > it, I

Re: [PATCH 0/59] Cleanup sysctl

2007-01-16 Thread H. Peter Anvin
Eric W. Biederman wrote: I think it would be fair to say that if they're not in they're not architectural, but that doesn't resolve the counterpositive (are there sysctls in which aren't architectural? From the looks of it, I would say yes.) Non-architectural sysctl numbers should not be

Re: [PATCH 0/59] Cleanup sysctl

2007-01-16 Thread Eric W. Biederman
CC list trimmed. "H. Peter Anvin" <[EMAIL PROTECTED]> writes: > Eric W. Biederman wrote: >> >> - Removal of sys_sysctl support where people had used conflicting sysctl >> numbers. Trying to break glibc or other applications by changing the >> ABI is not cool. 9 instances of this in the

Re: [PATCH 0/59] Cleanup sysctl

2007-01-16 Thread H. Peter Anvin
Eric W. Biederman wrote: - Removal of sys_sysctl support where people had used conflicting sysctl numbers. Trying to break glibc or other applications by changing the ABI is not cool. 9 instances of this in the kernel seems a little extreme. It would be highly advantageous if we could

[PATCH 0/59] Cleanup sysctl

2007-01-16 Thread Eric W. Biederman
There has not been much maintenance on sysctl in years, and as a result is there is a lot to do to allow future interesting work to happen, and being ambitious I'm trying to do it all at once :) The patches in this series fall into several general categories. - Removal of useless attempts to

Re: [PATCH 0/59] Cleanup sysctl

2007-01-16 Thread Eric W. Biederman
CC list trimmed. H. Peter Anvin [EMAIL PROTECTED] writes: Eric W. Biederman wrote: - Removal of sys_sysctl support where people had used conflicting sysctl numbers. Trying to break glibc or other applications by changing the ABI is not cool. 9 instances of this in the kernel seems a

Re: [PATCH 0/59] Cleanup sysctl

2007-01-16 Thread H. Peter Anvin
Eric W. Biederman wrote: I think it would be fair to say that if they're not in linux/sysctl.h they're not architectural, but that doesn't resolve the counterpositive (are there sysctls in linux/sysctl.h which aren't architectural? From the looks of it, I would say yes.) Non-architectural

Re: [PATCH 0/59] Cleanup sysctl

2007-01-16 Thread Eric W. Biederman
H. Peter Anvin [EMAIL PROTECTED] writes: Eric W. Biederman wrote: I think it would be fair to say that if they're not in linux/sysctl.h they're not architectural, but that doesn't resolve the counterpositive (are there sysctls in linux/sysctl.h which aren't architectural? From the looks of

Re: [PATCH 0/59] Cleanup sysctl

2007-01-16 Thread H. Peter Anvin
Eric W. Biederman wrote: With architectural I mean guaranteed to be stable (as opposed to incidental). Sorry for the confusion. Ok. Then largely we are in agreement. To implement that the rule is simple. If it isn't CTL_UNNUMBERED and the number is in Linus's tree, it is our

Re: [PATCH 0/59] Cleanup sysctl

2007-01-16 Thread Eric W. Biederman
H. Peter Anvin [EMAIL PROTECTED] writes: Eric W. Biederman wrote: With architectural I mean guaranteed to be stable (as opposed to incidental). Sorry for the confusion. Ok. Then largely we are in agreement. To implement that the rule is simple. If it isn't CTL_UNNUMBERED and the number

Re: [PATCH 0/59] Cleanup sysctl

2007-01-16 Thread H. Peter Anvin
Eric W. Biederman wrote: Agreed. *Furthermore*, if the number isn't in linux/sysctl.h it shouldn't exist anywhere else, either. That would be a good habit. Feel free to send the patches to ensure that is so. I'm a practical fix it when it is in my way kind of guy ;) That's fine.

Re: [PATCH 0/59] Cleanup sysctl

2007-01-16 Thread Eric W. Biederman
H. Peter Anvin [EMAIL PROTECTED] writes: Eric W. Biederman wrote: Agreed. *Furthermore*, if the number isn't in linux/sysctl.h it shouldn't exist anywhere else, either. That would be a good habit. Feel free to send the patches to ensure that is so. I'm a practical fix it when it is in

[PATCH 0/59] Cleanup sysctl

2007-01-16 Thread Eric W. Biederman
There has not been much maintenance on sysctl in years, and as a result is there is a lot to do to allow future interesting work to happen, and being ambitious I'm trying to do it all at once :) The patches in this series fall into several general categories. - Removal of useless attempts to

Re: [PATCH 0/59] Cleanup sysctl

2007-01-16 Thread H. Peter Anvin
Eric W. Biederman wrote: - Removal of sys_sysctl support where people had used conflicting sysctl numbers. Trying to break glibc or other applications by changing the ABI is not cool. 9 instances of this in the kernel seems a little extreme. It would be highly advantageous if we could

Re: [PATCH 0/59] Cleanup sysctl

2007-01-16 Thread David Howells
The FRV bits look okay. I can't test them until I get back from Australia in Feb. David - 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

Re: [PATCH 0/59] Cleanup sysctl

2007-01-16 Thread Andi Kleen
On Wednesday 17 January 2007 03:33, Eric W. Biederman wrote: There has not been much maintenance on sysctl in years, and as a result is there is a lot to do to allow future interesting work to happen, and being ambitious I'm trying to do it all at once :) The patches in this series fall into