From: Alex Ghiti <alex@ghiti.fr>
To: Palmer Dabbelt <palmer@dabbelt.com>, macro@orcam.me.uk
Cc: david.abdurachmanov@gmail.com, dvyukov@google.com,
Paul Walmsley <paul.walmsley@sifive.com>,
linux-api@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] riscv: Bump COMMAND_LINE_SIZE value to 1024
Date: Mon, 21 Jun 2021 09:11:37 +0200 [thread overview]
Message-ID: <182c1d4e-a117-79d6-4dd1-8e3c8a447b4a@ghiti.fr> (raw)
In-Reply-To: <mhng-9e6b4607-6bea-411c-b843-916c1e0798ee@palmerdabbelt-glaptop>
Hi Palmer,
Le 23/04/2021 à 04:57, Palmer Dabbelt a écrit :
> On Fri, 02 Apr 2021 11:33:30 PDT (-0700), macro@orcam.me.uk wrote:
>> On Fri, 2 Apr 2021, David Abdurachmanov wrote:
>>
>>> > > > This macro is exported as a part of the user API so it must
>>> not depend on
>>> > > > Kconfig. Also changing it (rather than say adding
>>> COMMAND_LINE_SIZE_V2 or
>>> > > > switching to an entirely new data object that has its dimension
>>> set in a
>>> > > > different way) requires careful evaluation as external binaries
>>> have and
>>> > > > will have the value it expands to compiled in, so it's a part
>>> of the ABI
>>> > > > too.
>>> > >
>>> > > Thanks, I didn't realize this was part of the user BI. In that
>>> case we
>>> > > really can't chage it, so we'll have to sort out some other way
>>> do fix
>>> > > whatever is going on.
>>> > >
>>> > > I've dropped this from fixes.
>>> >
>>> > Does increasing COMMAND_LINE_SIZE break user-space binaries? I would
>>> > expect it to work the same way as adding new enum values, or adding
>>> > fields at the end of versioned structs, etc.
>>> > I would assume the old bootloaders/etc will only support up to the
>>> > old, smaller max command line size, while the kernel will support
>>> > larger command line size, which is fine.
>>> > However, if something copies /proc/cmdline into a fixed-size buffer
>>> > and expects that to work, that will break... that's quite unfortunate
>>> > user-space code... is it what we afraid of?
>>> >
>>> > Alternatively, could expose the same COMMAND_LINE_SIZE, but internally
>>> > support a larger command line?
>>>
>>> Looking at kernel commit history I see PowerPC switched from 512 to
>>> 2048, and I don't see complaints about the ABI on the mailing list.
>>>
>>> If COMMAND_LINE_SIZE is used by user space applications and we
>>> increase it there shouldn't be problems. I would expect things to
>>> work, but just get truncated boot args? That is the application will
>>> continue only to look at the initial 512 chars.
>>
>> The macro is in an include/uapi header, so it's exported to the userland
>> and a part of the user API. I don't know what the consequences are for
>> the RISC-V port specifically, but it has raised my attention, and I think
>> it has to be investigated.
>>
>> Perhaps it's OK to change it after all, but you'd have to go through
>> known/potential users of this macro. I guess there shouldn't be that
>> many
>> of them.
>>
>> In any case it cannot depend on Kconfig, because the userland won't have
>> access to the configuration, and then presumably wants to handle any and
>> all.
>
> It kind of feels to me like COMMAND_LINE_SIZE shouldn't have been part
> of the UABI to begin with. I sent a patch to remove it from the
> asm-generic UABI, let's see if anyone knows of a reason it should be UABI:
>
> https://lore.kernel.org/linux-arch/20210423025545.313965-1-palmer@dabbelt.com/T/#u
Arnd seemed to agree with you about removing COMMAND_LINE_SIZE from the
UABI, any progress on your side?
Thanks,
Alex
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2021-06-21 7:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-16 19:34 [PATCH] riscv: Bump COMMAND_LINE_SIZE value to 1024 Alexandre Ghiti
2021-03-30 5:07 ` Palmer Dabbelt
2021-03-30 20:31 ` Maciej W. Rozycki
2021-04-02 4:37 ` Palmer Dabbelt
2021-04-02 8:40 ` Dmitry Vyukov
2021-04-02 8:58 ` David Abdurachmanov
2021-04-02 18:33 ` Maciej W. Rozycki
2021-04-23 2:57 ` Palmer Dabbelt
2021-06-21 7:11 ` Alex Ghiti [this message]
2022-11-10 21:01 ` Dmitry Vyukov
2023-02-09 11:37 ` Dmitry Vyukov
2023-02-09 19:30 ` Alex Ghiti
2023-03-02 3:17 ` Palmer Dabbelt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=182c1d4e-a117-79d6-4dd1-8e3c8a447b4a@ghiti.fr \
--to=alex@ghiti.fr \
--cc=david.abdurachmanov@gmail.com \
--cc=dvyukov@google.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=macro@orcam.me.uk \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).