OpenVZ Forum


Home » Mailing lists » Devel » [PATCH 0/59] Cleanup sysctl
Re: [PATCH 50/59] sysctl: Move utsname sysctls to their own file [message #17307 is a reply to message #17233] Mon, 22 January 2007 22:24 Go to previous messageGo to previous message
Herbert Poetzl is currently offline  Herbert Poetzl
Messages: 239
Registered: February 2006
Senior Member
On Wed, Jan 17, 2007 at 12:31:22PM -0700, Eric W. Biederman wrote:
> Kirill Korotaev <dev@sw.ru> writes:
> 
> > Eric, though I personally don't care much:
> > 1. I ask for not setting your authorship/copyright on the code which you just
> > copied
> >   from other places. Just doesn't look polite IMHO.
> 
> I can't claim complete ownership of the code, there was plenty of feed back
> and contributions from others but the final form without a big switch
> statement is mine.  I certainly can't claim the table, it has been in
> that form for years.
> 
> If you notice I actually didn't say whose copyright it was :)  just
> that I wrote the file.
> 
> If there are copyright claims I should include I will be happy to do that.
> Mostly I was just trying to find some stupid boiler plate that would work.

IMHO that is fine ...

> > 2. I would propose to not introduce utsname_sysctl.c.
> >   both files are too small and minor that I can't see much reasons splitting
> > them.
> 
> The impact of moving this code out of sysctl.c is a major
> simplification, to sysctl.c.  Putting them in their own file means we
> can cleanly restrict the code to only be compiled CONFIG_SYSCTL is set.
> 
> It is a necessary first step to implementing a per process /proc/sys.
> 
> It reorganizes the ipc and utsname sysctl from a terribly fragile
> structure to something that is robust and easy to follow.  Code
> scattered all throughout sysctl.c was just a disaster.  We had
> several instances of having to fix bugs with odd combinations of
> CONFIG options, simply because the other spot that needed to be touched
> wasn't obvious.
> 
> So from my perspective this is an extremely worthwhile change that
> will make maintenance easier and is a small first step towards
> some nice future functionality.

yep, agreed ...

best,
Herbert

> Eric
> _______________________________________________
> Containers mailing list
> Containers@lists.osdl.org
> https://lists.osdl.org/mailman/listinfo/containers
_______________________________________________
Containers mailing list
Containers@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: gentoo baselayout 1.13 openvz modifications
Next Topic: [PATCH] :EXT[3, 4] jbd layer function called instead of fs specific one
Goto Forum:
  


Current Time: Thu Sep 18 22:16:07 GMT 2025

Total time taken to generate the page: 0.05851 seconds