Re: [PATCH RESEND] UAPI: move RENAME_* definitions to separated file

2018-11-13 Thread Florian Weimer
* Yury Norov: > diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h > index 53a22e8e0408..dbf58bbf5bad 100644 > --- a/include/uapi/linux/fs.h > +++ b/include/uapi/linux/fs.h Could you move it to a dedicated header? Or add a comment that the header is only for rename flags? Then we

Re: [PATCH RESEND] UAPI: move RENAME_* definitions to separated file

2018-11-13 Thread Florian Weimer
* Yury Norov: > diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h > index 53a22e8e0408..dbf58bbf5bad 100644 > --- a/include/uapi/linux/fs.h > +++ b/include/uapi/linux/fs.h Could you move it to a dedicated header? Or add a comment that the header is only for rename flags? Then we

[PATCH RESEND] UAPI: move RENAME_* definitions to separated file

2018-11-13 Thread Yury Norov
Discussion: https://lore.kernel.org/lkml/20180702084622.GA15274@yury-thinkpad/ Although RENAME_* macros are exposed in kernel headers, they are not used by glibc. That's because linux/fs.h which hosts RENAME_* is considered unsuitable by glibc developers: As Florian Weimer wrote: > undefines

[PATCH RESEND] UAPI: move RENAME_* definitions to separated file

2018-11-13 Thread Yury Norov
Discussion: https://lore.kernel.org/lkml/20180702084622.GA15274@yury-thinkpad/ Although RENAME_* macros are exposed in kernel headers, they are not used by glibc. That's because linux/fs.h which hosts RENAME_* is considered unsuitable by glibc developers: As Florian Weimer wrote: > undefines