Re: [musl] Some pending changes/patches

["Érico Nogueira" <ericonr@disroot.org>]

Sorry for the noise, I forgot one patch:

- use SYS_openat instead of SYS_open in open(2) to avoid spurious
fcntl syscalls:
https://inbox.vuxu.org/musl/20201229225518.3677-1-ericonr@disroot.org/

All the questions in the patch still apply, so I don't believe it's 
ready to be merged, but a review would be very helpful - pointers on the 
matter of the kernel timeline regarding SYS_openat and O_CLOEXEC flag 
would also be appreciated. And maybe it should be using __syscall_cp for 
the syscall (I believe this makes a difference for cancellation points)?

Cheers

Em 17/01/2021 16:42, Érico Nogueira escreveu:
> Hi!
> 
> Firstly, congratulations on the new release :)
> 
> Secondly, I have some pending patches that I'd like to ping, plus some
> changes that I was asked to post about once the 1.2.2 release had been
> made.
> 
> - add cloexec flag to open() in pthread_setname_np:
> https://www.openwall.com/lists/musl/2020/12/24/1
> 
> - (low-priority) add pthread_getname_np:
> 	- my version (needs to be cleaned up for the change in the patch
> 	  above):
> 	  https://www.openwall.com/lists/musl/2020/12/19/3
> 	  It tries to avoid duplicating the setup for the
> 	  /proc/self/task/%d/com path by adding a helper function.
> 	- older version:
> 	  https://inbox.vuxu.org/musl/AM0PR07MB442007DDD4FECFF99BB5EBF48BE70@AM0PR07MB4420.eurprd07.prod.outlook.com/
> 	  Lacks cloexec flag when opening file.
> 
> - (low priority) implement gethostid() beyond a stub:
> https://inbox.vuxu.org/musl/20200804224230.27774-1-ericonr@disroot.org/
> 
> - fix type for __libc_start_main. In crt1.c and rcrt1.c, it is:
> 
> int __libc_start_main(int (*)(), int, char **,
> 	void (*)(), void(*)(), void(*)());
> 
> but in __libc_start_main.c, it is
> 
> int __libc_start_main(int (*main)(int,char **,char **), int argc, char **argv)
> 
> as far as I can tell the fix is simple and the signature mismatch isn't
> an issue. Since I don't know the context for the mismatch and therefore
> wouldn't be able to write an appropriate commit message, I refrained
> from sending a patch for it.
> 
> Happy new year,
> Érico
>