[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdbc=7Ozf472HGUZnQgWTJjoXuopts_EWLse__Ho4PZyRw@mail.gmail.com>
Date: Thu, 19 Mar 2020 16:18:24 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Andreas Dilger <adilger@...ger.ca>
Cc: "Theodore Ts'o" <tytso@....edu>,
linux-ext4 <linux-ext4@...r.kernel.org>,
Linux FS Devel <linux-fsdevel@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>,
QEMU Developers <qemu-devel@...gnu.org>,
Florian Weimer <fw@...eb.enyo.de>,
Peter Maydell <peter.maydell@...aro.org>,
Andy Lutomirski <luto@...nel.org>,
stable <stable@...r.kernel.org>
Subject: Re: [PATCH] ext4: Give 32bit personalities 32bit hashes
On Tue, Mar 17, 2020 at 11:29 PM Andreas Dilger <adilger@...ger.ca> wrote:
> That said, I'd think it would be preferable for ease of use and
> compatibility that applications didn't have to be modified
> (e.g. have QEMU or glibc internally set PER_LINUX32 for this
> process before the 32-bit syscall is called, given that it knows
> whether it is emulating a 32-bit runtime or not).
I think the plan is that QEMU set this, either directly when
you run qemu-user or through the binfmt handler.
https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html
IIUC the binfmt handler is invoked when you try to
execute ELF so-and-so-for-arch-so-and-so when you
are not that arch yourself. So that can set up this
personality.
Not that I know how the binfmt handler works, I am just
assuming that thing is some program that can issue
syscalls. It JustWorks for me after installing the QEMU
packages...
The problem still stands that userspace need to somehow
inform kernelspace that 32bit is going on, and this was the
best I could think of.
Yours,
Linus Walleij
Powered by blists - more mailing lists