Re: [RFC/PATCH] Per-device parameter support (13/16)

[Tejun Heo <tj@home-tj.org>]

On Mon, Oct 25, 2004 at 03:56:13PM +1000, Rusty Russell wrote:
> On Sat, 2004-10-23 at 13:31 +0900, Tejun Heo wrote:
> > +void devparam_module_done(struct module *mod)
> > +{
> > +	struct vector *vec = &mod->param_vec;
> > +	int i;
> > +
> > +	for (i = 0; i < vector_len(vec); i++) {
> > +		char **param = vector_elem(vec, i, 0);
> > +		if (param[0])
> > +			printk(KERN_ERR
> > +			       "Device params: Unknown parameter `%s'\n",
> > +			       param[0]);
> > +	}
> > +	
> > +	vector_destroy(vec);
> > +}
> 
> That seems a strange place to warn...  Is that right?

 Yes, it's right.  Because a module may contain more than one drivers,
devparam puts all paramters into an array and mask them off with NULL
when they are taken and, after module initialization is done, above
devparam_module_done() is called and prints warnings about untaken
paramters.  The same approach is used for boot options too.

> > +
> > +	/* Module parameter vector, used by deviceparam */
> > +	struct vector param_vec;
> 
> I don't mind the addition of your vector type, but adding infrastructure
> always results in arguments.  Can you think of another place which needs
> it?

 I just find dynamically expandable arrays very useful when I code
stuff.  Expanding/shrinking in the middle is maybe unnecessary but in
general, a vector w/ constructor/destructor is handy.  I cannot
pinpoint any specific code right now but I am pretty positive that
there are many places where unncessary fixed limit is employed to
avoid dynamic array management (not that fixed limit is always bad but
it's better to avoid them when possible without much overhead).

 If getting the vector in is difficult, I can merge vector codes into
devparam or change devparam to use list instead.  No problem there.
But I think that having generic vector around isn't a bad idea.  I'll
try to find places where vector can be useful if I can find some time.

 Thanks.

-- 
tejun