On Wed, Aug 07, 2002 at 02:22:27PM +0530, Ravikiran G Thirumalai wrote:
> Here's the new statctr patch (2.5.29) on top of kmalloc_percpu dynamic
> allocator. This one passes GFP_ flags for statctr_init as suggested by
> Andrew Morton and makes use of cpu_possible. Counters can be grouped into
> one or multiple /proc files as per Rik's suggestion.
> Here are the revised interfaces:
>
> 1. struct statctr_proc_entry
> *create_statctr_proc_entry(struct proc_dir_entry *parent, const char *name);
> To create a /proc file to group counters for automatic /proc reporting
>
> 2. free_statctr_proc_entry(struct statctr_proc_entry *)
>
> To free up the proc entry
>
> 3. int statctr_init(statctr_t *stctr, unsigned long val,
> struct statctr_proc_entry *pentry,
> const char *ctrname, int flags)
>
> Allocates memory to the counter , initialises it, and links the counter
> with statctr_proc_entry for automatic /proc reporting. ctrname is the
> counter label as it appears in /proc, flags are the GFP_ hints.
> /proc reporting can be turned off if pentry is NULL.
What about a general s/_proc//g for the API?
For statctr_init the flags argument would much better be named gfp_mask,
the val argument should be removed and the counter initialized to zero
by default - that's 90% of the uses..
Also the /proc-based implementation is really ugly. It should be moved
over to the seq_file interface at least, a simple ramfs-style own
filesystem ("stats" filesystem type) would be the cleanest solution.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:35 EST