Just a note that this is also very important for moving away from i2c-ipmi so the bmcsensors driver can be included in 2.6, so I'll be working with Jean and Mark on this (there is a thread from last week where Jean and I were discussing the problem). Unfortunately "real" work has been keeping me busy since that discussion, but I hope to get around to it this weekend. Jean, in reply to your message last week, separating i2c-ipmi is much easier than the task you have of separating i2c-isa since there is no overlap at all for ipmi as there seems to be for isa accessible chips. When I get home I'll send my preliminary patch for dynamic sysfs callbacks to you and get your opinion on things :-). Thanks, Yani On 4/13/05, Jean Delvare <khali at linux-fr.org> wrote: > > Hi Mark, hi Greg, > > Sorry for joining the thread late. Don't misinterpret this, I am *very* > interested by what Mark proposes. > > Greg, I am working at one end of the problem (making it possible to > separate ISA hardware monitoring drivers from the i2c-core), while Mark > works at the other end (preparing a hwmon class which is independant > from i2c so all hardware monitoring device drivers can use it regardless > of the bus they are connected to). Hopefully we'll meet at some point, > and the job will be done. > > > > Khali is working on patches to get rid of the i2c-isa 'pseudo-adapter'. > > > Since any sensor chip attached to the ISA bus will no longer appear in > > > the /sys/bus/i2c tree, a new way is needed. Userspace tools can be > > > taught to look in /sys/class/hwmon first, and then /sys/bus/i2c for > > > backwards-compatibility. > > > > Ok, that sounds acceptable. > > As Mark underlined, it's not only acceptable. It's needed. Newer > Super-I/O hardware monitoring logical devices just don't fit in the i2c > subsystem (for a reason: they are not I2C devices at all). These drivers > are currently very ugly and their registration is inefficient and > overall broken. > > The key here is that, from the early days, it was assumed that i2c and > hardware monitoring were the same thing. That's simply not true, which > is the reason why I want us to clean up the mess now, and have drivers > really attach to where they belong instead of an arbitrary bus. The > embedded folks will thank us when they won't need to load i2c-core for > their ISA hardware monitoring devices anymore (let alone the shrink in > the size of the drivers themselves). > > That being said, if your "acceptable" means that Mark's approach is > not the prefered way to do it, I'd certainly like to hear about the > proper way. We will change the hardware monitoring device drivers in a > major way, so we better get it right. > > > > > > 1. I don't like "1-0290" for a class ID, but it was the easiest > > > > > thing to use at the time. A better name might be w83627thf-0. > > > > > > > > As long as it's unique, that's the only requirement. > > > > > > I just strlcpy'd the '1-0290' ID from the /sys/bus/i2c tree because it > > > is unique. My concern is that it's not very descriptive. > > > > True, pick something else if you don't like that :) > > Once the ISA hardware monitoring drivers will have moved outside of the > i2c subsystem, their old client ID will make no more sense (the bus > part, that is), and will be changed to something that makes sense for an > ISA device. I don't know how other ISA device drivers do, but using the > base address alone would make sense. This means that 1-0290 would become > 0290. > > The reason why I mention that at this point is that it means that the > various driver types will have different ID schemes, so using the same > ID for the device and for its class sounds dangerous, as we wouldn't be > able to guarantee the uniqueness. (This is all new to me, I didn't know > that class entries needed an ID on their own.) Maybe we can take a look > at what other classes chose as an ID scheme? > > > Ok, if you have _no_ sysfs files, and you have no where anyone else > > could ever grab ahold of a reference to you, then no, you don't need a > > release function. But that's really not how a class_device structure > > should be used. > > How should it be used then? Do you suggest that all sysfs files should be > "physically" moved from the i2c device to the hwmon class? This would > break compatibility with the current user-space stuff :( > > I thought that classes were really only links to where the devices were > in the sysfs tree. Looks like I was wrong. > > Thanks, > -- > Jean Delvare > >
