Re: bus_space(9) overrides & resource reservations

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

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

Yes.

> 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

http://mail-index.NetBSD.org/tech-kern/2010/05/27/msg008243.html
>> > (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

http://mail-index.netbsd.org/tech-kern/2010/05/27/msg008256.html
>> 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:
   http://mail-index.NetBSD.org/tech-kern/2010/05/27/msg008240.html

 * 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.

---
Izumi Tsutsui