Re: RFC v1: sysctl: add sysctl header cookie, share tables between nets

[Lucian Adrian Grijincu]

On Thu, Mar 3, 2011 at 10:33 AM, Eric W. Biederman
<ebiederm@xxxxxxxxxxxx> wrote:
> I may be missing something in these patches. I haven't had time to look
> at this most recent batch carefully. ÂBut from a 10,000 foot perspective I
> have a problem with them. ÂWith a handful of network devices the size of
> the data structures is negligible.
>
> So until I can see a reason why we should save a few bytes at the cost
> of greater future maintenance costs I'm not in favor of this patch set.


Sorry, I'm moving between countries and I don't have as much time as
I'd like to.

This patch series adds the "cookie" field and uses it in a few places.
I need this for the next step, but I wanted some feedback regarding
the cookie approach (sane? applicable if the 'dynamic header' feature
is accepted?).

Afterwards I want to add a "dynamic ctl_header" which will implement a
few ops (something on the lines of 'find_in_table' and 'scan' from
proc_sysctl.c).

At 'scan' time the "dynamic header" will create inodes for the
directories underneath with:
  ctl_table='shared ctl table for /proc/sys/net/ipv4/conf' (or
ipv6/addrconf or neigh)
  ctl_table_header=a device specific (not dynamic) table header with
->cookie pointing to a struct {char*dev_name; struct net*net;}

proc_handlers will use the name (or even a pointer to the device or
whatever speeds up the implementation) and the net to find out the
real ->data similar to the netns_proc_handlers from this patch series.

Adding an interface will not need to scan through the list of existing
ctl headers to see if any duplicates exist because there cannot be two
interfaces with the same name.

Promise to get back with patches for this implementation as soon as I can.

PS: sorry if my mumbling does not make much sense, hopefully code will
make things clear.
-- 
Â.
..: Lucian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/