Allow default network type to be determined from an environmental variable

One typically wants to use the same networking type on a given system. For instance, if you have a bridge set up for taps, you'll generally pass -net tap to the guest. If you're an unprivileged user, you'll typically use -net user.

In the absence of a global configuration file, a reasonably sane way to support this configuration system wide is to use an environmental variable. QEMU already uses a number of global variables for configuring audio options.

This patch introduces a global variable (QEMU_NET_DEFAULT) which allows a user to set a system-wide default networking type. This saves a lot of typing for me as I no longer have to specify -net tap every time I launch QEMU.

Regards,

Anthony Liguori

Index: qemu/vl.c
===================================================================
@@ -8754,11 +8754,16 @@
 
     /* init network clients */
     if (nb_net_clients == 0) {
+	const char *net_type = getenv("QEMU_NET_DEFAULT");
+
+	if (net_type == NULL)
+	    net_type = "user";
+
         /* if no clients, we use a default config */
         pstrcpy(net_clients[0], sizeof(net_clients[0]),
                 "nic");
         pstrcpy(net_clients[1], sizeof(net_clients[0]),
-                "user");
+                net_type);
         nb_net_clients = 2;
     }
 

I'd really prefer we didn't do this, and preferably obsoleted/removed the existing environment variables. IMHO using environment variables is a really bad idea and should be avoided wherever possible.

Environment variables are about the worst user interface I can think of. For a start they're a global resource, which is limited on some systems. It's also extremely hard to determine what environment a user is running. This makes reproducing user bugs somewhere between hard and impossible.

Paul

Any suggestion on an alternative mechanism then? Can we introduce a config file and slowly introduce options into it?

Regards,

Anthony Liguori

In message: <[email protected]>
Paul Brook <[email protected]> writes:
: > In the absence of a global configuration file, a reasonably sane way to : > support this configuration system wide is to use an environmental : > variable. QEMU already uses a number of global variables for
: > configuring audio options.
:
: I'd really prefer we didn't do this, and preferably obsoleted/removed the : existing environment variables. IMHO using environment variables is a really : bad idea and should be avoided wherever possible.
:
: Environment variables are about the worst user interface I can think of. For a : start they're a global resource, which is limited on some systems. : It's also extremely hard to determine what environment a user is running. This : makes reproducing user bugs somewhere between hard and impossible.

Other than quick, developer friendly hacks, the only time environment variables make sense is to select globally something. A hypothetical QEMU_ROOT might be useful for selecting which tree of files qemu reads from. If you had multiple shells and wanted to run different installations of qmeu in each, this would be useful. But to have them control more fine grain options is something to be avoided. At least that's how I've selected them in my programs in the past....

Please note: I'm not saying this is the right way to select between multiple installed versions of qemu, just an example of when it makes sense.

Warner

On Windows, you mean?

They're a per-process resource on Linux. Inherited from the parent process, sure, but you inherit _copies_ of them, and changes you make to those copies don't propagate to parent processes. (A given process's environment variables aren't even necessarily passed on to its child processes. You supply the envionment variables to the syscall and wrappers like execle() let you specify. The "env" command exists to do this for you.)

Essentially the environment variables passed into a process are a second set of command line arguments (literally: argument 3 to main() is your list of environment variables, an array of pointers to "name=value" strings, with a null pointer terminating the array. Generally your setup code copies this pointer to _environ but you can grab it manually if you like.) There's no limit on the size here any more than there is on command line arguments. (Your _shell_ may limit command line arguments, but you can pipe stuff to xargs to get around that.)

Type "set" with no arguments. (I admit bash 3.x throws insane amounts of crap into this by default, but any program that's exposed to the FSF for an extended period of time bloats beyond recognition.)

The sane way to do this is prefix all the environment variables QEMU uses with QEMU_ so you can go

set | grep QEMU

And see just what you're interested in.

Would that make this approach more palatable?

Rob

"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

Windows is a particularly bad example, yes.

No.

Paul

I think Paul Brook was concerned about a situation where a user reports a problem saying X is not working when running "qemu -hda ..." and suddenly the number of things that may have triggered the bug has grown by the size of the environment. Even if you manage to tell the user to pastebin the environment, it may have changed by then. I'm pretty sure Paul knows how to list the env variables :)

I personally can accept not knowing what environment the user is running though. You'll never be able to reproduce 100% of user-reported bugs (and usually you won't even try), and any new way of configuring qemu that you introduce (say, config files) will have the same problem.

Please do not print this email unless absolutely necessary. Spread
environmental awareness.

Indeed. I see many, many users complain that qemu dies because of SDL errors. Almost without fail this is because they're running qemu in a different environment (e.g. under su as root), so are using an environment that can't connect to their X server.

Running "set | grep QEMU" is fine, except that it has to be done in the same environment as qemu runs in. You'd be surprised how many users are incapable of doing what seems to be a straightforward task.

This is similar to why I dislike qemu automagically guessing settings. If you force everything to be explicitly specified (or use fixed defaults) then there's no margin for error. If behaviour depends on external factors then you can guarantee the person stuck between you (the "expert") and the misbehaving application will have no clue how to determine or control those external factors.

Paul

Come on, if the concern is being able to determine the users environment, there are very well understood ways to handle this. Just have QEMU log all of the configuration parameters to some log file upon startup like so many other applications do.

If people don't like using environmental variables, I can accept that. Let's not pretend though that the reason is that we're protecting the end users :-)

Regards,

Anthony Liguori

It's more protecting me from end users :-)
I should have said part of the reason. I'll admit a large part is personal preference.

Paul