From owner-freebsd-current@FreeBSD.ORG Mon Oct 1 20:31:55 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82B1616A418 for ; Mon, 1 Oct 2007 20:31:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 4134D13C4B5 for ; Mon, 1 Oct 2007 20:31:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8p) with ESMTP id 212389738-1834499 for multiple; Mon, 01 Oct 2007 16:14:15 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l91KE5aa094076; Mon, 1 Oct 2007 16:14:08 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Marius Strobl Date: Mon, 1 Oct 2007 14:20:30 -0400 User-Agent: KMail/1.9.6 References: <20070930114914.GB38896@alchemy.franken.de> <4700ECC8.4090702@FreeBSD.org> <20071001132548.GE55741@alchemy.franken.de> In-Reply-To: <20071001132548.GE55741@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710011420.31077.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 01 Oct 2007 16:14:08 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/4445/Mon Oct 1 04:32:46 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-3.5 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00, SUBJECT_ENCODED_TWICE,SUBJECT_EXCESS_QP autolearn=no version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Michael Butler , Marcel Moolenaar , current@freebsd.org Subject: Re: Proposal to revise the new parsing of PCI selectors (was: Re: HEADS UP: [cvs commit: src UPDATING src/share/man/man4 pci.4 src/share/man/man9 pci.9 src/sys/amd64/include legacyvar.h src/sys/amd64/amd64 legacy.c src/sys/amd64/pci pci_bus.c src/sys/arm/xscale/i80321 i80321_pci.c src/sys/arm/xscale/ixp425 ...) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 20:31:55 -0000 On Monday 01 October 2007 09:25:48 am Marius Strobl wrote: > On Mon, Oct 01, 2007 at 02:49:12PM +0200, Stefan Esser wrote: > > Marius Strobl wrote: > > > On Sun, Sep 30, 2007 at 03:34:57PM -0700, Marcel Moolenaar wrote: > > >> On Sep 30, 2007, at 3:17 PM, Marius Strobl wrote: > > >> > > >>>> Where it would previously succeed, I now get .. > > >>>> > > >>>> toshi# pciconf -wb pci0:30:0 0x1a 8 > > >>>> pciconf: ioctl(PCIOCWRITE): Operation not supported by device > > >>>> > > >>> As mentioned the format of the location strings has changed, > > >>> you probably need to use pci0:0:30:0. > > >> If compatibility is a concern, we may be able to make the parsing > > >> a bit more smart without too much complexity. We can count the > > >> number of colons for exampl,e and assume missing elements are 0. > > >> So, if one enters pci1:2:3, the domain will be 0. If one enters > > >> pci4:5, both the domain and bus will be 0, etc. > > >> > > >> Just a thought... > > >> > > > > > > Unfortunately, for pciconf(8) the function is already optional > > > so pci1:2:3 would be ambiguous. > > > > > > Well, since it was me who chose to parse it that way, when pciconf > > saw the light of day, I can say that the logical extension appears > > to be the support of 3 formats for the PCI device selector: > > > > pci1:2:3:4 (full, domain/bus/slot/function, required if domain!=0) > > pci2:3:4 (abridged, in case the domain is "0") > > pci2:3 (abridged, in case the domain and function are "0") > > > > > > Since most devices are on a system with just a single PCI host > > adapter, the two abridged formats could still be used, as before. > > > > Just in case of multiple PCI domains, the full 4 value form was > > required for any domain other than "0". > > > > No compatibility problems, and the 3 value form would keep the > > current meaning (it would become domain/bus/slot now). > > > > This appears to be in compliance with POLA. It means, that all the > > current scripts (which may be shared between 6.x and 7.x) can stay > > unmodified, since the 2- and 3-value formats keep their semantics. > > And if PCI domains are used, its obvious there are no compatibility > > issues (since they are no present in 6.x). > > > > > > Since this was a change to my original code, I'd like to make the > > change I outlined above, unless there are strong objections. > > > > I'm ok with what you propose, I'd wait for John to comment > whether he sees any issues regarding the hints feature he is > working on though. This sounds good to me. -- John Baldwin