Currently ipu6-camera-hal supports multiple flavors under the control of build time variables. This brings several problems for downstream packaging maintainers, and can so far be worked around by playing all kinds of dirty binary tricks with assumptions of no base. The problems in the suggested installation steps are:
switching referenced binary set at runtime.
The very first thing this violates is the possibility to package for/install to a read-only root filesystem. The files installed to /usr should be immutable.
Second, as a prerequisite project of icamerasrc, this must be installed in the build environment for constructing icamerasrc. However, since there are multiple flavors of ipu6-camera-hal, and they're supposed to be switched based on hardware driven udev as suggested, it breaks the build system's assumption especially when the process is done automatically on virtual machines or chroots.
shared library linkage
As stated above, switching install binary set also brings out a problem that the down stream project is actually built against either one of the flavors. The ABI compatibility against other flavors that were not active at build time remains unknown and can only be identified at runtime tested on each supporting hardware platform. This introduces great uncertainty, human interaction, and is generally unacceptable in the packaging systems among distributions.
complexity and maintenance effort
This should be pretty obvious. While the suggested installation method doesn't meet the actual requirement of packaging systems, work-arounds are currently deployed to try resolve the violations. The efforts pile as new flavors being added, and the complexity expands linearly.
Proposed alternatives
libcamhal should hide hardware flavors from the down stream projects as its name, camera hardware abstraction layer, suggests. There should one sole libcamhal share library that icamerasrc depends on and links to,
To achieve 1., hardware model related configure parameters should be eliminated, and bits corresponding to all supporting hardware models should be built along with the major parts,
To achieve 1., hardware related object types should be pushed behind, and the public interface (to icamerasrc) must remain genuine,
To achieve 2. and 3., a proper designed backend discovering/loading should be implemented, probably in src/hal/CameraHal.cpp.
Problem description
Currently ipu6-camera-hal supports multiple flavors under the control of build time variables. This brings several problems for downstream packaging maintainers, and can so far be worked around by playing all kinds of dirty binary tricks with assumptions of no base. The problems in the suggested installation steps are:
switching referenced binary set at runtime.
The very first thing this violates is the possibility to package for/install to a read-only root filesystem. The files installed to
/usrshould be immutable.Second, as a prerequisite project of icamerasrc, this must be installed in the build environment for constructing icamerasrc. However, since there are multiple flavors of ipu6-camera-hal, and they're supposed to be switched based on hardware driven udev as suggested, it breaks the build system's assumption especially when the process is done automatically on virtual machines or chroots.
shared library linkage
As stated above, switching install binary set also brings out a problem that the down stream project is actually built against either one of the flavors. The ABI compatibility against other flavors that were not active at build time remains unknown and can only be identified at runtime tested on each supporting hardware platform. This introduces great uncertainty, human interaction, and is generally unacceptable in the packaging systems among distributions.
complexity and maintenance effort
This should be pretty obvious. While the suggested installation method doesn't meet the actual requirement of packaging systems, work-arounds are currently deployed to try resolve the violations. The efforts pile as new flavors being added, and the complexity expands linearly.
Proposed alternatives
src/hal/CameraHal.cpp.