Re: [libvirt] [PATCH 0/13] [RFC] Network filtering (ACL) extensions for libvirt
"Daniel P. Berrange" <berrange(a)redhat.com> wrote on 03/17/2010 11:00:26
AM:
Please respond to "Daniel P. Berrange"
On Wed, Mar 17, 2010 at 10:53:37AM -0400, Stefan Berger wrote:
> "Daniel P. Berrange" <berrange(a)redhat.com> wrote on 03/17/2010
10:40:36
> AM:
>
>
>
> I hadn't thought about calling that function... I would want to call a
> function that can handle something like bash scripts, i.e.,
multiple
> concatenated fragments as those shown above just to be more
'efficient'.
Is it really more efficient ? If you need to run 20 ebtables commands,
then using bash does 1 fork/exec for bash & bash then does another 20
fork/exec for ebtables.
Alternatively just use virRun() for each ebtables command you just still
have 20 fork/execs, without using bash.
> If virRun() can handle that and $? for example would be treated there
as
> the return value (which I think is bash-dependent), I'd be
happy to
call
> it as well.
I'd think just call virRun once for each ebtables command - virRun gives
you back the exit status of the command
Alright. Would it be ok to still gather the ebtables commands as I do now
and afterwards process them in a loop that searches for a '\n' between the
commands and, depending on whether a STOPONERROR token would be found
following a command, would terminate the loop on error and return the
error code. For some commands that are being executed I may actually
tolerate error codes in case for example a user-define ebtables table is
cleared that doesn't exist, but to get the system into an expected clean
state, it's cleared anyways. In that case no or a different token would be
found.
Regards,
Stefan
Regards,
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/:|
|: http://libvirt.org -o- http://virt-manager.org -o-
http://deltacloud.org:|
|: http://autobuild.org -o-
http://search.cpan.org/~danberr/:|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742
7D3B
9505 :|
Attachments:
- attachment.html (text/html — 3.2 KB)