> On Dec 28, 2018, at 6:54 PM, Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > >> On Sat, Dec 29, 2018 at 12:12:27AM +0000, Peter Maydell wrote: >> On Fri, 28 Dec 2018 at 23:16, Andreas Dilger <adilger@xxxxxxxxx> wrot >>> On Dec 28, 2018, at 4:18 AM, Peter Maydell <peter.maydell@xxxxxxxxxx> wrote: >>>> The problem is that there is no 32-bit API in some cases >>>> (unless I have misunderstood the kernel code) -- not all >>>> host architectures implement compat syscalls or allow them >>>> to be called from 64-bit processes or implement all the older >>>> syscall variants that had smaller offets. If there was a guaranteed >>>> "this syscall always exists and always gives me 32-bit offsets" >>>> we could use it. >>> >>> The "32bitapi" mount option would use 32-bit hash for seekdir >>> and telldir, regardless of what kernel API was used. That would >>> just set the FMODE_32BITHASH flag in the file->f_mode for all files. >> >> A mount option wouldn't be much use to QEMU -- we can't tell >> our users how to mount their filesystems, which they're >> often doing lots of other things with besides running QEMU. >> (Otherwise we could just tell them "don't use ext4", which >> would also solve the problem :-)) We need something we can >> use at the individual-syscall level. > > 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? How would this work? We already have the separate COMPAT_DEFINE_SYSCALL entries *and* in_compat_syscall(). Now we’d 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.
