qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] initialize unit id of IDE bus


From: Alex Williamson
Subject: Re: [Qemu-devel] [PATCH] initialize unit id of IDE bus
Date: Tue, 26 Oct 2010 08:15:52 -0600

On Tue, 2010-10-26 at 13:20 +0200, Markus Armbruster wrote:
> >> How to tell whether it's primary or secondary?  Primary uses I/O ports
> >> 0x1f0..0x1ff,0x3f0..0x3ff and IRQ 14.  IRQ could be easier to check,
> >> because it should be right in ISADevice member isairq[0].
> >> Alternatively, upcast to ISAIDEState and check members iobase or isairq.
> > Again idebus_dev_path() should not care about what device IDEBus resides on.
> 
> We really need to define what qbus's get_dev_path() callback is supposed
> to do before we continue.  Alex, you created it.  What's your take on
> its semantics?

Perhaps going into too much detail, but the idea of get_dev_path() is
that it's a recursive call up the device try, where each level adds a
string to come up with a unique description.  We currently only have
this of PCI because it's device path is obvious, while others are not,
particularly ISA.

To start, I'd think IDE could easily implement a get_dev_path(), where
the IDE qbus calls up to it's parent bus, then appends IDE channel and
slot.  So for a PCI IDE controller, we get something like
PCI:0000:00:03.0/piix3-IDE0.master (change this to match qdev info
strings, I'm just making it up here).

An ISA IDE controller is harder since ISA doesn't have a bus enumeration
mechanism.  IIRC, there we some suggestions to use ioports and/or irqs
to define a path on ISA, but not all ISA qdev devices expose these.  So
perhaps we'd want something like isa.irq14/piix3-IDE0.master.  Doing ISA
correctly probably means standardizing some portion of the qdev info for
all the ISA devices.  Thanks,

Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]