Hello, [email protected], le dim. 28 déc. 2025 11:09:25 +0100, a ecrit: > Dec 28, 2025, 09:38 by [email protected]: > > [email protected], le dim. 28 déc. 2025 10:18:06 +0100, a ecrit: > > > >> What's the status on this? > > > > The last thing I have in my notes is this: > > > > https://lists.gnu.org/archive/html/bug-hurd/2025-09/msg00067.html > > > >> Is there something I should adapt for the streamio patch? > > > > IIRC I had pushed a fix on > > https://lists.gnu.org/archive/html/bug-hurd/2025-09/msg00019.html > > > > I think this is > https://cgit.git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?id=d6b6fe73c2c3172abc95843665a668a6bd18a6be > which only addresses the lock. > > There is still the wrong early return with EWOULDBLOCK and then the actual > requesting of more data. > > These are in the rest of the patch from > https://lists.gnu.org/archive/html/bug-hurd/2025-09/msg00014.html
Ok, then my last answer is apparently "Yes, that looks sensible." " > I have no idea if the write part works and I just hope that it is > symmetrical. dev_write seems to work symmetrical with dev_read, so it'd probably be correct path, yes. " so apparently I agreed with the approach. But then I need a patch to be able to apply it. No, I cannot just pick up the patch from the list since in the meanwhile the lock part was applied separately (since that's a separate issue). No, I cannot take the time to adapt the patch. > >> What to do when the kmsg_buffer overflows? > >> > > > > As you proposed last: just drop the first unread char. > > I think I already sent something for gnumach here > https://lists.gnu.org/archive/html/bug-hurd/2025-09/msg00060.html where I did > not understand what you meant with your reply. You asked "Something like this", so I assumed that this wasn't the definite patch. And it'd need a changelog etc. anyway. Please, people, help me by taking the time to write complete patches with change logs etc. for inclusion. I just cannot be "the one who fixes everything", there are only 24h in my day, too. Samuel
