Mark Kettenis <mark.kettenis@xs4all.nl> wrote:

> > > ok. how about hanging xcall off an archs cpu device until they're all
> > > implemented, and not providing "xcall.h" so we can't have
> > > #if NXCALL > 0?
> > 
> > or how about a simpler rule: noone can use it, until they're all implemented.
> > that means you don't need the ifdef's.
> 
> We wan't to use this in MD-specific drivers.

tha is not my point.  MI code cannot use this, until all systems have it.

it should not, because otherwise we have more kernel types.  We have non-MP,
then we have MP, then we have MP with xcall internals.

Before long, there will be some artifact of either MP-without-xcall or MP-with-xcall
that people have to keep in mind, and I think this will be a mess.

> With dlg's latest
> proposals, those drivers can pull in the MI code bits by sepcifying
> the xcall as a dependency in the <arch>/conf/files.<arch> file.

I am saying that is a problem.

> Using the code in a few MD-specific drivers will give us confidence
> that we got the interface right before spending a lot of effort to
> implement the MD bits.

I don't believe in that process.  Get the parts everywhere, then start
using it.  And if it is wrong, then we change all the parts on all the
architectures.  It is not going to be discarded.   (It is more likely to
be discarded if it creates problems, such as developers assuming it
either exist, or assuming it does not exist, and making some architectures
unreliable.)  We have ENOUGH deviation between architectures, we don't need
more, hiding behind #ifdef.