Questions regarding Issue #4323

Nobody III hungryninja101 at
Wed Nov 17 08:29:17 CET 2021

There are lots of things to work on. For example, the current AHCI driver
doesn't work on AMD hardware that I have tried it on. To be clear, I've
tried to solve this, but haven't succeeded yet. I have other stuff to work
on for school and personal projects, so I'm not sure when I might get
around to trying to solve it again.

Is there a place to put these? There are open issues, but lots of issues
have been closed simply because people stopped working on them. It seems
like a good idea to have a place that lists all the tasks that would be
appreciated if someone were to pick them up, with links to the
corresponding GitHub issues.

On Mon, Nov 15, 2021, 3:29 AM Norman Feske <norman.feske at>

> Hello,
> welcome Costinteo to the mailing list, and thanks Cedric for commenting
> on the question!
> > Costinteo wrote:
> >
> > I saw Issue #4323, regarding a possible memory
> > leak. To my understanding, this would be a very easy fix, just
> > free the void pointer that was allocated. Is that enough?
> Your understanding is right.
> The issue is indeed rather marginal and simple to fix. In practice, I
> have not witnessed a failure of map local. However, I spotted this
> potential problem while working on issue #4324 [1] and opened the
> separate issue #4323 [2] as a matter of hygiene instead of silently
> fixing it as I went. But there is also the broader observation, outlined
> below.
> [1]
> [2]
> > Cedrik wrote:
> >
> > [...] are there similar unspotted problems elsewhere in the code,
> > can it be solved with RAII instead of manual freeing [...]
> I think that issue #4323 highlights a fragile programming pattern of
> manually rolling back operations in the error case. So Cedrik's
> mentioning of RAII as an alternative is spot-on.
> When reviewing the core code related to 'map_local' - especially when
> looking at more than one base platform - one can observe the repeated
> sequence of allocating a physical range, allocating a virtual range,
> installing the mapping, accessing the mapped memory, unmapping, and
> releasing the virtual range. The manual repetition of this sequence
> ought better be replaced by a single implementation (using a lambda
> function for accessing the content similar to [3]). Once when going
> forward with implementing this general improvement, one can conveniently
> reference issue #4323 as the underlying motivation. ;-)
> [3]
> > How should I go about helping with this? Search for such spots and
> > add a deallocation for each I find, then create a pull request?
> Reports about potential bugs are highly appreciated. Should you
> encounter code that raises your eyebrows, please bring it up. So we can
> either explain why it looks the way it is (and likely comment the code)
> or improve/fix it.
> I'd not rush issuing pull requests to Genode's main repository in the
> beginning. To get familiar with the project and the community, it is
> certainly best to pursue a custom project of your genuine research
> interests, maybe contributing to genode-world [4] along the way. To get
> inspiration for potential topics to work on, you may find the
> "Challenges" page [5] insightful. Note that some of these topics are
> already being worked on. To coordinate, please don't hesitate to post
> your plans to this mailing list.
> You may also have a look at the recently published articles at
> [6] to get a tangible feeling about current topics of
> interest.
> [4]
> [5]
> [6]
> Cheers
> Norman
> --
> Dr.-Ing. Norman Feske
> Genode Labs
> ·
> Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
> Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
> _______________________________________________
> Genode users mailing list
> users at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list