From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Io7fD-0002hB-GU for qemu-devel@nongnu.org; Fri, 02 Nov 2007 21:19:03 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Io7f8-0002au-8B for qemu-devel@nongnu.org; Fri, 02 Nov 2007 21:19:02 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Io7f8-0002aa-3p for qemu-devel@nongnu.org; Fri, 02 Nov 2007 21:18:58 -0400 Received: from relay01.mx.bawue.net ([193.7.176.67]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Io7f7-0001ca-T4 for qemu-devel@nongnu.org; Fri, 02 Nov 2007 21:18:58 -0400 Date: Sat, 3 Nov 2007 01:18:21 +0000 From: Thiemo Seufer Subject: Re: [Qemu-devel] qemu vl.c vl.h hw/an5206.c hw/etraxfs.c hw/inte... Message-ID: <20071103011821.GA10975@networkno.de> References: <1193797260.16781.380.camel@rapid> <1193805724.16781.406.camel@rapid> <1193826145.16781.424.camel@rapid> <1193870969.16781.461.camel@rapid> <1193944366.16781.473.camel@rapid> <1194049315.16781.537.camel@rapid> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1194049315.16781.537.camel@rapid> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "J. Mayer" Cc: qemu-devel@nongnu.org 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