On Tue, 2010-10-26 at 16:26 +0200, Gleb Natapov wrote: > On Tue, Oct 26, 2010 at 08:15:52AM -0600, Alex Williamson wrote: > > 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). > > > If we will do it like you suggest device path will be meaningless > outside of qemu internals. I would like get_dev_path() to build device > path that can be used in a guest to locate the device. In your example > above piix3-IDE0 does not provide any additional information anyway > since PCI:0000:00:03.0 already point at a device that can be easily > identified as piix3-ede0 by looking into PCI config space. > So for IDE I would like it to be like that: > p...@0000:00:03.0/i...@0:1
Yep, I agree, just overly verbose in my example I guess. > > 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, > Have you looked at my isabus_get_dev_path() patch? It keeps track of > ioports used by ISA device at ISADevice level. No I hadn't, great! It won't be an easy path to parse, but that's probably more a factor of ISA bus architecture than your decision to use ioports. Thanks, Alex
