commit | 19ace2b2303d5908252f6ea984def84c7efcac6a | [log] [tgz] |
---|---|---|
author | Ed Tanous <edtanous@google.com> | Tue Aug 17 09:53:15 2021 -0700 |
committer | Ed Tanous <ed@tanous.net> | Wed May 04 15:42:49 2022 +0000 |
tree | 9b06cebfcc3cb8a9e82a80899b0be51bc479fa9a | |
parent | 0cd5f786f5e8bcf5facb88d542bad3f7332da586 [diff] |
Document expectations for commit messages This commit tries to be more explicit about the expectations for commit messages and testing within bmcweb, and give maintainers something to point to instead of repeating the same statements over and over again. This will likely need to evolve, but I think it's a good start, and would help people put together commits that can be merged on the first try, rather than requiring followup. Tested: Documentation only, no testing. Signed-off-by: Ed Tanous <edtanous@google.com> Change-Id: Ib60ac90eccdc4f2c3215a755bbb462fff4796dd4
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 -C builddir test ninja -C builddir coverage
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.