I have not made proper patches before because I was not confident in them and looking for feedback and then got sidetracked by other things.See the attachments. Let me know if I should adapt something. I have split the streamio change in 2, one for the early return and one for the data request. Do you prefer them squashed?
With those reading /dev/klog works with both the syslogd from inetutils and shepherd. Dec 28, 2025, 10:25 by [email protected]: > 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 >
>From ffe82c73f89d12393c62d5ba35b06552af40e029 Mon Sep 17 00:00:00 2001 From: Yelninei <[email protected]> Date: Sun, 28 Dec 2025 10:59:56 +0000 Subject: [PATCH 1/2] streamio (io_select_common): Don't return in case of O_NONBLOCK. select should block even when opened with O_NONBLOCK. --- trans/streamio.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/trans/streamio.c b/trans/streamio.c index d21dc937..2a48d793 100644 --- a/trans/streamio.c +++ b/trans/streamio.c @@ -589,12 +589,6 @@ io_select_common (struct trivfs_protid *cred, return 0; } - if (cred->po->openmodes & O_NONBLOCK) - { - pthread_mutex_unlock (&global_lock); - return EWOULDBLOCK; - } - ports_interrupt_self_on_port_death (cred, reply); err = pthread_hurd_cond_timedwait_np (&select_alert, &global_lock, tsp); if (err) -- 2.52.0
>From 090062ef555ffc29bcb7afcaad5bb46dad5973e9 Mon Sep 17 00:00:00 2001 From: Yelninei <[email protected]> Date: Sun, 28 Dec 2025 11:03:57 +0000 Subject: [PATCH 2/2] streamio (io_select_common): Request data if none is available. If no data is available immediately start new read/write requests. --- trans/streamio.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/trans/streamio.c b/trans/streamio.c index 2a48d793..f7cd442f 100644 --- a/trans/streamio.c +++ b/trans/streamio.c @@ -190,6 +190,8 @@ error_t dev_write (const void *buf, size_t len, size_t *amount, int nowait); will wait for any activity to cease. */ error_t dev_sync (int wait); +static error_t start_input (int nowait); +static error_t start_output (int nowait); static struct argp_option options[] = @@ -589,6 +591,27 @@ io_select_common (struct trivfs_protid *cred, return 0; } + if (*type & SELECT_READ) + { + err = start_input(1); + if (err) + { + *type = 0; + pthread_mutex_unlock (&global_lock); + return err; + } + } + if (*type & SELECT_WRITE) + { + err = start_output(1); + if (err) + { + *type = 0; + pthread_mutex_unlock (&global_lock); + return err; + } + } + ports_interrupt_self_on_port_death (cred, reply); err = pthread_hurd_cond_timedwait_np (&select_alert, &global_lock, tsp); if (err) -- 2.52.0
>From 2c9868cd8974e75a028349aa1ec9b1417f5d6617 Mon Sep 17 00:00:00 2001 From: Yelninei <[email protected]> Date: Thu, 2 Oct 2025 16:20:00 +0000 Subject: [PATCH] kmsg: Don't truncate messages when overflowing. Instead of discarding a character drop the first unread one. --- device/kmsg.c | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/device/kmsg.c b/device/kmsg.c index e5b518e6..bb72930d 100644 --- a/device/kmsg.c +++ b/device/kmsg.c @@ -217,7 +217,6 @@ void kmsg_putchar (int c) { io_req_t ior; - int offset; spl_t s = -1; /* XXX: cninit is not called before cnputc is used. So call kmsginit @@ -230,22 +229,20 @@ kmsg_putchar (int c) if (spl_init) s = simple_lock_irq (&kmsg_lock); - offset = kmsg_write_offset + 1; - if (offset == KMSGBUFSIZE) - offset = 0; - - if (offset == kmsg_read_offset) - { - /* Discard C. */ - if (spl_init) - simple_unlock_irq (s, &kmsg_lock); - return; - } kmsg_buffer[kmsg_write_offset++] = c; if (kmsg_write_offset == KMSGBUFSIZE) kmsg_write_offset = 0; + if(kmsg_write_offset == kmsg_read_offset) + { + /* Drop first unread char */ + kmsg_read_offset++; + if (kmsg_read_offset == KMSGBUFSIZE) + kmsg_read_offset = 0; + } + + while ((ior = (io_req_t) dequeue_head (&kmsg_read_queue)) != NULL) iodone (ior); -- 2.52.0
