Date:	Mon, 2 May 2011 01:12:41 +0200
From:	Lucian Adrian Grijincu <lucian.grijincu@...il.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	linux-kernel@...r.kernel.org,
	Alexey Dobriyan <adobriyan@...il.com>,
	Octavian Purdila <tavi@...pub.ro>,
	"David S . Miller" <davem@...emloft.net>
Subject: Re: [PATCH 00/69] faster tree-based sysctl implementation

On Mon, May 2, 2011 at 12:49 AM, Eric W. Biederman
<ebiederm@...ssion.com> wrote:
>>> Since we are touching most if not all of the sysctl registrations this
>>> would also be a good time to pass a path string instead of the weird
>>> ctl_path data structure.  We needed ctl_path when we had both binary
>>> and proc paths to worry about but we no longer have that concern.
>>
>>
>> I still find good use for it in the next patches (some optimisations).
>> Getting rid of it makes some things more difficult:
>> - I wouldn't like to parse strings into path components at registeration
>
> I don't expect '/' being more difficult to deal with than an array.  In
> general I expect a single string to be more space efficient and easier
> for human comprehension.


We also use the string from ctl_path as a name for the sysctl
directory. We would need to either:
* strdup part of the string for each directory, remember to kfree
* replace '/' with '\0' in the given string (meaning it can't be put
in a read-only zone)

Also I make use of the ctl_path to add some optimisations that deal
with the case when there are very many known-to-be-uniquely-named
sub-directories like for /proc/sys/net/ipv4/conf/DEVICE. IXIACOM which
sponsored this work has usecases where they need to create 10^3..10^5
virtual network devices and these optimisations really add up for that
many interfaces.

For details about the optimisation see patches:
 61/69 http://thread.gmane.org/gmane.linux.kernel/1133667/focus=1133694 and
 62/69 http://thread.gmane.org/gmane.linux.kernel/1133667/focus=1133711


I will make another function that would take a string, parse it up,
create a ctl_path array and register it, but I'd really like to keep
ctl_path both in the implementation and as a means to register a
table.

>> - users of the register_sysctl_paths would need to create strings with
>> dynamic components (for example "net/conf/%s/" - where %s is a
>> netdevice-name or "kernel/sched_domain/%s/%s" with cpu-name and
>> domain-name).
>
> This is a good point.
>
> In the normal proc implementation this is solved by being able to
> pass the equivalent of a ctl_table_header into the registration
> function, which allows the use of relative paths in the registration
> function.
>
> In the examples you have given relative paths should also work for
> sysctl.


Hmm, I don't think we're on the same channel here. I don't understand
what you're trying to say
- normal proc implementation?
- the equivalent of a ctl_table_header?
- relative paths?

I was saying that if we are to *replace* the ctl_path based mechanism
with a string denoting the path, then some other registrants will need
to allocate memory for those strings because the paths they register
are computed at runtime. Then I gave two distinct examples where this
is done. In both of those cases, ctl_path saves us from allocating a
string before allocation, only to chop it then back to pieces in the
__register function.



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

Powered by blists - more mailing lists