Messages in this thread | | | Date | Mon, 06 Feb 2006 12:58:00 +0300 | From | "Artem B. Bityutskiy" <> | Subject | Re: [QUESTION/sysfs] strange refcounting |
| |
As &struct device structure has no @owner field, and corresponding functions rely on the @owner field at &struct device_driver, I conclude that I cannot use &struct device objects without bus and device driver objects, just by design.
On the other hand, 'device_register()' accepts &struct device objects with NULL-filled @bus and @driver fields perfectly fine, does not complain, does not return any error, and I even see corresponding entries at /sys/devices/. But there is a refcounting problem described at my first mail.
This is obviously a confusing discrepancy. Sysfs has to either reject bus-less and driver-less &struct device objects or deal with them correctly. The latter is impossible due to lack of an @owner field in &struct device.
In connection with this, I have a question. There is a whole bunch of drivers which do not directly relate to hardware devices, but which still want to expose their parameters via sysfs. For example, this could be a filesystem, LVM, a compression layer on top of a file system of a block device, whatever. These are "virtual" devices and they are not physically connected to any bus. How should they deal with sysfs?
I see there is the "class" stuff in sysfs, but it seems that it is far not as flexible as the "device, driver, and bus" stuff, because I cannot create many nested layers within classes. I can create a class, which goes to /sys/class/, and devices within this class, which go to /sys/class/myclass/mydev/. But I cannot create a class, devices within that class, and daughter devices within them, like:
/sys/class/myclass/ |-- mydev1/ | -- doughterdev1/ | -- doughterdev1/ | -- ... |-- mydev2/ |-- mydev3/ |-- ...
Please, comment this.
Thanks.
-- Best Regards, Artem B. Bityutskiy, St.-Petersburg, Russia. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |