[Fwd: Re: [Qemu-devel] multiple boot devices]

[Fwd: Re: [Qemu-devel] multiple boot devices]

[J. Mayer]

What about this patch ? Is there any remark ? Is it to be applied ?

-------- Forwarded Message --------
> From: J. Mayer <l_indien@magic.fr>
> Reply-To: qemu-devel@nongnu.org
> To: qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] multiple boot devices
> Date: Mon, 05 Nov 2007 14:04:40 +0100
> 
> On Sat, 2007-11-03 at 01:18 +0000, Thiemo Seufer wrote:
> > J. Mayer wrote:
> > [snip]
> > > > > It restricts the letter to the ones historically allowed by Qemu, not to
> > > > > anything specific to any architecture or hw platform. What I like in my
> > > > > implementation, compared to the strchr..., is that it exactly tells the
> > > > > user which given device is incorrect.
> > > > 
> > > > Well, here it makes no difference, strchr tells you exactly same as much.
> > > 
> > > Yes, you're right. Was thinking about the original strspn.
> > > 
> > > > Instead of the check, the code could also allow everything from 'a' to
> > > > 'z' and then just AND the produced 32bit bitmap with a machine defined
> > > > bitmap that would be part of QEMUMachine.
> > > 
> > > I guess we would better stop at 'n', because we can easily define a
> > > semantic for devices 'c' to 'm' (ie hard disk drives in a hardware
> > > platform specific order) but we have to define what means 'o' to 'z'.
> > > But I agree we would better extend it now, instead of having to rework
> > > it later...
> > 
> > To select the network device to boot from would probably become a
> > 'n' 'o' 'p' 'q' series.
> > 
> > [snip]
> > > > > Here's a second pass cleanup, adding the machine dependant checks for
> > > > > the PC machine and the PowerPC ones. As one can see, the OpenHack'Ware
> > > > > firmware is able to boot from devices 'e' and 'f'. For the PowerPC
> > > > > machines, I choosed to try to boot from the first given usable device,
> > > > > some may not agree with this choice. It can be noticed that the
> > > > > available boot devices are not the same for PowerPC PreP, g3bw and mac99
> > > > > machines.
> > > > > As I don't know the features and requirements for the other
> > > > > architectures, I prefered not to add any check for those ones.
> > > > 
> > > > Most other machines ignore -boot and those that don't, shouldn't break
> > > > from the introduced change, so please commit it when you feel ok with
> > > > it.
> > > 
> > > I'd like to know what are the feelings around about this patch and if
> > > there are specific requirements and/or problems for some platforms to be
> > > addressed before...
> > 
> > I think the proposed scheme (and the implementation) is flexible enough
> > to accomodate all relevant platforms.
> 
> Here's an updated patch that address the remark about network boot
> devices.
> 
-- 
J. Mayer <l_indien@magic.fr>
Never organized

Re: [Fwd: Re: [Qemu-devel] multiple boot devices]

[Thiemo Seufer]

J. Mayer wrote:
> What about this patch ? Is there any remark ? Is it to be applied ?

I'm in favour, but I think I said so already. :-)

> -------- Forwarded Message --------
> > From: J. Mayer <l_indien@magic.fr>
> > Reply-To: qemu-devel@nongnu.org
> > To: qemu-devel@nongnu.org
> > Subject: Re: [Qemu-devel] multiple boot devices
> > Date: Mon, 05 Nov 2007 14:04:40 +0100
> > 
> > On Sat, 2007-11-03 at 01:18 +0000, Thiemo Seufer wrote:
> > > J. Mayer wrote:
> > > [snip]
> > > > > > It restricts the letter to the ones historically allowed by Qemu, not to
> > > > > > anything specific to any architecture or hw platform. What I like in my
> > > > > > implementation, compared to the strchr..., is that it exactly tells the
> > > > > > user which given device is incorrect.
> > > > > 
> > > > > Well, here it makes no difference, strchr tells you exactly same as much.
> > > > 
> > > > Yes, you're right. Was thinking about the original strspn.
> > > > 
> > > > > Instead of the check, the code could also allow everything from 'a' to
> > > > > 'z' and then just AND the produced 32bit bitmap with a machine defined
> > > > > bitmap that would be part of QEMUMachine.
> > > > 
> > > > I guess we would better stop at 'n', because we can easily define a
> > > > semantic for devices 'c' to 'm' (ie hard disk drives in a hardware
> > > > platform specific order) but we have to define what means 'o' to 'z'.
> > > > But I agree we would better extend it now, instead of having to rework
> > > > it later...
> > > 
> > > To select the network device to boot from would probably become a
> > > 'n' 'o' 'p' 'q' series.
> > > 
> > > [snip]
> > > > > > Here's a second pass cleanup, adding the machine dependant checks for
> > > > > > the PC machine and the PowerPC ones. As one can see, the OpenHack'Ware
> > > > > > firmware is able to boot from devices 'e' and 'f'. For the PowerPC
> > > > > > machines, I choosed to try to boot from the first given usable device,
> > > > > > some may not agree with this choice. It can be noticed that the
> > > > > > available boot devices are not the same for PowerPC PreP, g3bw and mac99
> > > > > > machines.
> > > > > > As I don't know the features and requirements for the other
> > > > > > architectures, I prefered not to add any check for those ones.
> > > > > 
> > > > > Most other machines ignore -boot and those that don't, shouldn't break
> > > > > from the introduced change, so please commit it when you feel ok with
> > > > > it.
> > > > 
> > > > I'd like to know what are the feelings around about this patch and if
> > > > there are specific requirements and/or problems for some platforms to be
> > > > addressed before...
> > > 
> > > I think the proposed scheme (and the implementation) is flexible enough
> > > to accomodate all relevant platforms.
> > 
> > Here's an updated patch that address the remark about network boot
> > devices.
> > 
> -- 
> J. Mayer <l_indien@magic.fr>
> Never organized
> 
> 
> 
> 

Re: [Fwd: Re: [Qemu-devel] multiple boot devices]

[andrzej zaborowski]

On 09/11/2007, J. Mayer <l_indien@magic.fr> wrote:
> What about this patch ? Is there any remark ? Is it to be applied ?

Yes, I'm also in favour. Regarding the machines that boot off flash, I
will try to come up with some logical synatx. The Palm T|E board can
boot off the ROM and it needs no kernel image in such case. Currently
I was using "-option-rom rom.image -boot n" for this, as a hack, next
week I should again have some time to play with it.

Regards

Re: [Fwd: Re: [Qemu-devel] multiple boot devices]

[J. Mayer]

On Sat, 2007-11-10 at 00:43 +0100, andrzej zaborowski wrote:
> On 09/11/2007, J. Mayer <l_indien@magic.fr> wrote:
> > What about this patch ? Is there any remark ? Is it to be applied ?
> 
> Yes, I'm also in favour. Regarding the machines that boot off flash, I
> will try to come up with some logical synatx. The Palm T|E board can
> boot off the ROM and it needs no kernel image in such case. Currently
> I was using "-option-rom rom.image -boot n" for this, as a hack, next
> week I should again have some time to play with it.

What I do is use the -L / -bios options to specify a boot ROM, the same
way we can do for other machines. Maybe this scheme is not applicable to
all machines (?).
The only ennoying thing I see is that I have to give qemu a fake disk
image because qemu never wants to run if it has no bloc device
specified, which is a pity when the target machine do not have any bloc
device available.

-- 
J. Mayer <l_indien@magic.fr>
Never organized

Re: [Fwd: Re: [Qemu-devel] multiple boot devices]

[Blue Swirl]

On 11/10/07, J. Mayer <l_indien@magic.fr> wrote:
>
> On Sat, 2007-11-10 at 00:43 +0100, andrzej zaborowski wrote:
> > On 09/11/2007, J. Mayer <l_indien@magic.fr> wrote:
> > > What about this patch ? Is there any remark ? Is it to be applied ?
> >
> > Yes, I'm also in favour. Regarding the machines that boot off flash, I
> > will try to come up with some logical synatx. The Palm T|E board can
> > boot off the ROM and it needs no kernel image in such case. Currently
> > I was using "-option-rom rom.image -boot n" for this, as a hack, next
> > week I should again have some time to play with it.
>
> What I do is use the -L / -bios options to specify a boot ROM, the same
> way we can do for other machines. Maybe this scheme is not applicable to
> all machines (?).
> The only ennoying thing I see is that I have to give qemu a fake disk
> image because qemu never wants to run if it has no bloc device
> specified, which is a pity when the target machine do not have any bloc
> device available.

Also Sparc machines have supported diskless configuration for ages. I
think this restriction should be limited to x86.

The patch looks fine. On Sparc, the boot device string can be much
more complex than what can be specified with just a single letter.
This is still useful shortcut, the full path can be provided with
-prom-env switch.