IRC channel logs

<damo22>has anyone been working on doing the actual removal of linux/ from gnumach?

<damo22>are we at that point yet?

<youpi>gnumach can be built fine without linux/ yes

<youpi>for now rumpdisk still consumes too much memory before being able to enable it by default

<damo22>ok

<youpi>one "detail" is that the 128MB heap is locked-in in memory

<youpi>we'd need to change the sbrk/mmap allocation to avoid that

<damo22>how does gnumach disk driver avoid consuming so much ram

<youpi>that's a long-standing concern that we don't control that much how sbrk/mmap are layed out in memory

<youpi>it just doen't allocate it

<youpi>while in hurd, all processes have a 128MB reserved heap

<youpi>that's not usually a problem

<youpi>unless you use mlockall

<damo22>ah

<youpi>which rumpdisk does

<youpi>also, there is the todo about asynchronous requests

<damo22>how does async io work? is it difficult to do?

<youpi>that'd avoid piling up threads when running multiple requests

<youpi>it's not very difficule

<youpi>it's just about calling aoi_read

<youpi>and keeping a list of request

<youpi>gotrta go

<damo22>thx

<Pellescours>damo22: I have a branch with the linux code removed

<Pellescours>but can we before add a driver to be able to start in ide/ata? Because it’s the default mount option for qemu and if we remove completely support for it, a lot of pœple will complain about it

<youpi>sure we'll have to do this

<youpi>(note: there's a --disable-linux-groups option)

<damo22>yeah ok

<damo22>i *think* it could be as simple as linking with libpcidev_piixide

<damo22>when compiling rumpdisk

<curiosa>Hi, since I've seen from the logs that you are making a list of what is missing to get rid of the kernel space disk driver, I would like to add two things

<curiosa>The first one is a functioning cdrom driver

<curiosa>The second one, maybe, it is a transition plan that will allow people to upgrade without breaking their system: perhaps just keeping two version of gnumach in repositories for a while and a deprecation deadline will suffice

<youpi>the cdrom driver works

<youpi>in sata mode

<youpi>probably the ide driver will drive them fine

<youpi>yes, the transition plan is definitely needed

<youpi>a deprecation deadline may not really be enough, if we want people to be able to upgrade from their Debian Hurd 2021 system into Debian Hurd 2023

<luckyluke>Hi, is there some benchmark available for mach_msg()? I see there are a lot of special cases, I wonder if it could be simplified

<youpi>at the time that was benchmarked and that was why they wrote the special cases

<luckyluke>do you think it still makes sense to keep these optimizations? I see xnu drastically simplified the code for mach_msg()

<youpi>I don't know, benchmarks can tell

<youpi>possibly that part of the code is not what eats most of the time, and rather the page mapping management / data copy

<youpi>but at the same time people get excited with L4 and such which precisly benchmarks smallish IPCs, which do benefit from such optimizations

<luckyluke>I'll try to do some measurements, I'm slowly writing a sort of unit tests for gnumach, to run under qemu as bootstrap modules :)

<youpi>nice

IRC channel logs

2022-03-02.log