On Fri, Oct 9, 2009 at 05:03, David Woodhouse wrote: > On Fri, 2009-10-09 at 04:56 -0400, Mike Frysinger wrote: >> > Who says that a driver can't have two module_init()? >> >> Mr. C Code says it wont work. > > It could be fixed -- it works when the module is built-in; it could be > made to work in the way way when it's a module. probably, but it opens a fairly large can of worms that until now, no one has really complained as a real problem. if all the module_init functions do not return the same thing (i.e. all pass or all fail), what do you do ? - return an error to userspace an unload module (this happens today) - return an error to userspace but leave module loaded - do not return an error and leave the module loaded if you leave the module partially loaded, how do you know which fini functions to run ? in this case, we have an init/fini func for spi and an init/fini func for i2c. if the spi worked but i2c failed, we obviously dont want to run the fini i2c func with a partially loaded module. today, modules that lack a fini func are not allowed to be unloaded. how do you know in a multi init/fini setup which ones have a corresponding fini ? presumably the answer here would be resolved naturally if the previous question is answered. i also imagine the rest of the module framework in the kernel will need significant changes all over the place to handle an array of init/fini functions. this is a pretty hard sell when the answer could simply be: make more damned modules in your driver. we could have three modules here: ad714x, ad714x-i2c, ad714x-spi. then all of the issues raised by Michael and the things i raise above all magically resolve themselves with the framework we have today. personally, i think catering to this highly unlikely edge case is time that could be spent on other much more realistic cases > How did I get subscribed to this list, anyway? i think i might have accidentally added you to the subscribed list while processing moderation requests when i meant to add you to just the approved list. i'll fix it up of course, sorry about that. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
