[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [Qemu-devel] [PATCH] Do not emulate a floppy drive when -nodefaults



John Snow <jsnow@xxxxxxxxxx> writes:

> On 05/14/2015 10:07 AM, Michael S. Tsirkin wrote:
>> On Thu, May 14, 2015 at 02:02:04PM +0200, Markus Armbruster wrote:
>>> Correct.
>>>
>>> Here's how I think it should be done:
>>>
>>> * Create a machine option to control the FDC
>>>
>>>   This is a machine-specific option.  It should only exist for machine
>>>   types that have an optional FDC.
>>>
>>>   Default must be "on" for old machine types.  Default may be "off" for
>>>   new machine types.
>>>
>>>   It should certainly be off for pc-q35-2.4 and newer.  Real Q35 boards
>>>   commonly don't have an FDC (depends on the Super I/O chip used).
>>>
>>>   We may want to keep it off for pc-i440fx-2.4 and newer.  I doubt
>>>   there's a real i440FX without an FDC, but our virtual i440FX is quite
>>>   unlike a real one in other ways already.
>> 
>> I think making it off by default is a bad idea, it will break
>> command-line users.
>> 
>> 
>
> If we can add a flag to disable it, I still think I wouldn't mind that,
> if it could be worked out to not be hacky and gross.
>
>>> * Create the FDC only if the option is "on".
>>>
>>> * Optional: make -drive if=floppy,... auto-enable it
>> 
>> Every time we do such auto hacks, we regret this later.
>> Just do what we are told, fail if=floppy if disabled.
>> 
>
> I agree very much. Just because the current drive/device syntax is
> almost totally hosed doesn't mean we should put more wood on the fire.
>
>>>   I wouldn't bother doing the same for -global isa-fdc.driveA=... and
>>>   such.
>>>
>>> Stefano, if you're willing to tackle this, go right ahead!
>
>
> I'm definitely against a "--seriously-nothing" flag because the line for
> what is embedded or not is fuzzy. Paolo raises some good points against
> where you draw the line for what we decide to allow users to
> include/exclude that is otherwise considered part of the board.

--nodefaults must continue to disable all optional parts of the board.

What exactly is optional is for the board / machine type to define.  It
can't be changed once the machine type is released.

When in doubt, make it optional.  Especially when the device has
user-configurable properties, because optional devices are much nicer to
configure than onboard devices.  For an onboard device, you have to mess
with -global, e.g.

    -global isa-fdc.driveA=fda

Since -global applies to *all* devices of a kind, this has unwanted side
effects when you have more than one.  For instance:

    $ qemu-system-x86 -nodefaults -S -display none -drive if=none,id=fda 
-global isa-fdc.driveA=fda -device isa-fdc,iobase=370
    qemu-system-x86: -device isa-fdc,iobase=370: Warning: global 
isa-fdc.driveA=fda ignored (Property 'isa-fdc.driveA' can't take value 'fda', 
it's in use)

If it was optional, you'd do a perfectly regular

    -device isa-fdc,id=fdc0,driveA=floppyA

which doesn't mess up any subsequent -device isa-fdc.

Since Q35 is just starting to become migratable, the time to painlessly
change its optional parts is *now*.

For i440FX, we'll have to sacrifice some to the compatibility idols.

> Still, given the hype train, if there is an API we could introduce that
> is likely not to make our code gross (or make us belly-ache about how
> dumb we were in 5 years) that disables the FDC, I don't think I would
> mind terribly. I'll leave that to minds more opinionated than mine to
> hash out, though.
>
> Maybe the best option here really is to carefully separate optional from
> non-optional components (FDC vs. Floppy Drive, Floppy Disk code) and
> just give the core FDC code a good scrubbing.

In my not particularly humble opinion, time spent on FDC code is time
stolen from more useful matters.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.