> > 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. > > good idea, I don't know how either though. Seems impossible with the C preprocessor only. We would need something more powerful and flexible such as m4, but I don't think we want to rely on one more tool. The question I ask myself now is: "Why are these macros in the i2c tree while they are used only in the lm_sensors2 tree?" I guess there are historical reasons, and also this helps other people to create i2c clients more easily. But is it worth the dependency problem? We could define these macros on the lm_sensors2 side (if they are not already defined by some older i2c) and remove them from i2c. It doesn't cause any dependency problem for now (until the new i2c code reaches the kernel, but it will take months). And even then, what will it break? i2c clients we don't control, there aren't that many as far as I know. Does it sound OK to you? (I doubt it, but who knows...) > a) the dynamic allocations are isolated to ipmi. Our core code is > stable. new drivers come in all the time, that doesn't make the > existing drivers or core code unstable. Agreed. > b) is my opinion. I know the kernel does it - but do _most_ projects > do it? > If I'm wrong, then let's skip 2.7 and go to 2.8. I can't say if most do or not. Gtk+, Gimp, XMMS, SDL, Galeon do. Some others do, many others don't. And so many never leave the 0.x stage, we can't say ;) Indeed there's no obligation. Probably what matters here is wether i2c and lm_sensors 2.1, 2.3 and 2.5 have been considered unstable or not. If they have been, then 2.7, if it exists, will mean unstable, and we better skip it. If they have not, we are free to decide. Anyway, if we decide to go for 2.7, I want us to explain on the download page that it doesn't have the unstable meaning, just in case people would think it has. -- Jean Delvare http://www.ensicaen.ismra.fr/~delvare/
