IRC channel logs
2025-01-19.log
back to list of logs
<gnu_srs1>Hi, how to replace mount/umount calls for Linux with corresponding code for Hurd? <damo22>gnu_srs1: that may become easier when we port rumpfs instead of ext2fs <diegonc>I got "error opening terminal mach-gnu-color" when running mutt in the mach console (virtualbox BTW) <ZhaoM>damo22: can we completely replace ext2fs when rumpfs is implemented? <ZhaoM>ah I think rumpfs is a superset of ext2fs <luckyluke>Hi, I was reading the serverbootv2 proposal, I don't see the downside of using a ramdisk, in particular to avoid reimplementation of existing funcionality and adaptation to every driver used for the rootfs <azert>luckyluke: last time I checked the problem with the ram disk patch was that the memory would never get freed as such it was lost forevee <azert>also what should be the format of the ram disk? I would argue for a read only compressed format <luckyluke>yead there was also the idea to use a memory object, there were some patches from sergey that I wanted to test <luckyluke>about the dist format, I'd say tar + any compression would be ok, it would also support xattrs for translators <azert>what if tmpfs was taking such a compressed tar as an argument and decompress it with libarchive when starting? That would be generally useful and would largely solve the memory allocation issues <luckyluke>yes I was also thinking of something like that <luckyluke>in that way mounting the rootfs should be basically the same as mounting any fs, once auth and proc are started <luckyluke>and acpi/pci and the other dependencies would be started with the usual translator startup mechanism <azert>luckyluke: ok, let’s say it is tmpfs and a tar.gz file. How do you get the tar.gz file from grub? Do you link it to the static tmpfs as a .rodata elf segment? <azert>would be weird to regenerate such a file at each hurd update <luckyluke>azert: the targz can be a multiboot module, as it is currently for the ramdisk in debian. Using a memobj could solve the current problems with the ramdisk, so it can be regenerated as a normal archive, without linking an elf <diegonc>hello, I'm porting libgtop and one of the features is listing processes through the /proc filesystem. It does an opendir() followed by readdir() calls to get the list of pids. The thing is that it checks the d_type field of the dirent structure which on Hurd it appears to always return 0. <diegonc>Should I patch readdir() to return a valid d_type? Or just add a lstat() call on libgtop as suggested by readdir() man page? <youpi>sneek: later tell diegonc probably better fix procfs's putentries <sneek>Welcome back diegonc, you have 1 message! <sneek>diegonc, youpi says: probably better fix procfs's putentries <youpi>well, it *is* set by procfs :) <youpi>I guess filesystems often don't bother setting d_type because that'd require reading the inode <youpi>but for procfs it could be easy to set it <diegonc>right, I'll check procfs's putentries then