lkml.org 
[lkml]   [1998]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: sysctl() considered harmful
> Now that I look a bit more, it is good that nobody uses it,
> because it does random things.

Well, I agree that you've found a bug, but it is not as bad as
you describe. It just needs to be fixed in Linux 2.1. Anybody
using such is system should expect system behaviour to change
without notice, so it's not too late to change it back to the 2.0
behaviour.

> Ref: compare sysctl.h in 2.0.33 and 2.1.77.
> E.g., what value has KERN_SECURELVL? and NET_IPV4_ARP_TIMEOUT?
> What variable is accessed on one system by a program
> compiled on the other?

Yes, bad things happen. I think below should be a complete list:
- Somebody added values after KERN_MAXID before 2.0. This is not
present in 2.1, so a placeholder value should be introduced between
MAXFILE and SECURELVL
- KSWAPD changed to SWAPOUT, which unfortunately also changed the
calling convention. SWAPOUT should be moved to the end, and
a placeholder for the old KSWAPD should be inserted
- NET_CORE_NET_ALIAS_MAX should return into 2.1
- NET_IPV4_ARP_MAX_PINGS should be moved beyond at least DYNADDR
- NET_IPV4_FORWARD should return to 2.1. Is this the same as
NET_IPV4_FORWARDING?
- NET_IPV4_DYNADDR should be moved behind FORWARD

These changes will obviously break numbers assigned in 2.1. I see
no way to avoid this, and it has to happen now.

Finally, there should be an explicit policy stating that new sysctl
numbers should be unique among all existing kernel versions, and not
conflict with numbers introduced into more recent kernel versions.
Perhaps we can designate areas as experimental, so people know that
only numbers published in the released kernels count.

I'm willing to provide patches along the lines mentioned above,
unless somebody tells me that this is rubbish.

Regards,
Martin

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.043 / U:0.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site