On Fri, 2005-05-20 at 08:33 +1000, Benjamin Herrenschmidt wrote:
Marius was talking about the amount of data passed to the kernel.
A few Kb maybe... Current implementations always provide a full featured device-tree with pci devices so they aren't a good example (and I don't have numbers in mind at the moment). I'll try to get some later today. The property names are factored out (only one copy of a given name) to avoid bloat, the node format is very compact, A small device-tree would be only about a dozen node (the minimal is 5 nodes including the root) with only a few properties
Ok, I got some numbers here. (I have removed the page alignment constraint for the DT block and the strings block in the "blob" passed in btw, I forgot to update v2)
- The minimal example device-tree given as an example in the document (exactly identical as the one in v2 of the document, which means it may even shrink more, see below) fits in a blob (complete with header) of 764 bytes.
- The complete device-tree of my PowerMac laptop (this is _huge_, Apple puts a _lot_ of stuff in there, way more than most embedded board even the most complex ones will ever need) fits into a 37k blob.
I will come up with more numbers soon including a good "average" example that is a Maple board with all the ISA/serial stuff (which is very useful to have there) but without the individual PCI devices.
On an additional note, I'm also rev'ing up the blob format with additional space savings in mind:
- Current version is 2. That's what the kernel recognises and what current kexec tools generate (well... they actually generate a version 1 but the difference is minor).
- Version 3 will be backward compatible and just adds a "string table size" field to the header to help kernel do better memory management with the flattened device-tree. kexec can implement it, older kernel will still understand the tree.
- Version 16 will not be backward compatible (will require kernel patches, but that should be ok for new board vendors) that allows more space saving. For this version, I'm planning the following changes for now:
* Relax some alignement restrictions (already did it for the numbers above) * Allow replacing of the full path string with only the "name@unit address" part, letting the kernel reconstruct the full path. With this change, the "name" property get be dropped in each node as well as in can be reconstructed by the kernel. There is a lot of redundency in the full path, so that should save a bit. Side effect is also to remove any name requirement for the root node. * Make the "linux,phandle" property optional. It will only be required for nodes that are referenced by another node using a phandle value (typically, nodes part of the interrupt tree).
With those chances, the example minimal tree may shrink down to about 600 bytes (gross estimate), which would mean an average tree with a few devices would be between one and 3Kb (gross estimate too).
Ben.