[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87ftoyg7t3.fsf@oldenburg2.str.redhat.com>
Date: Tue, 28 May 2019 13:03:20 +0200
From: Florian Weimer <fweimer@...hat.com>
To: Cyril Hrubis <chrubis@...e.cz>
Cc: Andreas Schwab <schwab@...ux-m68k.org>,
lkml <linux-kernel@...r.kernel.org>, linux-alpha@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-ia64@...r.kernel.org,
linux-m68k@...ts.linux-m68k.org, Michal Simek <monstr@...str.eu>,
linux-mips@...r.kernel.org, linux-parisc@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, linux-s390@...r.kernel.org,
linux-sh@...r.kernel.org, sparclinux@...r.kernel.org,
linux-xtensa@...ux-xtensa.org, linux-fsdevel@...r.kernel.org,
linux-api@...r.kernel.org
Subject: Re: [PATCH] [RFC] Remove bdflush syscall stub
* Cyril Hrubis:
> Hi!
>> > I've tested the patch on i386. Before the patch calling bdflush() with
>> > attempt to tune a variable returned 0 and after the patch the syscall
>> > fails with EINVAL.
>>
>> Should be ENOSYS, doesn't it?
>
> My bad, the LTP syscall wrapper handles ENOSYS and produces skipped
> results based on that.
>
> EINVAL is what you get for not yet implemented syscalls, i.e. new
> syscall on old kernel.
EINVAL? Is that a bdflush-specific thing, test-specific, or is itmore
general?
glibc has fallback paths that test for ENOSYS only. EINVAL will be
passed to the application, skipping fallback. For missing system calls,
this is not what we want.
Thanks,
Florian
Powered by blists - more mailing lists