tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: General device properties API
> Date: Tue, 17 Aug 2021 13:33:45 -0700
> From: Jason Thorpe <thorpej%me.com@localhost>
>
> 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.
Home |
Main Index |
Thread Index |
Old Index