Mark M. Hoffman wrote: > Hi Jim: > > * Jim Cromie <jim.cromie at gmail.com> [2006-07-27 16:07:05 -0600]: > >>>> FWIW, device_remove_file() is only called 9 times. >>>> >>>> >> 8 from hwmon/ams.c >> 1 from hwmon/lm70.c >> >> This compares rather sparsely against: >> [jimc at harpo linux-2.6.18-rc2-mm1-sk]$ grep device_create_file >> drivers/hwmon/*.c |wc >> 1027 3046 83340 >> >> Is it truly this optional ? >> > > At present, yes. When the device goes away, the sysfs files go away too. > This will become a problem though when we (eventually) move to persistent > (i2c) devices, so we might as well fix it up now. > > >>>> Ive gone ahead and worked up a patch against pc87360 to >>>> count-errors-and-warn, which should suffice, at least for short term. >>>> >>>> >>> (Hopefully) I'll take a look at this later today. >>> >>> >>> >> dashed-hopes ;-) >> If you'd rather punt, I'll send it on to lkml, but I suppose Id like to >> keep it in-channel. >> > > Someday I will learn to keep my fantasies about free time to myself. ;-) - I now swallow the words "Two Weeks!", and try to answer with a question instead :-) > But > you didn't actually send your patch to the list right (?) At least I can't > find it now that I'm looking again. > > For the patch itself, I used a subject-line I thought more suitable for submission. However, it lost connection to this subject - doh. http://lists.lm-sensors.org/pipermail/lm-sensors/2006-July/016909.html > Anyway... I guess we should stuff all those attributes in a table and run > over them with a for loop. Then if we catch an error, we can run back > through the table in reverse. I mean, what else can we do right? Im not sure what you mean - - we dont *need* device-remove-file, since they 'go away' by themselves (at least for normal rmmods) and work properly when re-modprobed - changing strategy from completely-unchecked to undo-everything-and-bailout is a rather long step, and makes driver possibly unusable in some corner cases (none of which we know and can repeat) - my approach of just counting and warning is 'more legacy' (but warnings may be ignored, whereas a 'broken-driver' will elicit more feedback) IOW - theres a balance to strike here, and Im not sure where (too-clever see-saw analogy elided) Anyway, your forthcoming patches will clarify your sense of the right balance.. > I'll > patch the following to start, all of which I can either test easily or > for which I'm responsible anyway... > > asb100, lm75, lm78, smsc47b397, w83627hf > > Any volunteers for the other 38? > > Regards, > >
