[PATCH] gnu: linux: Escape the values of string-type kconfig options

Handles characters within the set

(char-set-intersection char-set:ascii char-set:printing), removing

those which are known to be unsupported.

---

gnu/packages/linux.scm | 20 +++++++++++++++++++-

1 file changed, 19 insertions(+), 1 deletion(-)

Hi,

antlers <autumnalantlers@gmail.com> skribis:

[...]

Nitpick: You can turn the docstring into a comment since the docstring

wouldn’t be accessible anyway.

Please avoid tabs.

‘transform-string’ is from (texinfo string-utils), which is not imported

here. IMO, we’d rather avoid depending on this module since it’s really

designed for the Texinfo machinery.

I wonder if this should be implemented in terms of ‘string-fold’

instead:

(string-concatenate-reverse

(string-fold (lambda (chr result)

(match chr

(#\# (cons "" result))

;; …

(_ (cons (string chr) result))))

'()

str))

Thoughts?

Thanks,

Ludo’.

tags 54846 + moreinfo

quit

Hi antlers,

Did you have a chance to look into it?

TIA,

Ludo’.

Ludovic Courtès <ludo@gnu.org> skribis:

Yeah, sorry for the silence, there's been a lot going on and being able to use strings in the first place is a comportable baseline of functionality- I don't feel that one should implement implicit escaping of a field until confident that all the corner cases are handled, and think that there are some subtle warts left. Haven't had that time iron those out, but I'll be glad to polish the details and can follow up within about a week once I've addressed my remaining cornerns about correctness. Thanks for bearing with me I fumble my way through the conventions of the mailing list and formatting, nitpicks are what I'm here for c:

I think transform-string is a gem for the task, the inputs are flexible and the author specifically cites better performance than string-fold in the (ice-9 texinfo) source, but I appreciate your point and can happily specialize it in-line.

----------------------------------------

Apr 28, 2022 5:16:46 AM Ludovic Courtès <ludo@gnu.org>:

Hi! Still a busy week, working retail will do that, but this

investigation has been on the back burner long enough that it's become

clear; the kernel provides no reliable heuristic for determining the

appropriate escapes for a given option (least of all for out-of-tree

modules). Some options are explicitly expanded in Makefiles, others

aren't but become parts of filenames which are, and every special

character seems to create a syntax error on a whole new layer :c

I'm short on time to write anything up tonight, but have explored the

'behavior of', 'supported escapes within', and 'unsupported characters

of' CONFIG_SYSTEM_*_KEYS, CONFIG_CMDLINE, CONFIG_LOCALVERSION, and

CONFIG_DEFAULT_HOSTNAME (complete with associated errors for

unsupported chars within the set I initially referenced), and would be

glad to follow up with a brief summary purely for posterity; but

there's simply no elegant or complete approach unless this were to be

addressed by upstream(s). It's clearly peeved of me, and I'd take it

to those Makefiles, but for similar issues in out-of-tree modules that

I don't think I could address. It's been a lot of fun though.

I suppose we could factor out the escapes which are common to all

fields (which could be seen as eliminating /a/ layer, that of

Kconfig/conf.c itself), or address only specific common options (not a

serious suggestion!), but these each feel like inelegant solutions

which are more likely to introduce additional confusion when an option

doesn't behave correctly as transcribed out of a .config file, hence

my all-or-nothing mindset.

While I'm here, I once wrote a bash script which would set options via

the kernel's 'config' utility (not worth using over the existing

method of appending to .config, doesn't do any validation), and was

having issues with some configurations because not every option I

tried to set had it's dependency clauses satisfied. This isn't an

issue when using menuconfig because options don't even appear until

their dependencies are satisfied, but scripts can't tell whether the

options they're setting are visible. At the time I just had it

double-check after a run of `make oldconfig` (when validation is

actually done) and emit warnings. I'm not confident that it caught

every issue by just using the 'config' utility or grepping .config,

but it was good enough.

Now, I've got this crazy idea to compile conf.c as a shared library

and link against it at runtime via Guile's FFI, in order to a) learn

how that works(!), and b) use the kernels own utilities to reconstruct

the options-graph (a 'menu' object) and emit correct warnings when

setting options that aren't visible, or even actively ensure

dependencies are satisfied. In brief, would this be Guix-y?

[won't-fix]