At Tue, 9 Jun 2009 22:01:21 +0200, Quentin Garnier <cube%cubidou.net@localhost>
wrote:
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.
0x00)
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
kernel.
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.
<woods%planix.com@localhost> +1 416 218-0099 http://www.planix.com/
Attachment:
pgpgjQp8ZKzpO.pgp
Description: PGP signature