On Fri 09 Jan 1998, Julian Coleman wrote:
> Leo Weppelman wrote:
> > Julians question basically boils down to:
> >     How do I obtain the (opaque!) tags in the console probe when
> >     the bus is not yet probed.
> 
> Ah, but I didn't put it that succinctly! :)

I'm completely missing the point here :-( My dictionary is still in a box
somewhere, so would you please expain 'succinctly'?

 [ .... ]
> > I was thinking to define an 'early_<bus>_scan()' function. As an
> > argument, it should get a probe function. The 'early_<bus>_scan'
> > function calls the probe function with a '<bus>_attach_args' argument.
> 
> Yes, this looks nice.  I notice that other drivers have a ...match() and
> a ...attach() routine.  Does it make sense to have match() and attach()
> routines, rather than a probe() routine?  That way, the driver code could
> be the same as those for the 'normal' bus scans.  For example, if I wanted
> my VME card as console, I just define it in the kernel config, otherwise
> I get a TT video console and the VME card found later (and grf attached).
> One snag is that you have more parameters to worry about.

I thought among these lines first too, but where do we get the
'struct device' and 'struct cfdata' arguments from? I think this makes
it difficult to (ab)use the match entry point.
A lot of drivers have a function that tries to identify the device. The
match function does some administrativia and calls this function. I
envisioned the aforementioned probe() function to do something like
that - a wrapper. Maybe the name 'probe' is a bad choise...

> Anyway, I shall go back to separating the functionality.  With any luck,
> I'll have time this weekend and be able to look at the X server too.

I wish you luck and time ;-)

Leo.