[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <BANLkTik2Y+Yy4kaa2cNUEvTMygXH6btWUg@mail.gmail.com>
Date: Tue, 10 May 2011 03:06:15 +0200
From: Lucian Adrian Grijincu <lucian.grijincu@...il.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
Alexey Dobriyan <adobriyan@...il.com>,
Octavian Purdila <tavi@...pub.ro>,
"David S . Miller" <davem@...emloft.net>
Subject: Re: [v2 000/115] faster tree-based sysctl implementation
On Mon, May 9, 2011 at 5:11 AM, Eric W. Biederman <ebiederm@...ssion.com> wrote:
> With respect to review and merging. The priorities should be:
> 1) Figure out what the users really need to do, before we change
> everything so we only need one sweeping pass through the users
> that hopefully simplifies them.
The users of the API should not rely on the .child field of 'struct
ctl_table' because we don't use that to encode the tree structure any
more.
That's absolutely the only thing that's changed in the API.
Most of the sysctl users in the tree don't need any change and will
work with the new sysctl just fine.
For the few that do, the first path of the series (the patches with
"no-child" in the name) get's rid of the .child field by:
a) replacing register_sysctl_table with register_sysctl_paths (very
straight forward change and the new code is cleaner)
b) registering files in multiple directories separately
That part of the patch series does not disturb the current
functionality and does not depend of the later patches; it uses the
current sysctl API to achieve the same goal.
> 2) Ensure you have a version of the new interfaces ready at the
> start of the patchset, so the sweeping changes can be made
> incrementally.
>
> 3) Clean up the users.
>
> 4) Make simplifications because you don't have any old users left.
Hmm. I'm not sure if I understand you correctly.
You want this so that the cleanup patches get in through the affected
subsystems, and not in a big series that would possibly create merge
problems with those trees?
This wouldn't be too hard to do and wouldn't uglify the new interface
too much, but I have limited time available to do this in the near
future (exams and school projects). I'll see how I can squeeze this
in.
--
.
..: Lucian
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists