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