LOBOS

LOBOS

[RaúlNúñez de Arenas Coronado]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 691 bytes --]

    Hello all :))

    I've reading a bit about booting Linux within Linux, and I'm
pretty interested in this issue. The point here is, will a stable
kernel support this in a near future?.

    There are a few alternatives like 'LOBOS' (which, IMHO, is the
most portable, easy and small of all), 'bootimg', the two kernel
monte, etc...

    This will be very useful for a lot of thinks: netbooting, initrd
replacement, kernel switching and testing, etc...

    Have you think about adding this to the kernel. It won't enlarge
the kernel and IMHO is a very good thing to have. Of course I'm not a
kernel guru and I don't know what kind of problems this would arise.

    Have fun :)
    Raúl

Re: LOBOS

[Larry McVoy]

I've been wanting Linux which can boot Linux for a long time.
See http://www.bitmover.com/ml for some slides on why, for those of you
who are guess, yes it is the same OS cluster idea for SMP scaling I've
been pushing on for 7 years.  It's finally getting some attention as
well, the IBM guys are looking at it, a FreeBSD guy is looking at it,
and the UML guy thinks he can do a UML implementation in such a way 
that putting it on real hardware would be a "simple" port.

On Tue, Nov 20, 2001 at 01:04:55AM +0100, RaúlNúñez de Arenas Coronado wrote:
>     Hello all :))
> 
>     I've reading a bit about booting Linux within Linux, and I'm
> pretty interested in this issue. The point here is, will a stable
> kernel support this in a near future?.
> 
>     There are a few alternatives like 'LOBOS' (which, IMHO, is the
> most portable, easy and small of all), 'bootimg', the two kernel
> monte, etc...
> 
>     This will be very useful for a lot of thinks: netbooting, initrd
> replacement, kernel switching and testing, etc...
> 
>     Have you think about adding this to the kernel. It won't enlarge
> the kernel and IMHO is a very good thing to have. Of course I'm not a
> kernel guru and I don't know what kind of problems this would arise.
> 
>     Have fun :)
>     Raúl
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: LOBOS

[Tim Hockin]

> I've been wanting Linux which can boot Linux for a long time.

This is what Cobalt firmware has been doing FOREVER.  We didn't solve it
generically, but it works marvelously for what it does.

Re: LOBOS

[Erik Andersen]

On Mon Nov 19, 2001 at 06:03:09PM -0800, Tim Hockin wrote:
> > I've been wanting Linux which can boot Linux for a long time.
> 
> This is what Cobalt firmware has been doing FOREVER.  We didn't solve it
> generically, but it works marvelously for what it does.

The netwinder firmware is a stripped down Linux kernel 
which boots another linux kernel.  
    ftp://ftp.netwinder.org/pub/ccc/firmware/

And the Linux BIOS project does that also 
    http://www.acl.lanl.gov/linuxbios/

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: LOBOS (kexec)

[Eric W. Biederman]

Larry McVoy <lm@bitmover.com> writes:

> I've been wanting Linux which can boot Linux for a long time.
> See http://www.bitmover.com/ml for some slides on why, for those of you
> who are guess, yes it is the same OS cluster idea for SMP scaling I've
> been pushing on for 7 years.  It's finally getting some attention as
> well, the IBM guys are looking at it, a FreeBSD guy is looking at it,
> and the UML guy thinks he can do a UML implementation in such a way 
> that putting it on real hardware would be a "simple" port.

I am maintaining a version of this functionality against 2.4.x
called kexec.  And I plan to work on integration into linux with 2.5.x.
After the details are worked out I will look at a backport to 2.4.x

The hard part is not linux booting linux but the passing of the
firmware/BIOS tables from one kernel to the next.  Especially those
that can only be obtained by a 16bit query.  It is my assumption that
after the OS runs you cannot return to the firmware, it's state is
hopelessly mangled.  That may not be totally true but it is fairly
close to the truth. 

I am doing this a part of the linuxBIOS effort and as such it is just
maturing enough that I can really start concentrating on this aspect
of the problem.  I do not want an interface that is mushy.  I want an
interface that is extensible.  But is pretty much frozen for all time
like the ELF file format.

My patches show up from time to time at:
ftp://download.linuxnetworx.com/pub/src/kernel-patches/

Hopefully soon I will get my port to 2.4.14 put up there soon.  
I have been maintaining and this since 2.4.0-pre9 or so.  And I have
been using this actively.  And I have an alpha port.  I would port to
other architectures but I don't have the machines available.

Eric

Re: LOBOS (kexec)

[Tim Hockin]

> The hard part is not linux booting linux but the passing of the
> firmware/BIOS tables from one kernel to the next.  Especially those
> that can only be obtained by a 16bit query.  It is my assumption that
> after the OS runs you cannot return to the firmware, it's state is
> hopelessly mangled.  That may not be totally true but it is fairly
> close to the truth. 

It is unless you control the firmware.  Our (Cobalt) firmware reserves a
region of memory which the primary (in-flash) kernel is not made aware of.
The in-flash kernel can do all the fun things a kernel can do, and then
return to firmware.

Re: LOBOS (kexec)

[Eric W. Biederman]

Tim Hockin <thockin@hockin.org> writes:

> > The hard part is not linux booting linux but the passing of the
> > firmware/BIOS tables from one kernel to the next.  Especially those
> > that can only be obtained by a 16bit query.  It is my assumption that
> > after the OS runs you cannot return to the firmware, it's state is
> > hopelessly mangled.  That may not be totally true but it is fairly
> > close to the truth. 
> 
> It is unless you control the firmware.  Our (Cobalt) firmware reserves a
> region of memory which the primary (in-flash) kernel is not made aware of.
> The in-flash kernel can do all the fun things a kernel can do, and then
> return to firmware.

Hmm.  I might have to check it out.  Comparing notes with what you do on
the Cobalt with what I'm doing in linuxBIOS.  Do you happen to have
a url?

But as I want a general solution I don't intend to pick a solution
that depends on the firmware.

Eric

Re: LOBOS (kexec)

[Werner Almesberger]

The approaching 2.5 seems to revive the spirits of the Linux to Linux
boot loaders ;-) Just a few days ago, I've started working again on
bootimg ...

Eric W. Biederman wrote:
> My patches show up from time to time at:
> ftp://download.linuxnetworx.com/pub/src/kernel-patches/

This site always seems to be unavailable. Is there a more stable
location for kexec ? I'd like to link to it from
http://bootimg.sourceforge.net/

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Lausanne, CH                    wa@almesberger.net /
/_http://icawww.epfl.ch/almesberger/_____________________________________/

Re: LOBOS (kexec)

[Eric W. Biederman]

Werner Almesberger <wa@almesberger.net> writes:

> The approaching 2.5 seems to revive the spirits of the Linux to Linux
> boot loaders ;-) Just a few days ago, I've started working again on
> bootimg ...

There is something to that.  I've mostly been in maintenance mode.
And tackling other things.  For what is worth I can currently
boot memtest86 and etherboot, besides the linux kernel.

> Eric W. Biederman wrote:
> > My patches show up from time to time at:
> > ftp://download.linuxnetworx.com/pub/src/kernel-patches/
> 
> This site always seems to be unavailable. Is there a more stable
> location for kexec ? I'd like to link to it from
> http://bootimg.sourceforge.net/

Hmm.  I will have to look.  I haven't had problems with it myself.
So I don't know what to say.

I'm not quite ready to do a whole lot on the maintenance side until
I finish working through my design issues.  But as soon as that
is completed I will make certain something is going on.

You might want to link to the linuxBIOS site.  http://www.linuxbios.org
As that is related.  But I guess not directly useful.

Eric

Re: LOBOS (kexec)

[Randy.Dunlap]

> > Eric W. Biederman wrote:
> > > My patches show up from time to time at:
> > > ftp://download.linuxnetworx.com/pub/src/kernel-patches/
> >
> > This site always seems to be unavailable. Is there a more stable
> > location for kexec ? I'd like to link to it from
> > http://bootimg.sourceforge.net/
> 
> Hmm.  I will have to look.  I haven't had problems with it myself.
> So I don't know what to say.

I had problems with that URL also.  It should be:
ftp://download.linuxnetworx.com/pub/src/linux-kernel-patches/

~Randy

Re: LOBOS (kexec)

[Eric W. Biederman]

"Randy.Dunlap" <rddunlap@osdl.org> writes:

> > > Eric W. Biederman wrote:
> > > > My patches show up from time to time at:
> > > > ftp://download.linuxnetworx.com/pub/src/kernel-patches/
> > >
> > > This site always seems to be unavailable. Is there a more stable
> > > location for kexec ? I'd like to link to it from
> > > http://bootimg.sourceforge.net/
> > 
> > Hmm.  I will have to look.  I haven't had problems with it myself.
> > So I don't know what to say.
> 
> I had problems with that URL also.  It should be:
> ftp://download.linuxnetworx.com/pub/src/linux-kernel-patches/

Oops I typed too much from memory...

Eric

Re: LOBOS

[victor]

hi read that url ;)
http://www.missl.cs.umd.edu/linuxbios/msg03992.html


  victor
-------------------------------------
 RaúlNúñez de Arenas Coronado <dervishd@jazzfree.com>
Hello all :))

    I've reading a bit about booting Linux within Linux, and I'm
pretty interested in this issue. The point here is, will a stable
kernel support this in a near future?.

    There are a few alternatives like 'LOBOS' (which, IMHO, is the
most portable, easy and small of all), 'bootimg', the two kernel
monte, etc...

    This will be very useful for a lot of thinks: netbooting, initrd
replacement, kernel switching and testing, etc...

    Have you think about adding this to the kernel. It won't enlarge
the kernel and IMHO is a very good thing to have. Of course I'm not a
kernel guru and I don't know what kind of problems this would arise.

    Have fun :)
    Raúl
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LOBOS (kexec)

[RaúlNúñez de Arenas Coronado]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 904 bytes --]

    Hello Larry (or Eric) :)

>> I've been wanting Linux which can boot Linux for a long time.
>I am maintaining a version of this functionality against 2.4.x
>called kexec.  And I plan to work on integration into linux with 2.5.x.
>After the details are worked out I will look at a backport to 2.4.x

    I think that this is a very important point, since will ease the
making of installation disks, etc... Moreover, it will ease the
creation of 'live' linux systems that can do a pretty work detecting
the hardware and the like.

>The hard part is not linux booting linux but the passing of the
>firmware/BIOS tables from one kernel to the next.

    Why?. I mean, I haven't read on this issue in the LOBOS project.
I'm afraid I thought that this was easier than it really is...

>I am doing this a part of the linuxBIOS effort and as such it is just

    I want to take a look at LinuxBIOS.

    Raúl

Re: LOBOS (kexec)

[Eric W. Biederman]

RaXl NXXez de Arenas Coronado <dervishd@jazzfree.com> writes:

>     Hello Larry (or Eric) :)
> 
> >> I've been wanting Linux which can boot Linux for a long time.
> >I am maintaining a version of this functionality against 2.4.x
> >called kexec.  And I plan to work on integration into linux with 2.5.x.
> >After the details are worked out I will look at a backport to 2.4.x
> 
>     I think that this is a very important point, since will ease the
> making of installation disks, etc... Moreover, it will ease the
> creation of 'live' linux systems that can do a pretty work detecting
> the hardware and the like.

Yep it allows linux to sever a lot of very interesting roles.  Linux
doesn't act especially well as firmware (it is fairly big).  But otherwise
it does a good job.
 
> >The hard part is not linux booting linux but the passing of the
> >firmware/BIOS tables from one kernel to the next.
> 
>     Why?. I mean, I haven't read on this issue in the LOBOS project.
> I'm afraid I thought that this was easier than it really is...

The difficulty isn't in implementation but in freezing the API.  Which
is needed if you want a solid long term approach.

> 
> >I am doing this a part of the linuxBIOS effort and as such it is just
> 
>     I want to take a look at LinuxBIOS.

The documentation is sketchy but you can look at:
http://www.linuxbios.org  and ask questions on the mailing list.

Eric