LinuxLists.cc - [PATCH] PCI: remove pcibios_scan_all

[permalink] [raw]

Subject: Re: [PATCH] PCI: remove pcibios_scan_all_fns()

On Mon, Jun 22, 2009 at 08:08:07AM -0600, Alex Chiang wrote:
> This was #define'd as 0 on all platforms, so let's get rid of it.
>
> This change makes pci_scan_slot() slightly easier to read.

> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index f1ae247..b613cad 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1056,8 +1056,7 @@ int pci_scan_slot(struct pci_bus *bus, int devfn)
> if (dev && !dev->is_added) /* new device? */
> nr++;
>
> - if ((dev && dev->multifunction) ||
> - (!dev && pcibios_scan_all_fns(bus, devfn))) {
> + if (dev && dev->multifunction) {
> for (fn = 1; fn < 8; fn++) {
> dev = pci_scan_single_device(bus, devfn + fn);
> if (dev) {

What a good idea. I was just looking at making this more complicated
(due to the ARI capability).

I'd like to know what the KVM / Xen / ... people think about this.
I don't know if they rely on function 5 being able to show up out of
the blue.

Anyway,
Reviewed-by: Matthew Wilcox <[email protected]>

--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."

2009-06-22 14:36:23

[permalink] [raw]

Subject: Re: [PATCH] PCI: remove pcibios_scan_all_fns()

On Mon, Jun 22, 2009 at 03:26:02PM +0100, Ralf Baechle wrote:
> On Mon, Jun 22, 2009 at 08:08:07AM -0600, Alex Chiang wrote:
> > This was #define'd as 0 on all platforms, so let's get rid of it.
> >
> > This change makes pci_scan_slot() slightly easier to read.
>
> I don't see why one would want to have a non-zero pcibios_scan_all_fns()
> anyway.

If you have real hardware, absolutely. If you have a hypervisor that
gives you function 5 of a device (instead of mapping your function 0 to
function 5 of the real device), you'll want something along these lines.

--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."

2009-06-22 15:31:18

by Russell King - ARM Linux

[permalink] [raw]

Subject: Re: [PATCH] PCI: remove pcibios_scan_all_fns()

On Mon, Jun 22, 2009 at 08:08:07AM -0600, Alex Chiang wrote:
> This was #define'd as 0 on all platforms, so let's get rid of it.
>
> This change makes pci_scan_slot() slightly easier to read.
>
> Cc: Ivan Kokshaysky <[email protected]>
> Cc: Russell King <[email protected]>

Acked-by: Russell King <[email protected]>

For:

> diff --git a/arch/arm/include/asm/pci.h b/arch/arm/include/asm/pci.h
> index 0abf386..226cddd 100644
> --- a/arch/arm/include/asm/pci.h
> +++ b/arch/arm/include/asm/pci.h
> @@ -6,8 +6,6 @@
>
> #include <mach/hardware.h> /* for PCIBIOS_MIN_* */
>
> -#define pcibios_scan_all_fns(a, b) 0
> -
> #ifdef CONFIG_PCI_HOST_ITE8152
> /* ITE bridge requires setting latency timer to avoid early bus access
> termination by PIC bus mater devices

Thanks.

2009-06-22 16:54:56

by Arnd Bergmann

[permalink] [raw]

Subject: Re: [PATCH] PCI: remove pcibios_scan_all_fns()

On Monday 22 June 2009, Alex Chiang wrote:
> --- a/include/asm-generic/pci.h
> +++ b/include/asm-generic/pci.h
> @@ -30,8 +30,6 @@ pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
> res->end = region->end;
> }
>
> -#define pcibios_scan_all_fns(a, b) 0
> -
> #ifndef HAVE_ARCH_PCI_GET_LEGACY_IDE_IRQ
> static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
> {
>

Acked-by: Arnd Bergmann <[email protected]>

2009-06-22 18:20:36

[permalink] [raw]

Subject: Re: [PATCH] PCI: remove pcibios_scan_all_fns()

On 06/22/09 07:34, Matthew Wilcox wrote:
> On Mon, Jun 22, 2009 at 08:08:07AM -0600, Alex Chiang wrote:
>
>> This was #define'd as 0 on all platforms, so let's get rid of it.
>>
>> This change makes pci_scan_slot() slightly easier to read.
>>
>
>
>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> index f1ae247..b613cad 100644
>> --- a/drivers/pci/probe.c
>> +++ b/drivers/pci/probe.c
>> @@ -1056,8 +1056,7 @@ int pci_scan_slot(struct pci_bus *bus, int devfn)
>> if (dev && !dev->is_added) /* new device? */
>> nr++;
>>
>> - if ((dev && dev->multifunction) ||
>> - (!dev && pcibios_scan_all_fns(bus, devfn))) {
>> + if (dev && dev->multifunction) {
>> for (fn = 1; fn < 8; fn++) {
>> dev = pci_scan_single_device(bus, devfn + fn);
>> if (dev) {
>>
>
> What a good idea. I was just looking at making this more complicated
> (due to the ARI capability).
>
> I'd like to know what the KVM / Xen / ... people think about this.
> I don't know if they rely on function 5 being able to show up out of
> the blue.
>

We want to be able to export specific functions to a particular domain,
so it might see a PCI device with only function 5.

It looks like we lose that ability with this patch, is that right?

J

2009-06-22 18:31:10

[permalink] [raw]

Subject: Re: [PATCH] PCI: remove pcibios_scan_all_fns()

On Mon, Jun 22, 2009 at 11:20:24AM -0700, Jeremy Fitzhardinge wrote:
> > I'd like to know what the KVM / Xen / ... people think about this.
> > I don't know if they rely on function 5 being able to show up out of
> > the blue.
>
> We want to be able to export specific functions to a particular domain,
> so it might see a PCI device with only function 5.
>
> It looks like we lose that ability with this patch, is that right?

That would be correct. I'm guessing your out-of-tree code sets
pcibios_scan_all_fns()?

Now, there are various options. One is that you could remap config
space accesses -- domain:bus:dev.fn in the guest don't have to match
domain:bus:dev.fn in the host. That's a certain amount of overhead in
every config space access, but it doesn't have to be a large one.

Another would be that you could create dummy devices in the guest at
function 0, and then the guest would scan all the functions. A little
ugly, perhaps.

A third would be for guests to not do this scanning at all. You could
present the devices through something like the openfirmware tree, and
create them insteaqd of scanning for them. If you care about startup
time, this is probably the way to go.

There's probably other ways I haven't thought of ...

--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."

2009-06-22 23:42:26

[permalink] [raw]

Subject: Re: [PATCH] PCI: remove pcibios_scan_all_fns()

On Mon, 2009-06-22 at 12:30 -0600, Matthew Wilcox wrote:
>
> That would be correct. I'm guessing your out-of-tree code sets
> pcibios_scan_all_fns()?
>
> Now, there are various options. One is that you could remap config
> space accesses -- domain:bus:dev.fn in the guest don't have to match
> domain:bus:dev.fn in the host. That's a certain amount of overhead in
> every config space access, but it doesn't have to be a large one.
>
That's tricky. Some devices have internal registers that -do- depend on
what function they are on. In fact, I remember seeing that in
multifunction devices that are meant to be virtualized but still need to
have some registers be accessed differently depending on the function
(ugh) though don't ask me who that was ...

> Another would be that you could create dummy devices in the guest at
> function 0, and then the guest would scan all the functions. A little
> ugly, perhaps.

But less ugly than the above.

> A third would be for guests to not do this scanning at all. You could
> present the devices through something like the openfirmware tree, and
> create them insteaqd of scanning for them. If you care about startup
> time, this is probably the way to go.

Which is what we do on powerpc nowadays. In fact, this code is currently
inside arch/powerpc and arch/sparc (2 copies slightly diverged) but I
had plans to make it common at move it over to either drivers/of or
drivers/pci (most probably the later).

> There's probably other ways I haven't thought of ...

Well, making up the devices without actual config space probing is nice
and fast but I don't think we want to see too many occurences of such
code in the kernel. We already had breakage once in powerpc land iirc
due to changes in drivers/pci/probe.c that we didn't reflect properly. I
think the normal and OF methods should be enough.

At this stage, it does look to me like a trivial tweak like
pcibios_scan_all_fns() but maybe done a bit nicely, would still be the
simplest solution in term of amount of code involved etc...

Maybe something like

pcibios_get_slot_fn_mask() which returns a bitmask of functions to be
scanned, whose default implementation (weak) would basically check
the header type for function 0 ? As I said, I don't -need- that right
now on powerpc "server" platforms but heh...

Cheers,
Ben.

2009-06-22 23:55:52

[permalink] [raw]

Subject: Re: [PATCH] PCI: remove pcibios_scan_all_fns()

On 06/22/09 11:30, Matthew Wilcox wrote:
> On Mon, Jun 22, 2009 at 11:20:24AM -0700, Jeremy Fitzhardinge wrote:
>
>>> I'd like to know what the KVM / Xen / ... people think about this.
>>> I don't know if they rely on function 5 being able to show up out of
>>> the blue.
>>>
>> We want to be able to export specific functions to a particular domain,
>> so it might see a PCI device with only function 5.
>>
>> It looks like we lose that ability with this patch, is that right?
>>
>
> That would be correct. I'm guessing your out-of-tree code sets
> pcibios_scan_all_fns()?
>

Yes.

> Now, there are various options. One is that you could remap config
> space accesses -- domain:bus:dev.fn in the guest don't have to match
> domain:bus:dev.fn in the host. That's a certain amount of overhead in
> every config space access, but it doesn't have to be a large one.
>

I think the problem with that is that certain devices have fixed
functions at fixed function numbers, so the drivers just expect the
function to be there and nowhere else (AFAIK there's no way to do
discovery on functions). Now perhaps you'd never export just some
functions to such devices, but that was the answer when I proposed doing
this.

And if we did want to do this, would it be acceptible to put config
space remapping in? I presume that's something that would have to be in
the generic pci library?

> Another would be that you could create dummy devices in the guest at
> function 0, and then the guest would scan all the functions. A little
> ugly, perhaps.
>

I wonder if that would upset drivers. Assuming they can cope with just
being given some functions, how could one generically make a function
look present-but-dummy enough to not upset the driver?

> A third would be for guests to not do this scanning at all. You could
> present the devices through something like the openfirmware tree, and
> create them insteaqd of scanning for them. If you care about startup
> time, this is probably the way to go.
>

I don't think startup time is an overriding concern.

J

2009-06-23 01:29:56

[permalink] [raw]

Subject: Re: [PATCH] PCI: remove pcibios_scan_all_fns()

On Mon, 2009-06-22 at 16:55 -0700, Jeremy Fitzhardinge wrote:
>
> I wonder if that would upset drivers. Assuming they can cope with just
> being given some functions, how could one generically make a function
> look present-but-dummy enough to not upset the driver?

Well, the dummy function would have a totally different vid/did, I think
that would work. In general, while I've seen drivers that -do- need to
know their real function number to get to the right registers, I haven't
seen much that also need to see function 0 "right" (or if they do, then
function 0 just needs to be plugged in the same partition and the whole
problem is somewhat moot).

Cheers,
Ben.

2009-06-23 01:49:21

by Chris Wright

[permalink] [raw]

Subject: Re: [PATCH] PCI: remove pcibios_scan_all_fns()

* Matthew Wilcox ([email protected]) wrote:
> I'd like to know what the KVM / Xen / ... people think about this.
> I don't know if they rely on function 5 being able to show up out of
> the blue.

KVM does not rely on this. Typically a multi-function device's BDF gets
remapped between host and guest (usually becoming a single function,
function 0).

thanks,
-chris

2009-06-23 02:23:45

[permalink] [raw]

Subject: Re: [PATCH] PCI: remove pcibios_scan_all_fns()

On Mon, 2009-06-22 at 18:43 -0700, Chris Wright wrote:
> > I'd like to know what the KVM / Xen / ... people think about this.
> > I don't know if they rely on function 5 being able to show up out of
> > the blue.
>
> KVM does not rely on this. Typically a multi-function device's BDF
> gets
> remapped between host and guest (usually becoming a single function,
> function 0).

I'm surprised you don't hit problems with some devices/drivers here,
I have distinct memories of seeing such things as drivers who need
to know their own function number reliably.

Cheers,
Ben.

2009-06-23 16:44:32

by Paul Mundt

[permalink] [raw]

Subject: Re: [PATCH] PCI: remove pcibios_scan_all_fns()

On Mon, Jun 22, 2009 at 08:08:07AM -0600, Alex Chiang wrote:
> This was #define'd as 0 on all platforms, so let's get rid of it.
>
> This change makes pci_scan_slot() slightly easier to read.
>
> Cc: Ivan Kokshaysky <[email protected]>
> Cc: Russell King <[email protected]>
> Cc: Yoshinori Sato <[email protected]>
> Cc: Tony Luck <[email protected]>
> Cc: Ralf Baechle <[email protected]>
> Cc: David Howells <[email protected]>
> Cc: Kyle McMartin <[email protected]>
> Cc: Benjamin Herrenschmidt <[email protected]>
> Cc: Paul Mundt <[email protected]>
> Cc: "David S. Miller" <[email protected]>
> Cc: Jeff Dike <[email protected]>
> Cc: Ingo Molnar <[email protected]>
> Cc: Arnd Bergmann <[email protected]>
> Signed-off-by: Alex Chiang <[email protected]>

Acked-by: Paul Mundt <[email protected]>

2009-06-23 18:31:30

by Avi Kivity

[permalink] [raw]

Subject: Re: [PATCH] PCI: remove pcibios_scan_all_fns()

On 06/22/2009 05:34 PM, Matthew Wilcox wrote:
>
>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> index f1ae247..b613cad 100644
>> --- a/drivers/pci/probe.c
>> +++ b/drivers/pci/probe.c
>> @@ -1056,8 +1056,7 @@ int pci_scan_slot(struct pci_bus *bus, int devfn)
>> if (dev&& !dev->is_added) /* new device? */
>> nr++;
>>
>> - if ((dev&& dev->multifunction) ||
>> - (!dev&& pcibios_scan_all_fns(bus, devfn))) {
>> + if (dev&& dev->multifunction) {
>> for (fn = 1; fn< 8; fn++) {
>> dev = pci_scan_single_device(bus, devfn + fn);
>> if (dev) {
>>
>
> What a good idea. I was just looking at making this more complicated
> (due to the ARI capability).
>
> I'd like to know what the KVM / Xen / ... people think about this.
> I don't know if they rely on function 5 being able to show up out of
> the blue.
>
>

You mean have a function 5 without a function 0? This doesn't impact
kvm at all.

Moreover, I see pcibios_scan_all_fns() uniformly defined as 0, so this
patch doesn't change much, does it?

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

2009-06-23 19:08:36

[permalink] [raw]

Subject: Re: [PATCH] PCI: remove pcibios_scan_all_fns()

On Tue, Jun 23, 2009 at 09:40:08AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2009-06-22 at 12:30 -0600, Matthew Wilcox wrote:
> >
> > That would be correct. I'm guessing your out-of-tree code sets
> > pcibios_scan_all_fns()?
> >
> > Now, there are various options. One is that you could remap config
> > space accesses -- domain:bus:dev.fn in the guest don't have to match
> > domain:bus:dev.fn in the host. That's a certain amount of overhead in
> > every config space access, but it doesn't have to be a large one.
> >
> That's tricky. Some devices have internal registers that -do- depend on
> what function they are on. In fact, I remember seeing that in
> multifunction devices that are meant to be virtualized but still need to
> have some registers be accessed differently depending on the function
> (ugh) though don't ask me who that was ...

That's pretty horrific. PA-RISC has a NS87415 superio chip that is
full of that kind of bogosity, but nobody's ever suggested it should
support v12n.

> > Another would be that you could create dummy devices in the guest at
> > function 0, and then the guest would scan all the functions. A little
> > ugly, perhaps.
>
> But less ugly than the above.

There's some nastiness when you want to later migrate function 0 into
the VM, and it looks a little ugly to have a fake func 0 in the VM with
nothing attached to it.

> > A third would be for guests to not do this scanning at all. You could
> > present the devices through something like the openfirmware tree, and
> > create them insteaqd of scanning for them. If you care about startup
> > time, this is probably the way to go.
>
> Which is what we do on powerpc nowadays. In fact, this code is currently
> inside arch/powerpc and arch/sparc (2 copies slightly diverged) but I
> had plans to make it common at move it over to either drivers/of or
> drivers/pci (most probably the later).

I'd support a drivers/pci/of.c. Definitely better than having two copies
of it under arch/, and you'd be well within your rights to complain if
we changed something and didn't fix it up.

> > There's probably other ways I haven't thought of ...
>
> Well, making up the devices without actual config space probing is nice
> and fast but I don't think we want to see too many occurences of such
> code in the kernel. We already had breakage once in powerpc land iirc
> due to changes in drivers/pci/probe.c that we didn't reflect properly. I
> think the normal and OF methods should be enough.

Particularly since we have these people creating fake OF trees for
embedded platforms so we don't have to probe them. The v12n people
should definitely take advantage of this work.

> At this stage, it does look to me like a trivial tweak like
> pcibios_scan_all_fns() but maybe done a bit nicely, would still be the
> simplest solution in term of amount of code involved etc...
>
> Maybe something like
>
> pcibios_get_slot_fn_mask() which returns a bitmask of functions to be
> scanned, whose default implementation (weak) would basically check
> the header type for function 0 ? As I said, I don't -need- that right
> now on powerpc "server" platforms but heh...

So we need to tweak this code anyway for Alternate RoutingID Interpretation,
and what I've ended up doing is creating a bunch of different functions that
can be called to determine what the next function to probe should be, given
the current device and function.

Take a look: http://marc.info/?l=linux-pci&m=124578246906927&w=2

It wouldn't be hard to continue supporting pcibios_scan_all_fns() with
this scheme; it's an extra two lines:

+ else if (pcibios_scan_all_fns())
+ next_fn = next_trad_fn;

I think simply materialising them, either the way the OF code does,
or the way the IOV code does is the best route forwards.

--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."

2009-06-23 20:34:55

[permalink] [raw]

Subject: Re: [PATCH] PCI: remove pcibios_scan_all_fns()

On 06/23/09 12:08, Matthew Wilcox wrote:
> I think simply materialising them, either the way the OF code does,
> or the way the IOV code does is the best route forwards.
>

On reflection, I think this will work. We have a Xen pci passthrough
driver which gets told about the passed-through devices via xenbus, and
does the appropriate setup. At first glance, there doesn't seem to be
any problem with that code just explicitly instantiate the devices at
the PCI level in the same way pci_scan_device does (ie,
alloc_pci_device, initalize the dev struct, pci_setup_device).

Is that what you mean?

IanC has looked at that code more closely, so perhaps he can confirm
that this will work on our side.

J

2009-06-23 20:57:07

[permalink] [raw]

Subject: Re: [PATCH] PCI: remove pcibios_scan_all_fns()

On Tue, Jun 23, 2009 at 01:34:46PM -0700, Jeremy Fitzhardinge wrote:
> On 06/23/09 12:08, Matthew Wilcox wrote:
> > I think simply materialising them, either the way the OF code does,
> > or the way the IOV code does is the best route forwards.
> >
>
> On reflection, I think this will work. We have a Xen pci passthrough
> driver which gets told about the passed-through devices via xenbus, and
> does the appropriate setup. At first glance, there doesn't seem to be
> any problem with that code just explicitly instantiate the devices at
> the PCI level in the same way pci_scan_device does (ie,
> alloc_pci_device, initalize the dev struct, pci_setup_device).

Even easier actually, pci_scan_single_device() should do everything you want.

> Is that what you mean?
>
> IanC has looked at that code more closely, so perhaps he can confirm
> that this will work on our side.
>
> J
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arch" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html

--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."

2009-06-23 21:49:26

[permalink] [raw]

Subject: Re: [PATCH] PCI: remove pcibios_scan_all_fns()

On Tue, 2009-06-23 at 13:08 -0600, Matthew Wilcox wrote:
>
> I think simply materialising them, either the way the OF code does,
> or the way the IOV code does is the best route forwards.

Agreed. I'm fine with removing pcibios_scan_all_fns() for now anyway,
and leave whatever arch do care with the responsibility of finding a
solution though :-)

Regarding the OF stuff, I'll see what I can do vs. moving it to
drivers/pci some time next week after I'm done fixing the regressions
from this merge window :-)

Cheers,
Ben.

2009-06-23 22:02:14

[permalink] [raw]

Subject: Re: [PATCH] PCI: remove pcibios_scan_all_fns()

On Tue, 2009-06-23 at 13:34 -0700, Jeremy Fitzhardinge wrote:
> On reflection, I think this will work. We have a Xen pci passthrough
> driver which gets told about the passed-through devices via xenbus,
> and
> does the appropriate setup. At first glance, there doesn't seem to be
> any problem with that code just explicitly instantiate the devices at
> the PCI level in the same way pci_scan_device does (ie,
> alloc_pci_device, initalize the dev struct, pci_setup_device).
>
> Is that what you mean?
>
> IanC has looked at that code more closely, so perhaps he can confirm
> that this will work on our side.
>
Yes, we do that in arch/powerpc/kernel/pci_64.c (and somewhere in
arch/sparc too). I'll merge those 2 implementations one of these days
and move them to drivers/of.

I think Willy was actually suggesting that you start using our
OF/device-tree stuff though which is a slightly more invasive deal but
might end up useful for other things in the long run :-)

Cheers,
Ben.

2009-06-23 22:24:56

[permalink] [raw]

Subject: Re: [PATCH] PCI: remove pcibios_scan_all_fns()

On 06/23/09 14:49, Benjamin Herrenschmidt wrote:
> I think Willy was actually suggesting that you start using our
> OF/device-tree stuff though which is a slightly more invasive deal but
> might end up useful for other things in the long run :-)
>

I guess we could fake up OF-like datastructures or something, but I
don't see what wide application that would have. It might help in this
case, but its a lot more complex than just calling
pci_scan_single_device() at the appropriate place.

Do you have any other cases in mind where it would be helpful?

J

2009-06-23 22:43:31

[permalink] [raw]

Subject: Re: [PATCH] PCI: remove pcibios_scan_all_fns()

On Tue, 2009-06-23 at 15:24 -0700, Jeremy Fitzhardinge wrote:
> I guess we could fake up OF-like datastructures or something, but I
> don't see what wide application that would have. It might help in this
> case, but its a lot more complex than just calling
> pci_scan_single_device() at the appropriate place.

It would be indeed more complex and probably not something to do
right now to solve that specific problem

> Do you have any other cases in mind where it would be helpful?

Well, it might be for virtual device discovery etc... but don't bother
now. We might talk about it at KS for those interested. It's more
something we see as useful for embedded archs at the moment but in the
long run it might make sense for hypervisors as well.

Cheers,
Ben.

2009-06-23 22:53:27

[permalink] [raw]

Subject: Re: [PATCH] PCI: remove pcibios_scan_all_fns()

On 06/23/09 15:41, Benjamin Herrenschmidt wrote:
>> Do you have any other cases in mind where it would be helpful?
>>
>
> Well, it might be for virtual device discovery etc... but don't bother
> now. We might talk about it at KS for those interested. It's more
> something we see as useful for embedded archs at the moment but in the
> long run it might make sense for hypervisors as well.
>

Perhaps. We have Xenbus - which is a little bit like OF in that it has
data in a hierarchical namespace - and I guess it might be possible to
find a mapping onto some generic OF-like interface. However, Xenbus is
an active communication channel between virtual machines rather than a
static representation of a machine configuration (for example, you can
put a watch on a particular path to get a notification of when someone
else changes it).

But, yes, this is a good KS hallway track subject.

J

2009-06-24 00:04:24