Return-Path: Received: from mail-ot1-f67.google.com ([209.85.210.67]:35609 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725974AbeL3N73 (ORCPT ); Sun, 30 Dec 2018 08:59:29 -0500 Received: by mail-ot1-f67.google.com with SMTP id 81so21981621otj.2 for ; Sun, 30 Dec 2018 05:59:29 -0800 (PST) MIME-Version: 1.0 References: <87bm56vqg4.fsf@mid.deneb.enyo.de> <9C6A7D45-CF53-4C61-B5DD-12CA0D419972@dilger.ca> <1EF1B31A-83D8-4642-BEBF-F56E45485223@dilger.ca> <20181229015453.GA6310@bombadil.infradead.org> In-Reply-To: From: Peter Maydell Date: Sun, 30 Dec 2018 13:59:17 +0000 Message-ID: Subject: Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation To: Andy Lutomirski Cc: Matthew Wilcox , Andreas Dilger , Florian Weimer , linux-fsdevel , Linux API , Ext4 Developers List , Latchesar Ionkov , libc-alpha , Arnd Bergmann , Eric Van Hensbergen , "H. Peter Anvin" , lkml - Kernel Mailing List , QEMU Developers , Ron Minnich , V9FS Developers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-ext4-owner@vger.kernel.org List-ID: On Sat, 29 Dec 2018 at 16:49, Andy Lutomirski wrote: > > Could you use a prctl to set whether you were running in 32 or 64 bit > > mode? Or do you change which kind of task you're emulating too often > > to make this a good idea? QEMU's linux-user mode always only runs the single process, which is a fixed guest architecture. But it also wants to make system calls on its own behalf, as well as the ones it is passing through from the guest, and I suspect it would confuse the host libc if we changed the semantics of those under its feet. > How would this work? We already have the separate > COMPAT_DEFINE_SYSCALL entries *and* in_compat_syscall(). Now we=E2=80=99d= have > a third degree of freedom. > > Either the arches people care about should add reasonable ways to > issue 32-bit syscalls from 64-bit mode or there should be an explicit > way to ask for the 32-bit directory offsets. The first of those is not sufficient for QEMU if done as a per-architecture thing, because there may not even be a 32-bit syscall interface on the host kernel. The second sounds better -- there's nothing conceptually architecture specific about what we want to do or which is tied to the idea of whether there's a 32-bit compat mode in the host architecture or not. thanks -- PMM