> Date: Fri, 13 Aug 2021 19:10:20 -0700 > From: Jason Thorpe <thor...@me.com> > > 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?