Hi,
I notice in http://tracker.coreboot.org/trac/coreboot/ticket/88 that Coresystems is no longer working on GRUB 2 (that's too bad, sorry that it didn't work out, etc...).
I have nothing to say about what you will be recommending as default bootloader in the future. Right now your wiki still recommends GRUB 2, and I suppose Coresystems folks will want to push for FILO. But this is not a discussion I want to be involved in (just wanted to clarify ;-)).
What I'm concerned about is that http://www.coreboot.org/GRUB2 in the wiki currently points to a branch of GRUB that is (unless I missed something) no longer being maintained. And it provides information that will, over time, become more and more obsolete. I'm worried that this can reflect bad on the image of GRUB.
So what I'd like is permission to keep it up to date, and reflect the current state of GRUB mainline. If you would give me a wiki account to do that, it'd be much appreciated.
Thanks
On Fri, Sep 5, 2008 at 5:08 PM, Robert Millan rmh@aybabtu.com wrote:
So what I'd like is permission to keep it up to date, and reflect the current state of GRUB mainline. If you would give me a wiki account to do that, it'd be much appreciated.
The payloads page would need to be updated too, then.
On 05/09/08 17:08 +0200, Robert Millan wrote:
Hi,
I notice in http://tracker.coreboot.org/trac/coreboot/ticket/88 that Coresystems is no longer working on GRUB 2 (that's too bad, sorry that it didn't work out, etc...).
I have nothing to say about what you will be recommending as default bootloader in the future. Right now your wiki still recommends GRUB 2, and I suppose Coresystems folks will want to push for FILO. But this is not a discussion I want to be involved in (just wanted to clarify ;-)).
Coresystems has people that depend on them for a livelyhood - they have to do what is best for their customers, and we are very lucky that their goals often align with those of the community. I do wish things had ended up differently, but I welcome the FILO work because it make both FILO and libpayload that much better, and thats not a bad thing.
But I don't think we as a community are ready to abandon GRUB2 quite yet. We need a working bootloader for Linux, that is true, but I believe in providing options to our customers. If there are people willing to do the work for GRUB2, then we'll be glad to keep tracking it in the wiki and in buildrom.
When you anoint a single program as the "chosen one" then you lock yourself for trouble down the road. I would much prefer to chose between 3 great programs then one mediocre one.
What I'm concerned about is that http://www.coreboot.org/GRUB2 in the wiki currently points to a branch of GRUB that is (unless I missed something) no longer being maintained. And it provides information that will, over time, become more and more obsolete. I'm worried that this can reflect bad on the image of GRUB.
So what I'd like is permission to keep it up to date, and reflect the current state of GRUB mainline. If you would give me a wiki account to do that, it'd be much appreciated.
I second the request.
Jordan
Coresystems folks will want to push for FILO.
I've actually been think about FILO alot lately. The code is still solid. With libpayload progressing, it would be really cool to see a "FILO 2.0" that is totally revamped with all dependencies on libpayload and all the great things libpayload has to offer. Just something I have been pondering lately....
Joseph Smith wrote:
Coresystems folks will want to push for FILO.
I've actually been think about FILO alot lately. The code is still solid. With libpayload progressing, it would be really cool to see a "FILO 2.0" that is totally revamped with all dependencies on libpayload and all the great things libpayload has to offer. Just something I have been pondering lately....
Yep, that's pretty much where it's going...
FILO might become just the main loop calling libpayload functions and painting a nice menu.
On Fri, 05 Sep 2008 18:45:41 +0200, Stefan Reinauer stepan@coresystems.de wrote:
Joseph Smith wrote:
Coresystems folks will want to push for FILO.
I've actually been think about FILO alot lately. The code is still
solid.
With libpayload progressing, it would be really cool to see a "FILO 2.0" that is totally revamped with all dependencies on libpayload and all the great things libpayload has to offer. Just something I have been
pondering
lately....
Yep, that's pretty much where it's going...
FILO might become just the main loop calling libpayload functions and painting a nice menu.
Do you mean integrating FILO into libpayload or will the FILO main() still be seperate code? I like the "painting a nice menu" part. Maybe with a pretty coreboot logo too... While we are on the subject, I was also thinking about how hard would it be to allocate a small part of flash as a read/write user area for saving boot options?
Joseph Smith wrote:
FILO might become just the main loop calling libpayload functions and painting a nice menu
Do you mean integrating FILO into libpayload or will the FILO main() still be seperate code?
No, it will always stay seperate code.
I like the "painting a nice menu" part. Maybe with a pretty coreboot logo too...
While we are on the subject, I was also thinking about how hard would it be to allocate a small part of flash as a read/write user area for saving boot options?
With flashrom ported to libpayload it should be quite reasonable.
If nvram (256 bytes of cmos) are enough, you can have that right away.. FILO 0.6 has an option to read the default menu entry from cmos, and it can be set/changed with nvramtool.
On Fri, 05 Sep 2008 19:17:13 +0200, Stefan Reinauer stepan@coresystems.de wrote:
Joseph Smith wrote:
FILO might become just the main loop calling libpayload functions and painting a nice menu
Do you mean integrating FILO into libpayload or will the FILO main()
still
be seperate code?
No, it will always stay seperate code.
I like the "painting a nice menu" part. Maybe with a pretty coreboot
logo
too...
While we are on the subject, I was also thinking about how hard would it
be
to allocate a small part of flash as a read/write user area for saving
boot
options?
With flashrom ported to libpayload it should be quite reasonable.
If nvram (256 bytes of cmos) are enough, you can have that right away.. FILO 0.6 has an option to read the default menu entry from cmos, and it can be set/changed with nvramtool.
Cool I did not know that, is it documented on the wiki somewhere?
On Fri, 05 Sep 2008 13:39:18 -0400, Joseph Smith joe@settoplinux.org wrote:
On Fri, 05 Sep 2008 19:17:13 +0200, Stefan Reinauer stepan@coresystems.de wrote:
Joseph Smith wrote:
FILO might become just the main loop calling libpayload functions and painting a nice menu
Do you mean integrating FILO into libpayload or will the FILO main()
still
be seperate code?
No, it will always stay seperate code.
I like the "painting a nice menu" part. Maybe with a pretty coreboot
logo
too...
While we are on the subject, I was also thinking about how hard would
it
be
to allocate a small part of flash as a read/write user area for saving
boot
options?
With flashrom ported to libpayload it should be quite reasonable.
If nvram (256 bytes of cmos) are enough, you can have that right away.. FILO 0.6 has an option to read the default menu entry from cmos, and it can be set/changed with nvramtool.
Cool I did not know that, is it documented on the wiki somewhere?
Looks like the nvram page on the wiki says:
Some of the fields are used by payloads - for instance all the fields that start with 'boot_' in the list above. FILO does not use those fields currently, but Etherboot does (someone confirm this please!).
Does this need to be updated?? Has it been confirmed??
Joseph Smith wrote:
Looks like the nvram page on the wiki says:
Some of the fields are used by payloads - for instance all the fields that start with 'boot_' in the list above. FILO does not use those fields currently, but Etherboot does (someone confirm this please!).
Any payload using libpayload can read arbitrary variables listed in cmos.layout with the functions libpayload provides.
The documentation there is quite outdated.
See http://tracker.coreboot.org/trac/filo/browser/trunk/filo/main/grub/builtins.... for an example.
Does this need to be updated?? Has it been confirmed?
Yes, I think this should be updated.
On Fri, Sep 05, 2008 at 09:42:29AM -0600, Jordan Crouse wrote:
On 05/09/08 17:08 +0200, Robert Millan wrote:
Hi,
I notice in http://tracker.coreboot.org/trac/coreboot/ticket/88 that Coresystems is no longer working on GRUB 2 (that's too bad, sorry that it didn't work out, etc...).
I have nothing to say about what you will be recommending as default bootloader in the future. Right now your wiki still recommends GRUB 2, and I suppose Coresystems folks will want to push for FILO. But this is not a discussion I want to be involved in (just wanted to clarify ;-)).
Coresystems has people that depend on them for a livelyhood - they have to do what is best for their customers, and we are very lucky that their goals often align with those of the community. I do wish things had ended up differently, but I welcome the FILO work because it make both FILO and libpayload that much better, and thats not a bad thing.
I understand. I didn't mean to say it is!
When you anoint a single program as the "chosen one" then you lock yourself for trouble down the road. I would much prefer to chose between 3 great programs then one mediocre one.
It seems I made too many assumptions; sorry about that. Let me put it as: whatever you choose to endorse or recommend is not my problem. I just want to make GRUB provide good support for coreboot, and (to the extent that this is reasonable) that users can find readily available information about it when browsing your list of supported payloads.
Robert Millan wrote:
I have nothing to say about what you will be recommending as default bootloader in the future. Right now your wiki still recommends GRUB 2, and I suppose Coresystems folks will want to push for FILO. But this is not a discussion I want to be involved in (just wanted to clarify ;-)).
We've not been pushing any "default bootloader" in the past, nor will we do so in the future. I believe coreboot is about freedom and choice. And about making stuff that people can actually use. Now, this last criteria is different for a multitude of use cases.
What I'm concerned about is that http://www.coreboot.org/GRUB2 in the wiki currently points to a branch of GRUB that is (unless I missed something) no longer being maintained. And it provides information that will, over time, become more and more obsolete. I'm worried that this can reflect bad on the image of GRUB.
I wonder whether we need to keep our own GRUB2 page at all, since there's a coreboot page in the GRUB2 wiki already and if things go as you suggest, one of them will eventually be a copy of the other one.
So what I'd like is permission to keep it up to date, and reflect the current state of GRUB mainline. If you would give me a wiki account to do that, it'd be much appreciated.
Use ist wisely. And please create User:RobertMillan so people know who you are.
All the best,
Stefan
On Fri, Sep 05, 2008 at 05:52:51PM +0200, Stefan Reinauer wrote:
Robert Millan wrote:
I have nothing to say about what you will be recommending as default bootloader in the future. Right now your wiki still recommends GRUB 2, and I suppose Coresystems folks will want to push for FILO. But this is not a discussion I want to be involved in (just wanted to clarify ;-)).
We've not been pushing any "default bootloader" in the past, nor will we do so in the future. I believe coreboot is about freedom and choice. And about making stuff that people can actually use. Now, this last criteria is different for a multitude of use cases.
Ok, understood. Thanks for the clarification. Anyway, I just wanted to make it clear that it's not my bussiness if you decide to endorse or recommend something else. My goal is to improve GRUB and its associated documentation & support, and that's it.
What I'm concerned about is that http://www.coreboot.org/GRUB2 in the wiki currently points to a branch of GRUB that is (unless I missed something) no longer being maintained. And it provides information that will, over time, become more and more obsolete. I'm worried that this can reflect bad on the image of GRUB.
I wonder whether we need to keep our own GRUB2 page at all, since there's a coreboot page in the GRUB2 wiki already and if things go as you suggest, one of them will eventually be a copy of the other one.
Or perhaps in long-term one of them could become a stub for the other? I'll talk about this with Marco and the other GRUB developers too. Anyway, in short term I'd like to put there a summary of GRUB status from coreboot perspective, including:
- The info which is currently in http://grub.enbug.org/CoreBoot
- References to information about other areas indirectly related to coreboot (such as USB support).
- A reference to the Coresystems branch, highlighting the extra features, in case someone is interested.
Seeing that you approved my account request, if there are no objections I'll proceed to prepare an edit for that page.
So what I'd like is permission to keep it up to date, and reflect the current state of GRUB mainline. If you would give me a wiki account to do that, it'd be much appreciated.
Use ist wisely. And please create User:RobertMillan so people know who you are.
Thank you. I will.
On Sat, Sep 06, 2008 at 12:02:09AM +0200, Robert Millan wrote:
Use ist wisely. And please create User:RobertMillan so people know who you are.
Thank you. I will.
I hope it's not too informal (but if it is, let me know and I'll find another picture):
http://www.coreboot.org/User:RobertMillan
On 06/09/08 01:39 +0200, Robert Millan wrote:
On Sat, Sep 06, 2008 at 12:02:09AM +0200, Robert Millan wrote:
Use ist wisely. And please create User:RobertMillan so people know who you are.
Thank you. I will.
I hope it's not too informal (but if it is, let me know and I'll find another picture):
Seesh, a picture? YOu are making the rest of us look bad over here :)
Jordan
-- Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all."
-- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On 05.09.2008 17:08, Robert Millan wrote:
I notice in http://tracker.coreboot.org/trac/coreboot/ticket/88 that Coresystems is no longer working on GRUB 2 (that's too bad, sorry that it didn't work out, etc...).
[...] What I'm concerned about is that http://www.coreboot.org/GRUB2 in the wiki currently points to a branch of GRUB that is (unless I missed something) no longer being maintained. And it provides information that will, over time, become more and more obsolete. I'm worried that this can reflect bad on the image of GRUB.
The most interesting question is why these GRUB patches were not merged upstream. If any, that may reflect badly on the image of GRUB.
Regards, Carl-Daniel
On Fri, Sep 05, 2008 at 06:10:44PM +0200, Carl-Daniel Hailfinger wrote:
The most interesting question is why these GRUB patches were not merged upstream. If any, that may reflect badly on the image of GRUB.
I won't argue against your preconception that this is GRUB's fault, mainly because this is a thing of the past, and I believe both sides have agreed to move on, but also because my perspective is probably biased.
To answer your question, suffice to say that the FSF and Coresystems didn't agree on the legal framework to be used for the contributions, because of a variety of reasons which I don't even know in detail. Therefore both sides exercised their legitimate right not to engage in collaboration under terms that weren't suitable for them.
If I expressed any opinion about this before, it is a mistake, and I now reserve my opinion for myself. I don't represent the FSF, and the only thing I care right now is to make GRUB as good as possible so that coreboot users may find coreboot/GRUB a suitable combination.
-
Carl-Daniel Hailfinger -
Jordan Crouse -
Joseph Smith -
Robert Millan -
Stefan Reinauer -
Vincent Legoll