[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: DC IDE adapter questions
> 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.
Main Index |
Thread Index |