Re: [Qemu-devel] [PATCH 00/16] clean up vl.c code

[Markus Armbruster]

Jes Sorensen <address@hidden> writes:

> On 06/04/10 13:54, Markus Armbruster wrote:
>> Jes Sorensen <address@hidden> writes:
>> 
>>> On 06/04/10 10:21, Markus Armbruster wrote:
>>>> I like moving stuff out of vl.c in general.  Your moves of entire
>>>> functions look like a win to me.  I have doubts about spreading the
>>>> option switch over three files, though.
>>>
>>> The problem is right now there are too many OS specific options, but
>>> having the #ifdefs plastered all over to enable/disable them accordingly
>>> is just a nightmare and is prone to leave in inconsistent behavior for
>>> various OSes. See the set_proc_name() stuff for an example.
>> 
>> I doubt spreading option code over separate files will help consistency.
>> 
>> I suspect the true root of the problem is having (too many) OS-specific
>> options in the first place.  What about parsing options the same
>> everywhere, calling out to OS-specific functions to do the actual work?
>> Let them fail with "can't do this on this OS".
>
> That is a possibility which I did consider, but it would end up in far
> more os specific functions for simple assignments etc.

Far more?

option                  condition       what's needed to make it uncond.
QEMU_OPTION_smb         !_WIN32         net_slirp_smb() dummy.
QEMU_OPTION_fsdev       CONFIG_LINUX    fsdev_init_func() dummy
QEMU_OPTION_virtfs      CONFIG_LINUX    nothing, it's just short for
                                        -fsdev & -device
QEMU_OPTION_daemonize   !_WIN32         move the big #ifndef _WIN32
                                        chunk at the end of main()
                                        into a helper, + dummy
QEMU_OPTION_chroot      !_WIN32         ditto
QEMU_OPTION_runas       !_WIN32         ditto

>                                                        I modeled it the
> way I did similar to how we handle ioctl calls in the kernel.
>
> If there is strong feeling we should do it this way instead, I can
> change the code to do it this way instead. I am not married to the
> current approach, I just find it the lesser evil.

I'm making suggestions, not demands.  If you still prefer your way after
considering my suggestions, go with it.

For what it's worth, pushing OS-dependent bits out of the option parsing
allows for:

    qemu: --frobnicate: Can't frobnicate under Windows

instead of

    qemu: --frobnicate: invalid option