[libcamera-devel] [PATCH v2 1/2] libcamera: ipa_manager: Only parse IPA modules

Thu Feb 13 18:36:23 CET 2025

Hi Dylan, Javier,

I've got some questions for you both at the bottom of this mail
regarding libcamera packaging.

Quoting Laurent Pinchart (2025-02-13 17:01:26)
> On Wed, Feb 12, 2025 at 09:42:07AM +0000, Kieran Bingham wrote:
> > Quoting Laurent Pinchart (2023-08-28 20:13:13)
> > > On Mon, Aug 28, 2023 at 01:28:37PM +0100, Kieran Bingham wrote:
> > > > Quoting Kieran Bingham (2023-05-04 20:03:56)
> > > > > On 04/05/2023 16:10, Laurent Pinchart wrote:
> > > > > > On Thu, May 04, 2023 at 03:48:00PM +0100, Kieran Bingham via libcamera-devel wrote:
> > > > > >> Ensure that when we iterate the libcamera libdir we only select shared
> > > > > >> objects which are expected to be IPA modules, with an ipa_ prefix.
> > > > > >>
> > > > > >> Any shared object not matching this filter is ignored and not processed
> > > > > >> by the IPA Manager.
> > > > > >>
> > > > > >> Reviewed-by: Javier Martinez Canillas <javierm at redhat.com>
> > > > > >> Signed-off-by: Kieran Bingham <kieran.bingham at ideasonboard.com>
> > > > > > 
> > > > > > I wonder what this protects against, as there shouldn't be other files
> > > > > > in this directory, especially if we move IPA modules to an ipa/
> > > > > > subdirectory. I don't mind much, as this isn't a hot path, so I have no
> > > > > > objection if you want to merge this, but is it useful ?
> > > > > 
> > > > > Only that it prevents us trying to load any files that might be there 
> > > > > otherwise.
> > > > > 
> > > > > 
> > > > > [76:32:31.897778214] [2776180] ERROR IPAModule ipa_module.cpp:286 
> > > > > fake.so: IPA module is not an ELF file
> > > > > [76:32:31.899112311] [2776180] ERROR IPAModule ipa_module.cpp:172 Symbol 
> > > > > ipaModuleInfo not found
> > > > > [76:32:31.899119975] [2776180] ERROR IPAModule ipa_module.cpp:292 
> > > > > v4l2-compat.so: IPA module has no valid info
> > > > > 
> > > > > 
> > > > > We already filter on .so objects, and we do other checks so it's not 
> > > > > crucial, and it's not going to prevent any attempt to get 
> > > > > 'non-libcamera' code parsed as anyone dropping a file here could equally 
> > > > > call it 'ipa_fake.so' ... so no not really.
> > > > > 
> > > > > I'll drop this and collect 2/2
> > > > 
> > > > I've started seeing various logs that report similar to:
> > > > ```
> > > > $ wireplumber 
> > > > [12:34:30.015061894] [206341] ERROR IPAModule ipa_module.cpp:172 Symbol ipaModuleInfo not found
> > > > [12:34:30.015085339] [206341] ERROR IPAModule ipa_module.cpp:292 v4l2-compat.so: IPA module has no valid info
> > > > [12:34:30.015125806] [206341]  INFO Camera camera_manager.cpp:284 libcamera v0.1.0
> > > > ```
> > > > 
> > > > I believe this is because some distributions are probably overriding the
> > > > installation path of the v4l2-compat.so.
> > > > 
> > > > Anyway, that makes me think that we /should/ ignore files that are not
> > > > prefixed by ipa_ ...
> > > 
> > > Or move IPA modules to an ipa/ subdirectory ?
> > 
> > And I've just seen this in some logs from a raspberry pi issue:
> > 
> > ```
> >   (AGS_311_venv) @AGS-RPI-0004:~$ libcamera-hello
> >   [0:01:23.242753930] [811] ERROR IPAModule ipa_module.cpp:171 Symbol ipaModuleInfo not found
> >   [0:01:23.242802797] [811] ERROR IPAModule ipa_module.cpp:291 v4l2-compat.so: IPA module has
> >   no valid info
> >   [0:01:23.242827435] [811]  INFO Camera camera_manager.cpp:327 libcamera v0.4.0+51-ca36c77f
> > ```
> > 
> > So I think it's time to move the IPA modules to a subdirectory. I like
> > that better than arbitrary filtering of the name.
> 
> It's really a distribution issue, by default IPA modules go to (on an
> Arm64 system) /usr/local/lib64 (and only IPA modules are installed
> there), and v4l2-compat.so go to /usr/local/libexec/libcamera/. We can
> create a subdirectory for IPA modules, but will distributions then
> decide to install v4l2-compat.so there ? :-)

A distribution issue that's impacting multiple distributions ...

So the question is /why/ ?

https://salsa.debian.org/multimedia-team/libcamera/-/blob/debian/unstable/debian/libcamera-ipa.install?ref_type=heads
shows:

usr/lib/*/libcamera/ipa_*.so
usr/lib/*/libcamera/ipa_*.so.sign
usr/lib/*/libcamera/*_ipa_proxy
usr/share/libcamera

so it's capturing the ipa files into a package based on where they get
installed.

https://salsa.debian.org/multimedia-team/libcamera/-/blob/debian/unstable/debian/libcamera-v4l2.install?ref_type=heads

shows

usr/lib/*/libcamera/v4l2-compat.so

for the V4L2 side.

And finally:

https://salsa.debian.org/multimedia-team/libcamera/-/blob/debian/unstable/debian/rules?ref_type=heads

Shows:

override_dh_auto_configure:
	dh_auto_configure -- \
		--libexecdir=lib/${DEB_HOST_MULTIARCH} \

Which is overridding the libexecdir for multiarch. 

Trying to search for debian guidance on this I hit:

https://linux.debian.devel.mentors.narkive.com/hkilz1si/using-usr-libexec-directory
which is a mentor on the debian lists giving the following guidance:

> Move the files to use "usr/lib" instead. Nothing on debian uses libexec.
>
> Usually there is a configure option one can pass, e.g. --libexecdir=/usr/lib

and
https://lists.debian.org/debian-devel/2005/05/msg00404.html
> > Should we change some of these to /usr/libexec?
> 
> well, it would be against the FHS, I think.
> 
> The BSDs use libexec but I don't really see a good reason why it exists.
> 

And this one:
https://lists.debian.org/debian-devel/2005/05/msg00565.html
> The BSDs use libexec but I don't really see a good reason why it exists.
> 
> The only reason we don't have it is because of petty bickering and
> politics between the FHS folks (several years ago).  There were few
> technical objections to it on the FHS list, but it was dropped for
> non-technical reasons.  Given that the FHS is supposed to codify
> existing practice, it should be in there on that count alone.  Every
> libexec-using package in Debian has been reconfigured not to use it;
> upstreams do use it, and I'd like to use it myself.
> 
> I'd personally be very glad to have it, and would support using it in
> Debian.

But so far I haven't found any documentation to 'specify' this.

Dylan, Do you know /why/ the v4l2-compat.so is moved out of libexec and
into lib/libcamera ? (Noting that it causes a spurious error to be
reported to users who have libcamera-v4l2 installed).

I know this same issue is occuring on Alpine and Arch systems too. So it
seems like "all the major distributions" are doing roughly the same
thing here.

Javier, Do you know if this is happening on Fedora or if there is any
requirements regarding /usr/libexec ?

--
Kieran