Use the DISABLE_ options to disable compilation, not just installation #8
Labels
enhancement
New feature or request
Comments
|
Does this actually cause impact to pull in more dependencies? It seems like if we disabled compilation when things were disabled, we'd have to update the dependencies in both cmake/meson and the recipe every time we added a sensor. We already have to do that for the service files, but also having to declare per-sensor dependencies in two places seems like a step backward, but if there's a good use case for this, I'm not necessarily against it. |
bradbishop
pushed a commit
that referenced
this issue
Feb 8, 2024
BOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT enables the older Networking TS executors instead of the newer "Standard Executors" and is not necessary for io_uring. Remove this option to use the newer execution model. Tested: Confirmed the io_uring interfaces are still being used. ``` (gdb) bt #0 0x00007ffff7dfba47 in ?? () from /usr/lib64/liburing.so.2 #1 0x00007ffff7dfbca2 in __io_uring_get_cqe () from /usr/lib64/liburing.so.2 #2 0x000055555556dd72 in io_uring_wait_cqe_nr (ring=0x555555807c30, cqe_ptr=0x7fffffffd9f0, wait_nr=1) at /usr/include/liburing.h:1175 #3 0x000055555556df08 in io_uring_wait_cqe (ring=0x555555807c30, cqe_ptr=0x7fffffffd9f0) at /usr/include/liburing.h:1248 #4 0x000055555557ff4f in boost::asio::detail::io_uring_service::run (this=0x555555807bf0, usec=-1, ops=...) at ../subprojects/boost_1_83_0/boost/asio/detail/impl/io_uring_service.ipp:437 #5 0x000055555557e7a4 in boost::asio::detail::scheduler::do_run_one (this=0x555555806020, lock=..., this_thread=..., ec=...) at ../subprojects/boost_1_83_0/boost/asio/detail/impl/scheduler.ipp:477 #6 0x000055555557e27a in boost::asio::detail::scheduler::run (this=0x555555806020, ec=...) at ../subprojects/boost_1_83_0/boost/asio/detail/impl/scheduler.ipp:210 #7 0x0000555555581725 in boost::asio::io_context::run (this=0x7fffffffdc90) at ../subprojects/boost_1_83_0/boost/asio/impl/io_context.ipp:64 #8 0x0000555555573af0 in main () at ../src/HwmonTempMain.cpp:643 ``` Ran QEMU for Bletchley and observed HwmonTempSensor still works: ``` root@bletchley:~# busctl introspect xyz.openbmc_project.HwmonTempSensor /xyz/openbmc_project/sensors/temperature/SLED1_THERM_LOCAL xyz.openbmc_project.Sensor.Value NAME TYPE SIGNATURE RESULT/VALUE FLAGS .MaxValue property d 127 emits-change .MinValue property d -128 emits-change .Unit property s "xyz.openbmc_project.Sensor.Value.Uni... emits-change .Value property d 0 emits-change writable ``` Checking strace yields lots of io_uring related calls: ``` root@bletchley:~# strace -p 960 strace: Process 960 attached io_uring_enter(4, 0, 1, IORING_ENTER_GETEVENTS, NULL, 8) = 0 clock_gettime64(CLOCK_MONOTONIC, {tv_sec=240, tv_nsec=810659232}) = 0 clock_gettime64(CLOCK_MONOTONIC, {tv_sec=240, tv_nsec=813407042}) = 0 io_uring_enter(4, 2, 0, 0, NULL, 8) = 2 clock_gettime64(CLOCK_MONOTONIC, {tv_sec=240, tv_nsec=816897328}) = 0 io_uring_enter(4, 0, 1, IORING_ENTER_GETEVENTS, NULL, 8) = 0 clock_gettime64(CLOCK_MONOTONIC, {tv_sec=240, tv_nsec=822788059}) = 0 clock_gettime64(CLOCK_MONOTONIC, {tv_sec=240, tv_nsec=824535222}) = 0 ``` Signed-off-by: Patrick Williams <[email protected]> Change-Id: I0eb1d732a9bc3bb25e625b9f8fe3eeeaf8ae3143
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If the DISABLE_* cmake options were also used to disable compilation, then the bitbake recipe would be able to select dependencies based on which applications are actually enabled, since as of now it has to pull in all dependencies even if an application won't be used.
The text was updated successfully, but these errors were encountered: