[Qemu-devel] [PATCH][RESENT] Be consistent in -clock parameter
Hi,
-soundhw, -M, -cpu and -d options use the '?' to display the list of
possibilities, whereas -clock uses 'help'. This has to be made consistent.
Some debug output is shown when -clock option is specified, which
displays list of available clocks. In my opinion, interest is very
limited (as invalid specified clocks are already printed, and list can
be obtained with -help)
When no available clock has been specified, display the list of valid
clock names and exit, instead of continuing with the default option
(once again, to be consistent with other options of Qemu)
Attached patch fixes these 3 issues.
Hervé
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.401
diff -u -r1.401 vl.c
--- vl.c23 Jan 2008 19:01:12 - 1.401
+++ vl.c31 Jan 2008 16:11:12 -
@@ -917,7 +917,7 @@
char *arg;
char *name;
-if (!strcmp(opt, help)) {
+if (!strcmp(opt, ?)) {
show_available_alarms();
exit(0);
}
@@ -956,13 +956,13 @@
free(arg);
if (cur) {
- /* Disable remaining timers */
+/* Disable remaining timers */
for (i = cur; i count; i++)
alarm_timers[i].name = NULL;
+} else {
+show_available_alarms();
+exit(1);
}
-
-/* debug */
-show_available_alarms();
}
QEMUClock *rt_clock;
@@ -7662,7 +7662,7 @@
-prom-env variable=value set OpenBIOS nvram variables\n
#endif
-clock force the use of the given methods for timer
alarm.\n
- To see what timers are available use -clock help\n
+ To see what timers are available use -clock ?\n
-startdate select initial date of the Qemu clock\n
-translation setting1,... configures code translation\n
(use -translation ? for a list of settings)\n
Re: [Qemu-devel] [PATCH] avoid name clashes due to LIST_* macros
Anthony Liguori writes (Re: [Qemu-devel] [PATCH] avoid name clashes due to LIST_* macros): Ian Jackson wrote: qemu's audio subdirectory contains a copy of BSD's sys-queue.h, which defines a bunch of LIST_ macros. This makes it difficult to build a program made partly out of qemu and partly out of the Linux kernel[1], since Linux has a different set of LIST_ macros. It might also cause trouble when mixing with BSD-derived code. That doesn't seem like a very good justification. If you're mixing QEMU code with other code, Well, surely with something like qemu one might expect to mix the code with other things ? Or is it the view of qemu upstream that qemu is not supposed to be portable to such embedded environments derived from Linux ? (Or BSD for that matter - since these LIST_* names came from BSD originally.) it's easier for you to maintain these merge conflict fixes as normal QEMU developers would have no idea what it wasn't okay to just use LIST_xxx This merge conflict is impractical to fix every time. Surely it is better just to fix it once in one place ? Normal qemu developers will know that they can use QEMU_LIST_... because that's what will be defined in the qemu tree. qemu developers who copy-and-paste code from other projects should IMO think more carefully about name clashes. Ian.
Re: [Qemu-devel] [PATCH] check return value from read() and write() properly
Anthony Liguori writes (Re: [Qemu-devel] [PATCH] check return value from
read() and write() properly):
Ian Jackson wrote:
The system calls read and write may return less than the whole amount
requested for a number of reasons. So the idioms
if (read(fd, object, sizeof(object)) != sizeof(object)) goto fail;
and even worse
if (read(fd, object, sizeof(object)) 0) goto fail;
are wrong. Additionally, read and write may sometimes return EINTR on
some systems so interruption is not desired or expected a loop is
needed.
In the attached patch I introduce two new pairs of functions:
qemu_{read,write} which are like read and write but never
return partial answers unnecessarily
and which never fail with EINTR
qemu_{read,write}_ok which returns -1 for any failure or
incomplete read, or +1 for success,
reducing repetition at calling points
There is already a unix_write function that serves this purpose. I
think a better approach would be to define unix_read/unix_write and
remove the EAGAIN handling and instead only spin on EINTR.
Is this just an argument about the name ? I chose names like
qemu_read and qemu_write by analogy with qemu_malloc. unix_write's
name is a bit of an anomaly. It is better to call it qemu_write
because that makes it clearer that these functions should be used
pretty much everywhere.
Also, unix_write is in the wrong file. It has to be in osdep.c so
that programs like qemu-img pick it up.
I don't really like the _ok thing as it's not a very common idiom.
Picking a random example from the code (loader.c near line 50):
-if (read(fd, addr, size) != size) {
+if (qemu_read_ok(fd, addr, size) 0) {
This is an improvement because you only have to write `size' once.
The idiom being replaced above is very common in the existing code and
is very clumsy when we get to things like this (dyngen.c near line
1130, indent removed to make it more readable):
- if(read(fd, dysymtabcmd, sizeof(struct dysymtab_command)) != sizeof(struct
dysymtab_command))
+ if(qemu_read_ok(fd, dysymtabcmd, sizeof(struct dysymtab_command)) 0)
As I say the former idiom is common in qemu but it is cumbersome.
As ever, facilities should be provided - and used - to improve
cumbersome idioms.
Ian.
Re: [Qemu-devel] [PATCH] avoid name clashes due to LIST_* macros
Hi, On Thu, 7 Feb 2008, Ian Jackson wrote: Anthony Liguori writes (Re: [Qemu-devel] [PATCH] avoid name clashes due to LIST_* macros): Ian Jackson wrote: qemu's audio subdirectory contains a copy of BSD's sys-queue.h, which defines a bunch of LIST_ macros. This makes it difficult to build a program made partly out of qemu and partly out of the Linux kernel[1], since Linux has a different set of LIST_ macros. It might also cause trouble when mixing with BSD-derived code. That doesn't seem like a very good justification. If you're mixing QEMU code with other code, Well, surely with something like qemu one might expect to mix the code with other things ? Read what you wrote. By that reasoning you cannot use _any_ name in qemu, because qemu should bend over to be mixable with other code. Now, if you seriously want to integrate the audiosubsystem with something in the Linux kernel, you might rename the macros. But unless you contribute that code, and people like it, I guess you will not stand much of a chance to get the renaming patch into QEmu. Ciao, Dscho
Re: [Qemu-devel] [PATCH] avoid name clashes due to LIST_* macros
Johannes Schindelin writes (Re: [Qemu-devel] [PATCH] avoid name clashes due to LIST_* macros): Read what you wrote. By that reasoning you cannot use _any_ name in qemu, because qemu should bend over to be mixable with other code. No, not at all. Just that when a clash happens something sensible should be done: one or the other should be renamed. Now, if you seriously want to integrate the audiosubsystem with something in the Linux kernel, you might rename the macros. But unless you contribute that code, and people like it, I guess you will not stand much of a chance to get the renaming patch into QEmu. This problem is not theoretical. I wouldn't be arguing about it otherwise. Without this change, our minios qemu does not build. Ian.
[Qemu-devel] Debugging QEMU
Hello, I'm getting acquainted with QEMU's internals because I'll need to know them very well for the next few months. I've reached a point where I want to debug QEMU with gdb in order to better understand the code flux related to some things that are still not clear after just looking at the code. The thing is, debugging QEMU with GDB seems to be quite troublesome. GDB keeps reporting the wrong source-code location when stepping through the code and I'm unable to insert breakpoints at some of the most important functions. I've tried to disable GCC optimizations, but the compilation fails without -O2. Is this my fault? How can I fix it? Or, is this the expected behavior? In that case, which techniques do you use to debug QEMU? Thanks in advance, Luís Pureza
Re: [Qemu-devel] [PATCH] avoid name clashes due to LIST_* macros
On Thu, 7 Feb 2008, Ian Jackson wrote: Johannes Schindelin writes (Re: [Qemu-devel] [PATCH] avoid name clashes due to LIST_* macros): Read what you wrote. By that reasoning you cannot use _any_ name in qemu, because qemu should bend over to be mixable with other code. No, not at all. Just that when a clash happens something sensible should be done: one or the other should be renamed. A bit of history: audio/sys-qemu.h only exists because when i was working on Windows side of things plain sys/queue.h wasn't available for Mingw (maybe things changed since then) so i took the liberty of copying the header from my linux system and using it. It would have been interesting if sys/queue.h was part of Mingw because i doubt that you would have pushed for changing the system supplied header. Anyway that was just to put things into perspective. Now, if you seriously want to integrate the audiosubsystem with something in the Linux kernel, you might rename the macros. But unless you contribute that code, and people like it, I guess you will not stand much of a chance to get the renaming patch into QEmu. This problem is not theoretical. I wouldn't be arguing about it otherwise. Without this change, our minios qemu does not build. -- mailto:[EMAIL PROTECTED]
Re: [Qemu-devel] [PATCH] Add script hook for VNC server to support mDNS/DNS-SD
This version is still a bit chatty when -name isn't specified so
attached is an updated version of the patch which is less chatty when
-name isn't specified.
Regards,
Anthony Liguori
Anthony Liguori wrote:
Modern DNS clients (like vinagre) support mDNS/DNS-SD discovery of VNC servers.
VNC servers like Vino link directly against libavahi to publish themselves.
Fitting libavahi into QEMU though would be pretty hairy and not as flexible as
simply calling out to a helper script and using the avahi utilities.
This patch adds support for a ',script=/patch/to/script' option to the existing
-vnc option. It also includes an example script which uses avahi-publish the
presence of the QEMU instance. Care has been taken to ensure that errors are
silenced if either bash or avahi aren't present and the user hasn't explicitly
specified ',script='.
Subject: [PATCH] Add script hook for VNC server to support mDNS/DNS-SD
Modern DNS clients (like vinagre) support mDNS/DNS-SD discovery of VNC servers.
VNC servers like Vino link directly against libavahi to publish themselves.
Fitting libavahi into QEMU though would be pretty hairy and not as flexible as
simply calling out to a helper script and using the avahi utilities.
This patch adds support for a ',script=/patch/to/script' option to the existing
-vnc option. It also includes an example script which uses avahi-publish the
presence of the QEMU instance. Care has been taken to ensure that errors are
silenced if either bash or avahi aren't present and the user hasn't explicitly
specified ',script='.
diff --git a/qemu-doc.texi b/qemu-doc.texi
index f9924d2..cd59aab 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -486,6 +486,21 @@ path following this option specifies where the x509 certificates are to
be loaded from. See the @ref{vnc_security} section for details on generating
certificates.
[EMAIL PROTECTED] [EMAIL PROTECTED]/path/to/script}
+
+Launch a script when the VNC server is started. The script is expected to
+continue running as long as the VNC server is running. When the VNC server
+closes, the script will receive either a SIGTERM or standard input will be
+shutdown. The script will be passed arguments in the order of @var{NAME}
[EMAIL PROTECTED] @var{PORT} where @var{NAME} is the value passed to the
[EMAIL PROTECTED] option, @var{ADDRESS} is the address the server is bound to,
+and @var{PORT} is the port the server is listening on.
+
+This script will not be executed if @var{reverse} is being used or if the
+server is listening on a Unix domain socket. If the @option{-name} option is
+not specified, the script will not be executed. The default location of the
+script is @file{/etc/qemu-vncup}.
+
@end table
@item -k @var{language}
diff --git a/qemu-vncup b/qemu-vncup
new file mode 100755
index 000..78b9d2d
--- /dev/null
+++ b/qemu-vncup
@@ -0,0 +1,27 @@
+#!/bin/bash
+
+function dokill() {
+kill -SIGTERM $1 /dev/null
+}
+
+if [ -z $1 -o -z $3 ]; then
+echo Usage: $0 NAME ADDRESS PORT
+exit 1
+fi
+
+which avahi-publish /dev/null
+if [ $? != 0 ] ; then
+exit 0
+fi
+
+avahi-publish -s $1 Virtual Console '_rfb._tcp' $3 /dev/null 21 /dev/null
+
+pid=`jobs -p %1`
+
+trap dokill -SIGTERM $pid; exit SIGINT SIGTERM
+
+while read LINE ; do
+echo $LINE
+done
+
+dokill -SIGTERM $pid
diff --git a/vnc.c b/vnc.c
index e7f3255..8d68770 100644
--- a/vnc.c
+++ b/vnc.c
@@ -31,6 +31,8 @@
#define VNC_REFRESH_INTERVAL (1000 / 30)
+#define VNC_DEFAULT_SCRIPT /etc/qemu-vncup
+
#include vnc_keysym.h
#include keymaps.c
#include d3des.h
@@ -40,6 +42,11 @@
#include gnutls/x509.h
#endif /* CONFIG_VNC_TLS */
+#ifndef _WIN32
+#include signal.h
+#include sys/wait.h
+#endif
+
// #define _VNC_DEBUG 1
#if _VNC_DEBUG
@@ -174,6 +181,11 @@ struct VncState
size_t read_handler_expect;
/* input */
uint8_t modifiers_state[256];
+
+#ifndef _WIN32
+pid_t script_pid;
+int script_fd;
+#endif
};
static VncState *vnc_state; /* needed for info vnc */
@@ -2056,6 +2068,13 @@ void vnc_display_close(DisplayState *ds)
vs-wiremode = VNC_WIREMODE_CLEAR;
#endif /* CONFIG_VNC_TLS */
}
+#ifndef _WIN32
+if (vs-script_pid) {
+ close(vs-script_fd);
+ while (waitpid(vs-script_pid, NULL, 0) == -1 errno == EINTR);
+ vs-script_pid = -1;
+}
+#endif
vs-auth = VNC_AUTH_INVALID;
#if CONFIG_VNC_TLS
vs-subauth = VNC_AUTH_INVALID;
@@ -2079,6 +2098,54 @@ int vnc_display_password(DisplayState *ds, const char *password)
return 0;
}
+#ifndef _WIN32
+static int launch_vnc_script(VncState *vs, const char *script,
+ const char *name, const char *addr,
+ int port)
+{
+int fds[2];
+int quiet = 0;
+
+vs-script_pid = 0;
+
+if (pipe(fds) == -1) {
+ fprintf(stderr, qemu: pipe failed\n);
+ return -1;
+}
+
+if (script == NULL) {
+ quiet = 1;
+ script = strdup(VNC_DEFAULT_SCRIPT);
+}
+
+vs-script_pid = fork();
+vs-script_fd = fds[1];
+if (vs-script_pid == 0) {
[Qemu-devel] [PATCH] Windows: put version and file info into exe
This patch will make an .rc file that will put the version info as well as a brief discription of the app for Windows. versionrc.diff Description: Binary data
[Qemu-devel] [PATCH] Add script hook for VNC server to support mDNS/DNS-SD
Modern DNS clients (like vinagre) support mDNS/DNS-SD discovery of VNC servers.
VNC servers like Vino link directly against libavahi to publish themselves.
Fitting libavahi into QEMU though would be pretty hairy and not as flexible as
simply calling out to a helper script and using the avahi utilities.
This patch adds support for a ',script=/patch/to/script' option to the existing
-vnc option. It also includes an example script which uses avahi-publish the
presence of the QEMU instance. Care has been taken to ensure that errors are
silenced if either bash or avahi aren't present and the user hasn't explicitly
specified ',script='.
diff --git a/qemu-doc.texi b/qemu-doc.texi
index f9924d2..cd59aab 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -486,6 +486,21 @@ path following this option specifies where the x509
certificates are to
be loaded from. See the @ref{vnc_security} section for details on generating
certificates.
[EMAIL PROTECTED] [EMAIL PROTECTED]/path/to/script}
+
+Launch a script when the VNC server is started. The script is expected to
+continue running as long as the VNC server is running. When the VNC server
+closes, the script will receive either a SIGTERM or standard input will be
+shutdown. The script will be passed arguments in the order of @var{NAME}
[EMAIL PROTECTED] @var{PORT} where @var{NAME} is the value passed to the
[EMAIL PROTECTED] option, @var{ADDRESS} is the address the server is bound to,
+and @var{PORT} is the port the server is listening on.
+
+This script will not be executed if @var{reverse} is being used or if the
+server is listening on a Unix domain socket. If the @option{-name} option is
+not specified, the script will not be executed. The default location of the
+script is @file{/etc/qemu-vncup}.
+
@end table
@item -k @var{language}
diff --git a/qemu-vncup b/qemu-vncup
new file mode 100755
index 000..78b9d2d
--- /dev/null
+++ b/qemu-vncup
@@ -0,0 +1,27 @@
+#!/bin/bash
+
+function dokill() {
+kill -SIGTERM $1 /dev/null
+}
+
+if [ -z $1 -o -z $3 ]; then
+echo Usage: $0 NAME ADDRESS PORT
+exit 1
+fi
+
+which avahi-publish /dev/null
+if [ $? != 0 ] ; then
+exit 0
+fi
+
+avahi-publish -s $1 Virtual Console '_rfb._tcp' $3 /dev/null 21
/dev/null
+
+pid=`jobs -p %1`
+
+trap dokill -SIGTERM $pid; exit SIGINT SIGTERM
+
+while read LINE ; do
+echo $LINE
+done
+
+dokill -SIGTERM $pid
diff --git a/vnc.c b/vnc.c
index b19c6d0..58a6ed4 100644
--- a/vnc.c
+++ b/vnc.c
@@ -31,6 +31,8 @@
#define VNC_REFRESH_INTERVAL (1000 / 30)
+#define VNC_DEFAULT_SCRIPT /etc/qemu-vncup
+
#include vnc_keysym.h
#include keymaps.c
#include d3des.h
@@ -40,6 +42,11 @@
#include gnutls/x509.h
#endif /* CONFIG_VNC_TLS */
+#ifndef _WIN32
+#include signal.h
+#include sys/wait.h
+#endif
+
// #define _VNC_DEBUG 1
#if _VNC_DEBUG
@@ -174,6 +181,11 @@ struct VncState
size_t read_handler_expect;
/* input */
uint8_t modifiers_state[256];
+
+#ifndef _WIN32
+pid_t script_pid;
+int script_fd;
+#endif
};
static VncState *vnc_state; /* needed for info vnc */
@@ -2098,6 +2110,13 @@ void vnc_display_close(DisplayState *ds)
vs-wiremode = VNC_WIREMODE_CLEAR;
#endif /* CONFIG_VNC_TLS */
}
+#ifndef _WIN32
+if (vs-script_pid) {
+ close(vs-script_fd);
+ while (waitpid(vs-script_pid, NULL, 0) == -1 errno == EINTR);
+ vs-script_pid = -1;
+}
+#endif
vs-auth = VNC_AUTH_INVALID;
#if CONFIG_VNC_TLS
vs-subauth = VNC_AUTH_INVALID;
@@ -2121,6 +2140,54 @@ int vnc_display_password(DisplayState *ds, const char
*password)
return 0;
}
+#ifndef _WIN32
+static int launch_vnc_script(VncState *vs, const char *script,
+const char *name, const char *addr,
+int port)
+{
+int fds[2];
+int quiet = 0;
+
+vs-script_pid = 0;
+
+if (pipe(fds) == -1) {
+ fprintf(stderr, qemu: pipe failed\n);
+ return -1;
+}
+
+if (script == NULL) {
+ quiet = 1;
+ script = strdup(VNC_DEFAULT_SCRIPT);
+}
+
+vs-script_pid = fork();
+vs-script_fd = fds[1];
+if (vs-script_pid == 0) {
+ int fd;
+ char port_str[32];
+
+ dup2(fds[0], STDIN_FILENO);
+ for (fd = 3; fd sysconf(_SC_OPEN_MAX); fd++)
+ close(fd);
+
+ snprintf(port_str, sizeof(port_str), %d, port);
+ execlp(script, script, name, addr, port_str, NULL);
+ if (!quiet)
+ fprintf(stderr, qemu: failed to exec vnc script: %m\n);
+ exit(1);
+} else if (vs-script_pid 0) {
+ fprintf(stderr, qemu: fork failed\n);
+ return -1;
+} else
+ close(fds[0]);
+
+if (quiet)
+ qemu_free((char *)script);
+
+return 0;
+}
+#endif
+
int vnc_display_open(DisplayState *ds, const char *display)
{
struct sockaddr *addr;
@@ -2138,6 +2205,8 @@ int vnc_display_open(DisplayState *ds, const char
*display)
#if CONFIG_VNC_TLS
int tls = 0, x509 = 0;
#endif
+char
[Qemu-devel] What does code_copy_enabled do?
Grepping through the source code, I can find 3 places where this global variable is set (it's initialized to a default value of 1, there's a no-code-copy command line option that sets it to zero, and then it shows up in the test suite once). What I can't find is any code ever actually checking or using the value put into this variable What's it for? Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson.
Re: [Qemu-devel] What does code_copy_enabled do?
On Friday 08 February 2008, Rob Landley wrote: Grepping through the source code, I can find 3 places where this global variable is set (it's initialized to a default value of 1, there's a no-code-copy command line option that sets it to zero, and then it shows up in the test suite once). What I can't find is any code ever actually checking or using the value put into this variable It got ripped out a while back. Paul
[Qemu-devel] [PATCH] Change the behaviour of -alt-grab and add X11-shortcuts
Hello,
this patch to sdl.c (qemu 0.9.1) changes the behavior of -alt-grab to be
similar to VirtualBox.
The reason for this is to have an easy way for sending ctrl-alt-Fn and
ctrl-alt-backspace to the guest. Since ctrl-alt-Fn and
ctrl-alt-backspace are intercepted by X11 new shortcuts are added:
grab_key+Fn
grab_key+backspace
For this to work the alternative grab key is changed from
left_ctrl+left_alt+left_shift to right_ctrl. When a ctrl-key is
needed, the left ctrl-key can still be used (this also applies to
combinations like ctrl-alt-delete for which the -alt-grab option was
originally added).
Disclaimer: I'm not very familiar with the qemu sources and perhaps
there is a nicer way for sending the keys to the guest.
--- qemu/sdl.c 2008-01-06 20:38:42.0 +0100
+++ qemu-altgrabmod/sdl.c 2008-02-07 20:04:58.0 +0100
@@ -229,7 +229,7 @@
if (!alt_grab)
status = - Press Ctrl-Alt to exit grab;
else
-status = - Press Ctrl-Alt-Shift to exit grab;
+status = - Press Ctrl (right) to exit grab;
}
if (qemu_name)
@@ -367,8 +367,8 @@
mod_state = (SDL_GetModState() gui_grab_code) ==
gui_grab_code;
} else {
-mod_state = (SDL_GetModState() (gui_grab_code | KMOD_LSHIFT)) ==
-(gui_grab_code | KMOD_LSHIFT);
+mod_state = (SDL_GetModState() KMOD_RCTRL) ==
+ KMOD_RCTRL;
}
gui_key_modifier_pressed = mod_state;
if (gui_key_modifier_pressed) {
@@ -390,6 +390,19 @@
}
gui_keysym = 1;
break;
+case 0x3b ... 0x44: /* F1 .. F10 keys */
+case 0xe: /* backspace */
+ /* like sendkey ctrl-alt-(fn|backspace) */
+ /* key down */
+ kbd_put_keycode(0x1d); /* left ctrl key */
+ kbd_put_keycode(0x38); /* left alt key */
+ kbd_put_keycode(keycode);
+ /* key up */
+ kbd_put_keycode(0x1d|0x80);
+ kbd_put_keycode(0x38|0x80);
+ kbd_put_keycode(keycode|0x80);
+ gui_keysym = 1;
+ break;
default:
break;
}
[Qemu-devel] [PATCH] boot a linux kernel from non-ide device
Since it's now possible to use the -drive option, the test for something
in the index 0 of the IDE bus is too restrictive.
A better idea, IMHO, is to check if the user specified any bootable device,
and only if not, fallback to the default, compatible behaviour of checking
hda regardless of the presence of a boot=on arg.
--
Glauber de Oliveira Costa.
Free as in Freedom
http://glommer.net
The less confident you are, the more serious you have to act.
commit 65b8fcf3bc5b754b720a04fa7efed6fdcd472a6a
Author: Glauber de Oliveira Costa [EMAIL PROTECTED]
Date: Fri Feb 8 05:02:47 2008 -0200
[PATCH] boot a linux kernel from non-ide device
Since it's now possible to use the -drive option, the test for something
in the index 0 of the IDE bus is too restrictive.
A better idea, IMHO, is to check if the user specified any bootable device,
and only if not, fallback to the default, compatible behaviour of checking
hda regardless of the presence of a boot=on arg.
diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
index 5ce28ab..a9b0f71 100644
--- a/qemu/hw/pc.c
+++ b/qemu/hw/pc.c
@@ -398,11 +398,14 @@ static void generate_bootsect(uint32_t gpr[8], uint16_t segs[6], uint16_t ip)
{
uint8_t bootsect[512], *p;
int i;
-int hda;
-
-hda = drive_get_index(IF_IDE, 0, 0);
-if (hda == -1) {
- fprintf(stderr, A disk image must be given for 'hda' when booting
+int hda = -1, boot_device;
+
+if (extboot_drive != -1)
+boot_device = extboot_drive;
+else if ((hda = drive_get_index(IF_IDE, 0, 0)) != -1)
+ boot_device = hda;
+else {
+ fprintf(stderr, A bootable disk image must be given when booting
a Linux kernel\n);
exit(1);
}
@@ -410,7 +413,7 @@ static void generate_bootsect(uint32_t gpr[8], uint16_t segs[6], uint16_t ip)
memset(bootsect, 0, sizeof(bootsect));
/* Copy the MSDOS partition table if possible */
-bdrv_read(drives_table[hda].bdrv, 0, bootsect, 1);
+bdrv_read(drives_table[boot_device].bdrv, 0, bootsect, 1);
/* Make sure we have a partition signature */
bootsect[510] = 0x55;
@@ -447,7 +450,7 @@ static void generate_bootsect(uint32_t gpr[8], uint16_t segs[6], uint16_t ip)
*p++ = segs[1]; /* CS */
*p++ = segs[1] 8;
-bdrv_set_boot_sector(drives_table[hda].bdrv, bootsect, sizeof(bootsect));
+bdrv_set_boot_sector(drives_table[boot_device].bdrv, bootsect, sizeof(bootsect));
}
static int load_kernel(const char *filename, uint8_t *addr,
