linux-kernel - Re: [v2 000/115] faster tree-based sysctl implementation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/