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

[Thiemo Seufer]

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.


Thiemo