Date: Fri, 5 Nov 2010 15:43:37 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-ppc@freebsd.org, freebsd-sparc64@freebsd.org Subject: Re: Review request -- splitting OF enumeration from nexus Message-ID: <20101105144337.GE5289@alchemy.franken.de> In-Reply-To: <201011050902.25879.jhb@freebsd.org> References: <4CCDD51F.2040003@freebsd.org> <20101105110728.GA65518@alchemy.franken.de> <201011050902.25879.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101105144337.GE5289>