* Re: new bi_rec interface (was Re: [Ppcboot-users] Re: EV-64260 booting) [not found] ` <20020318152329.B324434@brule.borg.umn.edu> @ 2002-03-18 23:33 ` Ethan Benson 2002-03-19 0:24 ` Wolfgang Denk 2002-03-19 0:29 ` Dan Malek 0 siblings, 2 replies; 4+ messages in thread From: Ethan Benson @ 2002-03-18 23:33 UTC (permalink / raw) To: linuxppc-dev On Mon, Mar 18, 2002 at 03:23:29PM -0600, Peter Bergner wrote: > > What happened to the idea (paulus' idea?) of creating some wrapper > code (eg, zimage) that would build the bootinfo and pass it into > the kernel, so yaboot doesn't need to do much other than pass in > boot params? This would force us to only boot zimages though > (or whatever wrapper code we create). from a logistical point of view this really seems to be the best approach. keeping all the details in a kernel wrapper of sorts gives the kernel maintainers much more freedom to make changes in the future, whereas if its kept in yaboot (rather $bootloader) you have to deal with backword compatibility and endless luser error due to using the wrong bootloader versions with wrong kernels. of course if someone doesn't want to use the wrapper they can just use the vmlinux and write thier own bootloader to handle all this stuff and take on the effort of ensuring its up to date with what the kernel wants. -- Ethan Benson http://www.alaska.net/~erbenson/ ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: new bi_rec interface (was Re: [Ppcboot-users] Re: EV-64260 booting) 2002-03-18 23:33 ` new bi_rec interface (was Re: [Ppcboot-users] Re: EV-64260 booting) Ethan Benson @ 2002-03-19 0:24 ` Wolfgang Denk 2002-03-19 9:21 ` Ethan Benson 2002-03-19 0:29 ` Dan Malek 1 sibling, 1 reply; 4+ messages in thread From: Wolfgang Denk @ 2002-03-19 0:24 UTC (permalink / raw) To: Ethan Benson; +Cc: linuxppc-dev In message <20020318143326.B26309@plato.local.lan> you wrote: > > > What happened to the idea (paulus' idea?) of creating some wrapper > > code (eg, zimage) that would build the bootinfo and pass it into > > the kernel, so yaboot doesn't need to do much other than pass in > > boot params? This would force us to only boot zimages though > > (or whatever wrapper code we create). > > from a logistical point of view this really seems to be the best > approach. keeping all the details in a kernel wrapper of sorts gives >From the point of view of someone who is working mostly with embedded systems this is definitely the WORST approach (YMMV). > the kernel maintainers much more freedom to make changes in the > future, whereas if its kept in yaboot (rather $bootloader) you have to The interfaces, once defined, should remain unchanged. > deal with backword compatibility and endless luser error due to using > the wrong bootloader versions with wrong kernels. There is no need to create such problems in the first place, so don;t do it then. > of course if someone doesn't want to use the wrapper they can just use > the vmlinux and write thier own bootloader to handle all this stuff > and take on the effort of ensuring its up to date with what the kernel > wants. What makes you think that kernel interfaces are somthing to change that often? From the current discussion about bi_recs I got the impression that we have some kind of agreement (in pronciple, not [yet] in detail), but what you propose sounds like a full roll-back to position zero??? Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de C++ is the best example of second-system effect since OS/360. ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: new bi_rec interface (was Re: [Ppcboot-users] Re: EV-64260 booting) 2002-03-19 0:24 ` Wolfgang Denk @ 2002-03-19 9:21 ` Ethan Benson 0 siblings, 0 replies; 4+ messages in thread From: Ethan Benson @ 2002-03-19 9:21 UTC (permalink / raw) To: linuxppc-dev On Tue, Mar 19, 2002 at 01:24:49AM +0100, Wolfgang Denk wrote: > > In message <20020318143326.B26309@plato.local.lan> you wrote: > > > > > What happened to the idea (paulus' idea?) of creating some wrapper > > > code (eg, zimage) that would build the bootinfo and pass it into > > > the kernel, so yaboot doesn't need to do much other than pass in > > > boot params? This would force us to only boot zimages though > > > (or whatever wrapper code we create). > > > > from a logistical point of view this really seems to be the best > > approach. keeping all the details in a kernel wrapper of sorts gives > > >From the point of view of someone who is working mostly with embedded > systems this is definitely the WORST approach (YMMV). fine, see the last part of my message. > > the kernel maintainers much more freedom to make changes in the > > future, whereas if its kept in yaboot (rather $bootloader) you have to > > The interfaces, once defined, should remain unchanged. yeah perfect world and all... > > deal with backword compatibility and endless luser error due to using > > the wrong bootloader versions with wrong kernels. > > There is no need to create such problems in the first place, so don;t > do it then. well linux has a piss poor history of following that guidline, every major kernel version has required several userspace utility replacments (modutils, firewalling utils etc). > > of course if someone doesn't want to use the wrapper they can just use > > the vmlinux and write thier own bootloader to handle all this stuff > > and take on the effort of ensuring its up to date with what the kernel > > wants. > > What makes you think that kernel interfaces are somthing to change > that often? From the current discussion about bi_recs I got the > impression that we have some kind of agreement (in pronciple, not > [yet] in detail), but what you propose sounds like a full roll-back > to position zero??? i don't know why you are getting so pissy, all i suggested was the zImage wrapper handle all the gory details of this bi_rec crap rather then $bootloader, if you don't want the wrapper then use the plain flat vmlinux and write your own bootloader to handle the gory details. it sounds like you don't want to use the zImage wrapper no matter what, so why the hell do you care what it does or does not do? either way hopefully the interfaces will not change, but excuse me for not having much confidence in that being the case. in the end i really don't much care how it ends up being done, however i am not willing to add all sorts of kludge config options to yaboot that you have to use to tell it what flavor kernel your booting, users will NEVER get that right. so if yaboot has to be responsible for the gory details damn well get the interfaces done right the first time and consider them engraved on stone tablets never to be altered again. -- Ethan Benson http://www.alaska.net/~erbenson/ ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: new bi_rec interface (was Re: [Ppcboot-users] Re: EV-64260 booting) 2002-03-18 23:33 ` new bi_rec interface (was Re: [Ppcboot-users] Re: EV-64260 booting) Ethan Benson 2002-03-19 0:24 ` Wolfgang Denk @ 2002-03-19 0:29 ` Dan Malek 1 sibling, 0 replies; 4+ messages in thread From: Dan Malek @ 2002-03-19 0:29 UTC (permalink / raw) To: Ethan Benson; +Cc: linuxppc-dev Ethan Benson wrote: > from a logistical point of view this really seems to be the best > approach. This has been the normal mode of operation for the embedded boards. Many of us think it is the logical approach, and quite a while ago some of us started talking about how we can combine these ideas in an effort to remove a reasonable amount of board specific code from the kernel setup functions. There were some challenges while trying to move from one method to another, with the transition being the 2.4 source tree. For 2.5 we just "declared" this will be the way. > of course if someone doesn't want to use the wrapper they can just use > the vmlinux and write thier own bootloader to handle all this stuff > and take on the effort of ensuring its up to date with what the kernel > wants. There are people that want to do this and see value in doing so. It does present a challenge as I was one that broke ppcboot when I changed the interface between the bootloader and the kernel (thinking everyone used the bootloader wrapper on embedded boards :-). -- Dan ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2002-03-19 9:21 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20020312195125.GB25926@cpe-24-221-152-185.az.sprintbbd.net>
[not found] ` <21274.1015997038@msa.cmst.csiro.au>
[not found] ` <20020313155503.GB721@opus.bloom.county>
[not found] ` <20020318152329.B324434@brule.borg.umn.edu>
2002-03-18 23:33 ` new bi_rec interface (was Re: [Ppcboot-users] Re: EV-64260 booting) Ethan Benson
2002-03-19 0:24 ` Wolfgang Denk
2002-03-19 9:21 ` Ethan Benson
2002-03-19 0:29 ` Dan Malek
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.