IRC channel logs
2020-07-18.log
back to list of logs
<Pellescours>Is it normal if a function defined in device/irq.h (install_user_intr_handler) is only implemented in linux driver (linux/dev/arch/i386/kernel/irq.c) ? <Pellescours>seeing the commit that introduce it I suppose it'a a yes ***Server sets mode: +nt
<damo22>Pellescours: i think the linux/ code is going to be removed eventually and at that point we'll have to fix irq again <damo22>we only rely on gnumach linux/ drivers for disk drivers currently, ive got a pile of pending patches to fix that <Pellescours>okay, it's because I'm still trying to build and boot gnumach in x86_64 and I had this function unlinked. I workaround this for now. I'm able to compile but not to launch the kernel. Still a lot to learn :) <damo22>Pellescours: i didnt think of the x86_64 version when i made irq changes <damo22>maybe it still needs some work to separate the arch <damo22>machine/irq.h needs to be implemented <youpi>we'll want to move some of the irq handling happening in linux/ to main gnumach, to prepare for the removal of linux/ <youpi>(which we won't use for x86_64 anyway, I don't think we want spend any time on that) <Pellescours>damo22: not a problem for now, I'm still not able to start gnumach in x86_64. Having all working properly in i386 is the first step before trying to have it working in x86_64 <youpi>Pellescours: you can #ifdef out the irq RPCs content, juste like for XEN <Pellescours>i worked around locally (crating an empty function in intr.c). I know this will move a lot in the future <Pellescours>youpi: Do you think having multiboot2 support will be nice ? I don't really know where to work and I don't have enough knowlegde to help in ACPI or irq <youpi>possibly, I don't remember what multiboot2 provides compared to multiboot? <youpi>note: knowledge is only to be acquired <youpi>I don't know *anything* about ACPI either <youpi>ah, uefi would be useful indeed :) <mihi>hello. My Debian hurd acts weirdly... I create a 40MB zeros file, mkfs.ext2 it, create the SHA1 hash. Then mount it to an empty directory, copy ~30MB worth of content to it, and unmount it again (with -f). Before unmounting, the files were there and df also showed usage. However, after unmounting the hash of the file is unchanged and when I mount it again it is empty again. I'm pretty sure I did the same before and it <mihi>Or even weirder: When I remount the image, the files are still there. However, when I copy the image (SHA1 still same) and mount the copy, the files are gone <youpi>that's surprising indeed. While the translator is still there it could be holding the data, but once it's gone the memory object should have been flushed <youpi>you can try to make a sync call just to see its effect, though <mihi>tried it at various stages and no effect :( <mihi>I now just to make sure fscked the root filesystem, but no errors <mihi>so the issue strangely even persists across reboots. 2 days ago I used the same method to make a ramdisk for Debian Hurd, and it worked. Now I want to make the "final" version with some tweaks, and I can no longer make it. And no, apart from the different files, I am not aware of anything that changed... <youpi>do you store the file in a real ext2fs FS, or a tmpfs FS ? <youpi>tmpfs is known to have issues with keeping references on data <mihi>the image file is a real ext2fs on a real ext2fs <jrtc27>are you sure you really mounted it in the first place? <jrtc27>(/maybe umount -f breaks it if you have a lot of buffered writes?) <jrtc27>(though I'd expect *some* files to be there, just maybe loss of data) <mihi>I wanted to reproduce it using "script" from bsdutils, I installed bsdutils but now don't have "script" only "scriptreplay"? (yes offtopic, debian packages...) <mihi>(packages.debian.org does not seem to list hurd packages any more to check file contents) <mihi>so let me redo it and I'll make a screenshot before I reach 25 lines... <jrtc27>configure: WARNING: sys/signalfd.h header not found; not building script <jrtc27>(last successful util-linux build log, which provides bsdutils) <youpi>there's a fixed version in unreleased <jrtc27>presumably still doesn't build script though? <jrtc27>(I assume "fixed" means "doesn't FTBFS so we can escape the bsdutils transition hellhole") <jrtc27>(which I've discovered I need to fix for kbsd... :( ) <youpi>I don't know about enabling script done or not <mihi>perhaps I am dumb and missing something obvious, therefore 2 screenshots above <mihi>another question: is there something like dmesg on Hurd? (show kernel or translator or any other log messages)? <mihi>Ok some new insight. After another reboot, the sha1sum of fsimg and fsimg2 are now different... So the problem is not that the mount did not "write through", but that the sha1sum and the copy somehow got an old version of the file...? <youpi>syslog is supposde to read it and put that in /var/log/dmesg <youpi>but at some point that broke and nobody fised it <mihi> /dev/klog is broken or syslogd? because it does not cat anything for me... <youpi>possibly something else read it before you <mihi>anyway, with a lot of rebooting in between I was able to build my ramdisk image... <mihi>(and I think I know why it worked 2 days ago: I created the ramdisk, rebooted to test if it works, and then added it to the ISO file. Today I tried without rebooting and therefore I ran into the issue) 