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
And yes, we are aware how big a ppc64 kernel is. One might argue that you need a 64 bit kernel only for big systems, so resources are cheap. On the other hand, we are also aware how big the 2.6 kernel is compared against 2.4, and how it suffers performancewise.
I wouldn't say it sufferred performance wise on all architectures. Small embedded CPUs may have sufferred (mostly because of larger memory footprint impact on small TLBs), but ppc64 is definitely not something you ever want to use with a 2.4 kernel, and I would expect 2.6 to be faster on 6xx/7xx/7xxx type CPUs as well.
My concern is that just adding a few kB of code here and there and passing a bit more data from A to B and using ASCII representation for the data and all of that will result in elegant and easily maintainable code on one side, but to even bigger memory footprints for boot loader and kernel and longer boot times on the other side, too. We have seen before how this works.
I don't think it will have any significant impact on the boot time. Not at all. In fact, I'm not even sure the code would be that much bigger neither. For example, all the code needed to declare all the device-specific platform devices used in some case would be _replaced_ by a generic routine that declares a device based on the device-tree data, that sort of thing. I honestly cannot tell what kind of bloat is to be expected, but I really don't think it will be relevant.
Even the code for iterating the fully expanded device-tree & properties in the kernel isn't big, but as I wrote earlier, a non-ppc architecture wanting to use that proposal may want to work directly on the flattened tree.
I REALLY think people are over-estimating the size & complexity of the device-tree.
A few tens or hundreds of milliseconds of boot time may not mean anything on a fast 64 bit machine which will spend ages anyway while scanning a lot of SCSI busses and all that, but it will *hurt* on many embedded systems.
I wouldn't even expect that much.
I would expect something like uboot to be a bit more smart though and provide optionally some functions to add nodes/properties, but heh, we'll see. I'll try to provide example code after I'm done with the spec part.
It's not only an issue of being smart enough. It has also a lot do to with hardware restrictions. If you have a product that sells several 1e4 or 1e5 units per year which now works with just 4 MB of flash for boot loader and Linux kernel and application code you have hard times to explain that the next software generation will need bigger (and more expensive) flashes just because of using more elegant code.
Yes, small *is* beautiful.
Did you read the "optional" above ? Let me repeat _AGAIN_ here: the bootloader doesn't _need_ ANY code to deal with the device-tree if you decide to just build the blob once for all, and embed it "as is". However, not everybody is fighting after 10 bytes of flash, and thus it would be useful if optionally, uboot could provide the machine specific code with functions to do things like edit the memory or bootargs properties in there.
We had this discussion before, several times. There once was a proposal by Mark A. Greer (see discussion on the linuxppc-embedded mailing list that started as "EV-64260-BP & GT64260 bi_recs" around March 19, 2002) which was elegant, flexible and lean. If it was not actually sad it could be funny that the general agreement will always end up to be the biggest and slowest of all possible solutioins.
Fuck it ! This is not by far the biggest and slowest of all solutions, the tree format is on purpose very compact, it's not a few strings that will make that much of a difference, damn . Do you really want me to propose ACPI AML instead ?
Besides, I know the bi_rec stuff well as I propoed it in the first place, and nobody ever came to an agreement about that neither.
Face it, there will NOT be any other way that will be accepted upstream to boot a ppc64 kernel.
But my biggest concern here on the U-Boot list is: U-Boot is not only for PowerPC systems. We should also keep an eye on what ARM and MIPS is doing... See my other posting.
Sure, you are welcome to do so. I'm posting to this list because of Marvell's intend to use uboot as a bootloader for what appear to be the first ppc64 platform not to implement the OF command line interface.
Ben.