[haiku-development] Re: RFC: Public header change os/device/graphic_driver.h (was RFC: Thermal sensors in /dev/)

On 28.11.2011 16:35, Alexander von Gluck wrote:

The proposed Haiku device attribute API could work by introducing a new
potential IO control on devfs nodes (allowing the pre-existing
not-supported returns on devfs nodes that wouldn't contain attribute
information, or devfs nodes it wouldn't make sense for)

Making a B_DEVICE_ATTRIBUTE IO control call would result in a struct
containing device attribute data.

Potential struct result layout:

typedef struct {
driver_path path;
driver_path parentPath;
uint32 type = B_CPU / MEMORY / DISK / BUS… not sure on categories yet
char name[256];
char serial[256];
uint32 sensorCount = 3;
sensor_data sensors[3];
} device_attributes;
I think you misunderstood me a bit: when I say attributes, I actually mean attributes. Like those you see in Tracker, just on a device. So a temperature would likely just be a string attribute, although we could introduce a type for storing temperatures as well if we wanted to.
This would allow nice things like querying devfs for a printer with a specific serial number (or model), so you no longer need to know where a printer is attached to, as that is likely to vary with USB, anyway. 


Questions:
new os/device/attribute.h public header included from DeviceKit.h?
B_DEVICE_ATTRIBUTE define in drivers/Drivers.h ?
What value should B_DEVICE_ATTRIBUTE be?
How would this tie into acpi data? Maybe later we can have a driver to
convert acpi devices into cpu, etc nodes that would have sensor data
attached?
Device nodes already have attributes, just that they aren't Tracker visible (nor are they intended to). We could either introduce special hooks to access the attributes of a device (as in devfs), or let devfs publish them based in some ioctls -- which would have the advantage that it would be a feature accessible to old style drivers as well. But there shouldn't be a fixed structure exporting everything, as that is not exactly flexible, and a graphics driver might want to export the size of its memory, while a SATA controller might want to export the bus speed. 


All this would make the Device Application a lot more useful :P


Sure, but that's really the least of my worries ;-)

Bye,
   Axel.

Other related posts: