> Date: Tue, 17 Aug 2021 13:33:45 -0700 > From: Jason Thorpe <thor...@me.com> > > Thanks for the constructive feedback I have received so far! I've > incorporated several suggestions, and have also tweaked a few things > to handle situations I encountered when converting code using > platform-specific functions to the general functions. An updated > diff is here: > > https://www.netbsd.org/~thorpej/device-getprop-diff-v2.txt > > ...and to aid in the discussion around the API, a man page: > > https://www.netbsd.org/~thorpej/device_properties.9
I read the man page, and...I'm more confused now than I was before. 1. Who defines properties? Who is the naming authority that a driver author or auditor consults to determine what the meaning of a property is? Is it NetBSD, or is it vendor-supplied (and, perhaps, -documented) firmware? If you set a property, how do you avoid colliding with existing meaning for the name? How do you audit a driver to determine whether it's making sensible use of the properties? 2. Why is there now a third copy of essentially the same dictionary lookup API, for devhandle_t? When would a driver choose device_* or devhandle_* and why? I'm seeing a lot of new mechanism here but what I really want to see is how this helps writing, maintaining, and auditing device drivers. P.S. I want to get a clearer idea of the higher-level purpose first before going into implementation details, but I also want to put up front that I'm very uncomfortable with the untyped runtime string method name dispatch mechanism of device_call -- and I'd like to see that addressed before we start committing to users of it that make it harder to change.
