Hello,

On Tue, 13 Nov 2007, Simon Horman wrote:

quoted text
> > > Running the latest git code I get the following messages during boot:
> > > sysctl table check failed: /net/ipv4/vs/drop_entry .3.5.21.4 Missing strategy
> > > [...]		  
> > > sysctl table check failed: /net/ipv4/vs/drop_packet .3.5.21.5 Missing strategy
> > > [...]
> > > sysctl table check failed: /net/ipv4/vs/secure_tcp .3.5.21.6 Missing strategy
> > > [...]
> > > sysctl table check failed: /net/ipv4/vs/sync_threshold .3.5.21.24 Missing strategy
> > > 
> > > I removed the binary sysctl handler for those messages and also removed
> > > the definitions in ip_vs.h. The alternative would be to implement a 
> > > proper strategy handler, but syscall sysctl is deprecated.
> > > 
> > > There are other sysctl definitions that are commented out or work with 
> > > the default sysctl_data strategy. I did not touch these. 
> > > 
> Hi Christian, Hi Dave,
> 
> I have indeed been looking into this of late. Assuming that you use of
> CTL_UNNUMBERED is correct, this patch looks fine to me.  Acked.
> 
> I was planning to do the same and also switch over all the other entries
> over to use CTL_UNNUMBERED, as its hard to imagine that anyone is using
> the sys_sysctl interface to IPVS.
> 
> As for the commented out entries. They are supposed to be exposed by
> some other means - I believe the thinking was to comply with the don't
> expose stuff in proc any more idea. Where is the best place to expose
> this kind of stuff?

	I assume /proc/sys is still valid place, only sysctl interface
is scheduled for removal. So, as long as these entries are not
accessible from sysctl it is safe to run without strategy handler but if
values can be changed then we will need strategy handler to
properly call update_defense_level() as done in proc_do_defense_mode()
as proc_handler. There could be side effects if new mode is not applied.

Regards

--
Julian Anastasov <ja@ssi.bg>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html