On Thursday 2008-11-13 23:18, Adam Nielsen wrote:
>> > +/*
>> > + * Known issues:
>> > + *
>> > + * - It's possible to add multiple led triggers with the same name (as
>> > + * set with --led-trigger-id)
>> > + *
>> > + */
>>
>> So fix this?
>
> I don't know how :-( Since the LED hardware class doesn't (to my knowledge)
> allow you to get a list of available LED triggers on the system,
But it may allow you to *test* the presence using something like
checkentry() {
...
char buf[];
strcpy(buf,"netfilter-");
strcat(buf,name);
if (led_get(buf) != NULL) {
printk(KERN_WARNING "That thing already exists\n");
return false;
}
...
}
No? In that case, you could keep a list of names withint he module itself:
struct name_entry {
struct list_head list;
char *name;
}
struct list_head known_names;
checkentry() {
char buf[];
...
list_for_each_entry(i, known_names, list)
if (strcmp(buf, i->name) == 0) {
printk("that already exists\n");
return false;
}
...
i = kmalloc(*i, GFP_KERNEL);
i->name = strdup(buf);
list_add(&known_names, &i->list);
}
something like that..
> I'd have to
> have some sort of global list that I append to every time a trigger is
> created. Given the likelihood of this happening (and the fact that it mostly
> works having two triggers with the same name, it just looks bad) I didn't
> think it was important enough for the additional code.
I will let others judge that ;-)
> If this functionality is added to the LED class then I will happily update
> my code to make use of it.
Yeah it would be best if the led class provided something. (preferably
a btree/hashlookup)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
