OpenBSD Journal

t2k19 Hackathon Report: Ken Westerback on dhclient, disklabel, and more

Contributed by rueda on from the regressions must be in CAPS dept.

Kenneth R Westerback (krw@) wrote in with a report on his recent participation in t2k19:

Rule 1 of Taipei travel -- nobody knows what an EasyCard is.

Your travel arranging sites, your travel book, even the Taipei transit web pages will extoll the virtues of the EasyCard (all true). And claim it is available everywhere (NOT true). Hypothetically, if you have staggered off a sleepless 12 hour business class flight that provided a bottomless glass of Cognac and then been sucked past the tourist friendly environs of the airport in the draft of a fast moving experienced traveller you may be forced to try your EasyCard luck at a 7-Eleven or Family Mart.

They will gaze at you in befuddlement. They will poke in vain at their iPhone translation software. BUT, if you ask for a "yo yo ka", you will be buried in colourful plastic squares and asked to make a choice. As always, it pays to know a local. Thanks Kevin!

Hackathon hotel was definitely a cut above the average. An in-room jacuzzi! The hackroom was excellent although we were not allowed to pilfer from the wine rack. When I say the next door barista used a Kruve to get his grind exact you can safely infer that good coffee was widely available. As was a plethora of food choices.

But I was there to do something … right! Hacking!

I continued ongoing dhclient work, with the major change being the implementation of human-readable parsing and display of the RFC1035 encoded data for option 119, a.k.a. 'domain-search'. It is now possible to read the domain-search values in leases without manually decoding a long hex string. It is also now possible to append/prepend data to the lease values via dhclient.conf(5), just as for most other variable length options.

While amending the dhcp-options(5) documentation I noticed a number of other errors and cleaned them up. In particular the classless-[ms-]static-routes options are much better presented; relay-agent-information, nds-context, nds-tree-name are correctly classed as data-string instead of string options; dhcp-message (option 56) is now documented; dhcp-max-message (57) correctly described; and unused int16 and int8 types are no longer listed.

I then turned to polishing disklabel(8) code. I started by adding a comment that strongly suggested that any modification to the auto_allocation tables MUST BE MATCHED WITH REGRESS TEST ADJUSTMENTS. I then worked with bluhm@ to fix the disklabel regress tests after recent adjustments to the tables. We also added a target to the regress test Makefile to make such adjustments a simple command in the future.

I massaged all the uses of ioctl() in disklabel(8) to use a consistent idiom, i.e. check the result against -1 and not '< 0'. The verbiage of error and warning messages associated with ioctl() usage was updated and clarified.

I tweaked the -R (restore) code to eliminate duplicate calls to DIOCGDINFO and mpsave(). I extended the -n (donothing) mode to prevent the surprise overwriting of files specified via -F/-f. I removed superfluous code that saved various fields in the disklabel across invocations of getasciilabel(), as getasciilabel() makes its own arrangements to avoid touching those fields. I nuked a vestigal error message generating routine, l_perror() and merged some related blocks to clarify logic.

Finally, to do something visible to the outside world, I enhanced the command line prompt used by disklabel(8) so that the disk being edited is always shown and the prompt changes when in expert mode. I've heard stories that other people have become confused and overwritten the wrong disklabel. This should help those poor, unnamed, souls.

Around the above projects I provided moral support for ongoing work to remove OCaml ports that are no longer needed in the new OPAM 2.0 world.

An excellent hackathon in an interesting and surprisingly inexpensive locale. Thanks to kevlo@ for the fine organizational effort and the OpenBSD Foundation for their support. We shall return to Taipei!

Thanks, Ken, for both the work and the report!

(Comments are closed)


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]