Thread (12 messages) 12 messages, 4 authors, 2024-10-30

Re: [PATCH v7 1/3] modules: Support extended MODVERSIONS info

From: Michael Ellerman <mpe@ellerman.id.au>
Date: 2024-10-30 05:35:25
Also in: linux-kbuild, linux-modules, lkml, rust-for-linux

Matthew Maurer [off-list ref] writes:
quoted
Sorry I realise it's version 7, but although the above looks correct it's
kind of dense.

I think the below would also work and is (I think) easier to follow, and
is more obviously similar to the existing code. I'm sure your version is
faster, but I don't think it's that performance critical.

static void dedotify_ext_version_names(char *str_seq, unsigned long size)
{
        char *end = str_seq + size;
        char *p = str_seq;

        while (p < end) {
                if (*p == '.')
                        memmove(p, p + 1, end - p - 1);

                p += strlen(p) + 1;
        }
}

The tail of str_seq will be filled with nulls as long as the last string
was null terminated.
As you alluded to, what you're providing is potentially O(n^2) in the
number of symbols a module depends on - the existing code is O(n).
If leading dots on names are rare, this is probably fine. If they're
common, this will potentially make loading modules with a large number
of imported symbols actually take a measurable amount of additional
time.
It should only be a single symbol these days, .TOC., for both big and
little endian builds.

But maybe someone out there is still building their kernel ELFv1, in
which case every function will begin with '.'.

I still don't think it will be measurable, but n^2 is asking for
trouble.

So forget it, just use your version, you've already written it anyway.
Sorry for the noise.

cheers
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help