Re: Improving bus/resource API

From: John Baldwin (jhb_at_FreeBSD.org)
Date: 09/20/05

  • Next message: Brooks Davis: "Re: [CFR] reflect resolv.conf update to running application" 
    To: "M. Warner Losh" <imp@bsdimp.com>
Date: Tue, 20 Sep 2005 16:08:35 -0400

    On Tuesday 20 September 2005 03:05 pm, M. Warner Losh wrote:
    > In message: <76404F68-547C-42E2-A3A9-BD0AF2ECFADF@nlsystems.com>
    >
    > Doug Rabson <dfr@nlsystems.com> writes:
    > : > Maybe bus_read_{1,2,4}() rather than bsr_? (Same with s/bsw_/
    > : > bus_write_/). I
    > : > do like having the accessors take just a resource rather than a
    > : > tag, handle
    > : > pair. Many drivers already hide this in wrapper macros already
    > : > though.
    >
    > Are we going to extend this to all the other things that bus space can
    > do?
    > http://people.freebsd.org/~imp/bus_space.html
    >
    > While many of these are less common than the familiar
    > bus_space_{read,write}, we should consider them as part of the updated
    > API.
    >
    > bs vs bus_ vs ???. These are really bus space + resource macros. So
    > maybe we want some other prefix...
    >
    > The whole point of the bsr vs bus_space_read was to make things much
    > shorter. bus_read/write does that, but to a more limited extent.
    > Still, saving 6 characters per function call, plus one argument will
    > help a lot.

    I think maybe just do 's/bus_space_/bus_/' on the current names, which gives
    the simple bus_read/bus_write for the common case. I think that along with
    reducing the first two args down to one that should make things shorter
    without making it cryptic. (I think bsrm_4() would be cryptic compared to
    bus_read_multi_4().)

    > : > For the dwiw (dwim? :-P) maybe since it takes an array, just make the
    > : > 'resource' part plural, thus 'bus_alloc_resources()' and
    > : > 'bus_release_resources()'?
    > :
    > : I like these names.
    >
    > That would settle the whole dwim vs dwiw arguement :-). I like it.
    >
    > Oh, I found another bug: There are no man pages. This is the only
    > fatal problem. There's still no man page, for example, for the d_*_t
    > functions, nor the cdevsw in general (other than really crunch ones).

    Now now, it's just a proposal at this stage. :) 

    -- 
John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: Brooks Davis: "Re: [CFR] reflect resolv.conf update to running application"

    Relevant Pages

    • Re: about che
      ... other hand you show and extremely poor discernment on the human ... condition.Castro (and I extend this observation to any and all ... Germans risked their very lives to cross to the other side.Nobody that ... their common good instead of fighting each other and trying to succeed ...
      (soc.culture.cuba)
    • Re: about che
      ... other hand you show and extremely poor discernment on the human ... condition.Castro (and I extend this observation to any and all ... Germans risked their very lives to cross to the other side.Nobody that ... their common good instead of fighting each other and trying to succeed ...
      (soc.culture.cuba)
    • Re: about che
      ... other hand you show and extremely poor discernment on the human ... condition.Castro (and I extend this observation to any and all ... Germans risked their very lives to cross to the other side.Nobody that ... their common good instead of fighting each other and trying to succeed ...
      (soc.culture.cuba)
    • Re: adding of signature/disclaimer to every email leaving exchange
      ... This used to be a simple registry entry with a supporting DLL to extend the ... Internet Mail Service, why has Microsoft made this common and simple function ...
      (microsoft.public.exchange.admin)