(Resending.) > > I don't know about the adm1021 module. What would it cost not to use > > the SENSORS_INSMOD_8 thing? > It was added for mc1066 support in adm1021. The only way around it > is to combine support for some of the 8 different chips and report > only 7 different chip types max. OK I get it. This workaround isn't acceptable IMHO (makes things more complex to understand with no benefit except the dependency issue). The fact that you need to have one macro for each possible number of chips associated with one driver is weird. What if there's another chip supported by adm1021? And then another again? We break the dependencies each time. Could we find some cleaner method? I have no idea for now, but there's a need. > > Does 2.7.0 mean "developement/unstable tree" for you? I think it > > will sound like that for almost everyone, including me. And if this > > means less support issues, it also means less feedback IMHO, so it's > > worth discussing. > Doesn't mean unstable to me. We don't use the odd/even system, we've > been stable for years :) Well, the SENSORS_INSMOD_42 issue together with the need for dynamic allocations for bmcsensors makes me think that we could want a 2.7.0 release, with the unstable meaning associated. Try to move back to cleaner code (I read that there are a lot of hacks in the recent code you commited, right?), even if it means a one-on-one dependency between i2c and lm_sensors releases for some time. When we're OK, we move to 2.8.0. Simple suggestion of course, my knowledge of the code and possibilities to enhance it is really thin. If there is no way to clean the code or you don't think we (globally) have the time/manpower required to do so, we keep the things the way they are. -- Jean Delvare http://www.ensicaen.ismra.fr/~delvare/
