No, this is not how to handle this. Saving persistent data in the kernel is a
inherently broken idea - it should be done by "insmod" instead, and it should
save the data in the filesystem. That way it will survive across a re-boot if
the user so wishes etc etc. It's also the "right" way to do it anyway, because
there simply is no sense in saving the data in the kernel when you can do it in
user level.
Obviously "insmod" knows only about user-supplied parameters, and won't be able
to save state that the driver itself has auto-detected etc, but that's a
feature, not a bug. If it's been autodetected once, it's better to let it be
autodetected in the future too..
I saw some patyches that did a "vmalloc()" and saved state in a kernel virtual
area over multiple "insmod"s, and I sincerely hope I will never have to see
that kind of thing ever again in my life. Ugh..
I don't know if insmod already handles things like this, but essentially it
needs to do "pre-insmod" and "post-insmod" things anyway, where the
"pre-insmod" thing can be looking up what addresses it should use (PnP, saved
state, whatever), and "post-insmod" is things like setting up /dev and maybe
adding routes for the new network interface it just inserted or whatever..
The kernel should not have to know about these things - it just inserts the
damn thing, and policy decisions HAVE to be made in user space.
Linus