While going through Device Driver Architecture — Haiku internals documentation I noticed a TODO for a picture of the device node tree.
I have created a basic draft from my understanding of the tree.
If you plan to add this to haiku documentation then please add this as a svg, and not ASCII.
I can’t comment on the technical accuracy however.
Depending on the machine, the PCI Host controller could be at the root (detected using legacy mechanism) or under ACPI (detected as an ACPI node).
In this specific page, the picture can remain quite generic, since it is only about the general operation of the device manager. There could be more detailed examples for each bus and driver in other pages, documenting what attributes are available in the nodes to identify them and attach drivers to them.
If you plan to add this to haiku documentation then please add this as a svg, and not ASCII.
Sure. Any particular reason for it?
Depending on the machine, the PCI Host controller could be at the root (detected using legacy mechanism) or under ACPI (detected as an ACPI node).
Oh, completely missed that. I will add a note for it.
There could be more detailed examples for each bus and driver in other pages, documenting what attributes are available in the nodes to identify them and attach drivers to them.
Makes sense. I am going through a lot of the driver source code so will try to update the docs as an when I understand something. Should make life simpler for people interested in writing drivers.
I have made some changes so I think I will submit a patch for it, doing this for the first time so I hope I don’t mess it up!
I’m not sure I understand?
For one Haiku doesn’t use ASCII but UTF-8, so restricting to using ASCII in documentation is a bit silly.
For another this part of the docs asked for an image, and text lends itself very badly to that. While an svg can keep the properties of how it is supposed to look. Even if you copy it out of the website and use it somewhere else or send it.
Haiku generally prefers vector formats for images, though not svg. But svg is about the only thing supported for webbrowsers.
Vector images have the big advantage that they look good regardless of what pixel density physical size your monitor has.
One seperate concern to this may be making this svg work with a dark theme aswell, this is done by a switch in the html which serves two seperate versions based on the requested version. But so far nothing else in the docs does this, and reworking many old images for that might be a lot of work, so not sure if I should be asking for that in general ; )
Using a SVG over a bitmap in this case alsp has the advantage that a SVG is vastly easier to edit if we need to change anything. If you were to use a bitmap image format you’d usually need a seperate “source” file (for example a womderbrush document). But those generally are already a vector format.
Well to keep the response shorter: the documentation is available in html format at Welcome to Haiku internals’s documentation! — Haiku internals documentation
The goal is to have that online version easy to read, and easy to keep up to date. That is much easier with an SVG file, than with either a bitmap (hard to touch up if we want to relayout it or change some text in it), or an “ASCII art” drawing (also hard to modify, for different reasons).
We may later export this documentation in other formats (pdf, for printing or use in ebook readers maybe), and there, ASCII art would feel a bit out of place.
Using a SVG over a bitmap in this case alsp has the advantage that a SVG is vastly easier to edit if we need to change anything. If you were to use a bitmap image format you’d usually need a seperate “source” file (for example a womderbrush document). But those generally are already a vector format.
That makes sense. I was just curious.
here’s the patch for reference: https://review.haiku-os.org/c/haiku/+/8983
