On 2022-07-25 14:51, Alejandro Colomar wrote: > Hi Florian! > > On 7/25/22 12:38, Florian Weimer wrote: > > * Alejandro Colomar via Libc-alpha: > > > > > Is there an easy way to regenerate that header to get the tatest > > > syscalls? Maybe a command could be supplied so that users (or at > > > least distributors) have it easy to regenerate them? Maybe it already > > > exists but it's not widely known? > > > > I have recently backported the syscall-names.list updates to glibc 2.34, > > but not glibc 2.33. It's a simple backport. > > > > We could perhaps enhance the glibc build process that it uses the union > > of the known system call names and what's found in the kernel headers. > > I guess it's a simple backport, since it's just adding the macros (I guess 0 > side effects). In addition the goal is to switch to glibc 2.34 in the next weeks, not that most problems related with the libpthread.so removal are identified. > But maybe providing a script, e.g., update-libc-syscalls(1), that > distributions and users can call when updating a kernel to immediately > backport syscalls to their system, would make it even simpler. > > E.g., when one runs `apt-get upgrade`, if the kernel is upgraded, > update-libc-syscalls(1) would be called by apt-get as a post install script, > and libc macros would have the new syscall numbers provided by the new > kernel. No need to wait glibc programmers to provide the backport. > > Makes sense? I don't think so. You do not want to modify files provided by a package. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net
Attachment:
signature.asc
Description: PGP signature