commit | b8983957a045878b0776411990be9059ed7f74c0 | [log] [tgz] |
---|---|---|
author | Ed Tanous <edtanous@google.com> | Thu Jun 03 14:55:44 2021 -0700 |
committer | Ed Tanous <ed@tanous.net> | Wed Jun 09 17:15:10 2021 +0000 |
tree | ec300784f358444816dbd5200f9bf5ce58cdb64c | |
parent | faa34ccff8ab4f2f6d8b848a9a229efe09e5fca2 [diff] |
Move the hypervisor endpoints into a namespace The /redfish/v1/systems/hypervisor endpoints seem to have copy/pasted a lot of code from ethernet.hpp, including all the function naming. This is causing naming conflicts as part of removing the Node class. For the moment, just put these methods into the redfish::hypervisor namespace, along with a comment, so we can at least get code that builds. At some point in the future we can deduplicate the duplicated code, and give the unique things unique method names so we don't have collisions and this can be undone. Tested: Ran redfish service validator on 42a9e0ee96ef1928732ffd8d567ad656a4f41887 No change in behavior, one failure on Manager UUID that appears unrelated. Signed-off-by: Ed Tanous <edtanous@google.com> Change-Id: I0d715ed3bf04a86a93eb7842804319568083f86d
This component attempts to be a "do everything" embedded webserver for openbmc.
At this time, the webserver implements a few interfaces:
BMCWeb is configured by setting -D
flags that correspond to options in bmcweb/meson_options.txt
and then compiling. For example, meson <builddir> -Dkvm=disabled ...
followed by ninja
in build directory. The option names become C++ preprocessor symbols that control which code is compiled into the program.
meson builddir ninja -C builddir
meson builddir -Dbuildtype=minsize -Db_lto=true -Dtests=disabled ninja -C buildir
If any of the dependencies are not found on the host system during configuration, meson automatically gets them via its wrap dependencies mentioned in bmcweb/subprojects
.
meson builddir -Dwrap_mode=nofallback ninja -C builddir
meson builddir -Dbuildtype=debug ninja -C builddir
meson builddir -Db_coverage=true -Dtests=enabled ninja coverage -C builddir test
When BMCWeb starts running, it reads persistent configuration data (such as UUID and session data) from a local file. If this is not usable, it generates a new configuration.
When BMCWeb SSL support is enabled and a usable certificate is not found, it will generate a self-sign a certificate before launching the server. The keys are generated by the secp384r1
algorithm. The certificate
C=US, O=OpenBMC, CN=testhost
,SHA-256
algorithm.