[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bus_space(9) overrides & resource reservations
> > > If the name troubles you, is bus_space_tag_refine() better?
> > Aren't many other guys confused by the name "create tag"?
> You're asking me? :-)
> I don't know if others are confused by the name.
* Did you explain why do you need these new APIs?
* Did you explain which functions will call your new bus_space_tag_create()?
MI bus driver?
MI device driver?
MD bus driver?
MD bus parent?
MD root device?
* Are you proposing to have multiple (both MI and MD)
"creating tag" functions?
You wrote first
>> > (See atari/dev/if_ne_mb.c for awful examples)
>> You could use bus_space_tag_create() in MD code such as if_ne_mb.c and
>> dev/sbus/stp4020.c, but I don't know if it will be worth it. The code
>> would look more consistent with MI code.
but you also wrote later
>> It sounds like you may be concerned that I intend bus_space_tag_create()
>> to replace comparable MD routines such as bus_space_tag_alloc() on
>> sparc. I do not.
Then I'm really confused.
Martin asked if your new API can replace MD code inside #ifdefs
in stp4020.c to initialize MD bus_space_tag_t internals.
Eduardo concerned that touching MD bus_space_tag_t in MI code
(to "create" tags) could cause serious messes.
* If your new bus_space_tag_create() won't replace MD routines,
how can it co-exist MD routines many ports already have?
bus_space_tag_t prepared in MD routines will also be passed
to whole MI drivers.
* If MD routines will co-exist, which ones should we use in MD drivers?
* If MD routines create MD bus_space_tag_t, why do you have to
allocate memory by kmem(9) for bus_space_tag_t again?
>> +bus_space_tag_create(bus_space_tag_t obst, const uint64_t present,
>> + const struct bus_space_overrides *ov, void *ctx, bus_space_tag_t *bstp)
>> + bst = kmem_alloc(sizeof(struct bus_space_tag), KM_SLEEP);
>> + if (pc == NULL)
>> + return ENOMEM;
>> + bst->bst_super = obst;
Isn't it enough to fill necessary members in passed bus_space_tag_t
in your bus_space_tag_create() because your patch also changes
MD bus_space_tag_t internals and MD routines should allocate
bus_space_tag_t before it passes bus_space_tag_t to children?
In this scope, the name of "create tag" is not acceptable
as I wrote in the first message:
* Do you seriously consider whether you can also apply your API
changes to sparc and all other ports that have more complicated
bus_space_tag_t internal structures?
As I and Eduardo wrote x86's bus_space_tag_t is too simple
to abstruct API. It's hard to review x86's sample code without
examples of usage of new APIs.
Main Index |
Thread Index |