Re: DC IDE adapter questions

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

marcus@ wrote:

> David Brownlee <abs%netbsd.org@localhost> writes:
> 
> > Presumably for dcext_bus_mem_init() setting up the bus_space_tag_t -
> > should that be done a different way?
> 
> I'm no bus_space expert, but I'm assuming the correct way to do it is
> to either delegate to the parent bus space, or to copy the accessor
> functions from there.

In MI code, bus_space_tag_t must be opaque and you're correct,
but in MD code it could often have dirty hacks for ugly hardware
implementation.  (see sys/arch/hp300/dev/frodo.c for example)

> Theoretically the IDE adapter could be
> connected to a different bus (bus plumbing is defined in the config
> file, not in the code), or a different implementation of the same bus.
 : 
> Looking at the LAN Adapter driver (which should have similar
> requirements), it seems to use memcpy() to copy the bus_space from
> the attach_args (see mbe_g2_match()).

(BTW if_mbe_g2.c and g2bus_set_bus_mem_sparse() were written
 after I wrote dcext.c)

LAN adapter is directly attached under g2bus so it can call g2bus stuff.
But IDE and NE2000 on dcext are attached under a pseudo child bus
"dcext0 at g2bus" (because dcext bridge needs own initialization),
so it shouldn't be initialized by parent's functions like
g2bus_set_bus_mem_sparse() in g2bus.c.

Of course we can copy bus_space_tag_t for dcext bus from
parent g2bus_attach_args, but strictly speaking memcpy() is not
allowed for "opaque" bus_space types.  It's also ugly
as well as exporting access functions.

Anyway, I object to committing the drivers without working hardware.
We should re-design and discuss driver implementations once after
fixed and working hardware appears.

---
Izumi Tsutsui