Mathieu Deschamps mdeschamps@mangrove-systems.com writes:
Hello,
Since i have mostly 'directly choose' Filo, i haven't had much time asking for the difference between Linuxbios native's Elfboot and Linuxbios native's filo. I know you did made some work around theses...
The native ``filo'' is scheduled for deletion, it touches hardwaremain which it should not. As implemented it is a maintenance nightmare and an implementation of policy and I refuse to support it, in the core of LinuxBIOS. Until just a little while ago I thought it was much less intrusive so was not forcing the issue.
(i have read the doc of Sone Takeshi and i have the features of filo.)
Could you explain me what differences there are and/or whether this one best suited for DoC or CF or other types i'am ignoring ? Please also let me know what type of filesys elfboot boots, and other thing about support
ELF boot is a minimal loader just good enough to load something real out off some device. ELF boot just grabs an ELF image at the offset in a device it is pointed at. The image can be sparse so it can exist with partition tables and filesystems. The trivial solution is to put a partition right after partition table for the ELF image. More interesting forms of coexistance are possible by noone has implemented more than a proof of concept.
If you want to use filo which understand filesystems and partitions get the real one. It has been developing faster and it appears to have more features.
Eric
Le ven 04/06/2004 à 02:34, Eric W. Biederman a écrit :
Mathieu Deschamps mdeschamps@mangrove-systems.com writes:
Hello,
Since i have mostly 'directly choose' Filo, i haven't had much time asking for the difference between Linuxbios native's Elfboot and Linuxbios native's filo. I know you did made some work around theses...
The native ``filo'' is scheduled for deletion, it touches hardwaremain which it should not. As implemented it is a maintenance nightmare and an implementation of policy and I refuse to support it, in the core of LinuxBIOS. Until just a little while ago I thought it was much less intrusive so was not forcing the issue.
ok I understand.
(i have read the doc of Sone Takeshi and i have the features of filo.)
Could you explain me what differences there are and/or whether this one best suited for DoC or CF or other types i'am ignoring ? Please also let me know what type of filesys elfboot boots, and other thing about support
ELF boot is a minimal loader just good enough to load something real out off some device. ELF boot just grabs an ELF image at the offset in a device it is pointed at. The image can be sparse so it can exist with partition tables and filesystems. The trivial solution is to put a partition right after partition table for the ELF image. More interesting forms of coexistance are possible by noone has implemented more than a proof of concept.
If you want to use filo which understand filesystems and partitions get the real one. It has been developing faster and it appears to have more features.
Ok, this week I'am a bit brain-slowed, so I recap to see if I catch the whole meaning:
you say that filo shouldn't be inside Linuxbios in the way it forces implementation/maintenance that isn't clean. So that's it : letting payload type program to modify 'Linuxbios core' is not acceptable, is it ? Then you say, what I can is to adopt the outside filo solution 'the real one' that has not the above burden, and that have moreover a lots of feature the inside's filo haven't.
(I have made a tool lbcc to build, to configure a rom and I seek also it to do the payload whatever is your payload program. But i felt troubled by coding the 'payload maker' because i hadn't clearly seen the "2 filos" even if I felt them.)
Thanks for the explaination but.. err i still can't make myself answer to theses questions.
-Can ELF boot onto CF , DoC or even CDROM and others instead of normal hard disk ? -Can it boot kernel from ext2, ext3, iso9660 or others ? -Can it understand image like bzImage or others?
You see I would like to make truely a list of payload solutions in a tab, and to tick whatever this solution or this other can this or that. So that somebody's look on my tab, can say "-ok, this is my solution for my build config, and it handles that filesys, support that image format"
mathieu
Eric _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
On 4 Jun 2004, Mathieu Deschamps wrote:
The native ``filo'' is scheduled for deletion, it touches hardwaremain which it should not. As implemented it is a maintenance nightmare and an implementation of policy and I refuse to support it, in the core of LinuxBIOS. Until just a little while ago I thought it was much less intrusive so was not forcing the issue.
ok I understand.
well, I am afraid I do not.
No one has contacted any of the other core maintainers of linuxbios and vetted this suggestion of scheduling components for deletion. This suggestion of deleting the embedded filo came out of left field, at least to me. Major changes on this level need discussion!
LinuxBIOS is a cooperative project. People add things from time to time that others do not like. Every other core member of this project has added software, at times, that I was not totally happy with, but I also have not deleted such software because it is the nature of shared open source projects that you can't keep everyone 100% happy all of the time. There are things in both V1 and V2 I dislike very much, but I recognize the right of authorship and the differences of opinion that come with different people writing different code.
I should probably remind everyone here that this project was started by LANL, and that the control of this project remains at LANL. We are a non-profit, and I hope neutral, third party. I have had questions from time to time about whether this or that commercial entity has too much control of the project, and my response has always been: "Don't worry, calm down, LANL is neutral here and can make sure we play fair". This type of query is serious. At one point I had a commercial company hinting about legal action as they felt that another company was holding back on releasing code to CVS. I was able to calm that one down too, simply by pointing out the role that LANL plays.
LANL has a duty to provide a level playing ground for all involved. We can not and will not allow deletions of subsystems deemed important by users without some amount of discussion first, followed by some sort of agreement. We had hoped to hash these issues out at the linuxbios summit but were unable to bring that meeting to fruition.
Short form: I would ask all involved not to take actions that could lead to consequences we will all regret.
ron
ron minnich rminnich@lanl.gov writes:
well, I am afraid I do not.
No one has contacted any of the other core maintainers of linuxbios and vetted this suggestion of scheduling components for deletion. This suggestion of deleting the embedded filo came out of left field, at least to me. Major changes on this level need discussion!
Exactly. No ever even discussed including it. No one ever discussed changing our long standing compromise. When I heard about it clear it was on the edge of a line I would not cross. And now that I have actually had a chance to look I see that it is over that line.
Now there are some real issues that need to be solved to make it simpler for users and sometime when I am not so mad I can barely talk. I will do something.
Eric
Hum.. I wasn't intended to be a media you use to rise such a polemic..
But from polemic can rise good things, and now that i'am part :
Le ven 04/06/2004 à 17:29, ron minnich a écrit :
On 4 Jun 2004, Mathieu Deschamps wrote:
The native ``filo'' is scheduled for deletion, it touches hardwaremain which it should not. As implemented it is a maintenance nightmare and an implementation of policy and I refuse to support it, in the core of LinuxBIOS. Until just a little while ago I thought it was much less intrusive so was not forcing the issue.
ok I understand.
well, I am afraid I do not.
No one has contacted any of the other core maintainers of linuxbios and vetted this suggestion of scheduling components for deletion. This suggestion of deleting the embedded filo came out of left field, at least to me. Major changes on this level need discussion!
LinuxBIOS is a cooperative project. People add things from time to time that others do not like. Every other core member of this project has added software, at times, that I was not totally happy with, but I also have not deleted such software because it is the nature of shared open source projects that you can't keep everyone 100% happy all of the time. There are things in both V1 and V2 I dislike very much, but I recognize the right of authorship and the differences of opinion that come with different people writing different code.
I do agree... even if IMHO mainteners are not clearly identified.
I should probably remind everyone here that this project was started by LANL, and that the control of this project remains at LANL. We are a non-profit, and I hope neutral, third party. I have had questions from time to time about whether this or that commercial entity has too much control of the project, and my response has always been: "Don't worry, calm down, LANL is neutral here and can make sure we play fair". This type of query is serious. At one point I had a commercial company hinting about legal action as they felt that another company was holding back on releasing code to CVS. I was able to calm that one down too, simply by pointing out the role that LANL plays.
Trying to understand the hows and the whys, obvious I'am not targeted...
I hope so, or YOUR OpenSource banner you rise means nothing if,for instance, features request can't be clearly openly answered, don't you think ? Anyway, I don't feel targeted concerning making majors changes :-) nor I'am concerned on lack of concertation.
For the rest, maybe i'am sensible but I have to say that commercial entity do not all aim at same thing or at least does not behave all the same. What I'am gaining with Linuxbios experience I'll try to give back in somehow i could, don't you feel this ?.
mathieu
LANL has a duty to provide a level playing ground for all involved. We can not and will not allow deletions of subsystems deemed important by users without some amount of discussion first, followed by some sort of agreement. We had hoped to hash these issues out at the linuxbios summit but were unable to bring that meeting to fruition.
Short form: I would ask all involved not to take actions that could lead to consequences we will all regret.
ron
On Fri, Jun 04, 2004 at 06:01:56PM +0200, Mathieu Deschamps wrote:
What I'am gaining with Linuxbios experience I'll try to give back in somehow i could, don't you feel this ?.
I agree! :) I think the lbcc script can be very useful!
We had hoped to hash these issues out at the linuxbios summit but were unable to bring that meeting to fruition.
Short form: I would ask all involved not to take actions that could lead to consequences we will all regret.
I hope this doesn't have to become a big problem, we should be able to just talk about it and straighten any issues out. It has been done online before.
Just my EUR .02. :)
//Peter
On Fri, 4 Jun 2004, Peter Stuge wrote:
I hope this doesn't have to become a big problem, we should be able to just talk about it and straighten any issues out. It has been done online before.
We'll all cool off over the weekend and work it out next week.
thanks
ron
On Fri, Jun 04, 2004 at 04:06:41PM -0600, ron minnich wrote:
I hope this doesn't have to become a big problem, we should be able to just talk about it and straighten any issues out. It has been done online before.
We'll all cool off over the weekend and work it out next week.
Sounds good. Kick back and enjoy a can or two of <insert favorite beverage here> in the sun, if you happen to live near some summer. :)
thanks
No problem. Hope you all have a nice weekend!
//Peter
Le ven 04/06/2004 à 22:34, Peter Stuge a écrit :
On Fri, Jun 04, 2004 at 06:01:56PM +0200, Mathieu Deschamps wrote:
What I'am gaining with Linuxbios experience I'll try to give back in somehow i could, don't you feel this ?.
I agree! :) I think the lbcc script can be very useful!
thank you :) yes maybe it will if it's shared and credited. For now, it needs some pipe work to connect to linuxbios utils and LANL's guidance and everybody's credit/opinion.
Le sam 05/06/2004 à 03:40, Peter Stuge a écrit :
On Fri, Jun 04, 2004 at 04:06:41PM -0600, ron minnich wrote:
I hope this doesn't have to become a big problem, we should be able to just talk about it and straighten any issues out. It has been done online before.
We'll all cool off over the weekend and work it out next week.
Sounds good. Kick back and enjoy a can or two of <insert favorite beverage here> in the sun, if you happen to live near some summer. :)
thanks
No problem. Hope you all have a nice weekend!
yes it was i got sunburnt but i'am cool off that's ok now :)
//Peter _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
We had hoped to hash these issues out at the linuxbios summit but were unable to bring that meeting to fruition.
Short form: I would ask all involved not to take actions that could lead to consequences we will all regret.
I hope this doesn't have to become a big problem, we should be able to just talk about it and straighten any issues out. It has been done online before.
Just my EUR .02. :)
//Peter _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
-
ebiederman＠lnxi.com -
Mathieu Deschamps -
Peter Stuge -
ron minnich