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