From: Anthony L. <ali...@us...> - 2008-05-13 21:19:14
|
There has been an awful lot of discussion about a configuration file with almost no general agreement except that one is strongly desired. I thought about it a bit, and I think a nice step would be to simply allow the current configuration parameters to be stored in a file using a pretty familiar format. I think this is pretty useful as-is. I think it also gives us a reasonable way to move forward that will keep everyone pretty happy. Here's a short example: qemu-system-x86_64 -hda ~/images/linux.img -snapshot -vnc :2 Would become `foo.qemu': # Main disk image hda=/home/anthony/images/linux.img # Redirect disk writes to a temporary image snapshot # Make the graphical display available on port 5902 vnc=:2 With: qemu-system-x86_64 -config foo.qemu Signed-off-by: Anthony Liguori <ali...@us...> diff --git a/qemu-doc.texi b/qemu-doc.texi index cca483c..4861fc0 100644 --- a/qemu-doc.texi +++ b/qemu-doc.texi @@ -395,6 +395,12 @@ Sets the @var{name} of the guest. This name will be display in the SDL window caption. The @var{name} will also be used for the VNC server. +@item -config @var{file} +Reads configuration options from @var{file}. The format of @var{file} is the +same as the command line options, except no dash ``-'' is required. Options +that take an argument are in the format @var{option=value}. A pound ``#'' +character can be used as a comment. + @end table Display options: diff --git a/vl.c b/vl.c index 67712f0..2eb39dd 100644 --- a/vl.c +++ b/vl.c @@ -7276,6 +7276,7 @@ static void help(int exitcode) "-clock force the use of the given methods for timer alarm.\n" " To see what timers are available use -clock ?\n" "-startdate select initial date of the clock\n" + "-config FILE read command line options from FILE\n" "\n" "During emulation, the following keys are useful:\n" "ctrl-alt-f toggle full screen\n" @@ -7379,6 +7380,7 @@ enum { QEMU_OPTION_old_param, QEMU_OPTION_clock, QEMU_OPTION_startdate, + QEMU_OPTION_config, }; typedef struct QEMUOption { @@ -7490,6 +7492,7 @@ const QEMUOption qemu_options[] = { #endif { "clock", HAS_ARG, QEMU_OPTION_clock }, { "startdate", HAS_ARG, QEMU_OPTION_startdate }, + { "config", HAS_ARG, QEMU_OPTION_config }, { NULL }, }; @@ -7665,9 +7668,106 @@ static BOOL WINAPI qemu_ctrl_handler(DWORD type) } #endif +static char **insert_opts(char **old_argv, int *old_argc, int index, + char **argv, int argc) +{ + char **new_argv; + + /* Allocate larger array */ + new_argv = realloc(old_argv, (*old_argc + argc) * sizeof(old_argv[0])); + if (new_argv == NULL) { + fprintf(stderr, "allocate failed in insert_opts\n"); + exit(1); + } + + /* move elements after insertion point to end of array */ + memmove(new_argv+index + argc, new_argv + index, + (*old_argc - index) * sizeof(argv[0])); + + /* copy in new elements */ + memcpy(new_argv + index, argv, argc * sizeof(argv[0])); + + *old_argc += argc; + + if (0) { /* for debugging */ + int i; + printf("argv[] = {"); + for (i = 0; i < *old_argc; i++) { + if (i) + printf(", "); + printf("\"%s\"", new_argv[i]); + } + printf("}\n"); + } + + return new_argv; +} + +static char **parse_config_file(const char *file, int *pargc) +{ + FILE *f; + char buffer[4096]; + char **argv = NULL; + int argc = 0; + + f = fopen(file, "r"); + if (f == NULL) + return NULL; + + while (fgets(buffer, sizeof(buffer), f)) { + char *ptr = buffer; + char *tok, *key, *val; + char *targv[2]; + int targc = 0; + + /* skip whitespace */ + while (isspace(*ptr)) ptr++; + + /* skip comments or empty lines */ + if (*ptr == '#' || *ptr == 0) + continue; + + /* trim new line and carriage return if necessary */ + tok = strchr(ptr, '\n'); + if (tok) + *tok = 0; + tok = strchr(ptr, '\r'); + if (tok) + *tok = 0; + + /* check if it has an argument */ + tok = strchr(ptr, '='); + if (tok) + *tok = 0; + + /* add key */ + if (asprintf(&key, "--%s", ptr) == -1) + return NULL; + targv[targc++] = key; + + /* add argument (optionally) */ + if (tok) { + if (asprintf(&val, "%s", tok + 1) == -1) + return NULL; + targv[targc++] = val; + } + + /* insert new arguments */ + argv = insert_opts(argv, &argc, argc, targv, targc); + if (argv == NULL) + return NULL; + } + + fclose(f); + + *pargc = argc; + + return argv; +} + #define MAX_NET_CLIENTS 32 -int main(int argc, char **argv) +int main(int orig_argc, char **orig_argv) { #ifdef CONFIG_GDBSTUB int use_gdbstub; @@ -7700,6 +7800,10 @@ int main(int argc, char **argv) int fds[2]; const char *pid_file = NULL; VLANState *vlan; + char **argv = NULL; + int argc = 0; + + argv = insert_opts(argv, &argc, 0, orig_argv, orig_argc); LIST_INIT (&vm_change_state_head); #ifndef _WIN32 @@ -8297,6 +8401,20 @@ int main(int argc, char **argv) } } break; + case QEMU_OPTION_config: { + char **config_argv; + int config_argc; + + config_argv = parse_config_file(optarg, &config_argc); + if (config_argv == NULL) { + fprintf(stderr, "failed to parse config file `%s'\n", optarg); + exit(1); + } + + argv = insert_opts(argv, &argc, optind, + config_argv, config_argc); + free(config_argv); + } break; } } } |
From: Anthony L. <an...@co...> - 2008-05-13 23:07:15
|
Anthony Liguori wrote: > I think this is pretty useful as-is. I think it also gives us a reasonable > way to move forward that will keep everyone pretty happy. > > Here's a short example: > > qemu-system-x86_64 -hda ~/images/linux.img -snapshot -vnc :2 > > Would become `foo.qemu': > > # Main disk image > hda=/home/anthony/images/linux.img > > # Redirect disk writes to a temporary image > snapshot > > # Make the graphical display available on port 5902 > vnc=:2 > > With: > > qemu-system-x86_64 -config foo.qemu One thought I had, is that it would be very nice to break up the -drive file=foo.img,if=scsi syntax within the config file. In general, I'm thinking something like: [drive] file=foo.img if=scsi or: drive { file=foo.img if=scsi } or even: drive: file=foo.img if=scsi Basically, I'm looking for a syntax for sub-options. This would be useful for -drive or -net but I also think would lay the foundations for specifying a full machine config. It would get very unwieldy on the command line to have a large number of suboptions but it works reasonably well within a config. Regards, Anthony Liguori |
From: Daniel P. B. <ber...@re...> - 2008-05-13 23:24:27
|
On Tue, May 13, 2008 at 06:07:08PM -0500, Anthony Liguori wrote: > Anthony Liguori wrote: > > I think this is pretty useful as-is. I think it also gives us a reasonable > > way to move forward that will keep everyone pretty happy. > > > > Here's a short example: > > > > qemu-system-x86_64 -hda ~/images/linux.img -snapshot -vnc :2 > > > > Would become `foo.qemu': > > > > # Main disk image > > hda=/home/anthony/images/linux.img > > > > # Redirect disk writes to a temporary image > > snapshot > > > > # Make the graphical display available on port 5902 > > vnc=:2 > > > > With: > > > > qemu-system-x86_64 -config foo.qemu > > One thought I had, is that it would be very nice to break up the -drive > file=foo.img,if=scsi syntax within the config file. In general, I'm > thinking something like: Yes, that would be the main concern I have with the plain conversion of existing command line args. It would essentially be limiting the expressiveness of the config file to that of the command line - flat key,value pairs. All we'd be gaining is avoidance of command line length limits and persistent storage. Two worthy goals, but IMHO it could be worth striving for more structure, so the config can explicitly represent arrays and hashes as concepts. > [drive] > file=foo.img > if=scsi This just feels like a bad 1/2 house compromise. Adds the complexity of a more structured config file without giving the full benefits of a more expressive format such as the 2 you show below. > drive { > file=foo.img > if=scsi > } I like both this & the next format because they're very expressive. > or even: > > drive: > file=foo.img > if=scsi That's very nearly YAML format[1], which is attractive because parsers are available in every major programming language, and it is still pretty human friendly. So my preference would be to go with the last option and make sure it really is YAML compliant so people can use standard tools for generating and parsing the format. Regards, Daniel [1] http://yaml.org/spec/1.2/ -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| |
From: Colin A. <col...@go...> - 2008-05-14 06:35:46
|
> That's very nearly YAML format[1], which is attractive because parsers > are available in every major programming language, Really? I can't find one for Eiffel. Can you give me a pointer please? |
From: Fabrice B. <fa...@be...> - 2008-05-14 08:27:34
|
Anthony Liguori wrote: > One thought I had, is that it would be very nice to break up the -drive > file=foo.img,if=scsi syntax within the config file. In general, I'm > thinking something like: > > [drive] > file=foo.img > if=scsi > > or: > > drive { > file=foo.img > if=scsi > } > > or even: > > drive: > file=foo.img > if=scsi > > Basically, I'm looking for a syntax for sub-options. This would be > useful for -drive or -net but I also think would lay the foundations for > specifying a full machine config. > > It would get very unwieldy on the command line to have a large number of > suboptions but it works reasonably well within a config. I prefer: drive.file=foo.img drive.if=scsi Regards, Fabrice. |
From: Avi K. <av...@qu...> - 2008-05-14 10:31:12
|
Fabrice Bellard wrote: > > I prefer: > > drive.file=foo.img > drive.if=scsi > That doesn't support multiple drives very well. -- error compiling committee.c: too many arguments to function |
From: Daniel P. B. <ber...@re...> - 2008-05-14 13:35:32
|
On Wed, May 14, 2008 at 02:26:40PM +0200, Fabrice Bellard wrote: > Avi Kivity wrote: > > Fabrice Bellard wrote: > >> > >> I prefer: > >> > >> drive.file=foo.img > >> drive.if=scsi > >> > > > > That doesn't support multiple drives very well. > > Right, I realized it afterwards ! > > I suggested it because my original plan for the configuration file was > based on this syntax with a strong inspiration from the OpenFirmware > device tree. The idea was that the object name ("drive" here) had no > hardcoded meaning, except for some predefined object names in order to > keep a kind of backward compatibility with the current QEMU options. In > order to create a new drive for example, you just have to do: > > mydrive.class=drive > mydrive.if=scsi > mydrive.file=abc.img With this kind of syntax, now tools generating config files need to make up unique names for each drive. So you'll probably end up with them just naming things based on the class name + a number appended. drive0.class=drive drive0.if=scsi drive0.file=foo.img drive1.class=drive drive1.if=scsi drive1.file=bar.img drive2.class=drive ... Which suggests it'd be better to take your original previous syntax example and using an explicit numeric component to represent lists of drives, eg drive.0.file=foo.img drive.0.if=scsi drive.1.file=bar.img drive.1.if=scsi drive.2.file=wiz.img drive.2.if=scsi Thus avoiding the need for adding the 'class' setting at all Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| |
From: Avi K. <av...@qu...> - 2008-05-14 14:41:36
|
Daniel P. Berrange wrote: > That's very nearly YAML format[1], which is attractive because parsers > are available in every major programming language, and it is still > pretty human friendly. > > So my preference would be to go with the last option and make sure > it really is YAML compliant so people can use standard tools for > generating and parsing the format. > Using a standard format has the added benefit that things like quoting are taken care of. Filenames with leading and trailing spaces, anyone? Embedded control characters? -- error compiling committee.c: too many arguments to function |
From: Anthony L. <ali...@us...> - 2008-05-14 15:00:56
|
Avi Kivity wrote: > Daniel P. Berrange wrote: >> That's very nearly YAML format[1], which is attractive because parsers >> are available in every major programming language, and it is still >> pretty human friendly. >> >> So my preference would be to go with the last option and make sure >> it really is YAML compliant so people can use standard tools for >> generating and parsing the format. >> > > Using a standard format has the added benefit that things like quoting > are taken care of. > > Filenames with leading and trailing spaces, anyone? Embedded control > characters? YAML is a bad choice though. It's purpose is to model data structures of embedded languages (similar to JSON). The syntax would get out of hand quickly because what we've been talking about so far would be modeled as an association whereas semantically, we want it to be a sequence. To make it a sequence, we would have to prefix every line with '-'. I'm not against following some sort of standard (or even best practice). I just don't like YAML. Regards, Anthony Liguori |
From: Dor L. <dor...@qu...> - 2008-05-14 14:56:48
|
On Wed, 2008-05-14 at 17:41 +0300, Avi Kivity wrote: > Daniel P. Berrange wrote: > > That's very nearly YAML format[1], which is attractive because parsers > > are available in every major programming language, and it is still > > pretty human friendly. > > > > So my preference would be to go with the last option and make sure > > it really is YAML compliant so people can use standard tools for > > generating and parsing the format. > > > > Using a standard format has the added benefit that things like quoting > are taken care of. > > Filenames with leading and trailing spaces, anyone? Embedded control > characters? > Please don't jump over me but I think it is worth mentioning OVF, at least for to know what's you opinions. Open Virtualization Format - http://www.vmware.com/appliances/learn/ovf.html It's xml based, supported by all major hypervisors, so qemu/kvm/xen users might eventually use a product that support OVF. Since its a new format it is open for changes and has lots of flexibility. As a start we don't have to be completely compatible with it. It supports definition cpus, startup options, various devices (nic, ide, scsi,...). For example: " <Item> <rasd:Caption>Ethernet adapter on "VM Network"</rasd:Caption> <rasd:InstanceId>4000</rasd:InstanceId> <rasd:ResourceType>10</rasd:ResourceType> <rasd:ResourceSubType>VmxNet, E1000</rasd:ResourceSubType> <rasd:AutomaticAllocation>true</rasd:AutomaticAllocation> <rasd:Connection>VM Network</rasd:Connection> </Item> <Item> <rasd:Caption>SCSI Controller 0</rasd:Caption> <rasd:InstanceId>1000</rasd:InstanceId> <rasd:ResourceType>6</rasd:ResourceType> <rasd:ResourceSubType>LsiLogic, BusLogic</rasd:ResourceSubType> </Item> <Item> <rasd:Caption>Harddisk 1</rasd:Caption> <rasd:InstanceId>22001</rasd:InstanceId> <rasd:ResourceType>17</rasd:ResourceType> <rasd:HostResource>disk/vmdisk1</rasd:HostResource> <rasd:Parent>1000</rasd:Parent> </Item> <Item> </Item> " One can claim to xml is bad and ovf is outside of the scope and if one wants ovf, mgmt tool can wrap it around qemu. Nevertheless why doubling the effort? Qemu can reuse it and its mgmt tools. |
From: Daniel P. B. <ber...@re...> - 2008-05-14 15:05:27
|
On Wed, May 14, 2008 at 05:52:56PM +0300, Dor Laor wrote: > > On Wed, 2008-05-14 at 17:41 +0300, Avi Kivity wrote: > > Daniel P. Berrange wrote: > > > That's very nearly YAML format[1], which is attractive because parsers > > > are available in every major programming language, and it is still > > > pretty human friendly. > > > > > > So my preference would be to go with the last option and make sure > > > it really is YAML compliant so people can use standard tools for > > > generating and parsing the format. > > > > > > > Using a standard format has the added benefit that things like quoting > > are taken care of. > > > > Filenames with leading and trailing spaces, anyone? Embedded control > > characters? > > > > Please don't jump over me but I think it is worth mentioning OVF, at > least for to know what's you opinions. OVF is insanely overcomplicated. It is also addressing a different problem space, that of virtual machine applinance interchange / distribution. And it is a disgusting format for users to deal with. > Open Virtualization Format - > http://www.vmware.com/appliances/learn/ovf.html > > It's xml based, supported by all major hypervisors, so qemu/kvm/xen > users might eventually use a product that support OVF. > Since its a new format it is open for changes and has lots of > flexibility. As a start we don't have to be completely compatible with > it. It is a 'open' format defined in secret invitation only cabal by a bunch of proprietry software vendors. No thanks. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| |
From: Anthony L. <an...@co...> - 2008-05-14 15:18:22
|
Dor Laor wrote: > On Wed, 2008-05-14 at 17:41 +0300, Avi Kivity wrote: > > Please don't jump over me but I think it is worth mentioning OVF, at > least for to know what's you opinions. > > Open Virtualization Format - > http://www.vmware.com/appliances/learn/ovf.html > > It's xml based, supported by all major hypervisors, so qemu/kvm/xen > users might eventually use a product that support OVF. > xml is a non-starter for QEMU. We go out of our way to be portable. Having an XML dependency that could be satisfied on Windows and Linux would probably require more code to support the dependency than all of QEMU itself. Regards, Anthony Liguori |
From: Fabrice B. <fa...@be...> - 2008-05-14 12:26:37
|
Avi Kivity wrote: > Fabrice Bellard wrote: >> >> I prefer: >> >> drive.file=foo.img >> drive.if=scsi >> > > That doesn't support multiple drives very well. Right, I realized it afterwards ! I suggested it because my original plan for the configuration file was based on this syntax with a strong inspiration from the OpenFirmware device tree. The idea was that the object name ("drive" here) had no hardcoded meaning, except for some predefined object names in order to keep a kind of backward compatibility with the current QEMU options. In order to create a new drive for example, you just have to do: mydrive.class=drive mydrive.if=scsi mydrive.file=abc.img the "class" field is used to select the device model. Then all the other parameters are used to initialize the device model. That way it is possible to keep the compatibility with the existing options and add a provision to instanciate arbitrary new device models, such as: mynetworkcard.class="ne2000pci" mynetworkcard.bus=1 # pci bus selection mynetworkcard.macaddr=00:01:02:03:04:05 mynetworkcard.vlan=1 I will strongly support configuration file formats having this property. Regards, Fabrice. |
From: Anthony L. <ali...@us...> - 2008-05-14 14:06:57
|
Fabrice Bellard wrote: > Avi Kivity wrote: >> Fabrice Bellard wrote: >>> >>> I prefer: >>> >>> drive.file=foo.img >>> drive.if=scsi >>> >> >> That doesn't support multiple drives very well. > > Right, I realized it afterwards ! > > I suggested it because my original plan for the configuration file was > based on this syntax with a strong inspiration from the OpenFirmware > device tree. The idea was that the object name ("drive" here) had no > hardcoded meaning, except for some predefined object names in order to > keep a kind of backward compatibility with the current QEMU options. > In order to create a new drive for example, you just have to do: > > mydrive.class=drive > mydrive.if=scsi > mydrive.file=abc.img > > the "class" field is used to select the device model. Then all the > other parameters are used to initialize the device model. That way it > is possible to keep the compatibility with the existing options and > add a provision to instanciate arbitrary new device models, such as: I like this syntax primarily because it provides a means to associate arbitrary data with a VM. It also provides a sane way to keep track of which device is which so that the "config" can be updated while the VM is running. I'll update the patch. Regards, Anthony Liguori > mynetworkcard.class="ne2000pci" > mynetworkcard.bus=1 # pci bus selection > mynetworkcard.macaddr=00:01:02:03:04:05 > mynetworkcard.vlan=1 > > I will strongly support configuration file formats having this property. > > Regards, > > Fabrice. > |
From: Paul B. <pa...@co...> - 2008-05-14 14:26:29
|
> I suggested it because my original plan for the configuration file was > based on this syntax with a strong inspiration from the OpenFirmware > device tree. The idea was that the object name ("drive" here) had no > hardcoded meaning, except for some predefined object names in order to > keep a kind of backward compatibility with the current QEMU options. In > order to create a new drive for example, you just have to do: > > mydrive.class=drive > mydrive.if=scsi > mydrive.file=abc.img > > the "class" field is used to select the device model. Then all the other > parameters are used to initialize the device model. That way it is > possible to keep the compatibility with the existing options and add a > provision to instanciate arbitrary new device models, such as: I like the idea, but I'm not so keen on the automatic allocation. I generally prefer explicit declaration over implicit things. The latter makes it very easy to not notice when you make a typo. It sounds like what you really want is something similar to an OF device tree. So you have something like: # pciide0 may be an alias (possibly provided by qemu) # e.g. pci0.slot1.func1.ide alias hda ide0.primary.master hda.type=disk hda.file=foo.img You can then define some form of magic aliases that select the next unused device. e.g. alias mydrive $next_ide_disk IMHO This provides the flexibility and structure that Fabrice is talking about, and with suitable aliases can be made to look a lot like the existing options. This may require some internal restructuring to allow the machine descriptions to feed into the user config file. Thoughts? Paul |
From: Fabrice B. <fa...@be...> - 2008-05-14 16:25:05
|
Paul Brook wrote: >> I suggested it because my original plan for the configuration file was >> based on this syntax with a strong inspiration from the OpenFirmware >> device tree. The idea was that the object name ("drive" here) had no >> hardcoded meaning, except for some predefined object names in order to >> keep a kind of backward compatibility with the current QEMU options. In >> order to create a new drive for example, you just have to do: >> >> mydrive.class=drive >> mydrive.if=scsi >> mydrive.file=abc.img >> >> the "class" field is used to select the device model. Then all the other >> parameters are used to initialize the device model. That way it is >> possible to keep the compatibility with the existing options and add a >> provision to instanciate arbitrary new device models, such as: > > I like the idea, but I'm not so keen on the automatic allocation. I generally > prefer explicit declaration over implicit things. The latter makes it very > easy to not notice when you make a typo. > > It sounds like what you really want is something similar to an OF device tree. > So you have something like: > > # pciide0 may be an alias (possibly provided by qemu) > # e.g. pci0.slot1.func1.ide > alias hda ide0.primary.master > > hda.type=disk > hda.file=foo.img > > You can then define some form of magic aliases that select the next unused > device. e.g. > > alias mydrive $next_ide_disk > > IMHO This provides the flexibility and structure that Fabrice is talking > about, and with suitable aliases can be made to look a lot like the existing > options. Right. It is my intent too to allow aliases to keep the same "familiar" names as the command line. Moreover the tree you suggest is necessary in order to derive the device instanciation order. In my idea, the tree has no relation with the actual device connections which are specified by explicit fields such as slots, functions, interface index, disk indexes or anything else. An interesting shortcut can be to automatically define a field "index" if the device name terminates with a number (if I remember correctly OpenFirmware does something like this). The initialization phase would consist in traversing the tree recursively and by instanciating a device for all nodes containing a "class" (or "type" if you prefer) field. The parents would be instanciated before the children to ensure a coherent initialization order. Regarding the syntax, quoted strings must be supported of course. I don't think there is a great complexity in that :-) A cpp like preprocessing can be added, but it can be done later. > This may require some internal restructuring to allow the machine descriptions > to feed into the user config file. Hopefully it is not necessary to fully implement the proposal now. But ultimately, each QEMU device would have to register its class name and an instanciation function. The machine descriptions would have to predefine some object names so that the user can modify parameters. Regards, Fabrice. |
From: andrzej z. <ba...@gm...> - 2008-05-14 14:36:44
|
On 14/05/2008, Anthony Liguori <an...@co...> wrote: > Anthony Liguori wrote: > > > I think this is pretty useful as-is. I think it also gives us a > reasonable > > way to move forward that will keep everyone pretty happy. > > > > Here's a short example: > > > > qemu-system-x86_64 -hda ~/images/linux.img -snapshot -vnc :2 > > > > Would become `foo.qemu': > > > > # Main disk image > > hda=/home/anthony/images/linux.img > > > > # Redirect disk writes to a temporary image > > snapshot > > > > # Make the graphical display available on port 5902 > > vnc=:2 > > > > With: > > > > qemu-system-x86_64 -config foo.qemu > > > > One thought I had, is that it would be very nice to break up the -drive > file=foo.img,if=scsi syntax within the config file. In general, I'm > thinking something like: > > [drive] > file=foo.img > if=scsi > > or: > > drive { > file=foo.img > if=scsi > } I like this one and it would be nice to be able to replace the equal sign with whitespace. What I'd love, though, but expect others will consider bloat, is that files are passed through cpp before interpreting. This way the syntax becomes not (much) less powerful than the current command line invocation where you get variable expansion for free. I would hate to type in some things in as many times as there are instances of a given hardware. Consider some disk arrays or the once discussed -pins switch for initial state of pins or jumpers (some machines have hundreds of them). -- Please do not print this email unless absolutely necessary. Spread environmental awareness. |
From: Johannes S. <Joh...@gm...> - 2008-05-14 15:10:40
|
Hi, On Wed, 14 May 2008, andrzej zaborowski wrote: > What I'd love, though, but expect others will consider bloat, is that > files are passed through cpp before interpreting. This will add a dependency to a developer's tool on an application that has not much to do with development for most users. Ciao, Dscho |
From: Ian J. <Ian...@eu...> - 2008-05-15 14:59:15
|
andrzej zaborowski writes ("Re: [Qemu-devel] Re: [PATCH] Add support for a configuration file"): > What I'd love, though, but expect others will consider bloat, is that > files are passed through cpp before interpreting. cpp is a terrible preprocessor. It mostly works for C source code (although it has some serious deficiences there - for example, that you can't have macros that generate macros). But for anything whose lexical structure is not much like C it causes terrible trouble - randomly inserting spaces, need for explicit token pasting (dependent on the C operator set), etc. It breaks even something as simple as #-comments, which are obviously what we would want in our plain text config file. If you really want a preprocessor, use m4 (one that supports -p and using a suitable m4_changequote). m4 isn't particularly pretty but it doesn't interfere with the core of the syntax. Better, make the configuration defaults sufficiently good that it is not necessary to reproduce lots of boilerplate to get things done. Then macros aren't needed for human-written files - and of course program-written config files can don't need a macro system anyway. Ian. |
From: Javier G. <ja...@gu...> - 2008-05-14 14:45:02
|
What about Lua? (http://www.lua.org) it started up as a configuration language, and evolved into a full programming language, while remaining _very_ light (less than 200K with all libraries), and wonderfully easy to embed into C programs. it lets you write things like: drives = { hda = {if='scsi', file='hda.img'}, hdb = {if='ide', file='hdb.img'}, } mem = 512*MB or, equivalently: drives={} drives.hda={} drives.hda.if='scsi' drives.hda.file='hda.img' drives.hdb={} drives.hdb.if='ide' drives.hdb.file='hdb.img' mem=512*MB or, if you want: drive {if='scsi', file='hda.img'} drive {if='ide', file='hdb.img'} mem(512*MB) or even: for img in lfs.dir("*.img") do drive{if='scsi', file=img} end -- Javier |
From: Daniel P. B. <ber...@re...> - 2008-05-14 15:25:39
|
On Wed, May 14, 2008 at 09:45:02AM -0500, Javier Guerra wrote: > What about Lua? (http://www.lua.org) > > it started up as a configuration language, and evolved into a full > programming language, while remaining _very_ light (less than 200K > with all libraries), and wonderfully easy to embed into C programs. Config files are data, not programs. Xen made this mistake originally too just having python config files that were eval'd, but thankfully they've defined a sensible data format now. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| |
From: Anthony L. <ali...@us...> - 2008-05-14 15:10:39
|
Paul Brook wrote: >> the "class" field is used to select the device model. Then all the other >> parameters are used to initialize the device model. That way it is >> possible to keep the compatibility with the existing options and add a >> provision to instanciate arbitrary new device models, such as: >> > > I like the idea, but I'm not so keen on the automatic allocation. I generally > prefer explicit declaration over implicit things. The latter makes it very > easy to not notice when you make a typo. > > It sounds like what you really want is something similar to an OF device tree. > So you have something like: > > # pciide0 may be an alias (possibly provided by qemu) > # e.g. pci0.slot1.func1.ide > alias hda ide0.primary.master > What I don't like about the ide0.primary.master syntax is that there isn't enough structure. I would prefer: alias hda ide,bus=0,primary,master If you combine this with your magic variable idea, you could also do: alias hda ide,bus=0,unit=$next But you could also just fold that into Fabrice's syntax (which I prefer): hda.class = ide,bus=0,unit=$next hda.type = disk hda.file = foo.img If you then default bus, and unit, you can just write: hda.class = ide hda.type = disk hda.file = foo.img And better yet, you could even allow for something like: hda.class = ide hda.bus = 0 hda.unit = 0 hda.type = disk hda.file = foo.img So I really actually prefer Fabrice's syntax because there is much more structure. I think it's a good idea to allow .class to contain multiple properties and to basically establish an alias. This way, you could predefine a bunch of aliases for today's parameters like hda, hdb, etc. > hda.type=disk > hda.file=foo.img > > You can then define some form of magic aliases that select the next unused > device. e.g. > > alias mydrive $next_ide_disk > > IMHO This provides the flexibility and structure that Fabrice is talking > about, and with suitable aliases can be made to look a lot like the existing > options. > > This may require some internal restructuring to allow the machine descriptions > to feed into the user config file. > I think if we choose a syntax we like, we can start using that pretty easily. We'll have to start adjusting option names keeping them only valid on the command line (for things like -m). However, I think it would grow pretty well into a machine description mechanism. Regards, Anthony Liguori > Thoughts? > > Paul > |
From: Paul B. <pa...@co...> - 2008-05-14 15:18:26
|
On Wednesday 14 May 2008, Anthony Liguori wrote: > Paul Brook wrote: > >> the "class" field is used to select the device model. Then all the other > >> parameters are used to initialize the device model. That way it is > >> possible to keep the compatibility with the existing options and add a > >> provision to instanciate arbitrary new device models, such as: > > > > I like the idea, but I'm not so keen on the automatic allocation. I > > generally prefer explicit declaration over implicit things. The latter > > makes it very easy to not notice when you make a typo. > > > > It sounds like what you really want is something similar to an OF device > > tree. So you have something like: > > > > # pciide0 may be an alias (possibly provided by qemu) > > # e.g. pci0.slot1.func1.ide > > alias hda ide0.primary.master > > What I don't like about the ide0.primary.master syntax is that there > isn't enough structure. I would prefer: > > alias hda ide,bus=0,primary,master > > If you combine this with your magic variable idea, you could also do: > > alias hda ide,bus=0,unit=$next > > But you could also just fold that into Fabrice's syntax (which I prefer): What I dislike about this is that it's a flat format, where you identify things by setting some combination of attributes. I really like the idea of having a tree structure. Paul |
From: Johannes S. <Joh...@gm...> - 2008-05-14 15:13:56
|
Hi, On Wed, 14 May 2008, Javier Guerra wrote: > What about Lua? (http://www.lua.org) > > it started up as a configuration language, and evolved into a full > programming language, while remaining _very_ light (less than 200K > with all libraries), and wonderfully easy to embed into C programs. Okay, so much for the upsides. Now for the downsides: a language that nearly nobody knows, for something that is not meant to be executed (think security implications). Hth, Dscho |
From: Javier G. <ja...@gu...> - 2008-05-14 15:30:51
|
On Wed, May 14, 2008 at 10:13 AM, Johannes Schindelin <Joh...@gm...> wrote: > On Wed, 14 May 2008, Javier Guerra wrote: > > What about Lua? (http://www.lua.org) > > > > it started up as a configuration language, and evolved into a full > > programming language, while remaining _very_ light (less than 200K > > with all libraries), and wonderfully easy to embed into C programs. > > Okay, so much for the upsides. Now for the downsides: a language that > nearly nobody knows, for something that is not meant to be executed (think > security implications). when embedded, you get to choose what libraries are available. there are several examples of fairly secure settings. personally, i find shell scripts enough for setting up parameters. a static config wouldn't bring much advantages. -- Javier |