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 ...)

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.

Marius