lkml.org 
[lkml]   [2021]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 01/13] kallsyms: Support "big" kernel symbols (2-byte lengths)
On Wed, Apr 14, 2021 at 9:45 PM Matthew Wilcox <willy@infradead.org> wrote:
>
> How about doing something a bit more utf-8-like?
>
> len = data[0];
> if (len == 0)
> error
> else if (len < 128)
> return len;
> else if (len < 192)
> return 128 + (len - 128) * 256 + data[1];
> ... that takes you all the way out to 16511 bytes. You probably don't

That would save some space and allow us to keep the 0 as an error, yeah.

> Alternatively, if the symbols are really this long, perhaps we should not
> do string matches. A sha-1 (... or whatever ...) hash of the function
> name is 160 bits. Expressed as hex digits, that's 40 characters.
> Expressed in base-64, it's 27 characters. We'd also want a "pretty"
> name to go along with the hash, but that seems preferable to printing
> out a mangled-with-types-and-who-knows-what name.

I have seen symbols up to ~300, but I don't think we will ever go up
to more than, say, 1024, unless we start to go crazy with generics,
namespaces and what not.

Hashing could be a nice solution if they really grow, yeah.

> If you have C-d-b, you don't also need S-o-b.

Hmm... `submitting-patches.rst` keeps the S-o-b in the example they
give, is it outdated?

Cheers,
Miguel

\
 
 \ /
  Last update: 2021-04-14 22:01    [W:0.098 / U:1.944 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site