Hi,
while I agree fully with renaming the project, we need to consider the point where we stop the renaming, also because some code referencing our code is outside of our control. We have LBTABLE structures and can rename them to CBTABLE. But will Linux kernel folks merge patches renaming the structs?
Different question for LAR. It's short and it actually can be pronounced. Do we really want to rename it to CBAR? Try to pronounce that. Renaming it to CAR would be even worse because it would be impossible to tell CorebootARchiver and CacheAsRam apart.
I didn't expect that the renaming business would be that much work with so many pitfalls.
Flames/comments welcome. I really feel lost in a maze of twisty little passages.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
Hi,
while I agree fully with renaming the project, we need to consider the point where we stop the renaming, also because some code referencing our code is outside of our control. We have LBTABLE structures and can rename them to CBTABLE. But will Linux kernel folks merge patches renaming the structs?
I can't think of any good reason not to.
Different question for LAR. It's short and it actually can be pronounced. Do we really want to rename it to CBAR? Try to pronounce that.
Eww, no argument with that.
Renaming it to CAR would be even worse because it would be impossible to tell CorebootARchiver and CacheAsRam apart.
And we don't want to assume that we could tell the difference based on context: "How do I use CAR on <system x>?" I'm trying to come up with better ideas, but I haven't got much. Perhaps BAR (Boot ARchive), since it's actually made up of coreboot + some other boot payload + extension roms, etc, but that seems like it could introduce confusion with Base AddRess.
I didn't expect that the renaming business would be that much work with so many pitfalls.
I don't think anyone really did. In hindsight, we probably should have just changed over v3 (since not many people should need old versions) and left the older versions alone. I wonder if it's possible to do a mass rename on the subversion server's archives, so subversion simply thinks it's always been coreboot.
Flames/comments welcome. I really feel lost in a maze of twisty little passages.
Regards, Carl-Daniel
Am Samstag, den 26.01.2008, 02:28 +0100 schrieb Carl-Daniel Hailfinger:
Different question for LAR. It's short and it actually can be pronounced. Do we really want to rename it to CBAR? Try to pronounce that. Renaming it to CAR would be even worse because it would be impossible to tell CorebootARchiver and CacheAsRam apart.
How about renaming LAR to "lightweight archive(r)" and keep the short name?
Regards, Patrick Georgi
On Jan 25, 2008 11:46 PM, Patrick Georgi patrick@georgi-clan.de wrote:
How about renaming LAR to "lightweight archive(r)" and keep the short name?
Good one. Works for me.
ron
ron minnich wrote:
On Jan 25, 2008 11:46 PM, Patrick Georgi patrick@georgi-clan.de wrote:
How about renaming LAR to "lightweight archive(r)" and keep the short name?
Good one. Works for me.
ron
Me too
-Corey
On 26.01.2008 09:46, Corey Osgood wrote:
ron minnich wrote:
On Jan 25, 2008 11:46 PM, Patrick Georgi patrick@georgi-clan.de wrote:
How about renaming LAR to "lightweight archive(r)" and keep the short name?
Good one. Works for me.
Me too
Same here.
Regards, Carl-Daniel
On Sat, Jan 26, 2008 at 08:46:29AM +0100, Patrick Georgi wrote:
How about renaming LAR to "lightweight archive(r)" and keep the short name?
Yes, let's keep lar.
*sigh* I really miss the LB acronym.
//Peter
* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [080126 02:28]:
while I agree fully with renaming the project, we need to consider the point where we stop the renaming, also because some code referencing our code is outside of our control. We have LBTABLE structures and can rename them to CBTABLE. But will Linux kernel folks merge patches renaming the structs?
what code in the linux kernel are you particularly referring to? Linux should be pretty much coreboot agnostic.
On 27.01.2008 03:01, Stefan Reinauer wrote:
- Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [080126 02:28]:
while I agree fully with renaming the project, we need to consider the point where we stop the renaming, also because some code referencing our code is outside of our control. We have LBTABLE structures and can rename them to CBTABLE. But will Linux kernel folks merge patches renaming the structs?
what code in the linux kernel are you particularly referring to? Linux should be pretty much coreboot agnostic.
Didn't the kernel have coreboot table parsing some time in the past? I'm not sure about current Linux code, though.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
On 27.01.2008 03:01, Stefan Reinauer wrote:
- Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [080126 02:28]:
while I agree fully with renaming the project, we need to consider the point where we stop the renaming, also because some code referencing our code is outside of our control. We have LBTABLE structures and can rename them to CBTABLE. But will Linux kernel folks merge patches renaming the structs?
what code in the linux kernel are you particularly referring to? Linux should be pretty much coreboot agnostic.
Didn't the kernel have coreboot table parsing some time in the past? I'm not sure about current Linux code, though.
Not that I know of.
The current linux kernel does not, I verified that.
The bootloader (payload) is preparing e820 entries to make linux see all of memory. Well, some of them do. Open Firmware does not. Which is why Torsten Duwe saw weeird problems when booting coreboot+openfirmware on a machine with 4G ram. I think Linux only saw 28M or some such 8)
The discussion reminds me we have to find a way to get the coreboot messages into dmesg, at least in v3. Any hints how to do this correctly? can it be done for the pre-ram code now that you improved the cache as ram stuff? that would be really really cool.
Stefan
On 27.01.2008 13:55, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
On 27.01.2008 03:01, Stefan Reinauer wrote:
- Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [080126
02:28]:
while I agree fully with renaming the project, we need to consider the point where we stop the renaming, also because some code referencing our code is outside of our control. We have LBTABLE structures and can rename them to CBTABLE. But will Linux kernel folks merge patches renaming the structs?
what code in the linux kernel are you particularly referring to? Linux should be pretty much coreboot agnostic.
Didn't the kernel have coreboot table parsing some time in the past? I'm not sure about current Linux code, though.
Not that I know of.
The current linux kernel does not, I verified that.
Good (or in that case bad) to know.
The bootloader (payload) is preparing e820 entries to make linux see all of memory. Well, some of them do. Open Firmware does not. Which is why Torsten Duwe saw weeird problems when booting coreboot+openfirmware on a machine with 4G ram. I think Linux only saw 28M or some such 8)
So if we want to pass any new information to a Linux kernel, we have to teach the bootloader about a new LBTABLE element and the bootloader has to translate that to an e820 section Linux can understand? Painful.
The discussion reminds me we have to find a way to get the coreboot messages into dmesg, at least in v3. Any hints how to do this correctly? can it be done for the pre-ram code now that you improved the cache as ram stuff? that would be really really cool.
Via e820? I have some code which keeps all messages from the beginning of CAR up to payload handoff in a local buffer. If anyone wants to write code which copies the buffer to some place where Linux expects it and handles the glue logic, be my guest.
Regards, Carl-Daniel
* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [080127 15:56]:
So if we want to pass any new information to a Linux kernel, we have to teach the bootloader about a new LBTABLE element and the bootloader has to translate that to an e820 section Linux can understand? Painful.
e820 is memory description only. You can't really put anything else in there. Most enhanced stuff (HPET) has to be passed via ACPI anyways. Which lead to this dream of mine to have one central data structure which can be used to create acpi, pirq, mptable, dmi/smbios, ... structures from the same consistent source.
Via e820? I have some code which keeps all messages from the beginning of CAR up to payload handoff in a local buffer. If anyone wants to write code which copies the buffer to some place where Linux expects it and handles the glue logic, be my guest.
e820 is not a solution here. I am not sure. Ron said he had a patch that made linuxbios logs available in linux at some point but i think it got lost. At least I could never find it on the net.
Stefan
On Sun, Jan 27, 2008 at 05:12:34PM +0100, Stefan Reinauer wrote:
Most enhanced stuff (HPET) has to be passed via ACPI anyways. Which lead to this dream of mine to have one central data structure
+1
which can be used to create acpi, pirq, mptable, dmi/smbios, ... structures from the same consistent source.
..for now, and later we'll teach Linux to read it directly.
In Hamburg we thought the device tree would do it. Does that still hold?
//Peter
* Peter Stuge peter@stuge.se [080127 17:24]:
which can be used to create acpi, pirq, mptable, dmi/smbios, ... structures from the same consistent source.
..for now, and later we'll teach Linux to read it directly.
In Hamburg we thought the device tree would do it. Does that still hold?
Actually there is more information than what we currently keep in the device tree. We can and have to put it in there at some point: PCI slots, IRQ routing, ... CMOS config settings (?), used devices a la which serial port to use (?) All this stuff could go to a device tree. Then we could use it as the one data structure that replaces the lbtable, too. It might or might not work.
-
Carl-Daniel Hailfinger -
Corey Osgood -
Patrick Georgi -
Peter Stuge -
ron minnich -
Stefan Reinauer