[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFiDJ5-jLsQ_Xej3K6DABwmRnu0YTqig=P+ByfFzNmWQhy3NYw@mail.gmail.com>
Date: Tue, 22 Apr 2014 16:24:33 +0800
From: Ley Foon Tan <lftan@...era.com>
To: Pavel Machek <pavel@...x.de>
Cc: Richard Weinberger <richard.weinberger@...il.com>,
Linux-Arch <linux-arch@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
cltang@...esourcery.com,
Michael Kerrisk-manpages <mtk.manpages@...il.com>
Subject: Re: [PATCH 16/28] nios2: System calls handling
On Tue, Apr 22, 2014 at 4:48 AM, Pavel Machek <pavel@...x.de> wrote:
>> >>> +/* sys_cacheflush -- flush the processor cache. */
>> >>> +asmlinkage int sys_cacheflush(unsigned long addr, unsigned long len,
>> >>> + unsigned int op)
>> >>> +{
>> >>> + struct vm_area_struct *vma;
>> >>> +
>> >>> + if (len == 0)
>> >>> + return 0;
>> >>
>> >> op is being ignored? You should remove it... or if (op) return -EINVAL
>> >> if you want future extensions.
>> > Yes, op argument is being ignored. Okay, will add the return -EINVAL
>> > if op is non-zero.
>>
>> Be careful. If existing applications already use this and maybe pass a
>> dummy value
>> to it you break them.
>
> Well.. of course, but passing ignored integer to syscall, that can be
> never used is beyond ugly. NAK-level ugly.
>
> If it is so, you can never ever use the argument, and might as well
> remove it (depending on your calling convention, it should not break
> anything.)
>
I'm prefer to keep the calling convention here for future use and add
the op checking here.
This prevent us to update toolchain if we plan to add in op option later.
Regards
Ley Foon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists