IRC channel logs
2026-03-27.log
back to list of logs
<almuhs>in glibc, file_name_lookup() only appears as extern in the headers <almuhs>hurd/hurd.h:203:extern file_t __file_name_lookup (const char *file, int flags, mode_t mode); <almuhs>hurd/hurd.h:204:extern file_t file_name_lookup (const char *file, int flags, mode_t mode); <sam_>it's in hurd/hurdlookup.c <almuhs>ok, the name in libc is __hurd_file_name_lookup () <sam_>yes, from hurd/hurdlookup.c:weak_alias (__hurd_file_name_lookup, hurd_file_name_lookup) <almuhs>__file_name_lookup (const char *file_name, int flags, mode_t mode) <almuhs> return __file_name_lookup_at (AT_FDCWD, 0, file_name, flags, mode); <almuhs>weak_alias (__file_name_lookup, file_name_lookup) <almuhs>__file_name_lookup_at (int fd, int at_flags, <almuhs> const char *file_name, int flags, mode_t mode) <AlmuHS>i'm deeping in the code, but i don't find any call to mach functions <AlmuHS>i'm reading this document which explain a bit about this function, but i don't solve the question <AlmuHS>to avoid the xy problem, I return to the main problem <AlmuHS>and i want to transform it in a translator <AlmuHS>the translator will be mounted in a file, and receive the number of messages as an argument. Once loaded, each time we access to the file, the translator will write the messages in the file <AlmuHS>but, how can i mount the file? With mach routines, or with file_name_lookup() ? <damo22>AlmuHS: if the contents of the file is stored in the filesystem, you dont need a translator to do that <damo22>translators are used to replace the source/destination of read/write operations, so if you wanted the contents to be stored in ram only for example until the translator is stopped, you could use one <AlmuHS>the messages are generated internally <damo22>yes but it sounds like the backing for the storage is the ext2fs under the file? <AlmuHS>the file is created in a filesystem, yes <AlmuHS>but it is not created previously <damo22>when the translator stops, does the file contents persist or disappear? <AlmuHS>the file is created when "settrans" is executed <damo22>so you want a translator that creates content on a node every time it is accessed? <AlmuHS>but when the translator is stopped, it disappears <damo22>wont that create a conflict? read() causes write() ? <AlmuHS>by example, caesar translator write in the file when you open the file <AlmuHS>but caesar read the content from a file (which exists previously) and write the encrypted content to another (the mounted file) <AlmuHS>then, i want to make a translator which writes the messages received from Mach in a file, instead in stdout <AlmuHS>or even to get that the self Mach writes to the file <Alicia>I'm not sure if I understand correctly, but I think when a translator is mounted that's not a new file that the translator writes content to, but rather that when someone else opens the path for reading the translator is responsible for sending the data in response to their read() calls? <AlmuHS>in fact, the file is created when you load the translator, but is written when you read it <AlmuHS>even, if the code makes some other things, these are made when you read the file (i think) <damo22>setting a translator program on a node allows the program to be executed to provide the content for read calls on that node, and implements what to do when write is called on that node <damo22>instead of the underlying filesystem doing that <Alicia>I suspect there's a miscommunication from calling providing the content writing to the file? <AlmuHS>my current code it's not a translator: only send messages to a mach queue and later recover them <damo22>yes the file is not written to on the underlying filesystem, the write calls go to the translator and it can do anything it wants with the data coming in <AlmuHS>in my current code, the messages read from mach queue are printed by screen. I want to dump these in a file <damo22>AlmuHS: consider the empty node your translator is attached to, what do you want your translator to do when you call open() then read() or write() on that node <AlmuHS>write the sequence of messages (strings) <AlmuHS>when the translator is loaded, it also receives the quantity of messages. And, when I open the file, the translator writes a sequence of these quantity of messages <AlmuHS>in fact, i need to create the file <AlmuHS>my current code is only stdin and stdout <AlmuHS>but i want to modify this to use a file <AlmuHS>and load as a translator (the current code doesn't works with settrans, is executed as a normal program) <damo22>AlmuHS: so when you open() then read() the node, it will print the sequence of messages as strings. <damo22>to stop reading messages after a limit? <AlmuHS>if the arguments is 5, then write 5 messages, by example <damo22>so you dont need to implement write() <AlmuHS>$ settrans -gac /tmp/out mytranslator 3 <AlmuHS>a fixed string concatenated with a number <damo22>i mean to make this a useful translator, what are you intending to return? <AlmuHS>the text "Message " concatenated with a number <AlmuHS>i want to implement it without trivfs <AlmuHS>libports, maybe libio or libfsys if necessary <AlmuHS>any idea about how can i make this? <yang>I have another PC where I can run Qemu on, the first one with ATOM CPU and HDD is kinda slow in booting <azert>youpi: there is one thing I’d like to discuss. Would you agree that everyone on mach can get the unprivileged host port? And that it is impossible to virtualize that interface since you can get that port from a syscall? <youpi>sneek: later tell azert yes it's mach_host_self(). Apparently it was not meant to be virtualized indeed <etno>Regarding the discussion on bug-hurd (which doesn't seem to accept my mail) about piix4 and ide disks : one can use virsh to issue monitor commands to a VM managed by libvirt <etno>Like : virsh -c qemu:///session qemu-monitor-command hurd-amd64 --hmp info qtree <key69105>damo22: Progress! I found that bhyve's PIT does not support mode 3, so I used mode 2 instead and the timer calibration completes. Let me know if you think this naive change would change results down the line. Current log: <key69105>As you can see, now it seems to have problems with disk. I also tried virtio, but I guess it's not supported by the rumpdisk... right? This log is with the VM using "AHCI controller attached to a SATA hard drive". <damo22>key69105: yes so the PIT is not supported <key69105>It is not a complete emulation, correct. It's supported for some modes, AFAIU. <key69105>Mode 2 is not that different, it seems... wrt the interrupt behavior if it is based on a rise. Is there a known reason to prefer the square wave here? <key69105>(not asked for a change, just trying to understand if mode 2 will break anything) <damo22>might be better to fix the emulator <key69105>No doubt about that, but right know it is what it is. <key69105>Any thoughts about how to add vitio to rumpdisk? I'm yet to find instructions about how it is created. <damo22>there is a branch of rumpkernel that enabled virtio, but it stopped compiling so i removed it <damo22>so you may need to get it to compile the lib and then integrate it into rumpdisk, which should be fairly trivial <key69105>Would you point me to that repo, please? <damo22>and you will have to install the libs