Hi Eric,
thank you very much for your comments. It's always a pleasure for me.
On Sunday 03 August 2003 19:52, Eric W. Biederman wrote:
> me wrote:
> >
> > Yep, I've looked at it. In general, if I need to load some
> > secondary menuing system, it does't matter, if this is 10L or 166K.
> > But when I'm forced to use a pxe loader, etherboot >= 5.1 isn't an
> > option anymore, since despite of the pxe target, it doesn't provide
> > any surplus value anymore, no, better than that, it creates a nice
> > useless boot loop. Options: use 5.0 with menus enabled, or go the
> > grub way.
>
> I have no problem at all using 5.1 with pxe. All it takes is a
> single if statement in the dhcpv3 configuration file to distinguish
> between etherboot and pxe.
Well, you're right, off cause. It's more the comfort of menus in my
usual office like environments, I highly depend on: I'm surrounded with
5 systems here, while none has a harddisk running! In fact, I don't
like harddisks at all in their single form, doing my hd math like: 3+1
hot spare most of the time ;-).
When it comes to linux installations, repartition or rescue harddisks, I
usually not even touch any removable media. But I can imagine that
these are old hats for you.
> > The nice thing in grub from developers pov is the approach to
> > provide some limited posix like f* functions to operate on files
> > (one at a time), which seems to work fine with tftp, too.
>
> I am amazed you are looking at the grub code and not going blind...
> I guess if you are not digging into it too deeply the code looks o.k.
Well, I kept my eyesight and have some experience with fragile
(commercial) software systems, where even grub compares positively 8|.
As long as I get it done in a timely fashion, I simply don't look.
That project seems to be missing a benevolent dictatorship, other
projects get their notable, but ordered advances from, like what is
happening in etherboots lucky case, especially when its leader is
supported such greatly from some magic genius called Eric :)
BTW: the real fun comes in with the gfxboot package, which is an ps like
interpreter, implemented in assembler (140K source), with hooks for
3 different boot loaders: syslinux, lilo and grub. crazyness approaching
infinity!
> > This is one thing, I didn't like in this scenario: the repetition
> > of device drivers in the different loaders. Much cooler would be to
> > install and use an interrupt vector for basic nic device
> > operations, such that chained boot loaders are able to use one set
> > of device drivers. That would spare me the now necessary port of
> > the current etherboot drivers to grub to not loose the track. I
> > hope, you don't have any objections.
>
> Chained drivers are so wrong. The reason they are wrong is very
> simple, software on a ROM is never updated. As long as the software
> on the ROM is good enough to do it's one thing that is all that is
> required of it.
Definitely yes in a perfect world, but reality is biting: think of PXE.
But in the etherboot case, we can at least try to get there.
> As for porting please notice that the 5.2 drivers are much easier to
> host.
Thanks to Axel Dittrich, I've also an example backport of e1000 drivers,
which I ported over to grub without any major hassles. I expect to get
it also done timely.
> Now if you want something really fun that saves all of the work
> of replicating drivers. I can hook you up with a kernel with kexec
> support and you can use all of it's drivers and boot anything you
> want.
That sounds like a crazy idea, but doesn't that impose opening a bulk of
other cans of worms: libc, complexity, etc.. One real nice thing of
etherboot is its concise implementation. In the linux bios case, I can
see all its beauties, but do you expect to equip nic flash roms with a
linux (micro?) kernel, just to boot linux? Well, the e1000 ships with a
256K flash. BTW: Does somebody has flashed that parts from linux? It's
one of the tasks, I currently do within a nbi dos session...
> Eric
Kind regards,
Pete
|