Menu
▾
▴
kvm-devel
|
From: Johannes S. <Joh...@gm...> - 2008-05-14 15:37:14
|
Hi, On Wed, 14 May 2008, Javier Guerra wrote: > 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. Why artificially make it complicated, and then have to take care of such issues? That's like an ex-colleague of mine, who absolutely had to rewrite the database engine in-RAM, and when the application was too slow over modem (leeching in megabytes, where it got bytes from the SQL database before), he tried to force Windows Terminal Services, instead of reverting his change. Simplicity is underrated. Ciao, Dscho |
|
From: Javier G. <ja...@gu...> - 2008-05-14 15:42:46
|
On Wed, May 14, 2008 at 10:37 AM, Johannes Schindelin <Joh...@gm...> wrote: > On Wed, 14 May 2008, Javier Guerra wrote: > > when embedded, you get to choose what libraries are available. there > > are several examples of fairly secure settings. > > Why artificially make it complicated, and then have to take care of such > issues? i should have said "Lua is secure by default, all libraries are optional", but it's quickly turning into a bikeshed (http://www.bikeshed.com) my own personal preference would be to just stuff the whole command line parameters into the qcow2 image file. -- Javier |
|
From: Kelly F. <kf...@fe...> - 2008-05-14 16:12:21
|
On Wed, 14 May 2008, Johannes Schindelin wrote: > Hi, > > On Wed, 14 May 2008, Javier Guerra wrote: > >> 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. > > Why artificially make it complicated, and then have to take care of such > issues? > > That's like an ex-colleague of mine, who absolutely had to rewrite the > database engine in-RAM, and when the application was too slow over modem > (leeching in megabytes, where it got bytes from the SQL database before), > he tried to force Windows Terminal Services, instead of reverting his > change. > > Simplicity is underrated. > > Ciao, > Dscho Why not just bypass the whole config file idea and just use enviornment variables? No more parsing or dependencies on the language of the day. Yes, you wouldn't have the tree format that some people are asking for. You'd get all of the power of your favorite shell, plus maybe some benefits when migrating a VM to another machine. -kf #!/bin/sh 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 exec qemu |
|
From: Paul B. <pa...@co...> - 2008-05-15 14:59:55
|
> Why not just bypass the whole config file idea and just use enviornment > variables? Absolutely not. Environment variables are a horrid way of configuring things. Paul |
|
From: Avi K. <av...@qu...> - 2008-05-15 08:04:49
|
Daniel P. Berrange wrote: > 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. > I would hope that tools don't have to resort to reading and writing these config files. Usually a management system would prefer storing parameters in its own database, and writing a temporary config file just to pass the data seems awkward. I would much prefer to see the command line and monitor retain full control over every configurable parameter. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. |
|
From: Daniel P. B. <ber...@re...> - 2008-05-15 11:55:40
|
On Thu, May 15, 2008 at 11:04:47AM +0300, Avi Kivity wrote: > Daniel P. Berrange wrote: > >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. > > > > I would hope that tools don't have to resort to reading and writing > these config files. Usually a management system would prefer storing > parameters in its own database, and writing a temporary config file just > to pass the data seems awkward. I would much prefer to see the command > line and monitor retain full control over every configurable parameter. I expect that libvirt will create config files - it is only a matter of time before we hit the command line ARGV length limits - particularly with the -net and -drive syntax. People already requesting that we support guests with > 16 disks, and > 8 network cards so command lines get very long. I wouldn't write out the config file to disk though - I'd just send it on the fly on stdin -, eg 'qemu -config -' to tell it to read the config on its stdin. Regards, Daniel. -- |: 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-15 12:04:28
|
Daniel P. Berrange wrote: > On Thu, May 15, 2008 at 11:04:47AM +0300, Avi Kivity wrote: > >> Daniel P. Berrange wrote: >> >>> 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. >>> >>> >> I would hope that tools don't have to resort to reading and writing >> these config files. Usually a management system would prefer storing >> parameters in its own database, and writing a temporary config file just >> to pass the data seems awkward. I would much prefer to see the command >> line and monitor retain full control over every configurable parameter. >> > > I expect that libvirt will create config files - it is only a matter of > time before we hit the command line ARGV length limits - particularly > with the -net and -drive syntax. People already requesting that we support > guests with > 16 disks, and > 8 network cards so command lines get very > long. > What are those limits, btw? ISTR 10240 words, but how many chars? > I wouldn't write out the config file to disk though - I'd just send it > on the fly on stdin -, eg 'qemu -config -' to tell it to read the config > on its stdin. > That's fine from my point of view. -- error compiling committee.c: too many arguments to function |
|
From: Laurent V. <Lau...@bu...> - 2008-05-15 12:20:49
|
Le jeudi 15 mai 2008 à 15:04 +0300, Avi Kivity a écrit :
> Daniel P. Berrange wrote:
> > On Thu, May 15, 2008 at 11:04:47AM +0300, Avi Kivity wrote:
> >
> >> Daniel P. Berrange wrote:
> >>
> >>> 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.
> >>>
> >>>
> >> I would hope that tools don't have to resort to reading and writing
> >> these config files. Usually a management system would prefer storing
> >> parameters in its own database, and writing a temporary config file just
> >> to pass the data seems awkward. I would much prefer to see the command
> >> line and monitor retain full control over every configurable parameter.
> >>
> >
> > I expect that libvirt will create config files - it is only a matter of
> > time before we hit the command line ARGV length limits - particularly
> > with the -net and -drive syntax. People already requesting that we support
> > guests with > 16 disks, and > 8 network cards so command lines get very
> > long.
> >
>
> What are those limits, btw? ISTR 10240 words, but how many chars?
ARG_MAX - _SC_ARG_MAX
The maximum length of the arguments to the exec(3) family of
functions. Must not be less than _POSIX_ARG_MAX (4096).
getconf ARG_MAX
131072
And from a configure log I have:
checking the maximum length of command line arguments: 98304
Regards,
Laurent
--
------------- Lau...@bu... ---------------
"The best way to predict the future is to invent it."
- Alan Kay
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X