hey folks,
Having hacked a bit on drivers/hwmon/pc87360,
it has occurred to me that struct sensor_device_attribute
(ie the *_attributes it contains) carry a lot of redundant
info that could be hoisted into a (more) common location.
discussing it backwards somehow seems easier:
1. reduce sensor_device_attribute to a single integer.
2. partition that integer similar to MAJOR/MINOR for device files.
forex: MAJOR/UNIT_TYPE/UNIT_NUMBER
unit-type would distinguish between in, fan, pwm, pwm_enable, etc...
unit-number selects 0 .. N. Nothing here prevents driver writer
from mapping his own hierarchy into this partitioning.
3. driver modules would register show/set handlers for each unit-type.
registration can be static - as currently - using macros to reserve
numbers
When a user does, forex:
cat /sys/bus/i2c/devices/9191-6620/in0_input
a reformulated sysfs could:
4. inode_operations.lookup() to get the parent directory,
5. find the device and data via the kobject / driver pointer
6. dispatch thru sysfs_ops to invoke the right show/set handlers
dispatch decisions are determined using UNIT_TYPE info obtained in 3.
7. show/set handlers decode UNIT_NUMBER using macros
the MAJOR is virtual in a sense - each driver gets the whole
range of 2**32, since step 4 finds the kobject / driver without it.
OTOH, inode #s must be unique in a filesystem, and this proposal
may be reducing sensor-device-attribute to an inode number.
If so, this is a complicating factor, since we want static assignments.
Still, 2**32 is a lot of sysfs attributes, and a scheme something
like CIDR & 192.168.1.0/24 would probably be workable
I've no doubt glossed over vast swaths of functionality and complexity
(all those parts I dont understand), but since this is the newbies list,
I figure not knowing isnt a crime, and some speculation is tolerated.
see also: http://lwn.net/Articles/161236/
Im cautiously optimistic that the fatal flaws in the above strawman will be
seen and set ablaze in a manner that creates useful illumination. ;-)
tia
jimc
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
