Re: Improving bus/resource API

From: M. Warner Losh (imp_at_bsdimp.com)
Date: 09/20/05

  • Next message: John Baldwin: "Re: Improving bus/resource API" 
    Date: Tue, 20 Sep 2005 13:05:28 -0600 (MDT)
To: dfr@nlsystems.com

    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.

    : > 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).

    Warner
    _______________________________________________
    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: John Baldwin: "Re: Improving bus/resource API"
    • Quantcast