tech-kern archive

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

wiring down device attachments (was: pcictl: simplify its usage)

At Wed, 10 Jun 2009 10:09:02 +0200, Alan Barrett <> 
Subject: Re: [PATCH] pcictl: simplify its usage
> On Tue, 09 Jun 2009, Greg A. Woods wrote:
> > > 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.
> What he means is that you can write
>     scsibus* at scsi?
>     # No explicit definition of "scsibus0" above, but the reference
>     # to "scsibus0" below works anyway, and will do what you want
>     # if you have only one scsi bus, or if you can predict which of
>     # your scsi buses will appear as scsibus0.
>     sd0     at scsibus0 target 0 lun 0      # SCSI disk 0
>     sd*     at scsibus? target ? lun ?      # other SCSI disk drives

Ah ha, I see!

Hmmm, but is that of any practical use for any devices which really
might matter in an operational sense?  It seems to me it's just another
way for things to drop through the cracks and lead to bad failure

For me the whole reason to wire down devices is to create "fail-safe"
systems for operators who might not know all the critical configuration
constraints for a given system but who might need to move system disks
to spare machines for quick repairs.  (or for developer systems where
new drivers added to a kernel might "suddenly" attach before drivers
actually needed to get the system up and operational)

By "fail safe" I mean such that the system disk will either boot in an
alternate machine and work flawlessly without requiring any user-level
reconfiguration despite probable hardware differences, or else it will
fail utterly such that it will be obvious that some re-configuration is
needed.  E.g. if you put the boot disk on the motherboard SCSI bus then
it will boot and be connected via the expected /dev/*sd0* names no
matter how many other SCSI controllers the new host might have installed
and no matter which order the old kernel might try to attach them.  To
some extent this wired-down approach even works relatively well for
network interfaces even for some classes of multi-homed systems provided
one has instituted org-wide rules for which connector is used for which

However in all the cases I've tried to achieve this kind of fail-safe
configuration it was explicitly because there was a good chance the
replacement machine might have additional HBAs or NICs installed over
and above what the motherboard supported.

                                                Greg A. Woods
                                                Planix, Inc.

<>       +1 416 218-0099

Attachment: pgp6UTTcltFRd.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index