From owner-freebsd-arch@FreeBSD.ORG Wed Sep 9 17:16:35 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3744106566C; Wed, 9 Sep 2009 17:16:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C364A8FC0C; Wed, 9 Sep 2009 17:16:34 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7635C46B06; Wed, 9 Sep 2009 13:16:34 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id A77028A01F; Wed, 9 Sep 2009 13:16:33 -0400 (EDT) From: John Baldwin To: Attilio Rao Date: Wed, 9 Sep 2009 13:16:27 -0400 User-Agent: KMail/1.9.7 References: <200909031340.n83Defkv034013@svn.freebsd.org> <200909080936.37603.jhb@freebsd.org> <3bbf2fe10909090239r519ae737t56ddd7ca36e5f84d@mail.gmail.com> In-Reply-To: <3bbf2fe10909090239r519ae737t56ddd7ca36e5f84d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909091316.28063.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 09 Sep 2009 13:16:33 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: NEWBUS states (was Re: svn commit: r196779 - in head/sys: kern sys) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 17:16:35 -0000 On Wednesday 09 September 2009 5:39:39 am Attilio Rao wrote: > 2009/9/8 John Baldwin : > > On Friday 04 September 2009 6:46:03 pm Attilio Rao wrote: > >> We all agreed the one-state was the better option but it can't be done > >> in this way because of the device_is_attached() used in the detach > >> virtual functions. Using just one transition state will break > >> device_is_attached() in those parts. > >> The right fix, as pointed out in other e-mails, is to not use > >> device_is_attached() in detach virtual functions. The better fix, in > >> my idea would involve: > >> - replace the device_is_attached() usage in detach virtual functions, > >> with a more functional support > >> - use one-state transition > >> > >> But that is just too much job to push in before then 8.0-REL and if > >> that would mean to not commit a patch and make impossible a future > >> MFC, I prefer to go with a lesser-perfect-but-still-working-approach. > > > > Wait, all you need to MFC is the change to the enum. Fixing the various > > detach routines does _not_ have to be in 8.0. That could be merged after the > > release. > > That's not what I mean. > What I mean is that in order to have a perfect job right now (and have > single-state transition usable *right now* by both STABLE_8 and HEAD) > that what should happen, which is impractical. > I was just explaining to Warner why we didn't go with the single-state > in the end. But we don't need it usable right now. All you need for 8.0 is to reserve the slot in the enum so that the ABI of the enum values doesn't change. Making the state usable is something that can happen after the release and it can include all the changes to make the single state usable. -- John Baldwin