Werner Almesberger <[EMAIL PROTECTED]> writes:
> > I agree writing the code to understand the table may be a significant
> > issue. On the other hand I still think it is worth a look, being
> > able to unify option parsing for multiple platforms is not a small
> > gain, nor is getting out from
Werner Almesberger [EMAIL PROTECTED] writes:
I agree writing the code to understand the table may be a significant
issue. On the other hand I still think it is worth a look, being
able to unify option parsing for multiple platforms is not a small
gain, nor is getting out from short
Werner Almesberger <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
> > The code wasn't trivially reusable, and the structures had a lot
> > of overhead.
>
> There's some overhead, but I think it's not too bad. I'll give it a
> try ...
>
> > The rebooting is done the rest is not yet.
>
Eric W. Biederman wrote:
> The code wasn't trivially reusable, and the structures had a lot
> of overhead.
There's some overhead, but I think it's not too bad. I'll give it a
try ...
> The rebooting is done the rest is not yet.
Ah, and I already wondered where in all the APIC code you've
Werner Almesberger <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
> > Well there is that. Somehow implementing scatter/gather from
> > a user space process seemed like a potential mess, and extra work.
>
> Did you look at kiobufs ? I think they may just have the right
> functionality.
Werner Almesberger [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Well there is that. Somehow implementing scatter/gather from
a user space process seemed like a potential mess, and extra work.
Did you look at kiobufs ? I think they may just have the right
functionality. I always
Eric W. Biederman wrote:
The code wasn't trivially reusable, and the structures had a lot
of overhead.
There's some overhead, but I think it's not too bad. I'll give it a
try ...
The rebooting is done the rest is not yet.
Ah, and I already wondered where in all the APIC code you've hidden
Werner Almesberger [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
The code wasn't trivially reusable, and the structures had a lot
of overhead.
There's some overhead, but I think it's not too bad. I'll give it a
try ...
The rebooting is done the rest is not yet.
Ah, and I
Eric W. Biederman wrote:
> Well there is that. Somehow implementing scatter/gather from
> a user space process seemed like a potential mess, and extra work.
Did you look at kiobufs ? I think they may just have the right
functionality. I always wanted bootimg to be able to memory-map things
to
Eric W. Biederman wrote:
Well there is that. Somehow implementing scatter/gather from
a user space process seemed like a potential mess, and extra work.
Did you look at kiobufs ? I think they may just have the right
functionality. I always wanted bootimg to be able to memory-map things
to
Werner Almesberger <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
> > There are a couple of differences.
> > But the big one is I'm trying to do it right.
>
> So why do you need a file-based interface then ? ;-)
When possible it is nice to set as much policy as possible,
without
Werner Almesberger [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
There are a couple of differences.
But the big one is I'm trying to do it right.
So why do you need a file-based interface then ? ;-)
When possible it is nice to set as much policy as possible,
without removing
Erik Andersen <[EMAIL PROTECTED]> writes:
> On Tue Nov 14, 2000 at 07:59:18AM -0700, Eric W. Biederman wrote:
> >
> > All mkelfImage does is the pasting of initrd's, command lines,
> > and just a touch of argument conversion code.
>
> You can link in an initrd using linker magic, i.e.
>
On Tue Nov 14, 2000 at 07:59:18AM -0700, Eric W. Biederman wrote:
>
> All mkelfImage does is the pasting of initrd's, command lines,
> and just a touch of argument conversion code.
You can link in an initrd using linker magic, i.e.
$(OBJCOPY) --add-section=image=kernel
Erik Andersen <[EMAIL PROTECTED]> writes:
> On Thu Nov 09, 2000 at 01:18:24AM -0700, Eric W. Biederman wrote:
> >
> > I have recently developed a patch that allows linux to directly boot
> > into another linux kernel.
>
> Looks very cool. I'm curious about your decision to use ELF images.
Erik Andersen [EMAIL PROTECTED] writes:
On Thu Nov 09, 2000 at 01:18:24AM -0700, Eric W. Biederman wrote:
I have recently developed a patch that allows linux to directly boot
into another linux kernel.
Looks very cool. I'm curious about your decision to use ELF images. This
makes
On Tue Nov 14, 2000 at 07:59:18AM -0700, Eric W. Biederman wrote:
All mkelfImage does is the pasting of initrd's, command lines,
and just a touch of argument conversion code.
You can link in an initrd using linker magic, i.e.
$(OBJCOPY) --add-section=image=kernel
Erik Andersen [EMAIL PROTECTED] writes:
On Tue Nov 14, 2000 at 07:59:18AM -0700, Eric W. Biederman wrote:
All mkelfImage does is the pasting of initrd's, command lines,
and just a touch of argument conversion code.
You can link in an initrd using linker magic, i.e.
$(OBJCOPY)
Eric W. Biederman wrote:
> There are a couple of differences.
> But the big one is I'm trying to do it right.
So why do you need a file-based interface then ? ;-)
Since this is a highly privileged operation anyway, you may as
well trust user space to use the right data format ...
I get the
Eric W. Biederman wrote:
There are a couple of differences.
But the big one is I'm trying to do it right.
So why do you need a file-based interface then ? ;-)
Since this is a highly privileged operation anyway, you may as
well trust user space to use the right data format ...
I get the
On Thu Nov 09, 2000 at 01:18:24AM -0700, Eric W. Biederman wrote:
>
> I have recently developed a patch that allows linux to directly boot
> into another linux kernel.
Looks very cool. I'm curious about your decision to use ELF images. This
makes it much less conveinient to use due to the
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> "Eric W. Biederman" wrote:
> >
> > Hmm. You must mean similiar to milo.
> >
> > Have fun. With linuxBIOS I'm working exactly the other way. Killing
> > off the BIOS. And letting the initial firmware be just a boot loader.
> > The reduction is
"Eric W. Biederman" wrote:
>
> Hmm. You must mean similiar to milo.
>
> Have fun. With linuxBIOS I'm working exactly the other way. Killing
> off the BIOS. And letting the initial firmware be just a boot loader.
> The reduction is complexity should make it more reliable.
>
... except that
Adam Lazur <[EMAIL PROTECTED]> writes:
> Eric W. Biederman ([EMAIL PROTECTED]) said:
> > Michael Rothwell <[EMAIL PROTECTED]> writes:
> > > This would rock. One place I can think of using it is with distro
> > > installers. The installer boots a generic i386 kernel, and then installs
> > > an
Adam Lazur <[EMAIL PROTECTED]> writes:
> Eric W. Biederman ([EMAIL PROTECTED]) said:
> > I have recently developed a patch that allows linux to directly boot
> > into another linux kernel. With the code freeze it appears
> > inappropriate to submit it at this time.
>
> Aside from what looks
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Followup to: <[EMAIL PROTECTED]>
> By author:[EMAIL PROTECTED] (Eric W. Biederman)
> In newsgroup: linux.dev.kernel
> > > >
> > > > The interface is designed to be simple and inflexible yet very
> > > > powerful. To that end the code just
Eric W. Biederman ([EMAIL PROTECTED]) said:
> Michael Rothwell <[EMAIL PROTECTED]> writes:
> > This would rock. One place I can think of using it is with distro
> > installers. The installer boots a generic i386 kernel, and then installs
> > an optimized (i.e, PIII, etc.) kernel for run-time.
>
Eric W. Biederman ([EMAIL PROTECTED]) said:
> I have recently developed a patch that allows linux to directly boot
> into another linux kernel. With the code freeze it appears
> inappropriate to submit it at this time.
Aside from what looks to be support for SMP, how does this differ from
the
Followup to: <[EMAIL PROTECTED]>
By author:[EMAIL PROTECTED] (Eric W. Biederman)
In newsgroup: linux.dev.kernel
> > >
> > > The interface is designed to be simple and inflexible yet very
> > > powerful. To that end the code just takes an elf binary, and a
> > > command line. The started
Michael Rothwell <[EMAIL PROTECTED]> writes:
> "Eric W. Biederman" wrote:
> >
> > I have recently developed a patch that allows linux to directly boot
> > into another linux kernel.
>
> This would rock. One place I can think of using it is with distro
> installers. The installer boots a
Michael Rothwell [EMAIL PROTECTED] writes:
"Eric W. Biederman" wrote:
I have recently developed a patch that allows linux to directly boot
into another linux kernel.
This would rock. One place I can think of using it is with distro
installers. The installer boots a generic i386
Followup to: [EMAIL PROTECTED]
By author:[EMAIL PROTECTED] (Eric W. Biederman)
In newsgroup: linux.dev.kernel
The interface is designed to be simple and inflexible yet very
powerful. To that end the code just takes an elf binary, and a
command line. The started image also
Eric W. Biederman ([EMAIL PROTECTED]) said:
I have recently developed a patch that allows linux to directly boot
into another linux kernel. With the code freeze it appears
inappropriate to submit it at this time.
Aside from what looks to be support for SMP, how does this differ from
the two
Eric W. Biederman ([EMAIL PROTECTED]) said:
Michael Rothwell [EMAIL PROTECTED] writes:
This would rock. One place I can think of using it is with distro
installers. The installer boots a generic i386 kernel, and then installs
an optimized (i.e, PIII, etc.) kernel for run-time.
This
"H. Peter Anvin" [EMAIL PROTECTED] writes:
Followup to: [EMAIL PROTECTED]
By author:[EMAIL PROTECTED] (Eric W. Biederman)
In newsgroup: linux.dev.kernel
The interface is designed to be simple and inflexible yet very
powerful. To that end the code just takes an elf binary,
Adam Lazur [EMAIL PROTECTED] writes:
Eric W. Biederman ([EMAIL PROTECTED]) said:
Michael Rothwell [EMAIL PROTECTED] writes:
This would rock. One place I can think of using it is with distro
installers. The installer boots a generic i386 kernel, and then installs
an optimized (i.e,
Adam Lazur [EMAIL PROTECTED] writes:
Eric W. Biederman ([EMAIL PROTECTED]) said:
I have recently developed a patch that allows linux to directly boot
into another linux kernel. With the code freeze it appears
inappropriate to submit it at this time.
Aside from what looks to be
"Eric W. Biederman" wrote:
Hmm. You must mean similiar to milo.
Have fun. With linuxBIOS I'm working exactly the other way. Killing
off the BIOS. And letting the initial firmware be just a boot loader.
The reduction is complexity should make it more reliable.
... except that you
"H. Peter Anvin" [EMAIL PROTECTED] writes:
"Eric W. Biederman" wrote:
Hmm. You must mean similiar to milo.
Have fun. With linuxBIOS I'm working exactly the other way. Killing
off the BIOS. And letting the initial firmware be just a boot loader.
The reduction is complexity
I have recently developed a patch that allows linux to directly boot
into another linux kernel. With the code freeze it appears
inappropriate to submit it at this time.
Linus in principal do you have any trouble with this kind of
functionality?
The immediate applications of this code, are:
I have recently developed a patch that allows linux to directly boot
into another linux kernel. With the code freeze it appears
inappropriate to submit it at this time.
Linus in principal do you have any trouble with this kind of
functionality?
The immediate applications of this code, are:
41 matches
Mail list logo
