IRC channel logs

2026-07-28.log

back to list of logs

<azert>was looking at the aforementioned dpdk drivers on Linux it uses eventfd and epoll for interrupts. In the Hurd could just use libirqhelper and port sets
<azert>instead of implementing eventfd and epoll
<azert>possibly libirqhelper could need a small update to dispatch notifications using port sets instead of one thread per interrupt, not even sure that’s not already supportes
<azert>there is the open issue about interrupt delivery and paging. That require wiring of the full process and it’s a bug in common with rumpdisk
<nexussfan>Is the glibc hurd support upstreamed?
<damo22>nexussfan: what do you mean? hurd uses upstream glibc in general yes
<sam_>yes, a long time ago
<youpi>nexussfan: the glibc support has been upstream since essentially always, actually
<youpi>it's already in the first git commit history
<sam_>ah, I knew it was old but I didn't know it was that old
<youpi>it's as old as the gnu project
<youpi>so early 90's
<azeem>glibc was written for the Hurd initially
<azeem>the Linux port came later
<nexussfan>Oh, I thought glibc had it's own custom Hurd repo? https://www.gnu.org/software/hurd/source_repositories/glibc.html
<azeem>no, the hurd has a custom glibc repo
<azeem>cause all of the original glibc maintainers that were also Hurd developers have stepped down, so it makes sense to maintain an outside fork
<nexussfan>Oh okay
<gnucode>hmm, kent overstreet just put out a post on patreon talking about the uses of AI. Apparently AI is fairly good at writing tests.
<sam_>azeem: I don't think that repo is really used (the debian one is, sure) but samuel has commit access upstream and glibc development is far more open and community-like these days
<nikolar>gnucode: he also thought his "ai" was sentient so that's neither here nor there
<gnucode>nikolar: I think he still believe his ai is sentient. :) But I don't know that for sure.
<nikolar>heh