-
David Johnson authored
libosload_new contains the new libosload. It provides the same API as the original libosload, but the functionality has been split out into well-defined methods that can be overridden by per-node type subclasses in small chunks. This is all protected by the NewOsload feature. libosload_switch.pm.in and libossetup_switch.pm.in contain the HP switch support, which requires the new libosload and new libossetup. libossetup_switch doesn't do anything too radical, but it does support running a node it is "lighting up" through multiple operations -- i.e., first a RELOAD, then a RECONFIG. This was necessary because switches require a config to be pushed to them (well, they do in the way I elected to support them), and they cannot fetch configuration in the normal Emulab way via tmcd. Eventually, that multi-op support will be factored out into libossetup more generically so that other node types which require push-based configuration can leverage it. libosload_switch contains the HP switch loading code. It's built around expect-like interaction on the serial console. It supports xmodem and tftp uploads, but tries to only flash the switch lazily. Thus, if the switch is already loaded with an image and a user (or the reload daemon, or anybody) reloads it with the same image, it won't actually get reloaded. You can now force this reload with os_load. libosload_switch also contains reconfig code (i.e., to wipe switch configs and recreate based on which experiment it is in). libossetup_switch directly invokes this instead of going through libosload, since configuring is not really part of loading. It is just convenient since configuration also happens over the serial console, and all the osload code for the switch can be reused. Also, of course, there are miscellaneous changes to support the new libosload in os_load itself.
7cfa7aa6