IRC channel logs

<almuhs>hi. where is /mach/msgserver.c ?

<gnucode>almuhs find . -name '*msgserver.c'

<damo22>its in glibc

<almuhs>and io_seek() ?

<almuhs>i'm fixing my rust port of this function: https://gitlab.com/AlmuHS/hurd-translator-in-rust/-/blob/main/Caesar_Encryption_Translator/Initial%20code/caesar.c?ref_type=heads#L130-168

<almuhs>Because newp doesn't get initial value and remains NULL

<almuhs>gdb doesn't provide me capabilities to execute step by step, so i'm simply working by try-error

<almuhs>my current port is that: https://gitlab.com/AlmuHS/hurd-translator-in-rust/-/blob/main/Caesar_Encryption_Translator/caesar-rust/src/main.rs?ref_type=heads#L197-257

<almuhs>but now seems that io_seek() fails

<almuhs>i don't know if there are other possible implementation for this function

<almuhs>maybe i can replace io_seek() with fseek() and ftell()

<almuhs>i need the docs for io_seek()

<youpi>sneek: later tell almuhs grep is really a convenient tool to find things. You'll be able to see if it's an actual function (documented in the .h and/or .texi), or an RPC (documented in the .defs)

<sneek>Will do.

<azeem>alextee: it's part of glibc I believe, or what is your problem?

<azeem>alextee: nevermind I was stuck in scrollback, sorry for the noise

<azeem>the 5min load average on amd64 seems to 0.0 all the time, is this a known issue?

<azeem>load average: 3.22, 0.00, 3.55

<azeem>(the 1min/15min look a bit high to me as well)

<youpi>I didn't know about it

<youpi>it looks like a 32b / 64b int imsmatch

<almuhs>hi

<sneek>Welcome back almuhs, you have 1 message!

<sneek>almuhs, youpi says: grep is really a convenient tool to find things. You'll be able to see if it's an actual function (documented in the .h and/or .texi), or an RPC (documented in the .defs)

<almuhs>youpi: i can't make grep if i don't know in which directory are this file

<almuhs>i don't know where are the .h and the .texi, neither the .defs

<etno>almuhs: grep -R might be helpful in this case

<diegonc>almuhs: for the .defs in the installed system:

<diegonc>$ find /usr/include/x86_64-gnu/ | grep .defs

<diegonc>I guess they come from hurd, gnumach packages (not sure about glibc)

<almuhs>diegonc: /usr/include only have the .h. I need the .c

<diegonc>ah ok

<almuhs>and, where are the .c? I found in gnumach and hurd sources, and these aren't there

<almuhs>**I search

<diegonc>I think some files are generated by mig, specially when they come from some RPC

<diegonc>others may come from glibc which is superpowered on Hurd :)

<diegonc>what are you looking for? I may help a bit if you don't mind

<almuhs>diegonc: i need to understand better the purpose of trivfs_S_io_seek(), trivfs_S_io_read() and trivfs_S_io_write()

<almuhs>In special the seek: https://gitlab.com/AlmuHS/hurd-translator-in-rust/-/blob/main/Caesar_Encryption_Translator/Initial%20code/caesar.c?ref_type=heads#L130-168

<almuhs>when this code is executed? Why this implementation?

<almuhs>in my rust port, newp remains NULL, and i don't know the reason. I tried to fix defining the SEEK_SET case calling to io_seek(), but now I have the error "resource lost"

<almuhs> https://gitlab.com/AlmuHS/hurd-translator-in-rust/-/blob/main/Caesar_Encryption_Translator/caesar-rust/src/main.rs?ref_type=heads#L197-257

<almuhs>i tried to debug with gdb, but the debugger skip these calls

<diegonc>> when this code is executed?

<diegonc>io_seek i's called from GLIBC,

<diegonc>io_seek is called from GLIBC, as shown here https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/lseek64.c;h=eafbc316244ce027ac8b84a2fc19bef65d61c376;hb=HEAD

<diegonc>> Why this implementation?

<diegonc>From what I can see the implementation is calling io_seek on the underlying filesystem node (i.e the one where ceasar is atteached to with settrans)

IRC channel logs

2025-08-30.log