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 <[email protected]> > Cc: Arnd Bergmann <[email protected]> > Cc: [email protected] > Cc: Vineet Gupta <[email protected]> > Cc: Catalin Marinas <[email protected]> > Cc: Will Deacon <[email protected]> > Cc: [email protected] > Cc: Mark Salter <[email protected]> > Cc: Aurelien Jacquiot <[email protected]> > Cc: [email protected] > Cc: Richard Kuo <[email protected]> > Cc: [email protected] > Cc: [email protected] > Cc: Jonas Bonn <[email protected]> > Cc: [email protected] > Cc: Chen Liqin <[email protected]> > Cc: Lennox Wu <[email protected]> > Cc: Chris Metcalf <[email protected]> > Cc: Guan Xuetao <[email protected]> > --- > 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-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
