On Thu, 2 Apr 1998 11:28:33 GMT, christos@zoulas.com (Christos Zoulas)
writes:

> This can be fixed with a couple of ifdefs no?

Jason hates ifdef with a passion.  In this case a couple of ifdefs is
a far lesser sin than duplicating an entire driver.  I hate
duplicating drivers even more than Jason hates ifdefs. 

Some Alpha models need different modem setup (the Flamingo leaves the
modem leads floating, right?). So the Alpha already needs some runtime
dispatch.  The only conflict is really between different CPU-type (or
system-type) namespaces.


If Jason insists on being absolutely squeaky-clean, we can:

	a) add a set of flags to the generic "zs at ioasic" code,
	   specifying the relevant behaviour for modem control
	   leads and setup (modem leads crossed vs floating;
	   both channels wired up, vs. just one.)

	b) add a set of model-specific cfdriver front-ends. These
	   are just wrappers. The match routines accept or reject
	   based o CPU model.  The attachroutines  just  call a common,
	   shared, ifdef-less driver with the appropriate flag values
	   for the  model(s) they match.

The variants in (b) could even be shared.  With an ifdef.  Which IMHO,
in this context, is an acceptable ifdef.  (Or it could be done as a
feature-test macro in an MD header file).

I think any way you look at this, duplicating the entire driver for
identical chips, hanging off an identical bus chip. just to get around
a couple of setup-time differences that could trivially be papered
over with a couple of ifdefs, says that something is unwell here.