Restarting part_block and vfs server

Developer's Corner
1

Howdy Genodians…

Well let’s get the ball rolling. There’s a question I’ve been wondering for a couple days that would probably be on-topic for the mailing-list, but I figure it would be nice to post it here to test drive the new forum instead. If there was a “development” channel it would probably go there.

The question is… I’m implementing a partition-setup tool for my Genode-based system. Currently getting to grips with “gpt_tool”. Of course it cannot access the ahci driver if part_block and vfs are already plugged into it.

So I figure, the right way to go about it is similar to (what I believe) SculptOS does : tear down the vfs, then part_block (there might be ‘dangling’ file descripitors in apps ?), do my gpt_write and ntfs formatting, then restore things in reverse order. How does that sound.

P.S. I’m “ttcoder” from the mailing-list, Norman kindly offered me to help animate this discourse a bit. I hope to allocate time as I do on the mailing list. That is to say, occasional posts and response. One benefit I can think of, is the ability to edit posts for spelling mistakes (I tend to make lots of those!), vs emails which are “forever” ^^

2 Likes
2

That is indeed how it is implemented in Sculpt OS. The partition operations are presented only if the block device is currently unused. So the user needs to take a deliberate step to release the block device from use (un-use, un-inspect). So the complicated problem of winding down the VFS is conveniently side-stepped as this is the job of the user.

For chaining operations, like expanding a partition followed by resizing the contained file system, the sculpt manager tracks the exit state of the spawned components using init’s state report. Once gpt_write exits, its exit code becomes visible in the state reported by the runtime init. When seeing the desired state, the sculpt manager enters the next stage by removing the gpt_write component from the runtime-init config and adding the resize-fs component instead.

3

Ok I was on the right track then. Thanks. Pushed a commit today along these lines, although my init-based stack does not yet propagate the exit status – so as a field-expedient work-around I make the code sleep for a few seconds inbetween chained ops (:blush: ). It’s only a unit test so far, but once I integrate that into a ‘distro’ I’ll test for real. I purchased a used HDD so that I can safely test wiping partitions and re-format on “bare metal” without worrying about losing any of my data ^^