IRC channel logs

<sneek>ZhaoM, you have 1 message!

<sneek>ZhaoM, youpi says: yes, ext2fs can understand partition tables, thanks to using libstore which uses libparted behind. But then that's the issue: libparted is gpl3 while ext2fs is gpl2-only, so we need to separate them in two translators, a storeio and ext2fs

<ZhaoM>youpi: separating the program to avoid the license conflict? That's cool

<youpi>yes, that's the cool thing with translators

<youpi>that allows to put boundaries

<youpi>whether to separate bugs, or licences :)

<Pellescours>that also will help to support GPT partition right?

<youpi>separating won't particularly help or not

<youpi>it's the storeio/libstore design that allowed it

<youpi>(by not using the in-kernel support for partitions)

<Pellescours>ah ok

<ZhaoM>youpi: does it matter to exclude the parted module of /hurd/ext2fs?

<ZhaoM>or it is only needed by /hurd/ext2fs.static at bootstrap

<ZhaoM>s/it/parted module/

<youpi>libpart is gpl, not lgpl, so it has to be excluded from ext2fs, not only ext2fs.static

<ZhaoM>I mean from the point of view of functionality

<damo22>youpi: netbsd has ext2fs support

<damo22>would it be preferred not to require another translator in between?

<damo22>i was not aware of that license conflict

<youpi>ah, for functionality ext2fs.static currently really needs the parted module since it doesn't currently have a partio translator next to it

<youpi>s/partio/storeio/

<Pellescours>why vm_pageout_page does not set the page as dirty = FALSE ? This make the kernel retain it even if data was written (when the page is kept in cache)

<Pellescours>And also, cannot gnumach use the page protections to avoid needing to copy the page? i.e. mark the page as read_only, ask the pageout to the pager, and then restore the perms (if the architecture support page access rights, and otherwise do the copy)

<Pellescours>(if I understand correctly the pagout mechanism)

<Pellescours>youpi: I tried to put the m->dirty = FALSE at the end of the vm_pageout_page function and I’m not able to reproduce the hang when I do the heavy copy, the yellow memory still growth, but some part is correctly released when a process needs more memory. If you understand the vm system enough, can you tell me if this change seems coherent/valid. And if it’s the correct behavior, I can submit a patch,

<Pellescours>or you can do the fix directly (as it’s a one line change)

<Pellescours>Ah nevermind, actually after the reboot (no crash a normal reboot), a lot of inodes where invalid

<Pellescours>(or maybe the fix is totally valid but I got another bug)

<Pellescours>actually I retried and the system hang, so it does not fix the problem

<youpi>Pellescours: various stuff can produce hangs, that's why it's important to closely observe the bug, not just observe the most apparent symptoms, to determine whether one is making progress in fixing hangs

<youpi>gnu_srs1: it's way easier to convince debian maintainers to include upstream patches when they have already been applied upstream

<gnu_srs1>youpi: So you mean that the meson patches should have been sent upstream, and the Debian patch to Debian BTS?

<youpi>gnu_srs1: it has to land there in the end yes, so better discuss directly with upstream to get it there, and then possibly ask debian to backport it while waiting for the newer release

IRC channel logs

2025-01-08.log