Hi.
On Sat, 2005-07-09 at 22:16, Pavel Machek wrote:
> Hi!
>
> You know what I think about plugins, right? There are already plugins
> at block device level, like raid5, LVM, device mapper... I do not see
> why you should need another one.
>
> > +/*
> > + * expected_compression_ratio
> > + *
> > + * Returns the expected ratio between the amount of memory
> > + * to be saved and the amount of space required on the
> > + * storage device.
> > + */
> > +int expected_compression_ratio(void)
> > +{
> > + struct suspend_plugin_ops * this_filter;
> > + unsigned long ratio = 100;
> > +
> > + list_for_each_entry(this_filter, &suspend_filters,
> > ops.filter.filter_list) {
> > + if (this_filter->disabled)
> > + continue;
> > + if (this_filter->ops.filter.expected_compression)
> > + ratio = ratio *
> > this_filter->ops.filter.expected_compression() / 100;
> > + }
> > +
> > + return (int) ratio;
> > +}
>
> Why the cast and why long in the first place?
My bad. Actually, since I recently switched to cryptoapi support, I can
get rid of this function.
> > +struct suspend_plugin_ops * find_plugin_given_name(char * name)
> > +{
> > + struct suspend_plugin_ops * this_plugin, * found_plugin = NULL;
> > +
> > + list_for_each_entry(this_plugin, &suspend_plugins, plugin_list) {
> > + if (!strcmp(name, this_plugin->name)) {
> > + found_plugin = this_plugin;
> > + break;
> > + }
> > + }
> > +
> > + return found_plugin;
> > +}
>
> How often are you doing this? Would hash table be prefered? How many
> plugins do you have? Maybe statical registration is right solution?
There would only be half a dozen tops.
Regards,
Nigel
--
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.
Be amazed that people believe it happened.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
