[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190528112022.GA16683@rei>
Date: Tue, 28 May 2019 13:20:23 +0200
From: Cyril Hrubis <chrubis@...e.cz>
To: Florian Weimer <fweimer@...hat.com>
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
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.
The syscall returns ENOSYS after this change, sorry for the confusion.
--
Cyril Hrubis
chrubis@...e.cz
Powered by blists - more mailing lists