On Fri, 4 Sep 1998, Harald Koerfgen wrote:
> We now have serial consoles running on DZ based as well as Z8530 based
> DECstations and I'd like to kick out the PROM console for various reasons.
I think its probably valuable to hold on the PROM console routines
In terms of this "undefined" behavior - Really we should have some
that has the logic something like:
1. Does my machine have TC interface and the option --->
ok, then use the TC driver - bind serial_console_init.
2. Does my machine have DZ interface && and the option --->
ok, then use the DZ driver - bind serial_console_init.
Otherwise
3. use the promcon stuff.
The problem I ran into when I was working on this was a name collision
on serial_console_init - I never really found where this was "bound"
-Tom
>
> Opinions?
>
> Another question: The way Olivier and Thomas have implemented the DZ driver
> would lead to undefined results when activating TURBOchannel and DZ support.
> Do
> we really want generic kernels?
>
I think we do want generic kernels - but at the time that I was working
through this I was having a very hard time making this happen.
-Tom
> I can think of a file dec_sercons.c with, for example:
>
> --- example ---
>
> #include <asm/dec/tc.h>
> [...]
>
> extern ...; [a whole lotta external declarations]
>
> #ifdef CONFIC_TC
> static struct console dz_sercons = {
> [...]
> }
> #endif
>
> #ifdef CONFIG_DZ
> static struct console zs_sercons = {
> [...]
> }
> #endif
>
> __initfunc(long serial_console_setup((long kmem_start, long kmem_end))
> {
> #if defined(CONFIG_DZ) && defined(CONFIG_TC)
> if (IOASIC)
> register_console(&zs_sercons);
> else
> register_console(&dz_sercons);
> #else
>
> #ifdef CONFIG_DZ
> register_console(&dz_sercons);
> #endif
>
> #ifdef CONFIG_TC
> register_console(&zs_sercons);
> #endif
>
> #endif /* CONFIG_DZ && CONFIG_TC */
>
> return kmem_start;
> }
>
> --- end example ---
>
> but we could run into similar "complications" in other device drivers.
>
> What do you think?
> ---
> Regards,
> Harald
>
|