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

On Mon, 28 Nov 2011 20:25:31 +0100, Axel Dörfler wrote:
On 28.11.2011 16:35, Alexander von Gluck wrote:
[...]

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;
[...]

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.

Ahhh..  I understand now.

Yeah, that goes way beyond my abilities. :)

A side node.. if you enable single window navigation in tracker and manually navigate to /dev, things get pretty weird pretty quick. (possibly related to
Tracker -> devfs access issues)

 * no title in title bar
 * devfs nodes don't show up but folders do
 * you can create a new folder, but can't rename it from 'new folder'
* you can't delete your new folder. (even from the terminal) as the devfs is read only)


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).

Yup. After you mentioned this I some digging and stumbled across device_attr. This kernel device_manager isn't used by much though. (mostly disk and acpi drivers)

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.

Good points. I would hate letting each driver decide as that would make things pretty inconsistent however. An array of generic name : value structs may work.. but the name field wouldn't be standardized and may cause issues as well.

I guess this is starting to creep beyond me, still just looking for somewhere to put thermal data that could be added across all of the graphic drivers and accessed by
user space :)

 -- Alex

Other related posts: