summaryrefslogtreecommitdiffstats
path: root/usr.bin/ssh/mac.c
diff options
context:
space:
mode:
authormatthew <matthew@openbsd.org>2012-06-27 22:40:38 +0000
committermatthew <matthew@openbsd.org>2012-06-27 22:40:38 +0000
commitb4e77cefa0939cd234eee0ec0c1ce5d9ffef4ee7 (patch)
tree78e8622eade62269dc10b2b8c41510a4050c0a3f /usr.bin/ssh/mac.c
parentleftover code re-enqueued the same item on the list multiple times (diff)
downloadwireguard-openbsd-b4e77cefa0939cd234eee0ec0c1ce5d9ffef4ee7.tar.xz
wireguard-openbsd-b4e77cefa0939cd234eee0ec0c1ce5d9ffef4ee7.zip
Change sparc64 to match the "fp" boot device path's parameter based on
the prototype-scsi_link's SDEV_2NDBUS flag rather than against its scsibus field. First, the scsibus field hasn't even been initialized when device_register() is called so it's always 0 anyway; second, the path number is supposed to be locally scoped to a single device whereas the scsibus field is a global scsibus(4) device number. The existing code only happened to work because all of the dual-port fibre-channel adapters we currently support attach as two devices with one scsibus each rather than a single device with two scsibuses, so we would never see anything but "fp@0". Initial investigation and diff by jmatthew after my SCSI cleanups at c2k11 broke sparc64's ability to boot from isp(4); newer version from me based on discussion with krw and kettenis. tested and ok kettenis
Diffstat (limited to 'usr.bin/ssh/mac.c')
0 files changed, 0 insertions, 0 deletions