[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e673d8d6-bfa8-be30-d1c1-fe09b5f811e3@redhat.com>
Date: Fri, 6 Oct 2023 14:07:16 +0200
From: David Hildenbrand <david@...hat.com>
To: "Guilherme G. Piccoli" <gpiccoli@...lia.com>,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Cc: linux-mm@...ck.org, kernel-dev@...lia.com, kernel@...ccoli.net,
keescook@...omium.org, ebiederm@...ssion.com, oleg@...hat.com,
yzaikin@...gle.com, mcgrof@...nel.org, akpm@...ux-foundation.org,
brauner@...nel.org, viro@...iv.linux.org.uk, willy@...radead.org,
dave@...olabs.net, sonicadvance1@...il.com, joshua@...ggi.es
Subject: Re: [RFC PATCH 0/2] Introduce a way to expose the interpreted file
with binfmt_misc
On 07.09.23 22:24, Guilherme G. Piccoli wrote:
> Currently the kernel provides a symlink to the executable binary, in the
> form of procfs file exe_file (/proc/self/exe_file for example). But what
> happens in interpreted scenarios (like binfmt_misc) is that such link
> always points to the *interpreter*. For cases of Linux binary emulators,
> like FEX [0] for example, it's then necessary to somehow mask that and
> emulate the true binary path.
I'm absolutely no expert on that, but I'm wondering if, instead of
modifying exe_file and adding an interpreter file, you'd want to leave
exe_file alone and instead provide an easier way to obtain the
interpreted file.
Can you maybe describe why modifying exe_file is desired (about which
consumers are we worrying? ) and what exactly FEX does to handle that
(how does it mask that?).
So a bit more background on the challenges without this change would be
appreciated.
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists