[Top] [All Lists]

Re: [PATCH 50/59] sysctl: Move utsname sysctls to their own file

To: Kirill Korotaev <>
Subject: Re: [PATCH 50/59] sysctl: Move utsname sysctls to their own file
From: (Eric W. Biederman)
Date: Wed, 17 Jan 2007 12:31:22 -0700
Cc: "<Andrew Morton" <>,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
In-reply-to: <> (Kirill Korotaev's message of "Wed, 17 Jan 2007 20:41:48 +0300")
Original-recipient: rfc822;
References: <> <> <>
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
Kirill Korotaev <> 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.

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


<Prev in Thread] Current Thread [Next in Thread>