Re: [Qemu-devel] qemu vl.c vl.h hw/an5206.c hw/etraxfs.c hw/inte...

[J. Mayer]

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.

Seems OK. Can we say 'c' to 'm' is sufficient to address all disk drive
cases or some more possibilities are needed for SCSI devices, or MTD
devices boot ? Maybe 'u'... for USB, as most available machines know how
to boot on USB, in the real world ? Or may we just consider 'c' to 'm'
are sufficient and it's up to the machine to determine the real meaning
of the letters, according to its implementation ? In this case, I think
we would better provide a per-machine callback to handle the '?' case,
printing an help on available boot devices letters and their meaning...

> [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.

I think there are still a few problems here:
1/ it would not be easy to add a way to use the disk syntax as proposed
here, but this could be useful. Another option could be added for this;
or it could be part of the '-disk' syntax.
2/ doing a generic check in vl.c using the machine features would need a
great rework. We then would have to first parse all options, then
retrieve the machine features, then check all options according to those
features. But this can be designed and done later
3/ it would be a great idea to provide a way to boot without any bloc
device available. Embedded devices often just have a flash device or a
ROM, then the checks done in vl.c to be sure there is a least one device
present should be machine specific, imho. Then having an empty
boot_devices string may not be a mistake.

The two last point can sure be addressed separatly. For the first one,
it seems to me that defining the way it has to be would be great: if it
needs the -boot option to be extended or redesigned, I think the best
would be to do it in the same patch...

-- 
J. Mayer <address@hidden>
Never organized