Re: General device properties API

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Fri, 13 Aug 2021 19:10:20 -0700
> From: Jason Thorpe <thorpej%me.com@localhost>
> 
> Over the last year or so, I've been playing around with ideas for a
> generic device properties API, and have been slowly adding some
> infrastructure to the kernel to enable it.  Enough of the
> infrastructure is now in place (or in the pipeline) and I think my
> design is now fully-formed enough in my head to float it here.

This is a little abstract to follow just from the types.  Can you show
examples of:

- code scattered around to reflect device tree properties?
- duplicated-and-tweaked code?
- reducing boilerplate in drivers?

Can you give a little more detail about: what information needs to be
encoded in a driver?  For example, if an ethernet device needs to get
its mac address from an OF/FDT property called mumblefrotz,mac-addr or
an ACPI method called _MAC, do we write code that looks like
device_hasprop(dh, "mumblefrotz,mac-addr"), device_hasprop(dh,
"_MAC"); or do we put those in separate mumblefrotz_fdt.c and
mumblefrotz_acpi.c bus attachments and pass it through
mumblefrotz_attach_args, or what?  Or am I barking up the wrong tree
about what this API is supposed to be used for?

> The interface to the device tree's properties (called the "backing
> store" in the code) is done using the devhandle / device_call()
> infrastructure I added earlier.  Device tree back-ends register a
> set of methods that provide the property access interface, and those
> methods are looked up based on the device's devhandle implementation
> (ACPI and FDT/OFW handles can co-exist in the same system, for
> example, and the code supports this).

Why do we pass untyped strings around with this device_call mechanism?
Was there any discussion about this beforehand?  Had I known it was
proposed I would have objected to an untyped string method calling
mechanism -- surely we can do better to detect typos and type errors
at compile-time.

> The backing store is consulted if a requested property is not found
> in the device's properties dictionary.  Clients should use the
> correctly-typed API calls to interact with properties, as the
> dictionary and some backing stores can / do have typing systems
> (e.g. ACPI), although some (notably the OpenBoot / OpenFirmware /
> FDT types) do not.  This places some limitations on how clients can
> interact with properties, but if all the clients follow the typing
> rules, then things should mostly work out OK.

How do clients know they are following the typing rules?  Does the
compiler provide any way to detect errors, or can that be detected
only at run-time depending on what OF/FDT/ACPI data the firmware
provides?

> Anyway, the API: [...]

What's the advantage of creating a new API with many of essentially
the same functions prop_* (prop_dictionary_get_string, &c.), vs just
mapping the entire tree recursively into a proplib dictionary and
having drivers use the existing prop_* API to query it?