Query on apparently 'disconnected' sysfs interfaces

Mark M. Hoffman mhoffman at lightlink.com
Fri Mar 18 06:25:39 CET 2005


Hi Grant:

* Grant Coady <grant_nospam at dodo.com.au> [2005-03-18 11:35:40 +1100]:

(...)

> Problem: There are many examples of disconnected code fragments 
> in the sysfs interface area.
> 
> Possibilities?  I'm missing an obscure indirection, cruft in code, 
> something else I've not yet thought of.  Also, I'm no preprocessor 
> expert, still picking up what the macros are doing from context. 

The preprocessor macros are the keys to understanding these drivers.

> Given (## = my thoughts) so few drivers are inconsistent, here's 
> one example:

That (## = my thoughts) is a little ironic, you will see...

(...)

> ## more attributes defined but not used?
> drivers/i2c/chips/lm83.c:static DEVICE_ATTR(temp1_input, S_IRUGO, show_temp_input1, NULL);
> drivers/i2c/chips/lm83.c:static DEVICE_ATTR(temp2_input, S_IRUGO, show_temp_input2, NULL);
> drivers/i2c/chips/lm83.c:static DEVICE_ATTR(temp3_input, S_IRUGO, show_temp_input3, NULL);
> drivers/i2c/chips/lm83.c:static DEVICE_ATTR(temp4_input, S_IRUGO, show_temp_input4, NULL);

E.g. with lm83, take a look at this part (to which I added two comments):

	#define show_temp(suffix, value) \
	static ssize_t show_temp_##suffix(struct device *dev, char *buf) \
	{ \
        	struct lm83_data *data = lm83_update_device(dev); \
        	return sprintf(buf, "%d\n", TEMP_FROM_REG(data->value)); \
	}
	show_temp(input1, temp_input[0]); /* defines show_temp_input1() */
	show_temp(input2, temp_input[1]); /* defines show_temp_input2() */
	/* ... */

Each show_temp() defines an entire (small) function.  The preprocessor
operator ## is used to tack the literal text "input1" onto "show_temp_"
to form a single token.  See page 90 of K&R/C.

> My problem at this point is seeing how the driver interfaces to 
> sysfs -- finding many exceptions to the 'norm', thus now it seems 
> I must find what the non-documented 'norm' actually is, before 
> bothering writing to an indeterminate (in my mind) interface.

Functions like the above show_temp_input1() are registered to sysfs and
are invoked whenever the sysfs file is read or written.  They are
registered by calling device_create_file().

> Is it worth documenting inconsistencies while I try to fathom 
> current practice vs documentation?

The existing documentation is a guideline for how to name the sysfs files;
it doesn't really specify how to code it.  In practice, the macro-fu just
reduces the line count for all those little functions.

> Are there tools written to perform this or similar checking?
> I'd really dislike re-inventing this stuff.  

I'm not sure what you mean here.  What checking?

> Another thing I tried was diff'ing -mm4 against -ac4, showed 
> where many obvious improvements have been made in -mm4 tree.
> Then I got side-tracked back into my current problem space, 
> sysfs interface seems not fully documented and/or me confused.  

Greg KH's i2c/sensors tree gets picked up by -mm long before those 
patches hit -ac.  I.e. what you saw is expected.

I hope this helps; regards,

-- 
Mark M. Hoffman
mhoffman at lightlink.com



More information about the lm-sensors mailing list