IRC channel logs

2025-07-29.log

back to list of logs

<azert>hello
<sneek>Welcome back azert, you have 1 message!
<sneek>azert, youpi says: yes that's easier to integrate, licence-wise
<azert>youpi: because I was looking at ext4 and noticed that linux/fs/jbd2/ code is gpl2+ and quite well insulated from ext4 code
<azert>so if one was to make it into a Hurd libjdb2fs, it would probably be the most straightforward way to give Hurd ext2fs a journal
<azert>the alternative could be to make it an independent server, although I don’t see any advantage doing that
<youpi>the other alternative is to just use rumpfs ;)
<azert>youpi: I’m a bit confused, I can see how rumpfs would almost be straightforward to implement as it is already working and just need to be wired up to Hurd ipc. But what about the pager api? Will it be possible to implement virtual memory and page faults with rumpfs?
<azert>Here https://iso.netbsd.org/pub/NetBSD/NetBSD-current/src/lib/libp2k/p2k.c doesn’t seem like there much logic for that, perhaps the last two functions/shims
<azert>there are people that claim that 21st century computing doesn’t need virtual memory
<damo22>doesnt rump just use malloc?
<damo22>or dmalloc
<azert>damo22: what I meant is that when you mmap a file you don’t normally just read it in memory, but you read it upon page faults
<azert>this way you can mmap files that are much bigger then the memory available and also the swap file
<damo22>i dont know how mmap works on files
<azert>it needs to cooperate with the gnumach kernel to do that
<azert>damo22: it literally just allocate placeholders in the page table, it is normally lazy allocation
<azert>in the 80s mainframe, this was a fundamental mechanism to allow multiusers on limited memory
<damo22>i dont recall if rump has a hypercall to hook into mmap
<azert>on netbsd rumpfs can do mmap
<damo22>can it just call mmap internally?
<azert>Yes
<damo22>it probably already does then
<azert>but I don’t see how that can handle page faults?
<azert>how does it enforce permissions on shared memory?
<azert>I don’t see how it can do that without hooking into the real kernel
<damo22>panic("bus_dmamem_mmap not supported");
<damo22>rumpuser_anonmap() mem = mmap(prefaddr, size, prot,
<damo22> MAP_PRIVATE | MAP_ANON | MAP_ALIGNED(alignbit), -1, 0);
<damo22>it probably uses rumpuser_anonmap
<damo22>anonmmap
<azert>damo22: here rump mmap is defined https://ftp.netbsd.org/pub/NetBSD/NetBSD-release-10/src/sys/rump/include/rump/rumpvnode_if.h
<azert>it just ends up using netbsd rumpkernel mmap https://man.netbsd.org/vnodeops.9
<azert>But I don’t see how
<damo22>rumpuser_anonmmap
<azert>that’s like malloc
<azert>how does it serves the content of the file?
<damo22>magic in vnops
<azert>yes I think it is possible
<azert>One would have to connect the Hurd file and pager api to the netbsd vfs api
<azert>somehow similar job to what libdiskfs does
<azert>maybe libdiskfs can be used