Re: [QUESTION/sysfs] strange refcounting

[Artem B. Bityutskiy]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/