From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 13 17:56:59 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B48651065673; Fri, 13 Jul 2012 17:56:59 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 19B6F8FC14; Fri, 13 Jul 2012 17:56:58 +0000 (UTC) Received: by weyx56 with SMTP id x56so3552896wey.13 for ; Fri, 13 Jul 2012 10:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6ni6wES3hVOMhStcZoBcASbqzS5yXiXojkyav9c/BjY=; b=Gym12y7kMzTE6ihNNtGei0GwVJIs5U8ebe1IJ9FGYfb+De9FgJR/BGVwKveD34q2OC xshl0SfRuLwonxFr8PlNagrp3xXk/QM5lJlv2XxC0PWk95508BhqMnCQyUJNIiAoUYiy MaLd2dbPg1ejfDCuqXpvAAiQ5BvGebNiSNSl1gsxL1oXTHvy08bwDajGlodor8Wpn0Vk vRGGj7HCL3oiRBE5hfQfYNvTgfKLL0zdTVT1rIoFAYjh95B0KnsjGgybIwBMk9I0I5Yk KF2wCcwILbO6M4qtNpzej0rkYEJTh9R2BibhEMBGErbk7kxU+t+cinhFfAGQE1Y+5oMb p5Dw== MIME-Version: 1.0 Received: by 10.180.102.136 with SMTP id fo8mr4440898wib.19.1342202218019; Fri, 13 Jul 2012 10:56:58 -0700 (PDT) Received: by 10.216.23.200 with HTTP; Fri, 13 Jul 2012 10:56:57 -0700 (PDT) In-Reply-To: <73F3FBC9-337C-4F61-9470-5173D6DAE56B@bsdimp.com> References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> <5C18109D-E7A8-4868-BEA9-26B63360BB24@bsdimp.com> <8048FFC5-6952-49FC-849D-EA1A5675ACBE@bsdimp.com> <73F3FBC9-337C-4F61-9470-5173D6DAE56B@bsdimp.com> Date: Fri, 13 Jul 2012 13:56:57 -0400 Message-ID: From: Arnaud Lacombe To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 17:56:59 -0000 Hi, On Thu, Jul 12, 2012 at 1:20 AM, Warner Losh wrote: > [..] > Honestly, though, I think you'll be more pissed when you find out that the N:1 interface that you want is being done in the wrong domain. But I've been wrong before and look forward to seeing your replacement. > I will just pass function pointers for now, if things should be done dirty, let's be explicit about it. Now, the hinted device attachment did work quite smoothly, however, I would have a few suggestion: 1) add a call to bus_enumerate_hinted_children() before the call DEVICE_IDENTIFY() call in bus_generic_driver_added() this is required to be able to support dynamic loading and attachment of hinted children. 2) have a generic bus_hinted_child method which would just add a new child to the bus. 3) have bus_enumerate_hinted_children() and bus_generic_attach() always ran on device attachment. There is current +100 explicit call to bus_generic_attach() in the sys/dev/ tree. This should be done always and implicitly. 4) have bus_generic_detach() always ran prior to device detachment If not already the case. There is still the same +100 direct call to bus_generic_detach is the tree. 5) have the bus_generic_* method be the default of their respective method 6) have device_delete_child() called upon device detachment. As a rule of thumb, when a kld is unloaded there should not be any remains of anything built previously. Without device_delete_child() or proper singleton implementation, multiple load/unload sequence of bus will attempt to attach multiple version of a child, even if the single child was added prior to the bus_generic_attach() call. Also, as a rule of thumb, if the same logic is implemented in more than a few buses, it should be made generic and implicit. I am lazy, I hate doing the same things over and over, not to say it raised the likelihood of bugs' introduction... - Arnaud