From: "J. Mayer" <l_indien@magic.fr>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] qemu vl.c vl.h hw/an5206.c hw/etraxfs.c hw/inte...
Date: Wed, 31 Oct 2007 23:49:29 +0100 [thread overview]
Message-ID: <1193870969.16781.461.camel@rapid> (raw)
In-Reply-To: <1193826145.16781.424.camel@rapid>
[-- Attachment #1: Type: text/plain, Size: 4744 bytes --]
On Wed, 2007-10-31 at 11:22 +0100, J. Mayer wrote:
> On Wed, 2007-10-31 at 11:01 +0100, andrzej zaborowski wrote:
> > On 31/10/2007, J. Mayer <l_indien@magic.fr> wrote:
> > >
> > > On Wed, 2007-10-31 at 03:35 +0100, andrzej zaborowski wrote:
> > > > Hi,
> > > >
> > > > On 31/10/2007, J. Mayer <l_indien@magic.fr> wrote:
> > > > >
> > > > > On Wed, 2007-10-31 at 01:54 +0000, Andrzej Zaborowski wrote:
> > > > > > CVSROOT: /sources/qemu
> > > > > > Module name: qemu
> > > > > > Changes by: Andrzej Zaborowski <balrog> 07/10/31 01:54:05
> > > > > >
> > > > > > Modified files:
> > > > > > . : vl.c vl.h
> > > > > > hw : an5206.c etraxfs.c integratorcp.c mcf5208.c
> > > > > > mips_malta.c mips_mipssim.c mips_pica61.c
> > > > > > mips_r4k.c palm.c pc.c ppc405_boards.c
> > > > > > ppc_chrp.c ppc_oldworld.c ppc_prep.c r2d.c
> > > > > > realview.c shix.c spitz.c sun4m.c sun4u.c
> > > > > > versatilepb.c
> > > > > >
> > > > > > Log message:
> > > > > > Set boot sequence from command line (Dan Kenigsberg).
> > > > >
> > > > > There have been remarks about this patch that have not been addressed
> > > > > (not even answered, in fact). For example, the MAX_BOOT_DEVICES is set
> > > > > to 3 when more than 3 boot devices are possible to select (see the
> > > > > BOOTCHARS definition), which clearly shows the patch is not consistent.
> > > >
> > > > I double-checked to make sure all remarks made on qemu-devel were
> > > > addressed, but I may have missed something. It was explained that the
> > > > default bios supports only three boot devices,
> > >
> > > Then just take a look at the function boot_device2nibble in hw/pc.c. You
> > > can see 4 possibilities implemented here. And I think I've never seen a
> > > PC BIOS (on real machines, I mean) that don't allow more than 4 choices
> > > in last 5 years (and maybe much more...)
> >
> > MAX_BOOT_DEVICES doesn't limit the number of possible boot devices, it
> > is only a limit for the length of the sequence given on command-line.
> >
> > > The second point is that, as the legacy PC-BIOS is maybe the less
> > > versatile architecture that can be, putting limitations to the emulation
> > > model based on this spec seems to be a nonsense in Qemu, which is
> > > supposed to emulate _a lot_ of different architectures. As a matter of
> > > fact, a specific implementation (ie legacy PC target) should not lead to
> > > have hardcoded limits that would affect all other emulated targets.
> >
> > I personally wouldn't hardcode any limit but this code was submitted
> > this way and doesn't limit any current functionality in any way, it
> > extends it. I prefer the GNU/Hurd style code where no software limits
> > are ever imposed and even the standard unix limits are undefined (e.g.
> > no MAXPATHLEN), sometimes at significant cost.
>
> Imho, in that case, the only thing that can be check is that the given
> string contains only characters that can be valid devices in Qemu. Then,
> making boot_device a pointer directly assigned to optarg then check that
> all chars are >= 'a' and < 'c' + MAX_DISKS || chars == 'n' would greatly
> simplify the code. And this kind of check is the only valid one you can
> do in the generic code.
Here's a generic implementation that checks only the boot devices known
to be supported, ie 'a', 'c', 'd' and 'n', thus need no change in the
machine emulation code to work. When the machines will be able to check
properly if the boot devices match the emulated hardware and the BIOS
ABI, then it can be easily extended, changing one line, to allow boot
from more devices. I think that this code should allow choosing to (try
to...) boot from at least the 2 floppies and the 4 possible IDE devices.
The consistency test could also be changed to add more drives if it
seems to be needed.
For consistency, I also made the boot_devices variable local to the main
routine, as it's never used anywhere else.
This patch does not make the code simpler (in fact it's even more
complicated as it does more generic consistency checks) but is generic
and extensible, not breaking the previous patch and being consistent
with the i386 machine BIOS features, as implemented now.
The machine specific checks can be added later, for each target that
need some. Another solution could be that every machine implements a
callback that return a features bitmap, then the generic code could
check if the given command line arguments (including the -boot option,
but not only) are consistent with the emulated hardware platform.
[...]
--
J. Mayer <l_indien@magic.fr>
Never organized
[-- Attachment #2: boot_devices.diff --]
[-- Type: text/x-patch, Size: 4496 bytes --]
Index: vl.c
===================================================================
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.353
diff -u -d -d -p -r1.353 vl.c
--- vl.c 31 Oct 2007 01:54:03 -0000 1.353
+++ vl.c 31 Oct 2007 22:39:27 -0000
@@ -162,12 +162,6 @@ static DisplayState display_state;
int nographic;
const char* keyboard_layout = NULL;
int64_t ticks_per_sec;
-#if defined(TARGET_I386)
-#define MAX_BOOT_DEVICES 3
-#else
-#define MAX_BOOT_DEVICES 1
-#endif
-static char boot_device[MAX_BOOT_DEVICES + 1];
int ram_size;
int pit_min_timer_count = 0;
int nb_nics;
@@ -7564,6 +7560,7 @@ int main(int argc, char **argv)
const char *sd_filename;
const char *mtd_filename;
const char *kernel_filename, *kernel_cmdline;
+ const char *boot_devices = "";
DisplayState *ds = &display_state;
int cyls, heads, secs, translation;
char net_clients[MAX_NET_CLIENTS][256];
@@ -7815,20 +7812,31 @@ int main(int argc, char **argv)
}
break;
case QEMU_OPTION_boot:
- if (strlen(optarg) > MAX_BOOT_DEVICES) {
- fprintf(stderr, "qemu: too many boot devices\n");
- exit(1);
- }
- strncpy(boot_device, optarg, MAX_BOOT_DEVICES);
-#if defined(TARGET_SPARC) || defined(TARGET_I386)
-#define BOOTCHARS "acdn"
-#else
-#define BOOTCHARS "acd"
-#endif
- if (strlen(boot_device) != strspn(boot_device, BOOTCHARS)) {
- fprintf(stderr, "qemu: invalid boot device "
- "sequence '%s'\n", boot_device);
- exit(1);
+ boot_devices = optarg;
+ /* We just do some generic consistency checks */
+ {
+ /* Could easily be extended to 64 devices if needed */
+ const unsigned char *p;
+ uint32_t boot_devices_bitmap = 0;
+
+ for (p = boot_devices; *p != '\0'; p++) {
+ /* Note this could easily be extended in a way like:
+ * if (*p < 'a' || (*p > 'e' && *p != 'n'))
+ * then provide at least the ability to boot from
+ * any floppy or IDE drive for targets that can
+ * handle it.
+ */
+ if (*p != 'a' && *p != 'c' && *p != 'd' && *p != 'n') {
+ fprintf(stderr, "Invalid boot device '%c'\n", *p);
+ exit(1);
+ }
+ if (boot_devices_bitmap & (1 << (*p - 'a'))) {
+ fprintf(stderr,
+ "Boot device '%c' was given twice\n",*p);
+ exit(1);
+ }
+ boot_devices_bitmap |= 1 << (p - 'a');
+ }
}
break;
case QEMU_OPTION_fda:
@@ -8178,21 +8186,20 @@ int main(int argc, char **argv)
linux_boot = (kernel_filename != NULL);
if (!linux_boot &&
- (!strchr(boot_device, 'n')) &&
+ (!strchr(boot_devices, 'n')) &&
hd_filename[0] == '\0' &&
(cdrom_index >= 0 && hd_filename[cdrom_index] == '\0') &&
fd_filename[0] == '\0')
help(1);
/* boot to floppy or the default cd if no hard disk defined yet */
- if (!boot_device[0]) {
+ if (!boot_devices[0]) {
if (hd_filename[0] != '\0')
- boot_device[0] = 'c';
+ boot_devices = "c";
else if (fd_filename[0] != '\0')
- boot_device[0] = 'a';
+ boot_devices = "a";
else
- boot_device[0] = 'd';
- boot_device[1] = 0;
+ boot_devices = "d";
}
setvbuf(stdout, NULL, _IOLBF, 0);
@@ -8232,7 +8239,7 @@ int main(int argc, char **argv)
}
#ifdef TARGET_I386
- if (strchr(boot_device, 'n')) {
+ if (strchr(boot_devices, 'n')) {
for (i = 0; i < nb_nics; i++) {
const char *model = nd_table[i].model;
char buf[1024];
@@ -8425,7 +8432,7 @@ int main(int argc, char **argv)
}
}
- machine->init(ram_size, vga_ram_size, boot_device,
+ machine->init(ram_size, vga_ram_size, boot_devices,
ds, fd_filename, snapshot,
kernel_filename, kernel_cmdline, initrd_filename, cpu_model);
next prev parent reply other threads:[~2007-10-31 22:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-31 1:54 [Qemu-devel] qemu vl.c vl.h hw/an5206.c hw/etraxfs.c hw/inte Andrzej Zaborowski
2007-10-31 2:21 ` J. Mayer
2007-10-31 2:35 ` andrzej zaborowski
2007-10-31 4:42 ` J. Mayer
2007-10-31 10:01 ` andrzej zaborowski
2007-10-31 10:22 ` J. Mayer
2007-10-31 22:49 ` J. Mayer [this message]
2007-11-01 0:01 ` andrzej zaborowski
2007-11-01 19:12 ` J. Mayer
2007-11-03 0:01 ` andrzej zaborowski
2007-11-03 0:21 ` J. Mayer
2007-11-03 1:18 ` Thiemo Seufer
2007-11-03 12:40 ` J. Mayer
2007-11-05 13:04 ` [Qemu-devel] multiple boot devices J. Mayer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1193870969.16781.461.camel@rapid \
--to=l_indien@magic.fr \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).