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