Was planning to post on this (before going back to the mailing-list for the “year debrief” thread) but John beat me to it ^^
I’ll first post my understanding of the situation re XML configuration, before adding random thoughts.
In the past years the XML config was sometimes the object of discussions. Some focused on the XML syntax itself, and some on the semantic aspect it is used for, i.e. configuring the system. That latter one is one of the more hairy parts: the Genode framework fully empowers the system integrator to set “wires” and “pipes” to connect components with each others, to a degree that is unseen in other systems, I suspect. All OS’es strike a balance between hardcoding configuration in (C++ ?) code on one hand, or allowing the system designer (or even the end-user) to set the configuration in text files, like in the Linux /etcdirectory, on the other hand. Of the systems I am familiar with, most don’t allow for the outright removal of “lego bricks”, whereas Genode not only allows for it, but allows to do it by editing a textual config. One may ‘restack’ the storage stack, audio stack, net stack, etc, without writing one line of C++ code. One may remove (or add) new layers in the stack, re-organize how the “lego bricks” deal with each other, make the system as small and agile or as full-featured as desired, just by redesigning the XML config… It helps hugely for QA/unit-testing/debugging, and of course it gives Genode its unbelievable flexibility for running on various hardware and to perform various scenarios. That’s fanstastic to have.
But “with great power, comes great responsibility” 
… All complexity which is normally (in other operating systems) handled in code, is (in Genode) exposed in the XML config instead. The fact that it is textual does not remove the obligation to “get things right”, in order to obtain a working system.It just makes it cleaner, being cleanly separated from the code (kinda like the modern web separates contents and presentation, HTML and CSS stylesheets, I guess), but the complexity is still there… Some of it unavoidable – we don’t want to remove the ability to connect components together and various ways… And some of it (I believe) might benefit from further improvements and ambiguity reduction.
So over the years, I’ve been pondering that latter aspect, more than the XML syntax aspect. That is, a possible move away from XML would (as far as I’m concerned) be more a means to an end, not so much an end in itself. From Norman’s article, wIth the hrd command-line tool that is hinted at, I’d guess that configuration might become easier, or at least benefit from more infrastructure for someone looking to make it easier : that new hrd command might serve as a building block for (at least in my case) the developer/integrator to build upon, to create some sort of ‘assistant’ tool that deals not just with the syntax (don’t forget to close every open tag and chevron etc) but also with the semantics (a report_rom must be connected at both ends, don’t forget the policy, etc).
Now for the ‘remarks in no particular order’:
Reading this sample I was wondering why the children of vfs didn’t have the ‘pipe’ char leadig the ‘+’ char, whereas the children of dir did have pipes… But the above response addresses that: the pipe is optional:
config
+ vfs
+ tar bash-minimal.tar
+ tar coreutils-minimal.tar
+ tar vim-minimal.tar
+ dir dev
| + zero
| + null
| + terminal
- as I read the article, I find myself mentally translating the hdr samples to XML on-the-fly to understand them; it’s probably only natural since I’ve had just a few hours of exposure to them, once I get more familiar in the coming months I won’t have to worry so much about that.
- agreed it would be important for the hdr class to have an
as_xml() getter and for Xml_node to have from_hdr()setter. That part of the code can be discarded in a year or two after the migration is complete (or moved outside of the TCB, like the printf/sscanf-like code that was moved last year) to keep a “tight ship”.
- good that white spaces are not semantically significant
- don’t expect wiki (or others) to suddenly stop harping on the “Genode uses XML” theme, they’ll surely find other subjects to gripe on – if the Genode community migrates away from XML we should do it for our own sake and because it empowers us, not to please people who don’t use Genode
- SH (syntax highlighting): as I work with various text formats these days (often Genode related), including some out-of-the-beaten-path ones with no bovious S.H. option, I tend to use tricks to syntax-highlight them, with some degree of success. For example, editing Genode .run files or my own Jamfiles, I switch between XML mode and something like Bash/Shell mode, depending on whether I’m reviewing/editing the XML-like part of the file or the one with
# pound signs that denotate commented-out lines. Will I find a S.H. mode in my editor that matches the HRD format? It uses tokens I’ve never seen before, for commenting out a line etc, so the jury is still out. I’ll take a look, and maybe craft a new mode from scratch, if none of the existing ones match, we’ll see. (and maybe someone else will experiment and report “such and such S.H. mode works well for me”).
- admittedly, part of the need for S.H. relates to the “noise” inherent to the XML syntax: once you remove that noise (chevrons etc), then there might not all that much stuff to highlight. But the “remed out line” part seems worth it to me, especially with the “x” character, which does not at all register instinctively as “comment out” in my mind. Another candidate would be “:” colon prefixed embeddings.
- plus, “comment” lines have a different prefix from “commented-out” lines (quote versus ‘x’)
- as always with text data, there’s an infinite number of ways a hand-crafted config can go wrong and have typos… I suspect a big part of the “make or break” result for us developers will be how graceful the error handling will be. If we end up with ‘breakage’ situations that are impossible to get out from, that’ll be a lot of friction! We want to avoid that… Even if it’s very hard to foresee all the different typo types that exist and how to deal with them…
- I can already detect one way that HRD wil help me: in my Jamfiles (unlike in Genode’s .run files) I’m forced to escape XML quotes, due to Jam constraints. Since HRD makes little to no use of quotes, that’ll make things easier for me, at least in that respect.
- Re. migration, I suppose one migration path would be 1) Genode Labs write all new config contents in HRD, then 2) starts converting old XML contents to HRD too. Assuming Genode can support both during the migration period.
So overall a careful 
from me as I trust the Genode team to take care of us as always ^^.
) can possibly make, guiding me to the correct config – that seems like an impossibly large task for the Genode team, just to accomodate a small handful of recalcitrant devs ; not to mention, this would enlarge the TCB with un-necessary code, which is a big no-no ; or 2) we move the problem out of the TCB, probably into the lap of a third-party developer, in the form of a textual or visual tool that helps me build the config. I’ve been thinking about that for a few years, and will probably keep thinking about that unproductively for a few more years, so please carry on with the (more productive) rest of this thread, I don’t want to interrupt 