On Tue, Mar 24, 2020 at 7:48 PM Theodore Y. Ts'o wrote:
> On Tue, Mar 24, 2020 at 09:29:58AM +, Peter Maydell wrote:
> >
> > On the contrary, that would be a much better interface for QEMU.
> > We always know when we're doing an open-syscall on behalf
> > of the guest, and it would be trivial
On Tue, Mar 24, 2020 at 09:29:58AM +, Peter Maydell wrote:
>
> On the contrary, that would be a much better interface for QEMU.
> We always know when we're doing an open-syscall on behalf
> of the guest, and it would be trivial to make the fcntl() call then.
> That would ensure that we don't a
On Tue, 24 Mar 2020 at 02:34, Theodore Y. Ts'o wrote:
> Another possibility, which would be messier for qemu, would be use a
> flag set via fcntl. That would require qemu from noticing when the
> guest is calling open, openat, or openat2, and then inserting a fcntl
> system call to set the 32-bit
On Thu, Mar 19, 2020 at 11:23:33PM +0100, Linus Walleij wrote:
> OK I guess we can at least take this opportunity to add
> some kerneldoc to the include file.
>
> > As a concrete example, should "give me 32-bit semantics
> > via PER_LINUX32" mean "mmap should always return addresses
> > within 4GB
On Thu, Mar 19, 2020 at 4:25 PM Peter Maydell wrote:
> On Thu, 19 Mar 2020 at 15:13, Linus Walleij wrote:
> > On Tue, Mar 17, 2020 at 12:58 PM Peter Maydell
> > wrote:
> > > What in particular does this personality setting affect?
> > > My copy of the personality(2) manpage just says:
> > >
> >
On Thu, 19 Mar 2020 at 15:13, Linus Walleij wrote:
> On Tue, Mar 17, 2020 at 12:58 PM Peter Maydell
> wrote:
> > What in particular does this personality setting affect?
> > My copy of the personality(2) manpage just says:
> >
> >PER_LINUX32 (since Linux 2.2)
> > [To be doc
On Tue, Mar 17, 2020 at 11:29 PM Andreas Dilger 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
On Tue, Mar 17, 2020 at 12:58 PM Peter Maydell wrote:
> On Tue, 17 Mar 2020 at 11:31, Linus Walleij wrote:
> >
> > It was brought to my attention that this bug from 2018 was
> > still unresolved: 32 bit emulators like QEMU were given
> > 64 bit hashes when running 32 bit emulation on 64 bit syste
On Mar 17, 2020, at 5:31 AM, Linus Walleij wrote:
>
> It was brought to my attention that this bug from 2018 was
> still unresolved: 32 bit emulators like QEMU were given
> 64 bit hashes when running 32 bit emulation on 64 bit systems.
>
> The personality(2) system call supports to let processes
On Tue, Mar 17, 2020 at 12:53 PM Florian Weimer wrote:
> Just be sure: Is it possible to move the PER_LINUX32 setting into QEMU?
> (I see why not.)
I set it in the program explicitly, but what actually happens when
I run it is that the binfmt handler invokes qemu-user so certainly
that program c
On Tue, 17 Mar 2020 at 11:31, Linus Walleij wrote:
>
> It was brought to my attention that this bug from 2018 was
> still unresolved: 32 bit emulators like QEMU were given
> 64 bit hashes when running 32 bit emulation on 64 bit systems.
>
> The personality(2) system call supports to let processes
* Linus Walleij:
> It was brought to my attention that this bug from 2018 was
> still unresolved: 32 bit emulators like QEMU were given
> 64 bit hashes when running 32 bit emulation on 64 bit systems.
>
> The personality(2) system call supports to let processes
> indicate that they are 32 bit Linu
It was brought to my attention that this bug from 2018 was
still unresolved: 32 bit emulators like QEMU were given
64 bit hashes when running 32 bit emulation on 64 bit systems.
The personality(2) system call supports to let processes
indicate that they are 32 bit Linux to the kernel. This
was sug
13 matches
Mail list logo
