On Wednesday 23 April 2014, James Hogan wrote:
> The new renameat2 syscall provides all the functionality provided by the
> renameat syscall and adds flags, so future architectures won't need to
> include renameat.
> 
> Therefore drop the renameat syscall from the generic syscall list unless
> __ARCH_WANT_RENAMEAT is defined by the architecture's unistd.h prior to
> including asm-generic/unistd.h, and adjust all architectures using the
> generic syscall list to define it so that no in-tree architectures are
> affected.

I should have read this one before replying to patch 2 ;-)

> Signed-off-by: James Hogan <james.ho...@imgtec.com>
> Cc: Arnd Bergmann <a...@arndb.de>
> Cc: linux-a...@vger.kernel.org
> Cc: Vineet Gupta <vgu...@synopsys.com>
> Cc: Catalin Marinas <catalin.mari...@arm.com>
> Cc: Will Deacon <will.dea...@arm.com>
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: Mark Salter <msal...@redhat.com>
> Cc: Aurelien Jacquiot <a-jacqu...@ti.com>
> Cc: linux-c6x-...@linux-c6x.org
> Cc: Richard Kuo <r...@codeaurora.org>
> Cc: linux-hexa...@vger.kernel.org
> Cc: linux-metag@vger.kernel.org
> Cc: Jonas Bonn <jo...@southpole.se>
> Cc: li...@lists.openrisc.net
> Cc: Chen Liqin <liqin.li...@gmail.com>
> Cc: Lennox Wu <lennox...@gmail.com>
> Cc: Chris Metcalf <cmetc...@tilera.com>
> Cc: Guan Xuetao <g...@mprc.pku.edu.cn>
> ---
> Is this the approach we want to take to keep the default syscall list
> minimal? We could for example have made renameat2 use the renameat
> syscall number for new arches, but it seemed best to leave a gap for new
> arches to improve consistency of numbering.

I think leaving the hole is best.

> This patch is a no-op for arches in tree, so there's no harm for this to
> wait for the v3.16 merge window.

Sounds good. I guess I'll have to put this into my asm-generic tree
then, unless I can get the nios2 maintainers to pick it up.

If you don't mind, can you submit the first two patches to Linus
directly?

        Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-metag" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to