On 2025/3/26 00:31, Benjamin Berg wrote: > On Tue, 2025-03-18 at 22:55 +0800, Tiwei Bie wrote: >> On 2025/3/18 21:16, Johannes Berg wrote: >>> On Tue, 2025-03-18 at 14:06 +0100, Johannes Berg wrote: >>>> On Thu, 2025-03-06 at 23:07 +0800, Tiwei Bie wrote: >>>>> Introduce a new set of utility functions that can be used to create >>>>> pthread-based helpers. Helper threads created in this way will ensure >>>>> thread safety for errno while sharing the same memory space. >>>> >>>> Using pthreads seemed odd, but Benjamin argues that it's the only way to >>>> get libc to really sort it all out, unless we never use libc syscall >>>> functions, which is probably kind of unreasonable? Or maybe we could? >>> >>> It's a long list of symbols that are needed: >>> https://p.sipsolutions.net/2f0c8e0de1e69147.txt >> >> Thanks for the list! That's indeed a long one. > > So, if we dropped libc, then I think that would also imply dropping the > abstraction to support hosts other than Linux. And then the hard split > between user/kernel code might not be needed anymore as one would > ideally not rely on system headers at all. > > I can imagine that parts of the code base would really benefit (e.g. > include handling). While other parts would obviously become more > complicated (e.g. parsing /proc/cpuinfo, mcontext handling). > > It seems to me that the cleanup potential is likely big enough to make > it worthwhile.
+1. By dropping libc entirely, we can achieve greater flexibility and elegance by directly leveraging the Linux ABI. While this approach may require considerable effort, the potential benefits seem worthwhile. Regards, Tiwei
