When I read Avi's TODO, I basically thought about getting rid of the
long command lines I had to store in scripts. I wanted to write that
command line once, and then forgetting about it, until I needed to
change it.
Instead of inventing great and wonderfully complicated schemes, the
most sensibl
yet colinux >= 0.7.1 is using I believe a similar approach for passing its
parameters...
quoting the readme: "colinux-daemon @example.conf"
and this is what I use on a daily basis to compile detaolb on colinux
(which I test later using qemu).
On 8/14/07, Thiemo Seufer <[EMAIL PROTECTED]> wrote:
Jorge Lucángeli Obes wrote:
[snip]
> Quoting Thiemo, this '@' thing was "a feature which is now implemented
> in the GNU toolchain". That's why I tried it. Now I would like to know
> what he did to get it working. It would certainly be an useful
> feature, even if it does not exactly suit our purpo
On 8/14/07, Laurent Vivier <[EMAIL PROTECTED]> wrote:
> Markus Hitter wrote:
> >
> > Am 13.08.2007 um 11:19 schrieb Laurent Vivier:
> >
> >> We can modify qemu to test if the argument is a directory, if yes, it
> >> reads args
> >> from file args in this directory and for security the disk image mu
Markus Hitter wrote:
>
> Am 13.08.2007 um 11:19 schrieb Laurent Vivier:
>
>> We can modify qemu to test if the argument is a directory, if yes, it
>> reads args
>> from file args in this directory and for security the disk image must
>> be in the
>> same directory.
>>
>> for instance, we have:
>>
On 14 Aug 2007, at 00:31, Thiemo Seufer wrote:
Philip Boulain wrote:
On 13 Aug 2007, at 20:39, Thiemo Seufer wrote:
...implemented in the GNU toolchain, and apparently stems from
Windows:
qemu @qemu.cfg
I'm not familiar with that. Is it just GNU bash shorthand for
qemu `cat
qemu.cfg` ?
Am 13.08.2007 um 11:19 schrieb Laurent Vivier:
We can modify qemu to test if the argument is a directory, if yes,
it reads args
from file args in this directory and for security the disk image
must be in the
same directory.
for instance, we have:
./pc1/
./pc1/args
./pc1/my_disk
and in ./
Thiemo Seufer wrote:
> Jorge Lucángeli Obes wrote:
> [snip]
>> When I read Avi's TODO, I basically thought about getting rid of the
>> long command lines I had to store in scripts. I wanted to write that
>> command line once, and then forgetting about it, until I needed to
>> change it.
>
> Instea
Jorge Lucángeli Obes schrieb:
> qemu: could not open hard disk image '@config'
I think this was a suggestion for implementation, not a working feature.
> I did not know about '@config', and if I can get it to work, I like it
> better than a shell script. However, I think it does not completely
>
On 8/14/07, Anthony Liguori <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2007-08-13 at 20:39 +0100, Thiemo Seufer wrote:
> > Jorge Lucángeli Obes wrote:
> > [snip]
> > > When I read Avi's TODO, I basically thought about getting rid of the
> > > long command lines I had to store in scripts. I wanted to wr
On Mon, 2007-08-13 at 20:39 +0100, Thiemo Seufer wrote:
> Jorge Lucángeli Obes wrote:
> [snip]
> > When I read Avi's TODO, I basically thought about getting rid of the
> > long command lines I had to store in scripts. I wanted to write that
> > command line once, and then forgetting about it, unti
Philip Boulain wrote:
> On 13 Aug 2007, at 20:39, Thiemo Seufer wrote:
>> Instead of inventing great and wonderfully complicated schemes, the
>> most sensible way I can think of is to recycle a feature which is now
>> implemented in the GNU toolchain, and apparently stems from Windows:
>> qemu @q
On 13 Aug 2007, at 20:39, Thiemo Seufer wrote:
Instead of inventing great and wonderfully complicated schemes, the
most sensible way I can think of is to recycle a feature which is now
implemented in the GNU toolchain, and apparently stems from Windows:
qemu @qemu.cfg
I'm not familiar with th
On 8/13/07, Thiemo Seufer <[EMAIL PROTECTED]> wrote:
> Instead of inventing great and wonderfully complicated schemes, the
> most sensible way I can think of is to recycle a feature which is now
> implemented in the GNU toolchain, and apparently stems from Windows:
>
> qemu @qemu.cfg
>
> where qem
Jorge Lucángeli Obes wrote:
[snip]
> When I read Avi's TODO, I basically thought about getting rid of the
> long command lines I had to store in scripts. I wanted to write that
> command line once, and then forgetting about it, until I needed to
> change it.
Instead of inventing great and wonderfu
On 8/13/07, Laurent Vivier <[EMAIL PROTECTED]> wrote:
> I know we are not in democracy, but if I can vote I'd like to vote to the idea
> of Christian Brunschen...
>
> We can modify qemu to test if the argument is a directory, if yes, it reads
> args
> from file args in this directory and for secur
Avi Kivity wrote:
> Jorge Lucángeli Obes wrote:
My feeling is that config files are outdated. When used with a gui,
you end up writing silly parsers and stuff and still wrecking things
horribly when the the gui writer's expectations don't match reality.
When used without a gui,
Jorge Lucángeli Obes wrote:
My feeling is that config files are outdated. When used with a gui,
you end up writing silly parsers and stuff and still wrecking things
horribly when the the gui writer's expectations don't match reality.
When used without a gui, they increase the amount of details o
> > My feeling is that config files are outdated. When used with a gui,
> > you end up writing silly parsers and stuff and still wrecking things
> > horribly when the the gui writer's expectations don't match reality.
> > When used without a gui, they increase the amount of details one has
> > to
Avi Kivity wrote:
Anthony Liguori wrote:
Avi Kivity wrote:
This is a big effort but a config file is the right long term
solution.
For which use case? management-full or management-less?
Both. A config file will be useful not just for expressing the
functionality we have today,
Anthony Liguori wrote:
Avi Kivity wrote:
This is a big effort but a config file is the right long term solution.
For which use case? management-full or management-less?
Both. A config file will be useful not just for expressing the
functionality we have today, but also for describ
Avi Kivity wrote:
This is a big effort but a config file is the right long term solution.
For which use case? management-full or management-less?
Both. A config file will be useful not just for expressing the
functionality we have today, but also for describing the guest's
environ
22 matches
Mail list logo
