From owner-freebsd-sparc64@FreeBSD.ORG Fri Nov 5 14:43:39 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8BF0106566C; Fri, 5 Nov 2010 14:43:39 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 36EC68FC12; Fri, 5 Nov 2010 14:43:38 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id oA5Ehb36067039; Fri, 5 Nov 2010 15:43:37 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id oA5EhbUm067038; Fri, 5 Nov 2010 15:43:37 +0100 (CET) (envelope-from marius) Date: Fri, 5 Nov 2010 15:43:37 +0100 From: Marius Strobl To: John Baldwin Message-ID: <20101105144337.GE5289@alchemy.franken.de> References: <4CCDD51F.2040003@freebsd.org> <20101105110728.GA65518@alchemy.franken.de> <201011050902.25879.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201011050902.25879.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-ppc@freebsd.org, freebsd-sparc64@freebsd.org Subject: Re: Review request -- splitting OF enumeration from nexus X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 14:43:39 -0000 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