tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: [PATCH] pcictl: simplify its usage

At Tue, 9 Jun 2009 22:01:21 +0200, Quentin Garnier <> 
Subject: Re: [PATCH] pcictl: simplify its usage
> [1  <text/plain; us-ascii (quoted-printable)>]
> On Thu, Jun 04, 2009 at 10:35:55PM -0400, der Mouse wrote:
> > >> There is nothing that compels busses to be numbered starting 0, and,
> > >> if pci0 is explicitly configured but not found, it won't exist.
> > > No, you're right.  But that would be a very strange kernel config
> > > file;
> > 
> > Not so strange as all that.  If you want to nail down something - disk,
> > network, etc - you have to nail down everything on the path from
> > mainbus0 to it, which likely includes PCI busses.  Then if you boot
> > that kernel on a machine which doesn't have one of those, it will be
> > absent.
> config(5) has allowed referencing specific instances of a starred
> configuration for quite some time, and even though it's far from perfect
> for partially wired down configurations, it does allow a lot more
> flexibility than what you describe here.

I'm not sure what you mean by that, unless perhaps that you simply mean
one can hard-wire known devices and still allow attachment of new
unknown devices in such a way that (hopefully) user-level assumptions
won't break.

Eg. like this, excerpted from a real config file designed to make sure
other disks attached to the system never appeared as either sd0 or sd1
no matter where or how they were attached.  I'm not sure I've caught
everything relevant, or excerpted all the relevant parts, but I think
this is mostly complete (ignoring many of the other possible HBAs):

        pci0    at mainbus0 bus 0
        pci*    at mainbus? bus ?
        pci1    at pchb1 bus 1
        pci*    at pchb? bus ?
        pci*    at ppb? bus ?

        pchb0   at pci0 dev 0 function 0        # ServerWorks CNB20LE Host 
(rev. 0x05)
        pchb1   at pci0 dev 0 function 1        # ServerWorks CNB20LE Host 
(rev. 0x05)
        pchb*   at pci? dev ? function ?        # PCI-Host bridges

        pcib0   at pci0 dev 15 function 0       # ServerWorks ROSB4 SouthBridge 
(rev. 0x4f)
        pcib*   at pci? dev ? function ?        # PCI-ISA bridges

        ahc0    at pci1 dev 4 function 0        # aic7899 Wide Channel A, SCSI 
Id=7, 16/255 SCBs
        ahc1    at pci1 dev 4 function 1        # aic7899 Wide Channel B, SCSI 
Id=7, 16/255 SCBs
        ahc*    at pci? dev ? function ?        # Adaptec [23]94x, aic78x0 SCSI

        siop0   at pci0 dev 6 function 0        # Symbios Logic 53c895 
(ultra2-wide scsi)
        siop*   at pci? dev ? function ?        # Symbios 53c8xx SCSI

        scsibus0 at ahc0
        scsibus1 at ahc1
        scsibus* at ahc?
        scsibus2 at siop0
        scsibus* at siop?

        sd0     at scsibus0 target 0 lun 0      # SCSI disk 0
        sd1     at scsibus1 target 0 lun 0      # SCSI disk 1
        sd*     at scsibus? target ? lun ?      # SCSI disk drives

        pciide0 at pci0 dev 15 function 1 flags 0x0000  # ServerWorks IDE (rev. 
        pciide* at pci? dev ? function ? flags 0x0000

        ohci0   at pci0 dev 15 function 2       # ServerWorks OSB4/CSB5 USB 
(rev. 0x04)
        ohci*   at pci? dev ? function ?        # Open Host Controller

        usb0    at ohci0
        usb*    at ohci?

        # uhub0 probably isn't really wired down properly
        uhub0   at usb0                         # ServerWorks OHCI root hub, 
class 9/0, rev 1.00/1.00, addr 1
        uhub*   at usb?
        uhub*   at uhub? port ? configuration ? interface ?

        umass*  at uhub? port ? configuration ? interface ?
        atapibus* at umass? channel ?
        scsibus* at umass? channel ?

        usscanner* at uhub? port ?
        scsibus* at usscanner? channel ?

It's not really very flexible beyond allowing some new hardware to be
attached and tested/used on a production system before building a new

It also does allow one to boot a set of disks on another new system and
then manually reconfigure things such that it can be brought back into
production without first having to build a new kernel.

Of course in both cases a new kernel will then have to be built to wire
down the changes again.

                                                Greg A. Woods
                                                Planix, Inc.

<>       +1 416 218-0099

Attachment: pgpgjQp8ZKzpO.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index