Resources and links

[Myles Watson]

I've been thinking about getting rid of the links in v3, or changing their
meaning.  I can't see anywhere that they're being used right now.

The problem is how to deal with k8.  It has "multiple links", but not in the
same sense as v3.  In v3, multiple links means logical connections to
multiple devices.  K8 has multiple physical connections, but only one
logical connection.

This is a problem for resource allocation (the current implementation as
well as my patch.)  The idea is that for every bridge resource gets all
matching resources from the sub-tree packed into it.  The problem is that
for k8 there can be multiple bridge resources of the same type, and to know
which resources to pack into it, you have to know which physical link they
are connected to.  At the same time, all the children are logically
connected to the same PCI.

This could be solved in several ways, but I'm hoping that there's an elegant
way that I haven't thought of yet.  Here are a couple I was thinking of:

1. Let links have resources, and make all bridge resources live there.
    I don't like this one because links aren't needed anywhere else, and
this just makes links larger.

2. Give bridges a function which returns the children under a resource.
    It's an extra function for all bridges, but most would just return
all children.

I'm sure there are myriad other ways.  I'm looking for one that will be easy
to explain and implement correctly.

Thanks,
Myles

[Marc Jones]

On Thu, Dec 4, 2008 at 7:00 AM, Myles Watson  wrote:
> I've been thinking about getting rid of the links in v3, or changing their
> meaning.  I can't see anywhere that they're being used right now.
>
> The problem is how to deal with k8.  It has "multiple links", but not in the
> same sense as v3.  In v3, multiple links means logical connections to
> multiple devices.  K8 has multiple physical connections, but only one
> logical connection.
>
> This is a problem for resource allocation (the current implementation as
> well as my patch.)  The idea is that for every bridge resource gets all
> matching resources from the sub-tree packed into it.  The problem is that
> for k8 there can be multiple bridge resources of the same type, and to know
> which resources to pack into it, you have to know which physical link they
> are connected to.  At the same time, all the children are logically
> connected to the same PCI.
>
> This could be solved in several ways, but I'm hoping that there's an elegant
> way that I haven't thought of yet.  Here are a couple I was thinking of:
> Let links have resources, and make all bridge resources live there.
>     I don't like this one because links aren't needed anywhere else, and
>
> this just makes links larger.
> Give bridges a function which returns the children under a resource.
>     It's an extra function for all bridges, but most would just return
>
> all children.

Myles,

#2 seems like it would be useful. Would it be useful to have the link
hold pointes to the child bridge(s) or is that already handled?

Marc