Hi Kay, On Thu, 23 Jul 2009 17:19:22 +0200, Kay Sievers wrote: > On Thu, Jul 23, 2009 at 16:02, Jean Delvare<khali@xxxxxxxxxxxx> wrote: > > I don't think you need the "return" here, as sysfs_remove_link returns > > void. > > Fixed. Thanks. What's the merge timeline for this patch? > > Other than that (and in practice even with that) your patch works just > > fine for me. Thanks! Unfortunately it doesn't provide perfect > > compatibility, [...] to add this device link (pointing to "..") temporarily > > or would that be too confusing? > > I think that's ok, if it solves a real problem. The entire idea of _a_ > "device" link is pretty flawed, and the reason we ripped all the > "struct class_device" devices out. OK, I've added the "device" link and now compatibility works perfectly. I'll post the updated patch series soon, if you want to take a look. Would it make sense to move the "device" link creation into class_compat_create_link()? I suspect other users of a compatibility class may need it as well. > > Another thing we have to discuss is the compatibility option. For now > > I've made it i2c-specific and enabled by default: > > > > config I2C_COMPAT > > boolean "Enable compatibility bits for old user-space" > > default y > > help > > Say Y here if you intend to run lm-sensors 3.1.1 or older. > > > > But this means a lot of ifdefs in my code (6). With a system-wide > > option, we could provide empty stubs I could get rid of them. OTOH, It > > is easier to control the lifetime, and change the default value, of a > > subsystem specific option. So I'm not too sure what do to. > > I'm not sure too. I think it's fine to have it per-subsytem, as only > the subsystem knows for how long it is needed, and it can probably be > dropped some day. OK, fine with me. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
