Once I got to the hackroom the next day and established communications
with sf@, we quickly got the vioblk, vioscsi and scsi XS_NO_CCB
removal code tested and committed. Over the next few days, despite
repeated interruptions described below, XS_NO_CCB stayed out of the
tree and a number of associated cleanups and code simplifications were
committed by sf@, mlarkin@ and myself. In particular the vioblk queues
were doubled in size to 128, a limit which appears to be imposed by
deeper code. At the moment this has little impact but work is
progressing to attempt asynchronous i/o in virtio devices.
In the middle of this important work, henning@ tapped me on the
shoulder and complained that dhclient was abusing his, hmm,
specialized vlan + static routes setup. i.e. dhclient was starting up,
then noticing that the vlan device has a new LLADDR and immediately
restarting. Which meant the "!route ..." statement in his
hostname.vlanNN file was being executed before the interface had a
lease in place. Which was bad.
I admitted there had been a change in dhclient to get the LLADDR
earlier but didn't understand how this could possibly impact the
setup. As it turns out vlan devices were not inheriting their LLADDR
at creation time, among other possible milestones that might impact
LLADDR. After some back and forth discussion among mpi@, dlg@ and
myself a change was committed to ensure vlan interfaces have a valid
LLADDR under most conceivable circumstances. Problem solved!
Unfortunately, even with a valid LLADDR the vlan interface was
misbehaving on startup when the parent interface did not have
link. e.g. if the wired interface was unplugged. More poking showed
that vlan did not implement the SIOCGIFMEDIA ioctl. So dhclient assumed
the vlan link was up and immediately started pumping out packets that
went nowhere. mpi@ put together a diff that implemented SIOCGIFMEDIA
by passing such requests to the parent interface. Problem solved!
In putting together the diff, mpi@ spotted the the incredibly old and
crufty way dhclient detected link state. He recommended using
getifaddr() information instead. Which I happily committed as it
simplified the code and likely simplified future pledge(2)
work. Problem solved!
People immediately noticed that the new dhclient link detection was
bogus for wifi interfaces. This resulted in some soul and code
searching that revealed that wifi interfaces were not setting their
link state to LINK_DOWN when it was appropriate to do so. Instead they
left the link state as LINK_UNKNOWN. Which dhclient has to interpret
as the link might be up. stsp@ quickly fixed this by having the wifi
interfaces set link state appropriately. Problem solved!
Silence ... Yay!
A final pass through the virtio code to replace a local DBGPRINT()
macro with DPRINTF/DNPRINTF and the hackathon was over.
Excellent venue. Excellent organization. Excellent results! Thanks to
our hosts, organizers, sponsors and attendees!