[Unstable][PATCH] UBUNTU: [Packaging] Add module versions to the ABI
Seth Forshee
seth.forshee at canonical.com
Tue Apr 20 12:15:59 UTC 2021
On Tue, Apr 20, 2021 at 12:38:03PM +0200, Juerg Haefliger wrote:
> On Mon, 19 Apr 2021 15:25:56 -0500
> Seth Forshee <seth.forshee at canonical.com> wrote:
>
> > On Tue, Apr 13, 2021 at 02:36:38PM +0200, Juerg Haefliger wrote:
> > > Add module versions to the ABI (or '-' if the module doesn't report a
> > > version) and make sure the module check only looks at the module name
> > > and ignores the trailing version.
> > >
> > > This info ends up in the buildinfo package which can be used by meta
> > > packages so that they don't have to build-depend on the huge modules
> > > package to determine versions of in-tree DKMS modules.
> > >
> > > Signed-off-by: Juerg Haefliger <juergh at canonical.com>
> >
> > This doesn't seem like a very extensible way of doing things if we ever
> > need to add additional information from modinfo later.
>
> We could turn this into a CSV list and add more fields as necessary but I
> agree it's not very flexible.
>
>
> > We're already
> > inclding the firmware information separately in the fwinfo file. I
> > wonder how much it would bloat the abi size to include all of the
> > modinfo data, similar to what's in modules.builtin.modinfo
>
> Huh? Where does this file live?
/usr/lib/modules/$(uname -r)/modules.builtin.modinfo
It's like a text file but fields are separated by nulls rather than
newlines, so run it through "tr '\0' '\n'" if you want to look at it.
>
>
> > already
> > (which we would probably also want to pull in as part of this
> > information). It could probably replace the fwinfo and flavour.modules
> > files though as they would now contain redundant information.
>
> Yes, the more I think about it the more I believe we should include all
> modinfo data and let the consumer decide which data to use rather than trying
> to be 'smart' at buildinfo build time (just to realize later that we should
> also have included XYZ). I'll play around with it some more.
>
> ...Juerg
>
>
> > Seth
>
More information about the kernel-team
mailing list