Review request -- splitting OF enumeration from nexus

[Marius Strobl]

On Fri, Nov 05, 2010 at 09:02:25AM -0400, John Baldwin wrote:
> On Friday, November 05, 2010 7:07:28 am Marius Strobl wrote:
> > On Sun, Oct 31, 2010 at 03:44:15PM -0500, Nathan Whitehorn wrote:
> > > Nexus on OF platforms doesn't behave like nexus on x86, which generates 
> > > some periodic difficulty with cryptosoft or syscons attaching to all 
> > > devices and taking over the system when someone makes a wrong 
> > > assumption.
> > 
> > I think this is an exaggeration of the problem; the only relevant
> > difference in this regard should be that on x86 there are no
> > (unattached) non-pseudo-devices on the nexus, while on powerpc and
> > sparc64 (apparently this also applies to the embedded architectures
> > though) there are real devices where a buggy pseudo-driver like
> > cryptosoft(4) has a chance to attach to. AFAICT cryptosoft(4) also
> > is the only MI driver suffering from this and can be easily fixed
> > by letting it add its pseudo-device with a specific unit number and
> > return BUS_PROBE_NOWILDCARD. The syscons(4) front-end you are
> > referring to is a powerpc MD part and the sparc64 counterpart never
> > had that problem.
> 
> Actually, I think the fix for cryptosoft is that it doesn't belong in new_bus 
> at all.  It simply needs to supply a kobj that implements the crypto-related 
> methods, but all the new-bus stuff isn't actually needed.
> 

Likely that would be the best fix but AFAICT that unfortunately isn't
exactly straightforward as crypto_get_driverid() and the rest of
crypto(9) apparently inherently expect a valid device_t (probably due
to the fact it was mainly intended for hardware crypto devices). I'm
not sure it's worth fixing that also or do you see a way that gets rid
of the device_t dependency and doesn't break the KPI?

Marius