Hi folks,

Ok, yet another Newbus' limitation. Assuming a device exports more
than one interface, and one of its child has need to use more than one
interface, each interfaces cannot register, concurrently, its own
ivar. While I try to always have a single child per
interface/resource, I need to keep some compatibility with the old way
of doing thing (POLA wrt. drivers I cannot/will not convert and
userland). So, it would have been nice if ivar had been per-interface,
not global and unique to one device.

Unless I am mistaken, ivar are the only way for a parent can transmit
information to a child. I can not simply implement a new METHOD to get
that ivar as the device implements multiple time the same function
(actually, up to 4 time for one, 3 for the other, with possible
crossovers...), each one physically distinct. Each child is being tied
to a pair. Thus, I need to pass each child discriminator(s) for each
interfaces right after having been *created*, which cannot be done
later on. Of course, it is out-of-question to have crossover in the
interfaces definitions.

The best way I could achieve this currently is to pass the child's
device to its parent, and do a lookup based on that pointer to get
information I need, but erk....

my 1c,
- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

Hi folks,

Ok, yet another Newbus' limitation. Assuming a device exports more
than one interface, and one of its child has need to use more than one
interface, each interfaces cannot register, concurrently, its own
ivar. While I try to always have a single child per
interface/resource, I need to keep some compatibility with the old way
of doing thing (POLA wrt. drivers I cannot/will not convert and
userland). So, it would have been nice if ivar had been per-interface,
not global and unique to one device.

Unless I am mistaken, ivar are the only way for a parent can transmit
information to a child. I can not simply implement a new METHOD to get
that ivar as the device implements multiple time the same function
(actually, up to 4 time for one, 3 for the other, with possible
crossovers...), each one physically distinct. Each child is being tied
to a pair. Thus, I need to pass each child discriminator(s) for each
interfaces right after having been *created*, which cannot be done
later on. Of course, it is out-of-question to have crossover in the
interfaces definitions.

The best way I could achieve this currently is to pass the child's
device to its parent, and do a lookup based on that pointer to get
information I need, but erk....

my 1c,
- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
> Ok, yet another Newbus' limitation. Assuming a device exports more
> than one interface, and one of its child has need to use more than one
> interface, each interfaces cannot register, concurrently, its own
> ivar. While I try to always have a single child per
> interface/resource, I need to keep some compatibility with the old way
> of doing thing (POLA wrt. drivers I cannot/will not convert and
> userland). So, it would have been nice if ivar had been per-interface,
> not global and unique to one device.

There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.

So I'm not sure I understand what you are saying here.

The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
....
};

We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:

enum ivar_namespace {
IVAR_PCI = 1,
IVAR_PCCARD,
IVAR_USB,
etc
};
#define IVAR_SHIFT 16

and the above could be changed to:

enum pci_device_ivars {
PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
....
};

and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.

but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.

> Unless I am mistaken, ivar are the only way for a parent can transmit
> information to a child. I can not simply implement a new METHOD to get
> that ivar as the device implements multiple time the same function
> (actually, up to 4 time for one, 3 for the other, with possible
> crossovers...), each one physically distinct. Each child is being tied
> to a pair. Thus, I need to pass each child discriminator(s) for each
> interfaces right after having been *created*, which cannot be done
> later on. Of course, it is out-of-question to have crossover in the
> interfaces definitions.

ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.

> The best way I could achieve this currently is to pass the child's
> device to its parent, and do a lookup based on that pointer to get
> information I need, but erk....

That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.

Warner_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

Hi folks,

Ok, yet another Newbus' limitation. Assuming a device exports more
than one interface, and one of its child has need to use more than one
interface, each interfaces cannot register, concurrently, its own
ivar. While I try to always have a single child per
interface/resource, I need to keep some compatibility with the old way
of doing thing (POLA wrt. drivers I cannot/will not convert and
userland). So, it would have been nice if ivar had been per-interface,
not global and unique to one device.

Unless I am mistaken, ivar are the only way for a parent can transmit
information to a child. I can not simply implement a new METHOD to get
that ivar as the device implements multiple time the same function
(actually, up to 4 time for one, 3 for the other, with possible
crossovers...), each one physically distinct. Each child is being tied
to a pair. Thus, I need to pass each child discriminator(s) for each
interfaces right after having been *created*, which cannot be done
later on. Of course, it is out-of-question to have crossover in the
interfaces definitions.

The best way I could achieve this currently is to pass the child's
device to its parent, and do a lookup based on that pointer to get
information I need, but erk....

my 1c,
- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
> Ok, yet another Newbus' limitation. Assuming a device exports more
> than one interface, and one of its child has need to use more than one
> interface, each interfaces cannot register, concurrently, its own
> ivar. While I try to always have a single child per
> interface/resource, I need to keep some compatibility with the old way
> of doing thing (POLA wrt. drivers I cannot/will not convert and
> userland). So, it would have been nice if ivar had been per-interface,
> not global and unique to one device.

There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.

So I'm not sure I understand what you are saying here.

The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
....
};

We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:

enum ivar_namespace {
IVAR_PCI = 1,
IVAR_PCCARD,
IVAR_USB,
etc
};
#define IVAR_SHIFT 16

and the above could be changed to:

enum pci_device_ivars {
PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
....
};

and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.

but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.

> Unless I am mistaken, ivar are the only way for a parent can transmit
> information to a child. I can not simply implement a new METHOD to get
> that ivar as the device implements multiple time the same function
> (actually, up to 4 time for one, 3 for the other, with possible
> crossovers...), each one physically distinct. Each child is being tied
> to a pair. Thus, I need to pass each child discriminator(s) for each
> interfaces right after having been *created*, which cannot be done
> later on. Of course, it is out-of-question to have crossover in the
> interfaces definitions.

ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.

> The best way I could achieve this currently is to pass the child's
> device to its parent, and do a lookup based on that pointer to get
> information I need, but erk....

That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.

Warner_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>> Ok, yet another Newbus' limitation. Assuming a device exports more
>> than one interface, and one of its child has need to use more than one
>> interface, each interfaces cannot register, concurrently, its own
>> ivar. While I try to always have a single child per
>> interface/resource, I need to keep some compatibility with the old way
>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>> userland). So, it would have been nice if ivar had been per-interface,
>> not global and unique to one device.
>
> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>
> So I'm not sure I understand what you are saying here.
>
dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
use both interfaces. There is no generic way for dev0 to export
independent ivars for both interface. For now, I restricted the
function of the second interface not to need ivar, but that's kind of
hackish.

- Arnaud

> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>
> enum ivar_namespace {
> IVAR_PCI = 1,
> IVAR_PCCARD,
> IVAR_USB,
> etc
> };
> #define IVAR_SHIFT 16
>
> and the above could be changed to:
>
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>
> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>
>> Unless I am mistaken, ivar are the only way for a parent can transmit
>> information to a child. I can not simply implement a new METHOD to get
>> that ivar as the device implements multiple time the same function
>> (actually, up to 4 time for one, 3 for the other, with possible
>> crossovers...), each one physically distinct. Each child is being tied
>> to a pair. Thus, I need to pass each child discriminator(s) for each
>> interfaces right after having been *created*, which cannot be done
>> later on. Of course, it is out-of-question to have crossover in the
>> interfaces definitions.
>
> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>
>> The best way I could achieve this currently is to pass the child's
>> device to its parent, and do a lookup based on that pointer to get
>> information I need, but erk....
>
> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>
> Warner
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

Hi folks,

Ok, yet another Newbus' limitation. Assuming a device exports more
than one interface, and one of its child has need to use more than one
interface, each interfaces cannot register, concurrently, its own
ivar. While I try to always have a single child per
interface/resource, I need to keep some compatibility with the old way
of doing thing (POLA wrt. drivers I cannot/will not convert and
userland). So, it would have been nice if ivar had been per-interface,
not global and unique to one device.

Unless I am mistaken, ivar are the only way for a parent can transmit
information to a child. I can not simply implement a new METHOD to get
that ivar as the device implements multiple time the same function
(actually, up to 4 time for one, 3 for the other, with possible
crossovers...), each one physically distinct. Each child is being tied
to a pair. Thus, I need to pass each child discriminator(s) for each
interfaces right after having been *created*, which cannot be done
later on. Of course, it is out-of-question to have crossover in the
interfaces definitions.

The best way I could achieve this currently is to pass the child's
device to its parent, and do a lookup based on that pointer to get
information I need, but erk....

my 1c,
- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
> Ok, yet another Newbus' limitation. Assuming a device exports more
> than one interface, and one of its child has need to use more than one
> interface, each interfaces cannot register, concurrently, its own
> ivar. While I try to always have a single child per
> interface/resource, I need to keep some compatibility with the old way
> of doing thing (POLA wrt. drivers I cannot/will not convert and
> userland). So, it would have been nice if ivar had been per-interface,
> not global and unique to one device.

There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.

So I'm not sure I understand what you are saying here.

The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
....
};

We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:

enum ivar_namespace {
IVAR_PCI = 1,
IVAR_PCCARD,
IVAR_USB,
etc
};
#define IVAR_SHIFT 16

and the above could be changed to:

enum pci_device_ivars {
PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
....
};

and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.

but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.

> Unless I am mistaken, ivar are the only way for a parent can transmit
> information to a child. I can not simply implement a new METHOD to get
> that ivar as the device implements multiple time the same function
> (actually, up to 4 time for one, 3 for the other, with possible
> crossovers...), each one physically distinct. Each child is being tied
> to a pair. Thus, I need to pass each child discriminator(s) for each
> interfaces right after having been *created*, which cannot be done
> later on. Of course, it is out-of-question to have crossover in the
> interfaces definitions.

ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.

> The best way I could achieve this currently is to pass the child's
> device to its parent, and do a lookup based on that pointer to get
> information I need, but erk....

That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.

Warner_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>> Ok, yet another Newbus' limitation. Assuming a device exports more
>> than one interface, and one of its child has need to use more than one
>> interface, each interfaces cannot register, concurrently, its own
>> ivar. While I try to always have a single child per
>> interface/resource, I need to keep some compatibility with the old way
>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>> userland). So, it would have been nice if ivar had been per-interface,
>> not global and unique to one device.
>
> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>
> So I'm not sure I understand what you are saying here.
>
dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
use both interfaces. There is no generic way for dev0 to export
independent ivars for both interface. For now, I restricted the
function of the second interface not to need ivar, but that's kind of
hackish.

- Arnaud

> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>
> enum ivar_namespace {
> IVAR_PCI = 1,
> IVAR_PCCARD,
> IVAR_USB,
> etc
> };
> #define IVAR_SHIFT 16
>
> and the above could be changed to:
>
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>
> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>
>> Unless I am mistaken, ivar are the only way for a parent can transmit
>> information to a child. I can not simply implement a new METHOD to get
>> that ivar as the device implements multiple time the same function
>> (actually, up to 4 time for one, 3 for the other, with possible
>> crossovers...), each one physically distinct. Each child is being tied
>> to a pair. Thus, I need to pass each child discriminator(s) for each
>> interfaces right after having been *created*, which cannot be done
>> later on. Of course, it is out-of-question to have crossover in the
>> interfaces definitions.
>
> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>
>> The best way I could achieve this currently is to pass the child's
>> device to its parent, and do a lookup based on that pointer to get
>> information I need, but erk....
>
> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>
> Warner
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:

> Hi,
>
> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>> than one interface, and one of its child has need to use more than one
>>> interface, each interfaces cannot register, concurrently, its own
>>> ivar. While I try to always have a single child per
>>> interface/resource, I need to keep some compatibility with the old way
>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>> userland). So, it would have been nice if ivar had been per-interface,
>>> not global and unique to one device.
>>
>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>
>> So I'm not sure I understand what you are saying here.
>>
> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
> use both interfaces. There is no generic way for dev0 to export
> independent ivars for both interface. For now, I restricted the
> function of the second interface not to need ivar, but that's kind of
> hackish.

Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.

Warner

> - Arnaud
>
>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>
>> enum ivar_namespace {
>> IVAR_PCI = 1,
>> IVAR_PCCARD,
>> IVAR_USB,
>> etc
>> };
>> #define IVAR_SHIFT 16
>>
>> and the above could be changed to:
>>
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>
>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>
>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>> information to a child. I can not simply implement a new METHOD to get
>>> that ivar as the device implements multiple time the same function
>>> (actually, up to 4 time for one, 3 for the other, with possible
>>> crossovers...), each one physically distinct. Each child is being tied
>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>> interfaces right after having been *created*, which cannot be done
>>> later on. Of course, it is out-of-question to have crossover in the
>>> interfaces definitions.
>>
>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>
>>> The best way I could achieve this currently is to pass the child's
>>> device to its parent, and do a lookup based on that pointer to get
>>> information I need, but erk....
>>
>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>
>> Warner

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

Hi folks,

Ok, yet another Newbus' limitation. Assuming a device exports more
than one interface, and one of its child has need to use more than one
interface, each interfaces cannot register, concurrently, its own
ivar. While I try to always have a single child per
interface/resource, I need to keep some compatibility with the old way
of doing thing (POLA wrt. drivers I cannot/will not convert and
userland). So, it would have been nice if ivar had been per-interface,
not global and unique to one device.

Unless I am mistaken, ivar are the only way for a parent can transmit
information to a child. I can not simply implement a new METHOD to get
that ivar as the device implements multiple time the same function
(actually, up to 4 time for one, 3 for the other, with possible
crossovers...), each one physically distinct. Each child is being tied
to a pair. Thus, I need to pass each child discriminator(s) for each
interfaces right after having been *created*, which cannot be done
later on. Of course, it is out-of-question to have crossover in the
interfaces definitions.

The best way I could achieve this currently is to pass the child's
device to its parent, and do a lookup based on that pointer to get
information I need, but erk....

my 1c,
- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
> Ok, yet another Newbus' limitation. Assuming a device exports more
> than one interface, and one of its child has need to use more than one
> interface, each interfaces cannot register, concurrently, its own
> ivar. While I try to always have a single child per
> interface/resource, I need to keep some compatibility with the old way
> of doing thing (POLA wrt. drivers I cannot/will not convert and
> userland). So, it would have been nice if ivar had been per-interface,
> not global and unique to one device.

There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.

So I'm not sure I understand what you are saying here.

The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
....
};

We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:

enum ivar_namespace {
IVAR_PCI = 1,
IVAR_PCCARD,
IVAR_USB,
etc
};
#define IVAR_SHIFT 16

and the above could be changed to:

enum pci_device_ivars {
PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
....
};

and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.

but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.

> Unless I am mistaken, ivar are the only way for a parent can transmit
> information to a child. I can not simply implement a new METHOD to get
> that ivar as the device implements multiple time the same function
> (actually, up to 4 time for one, 3 for the other, with possible
> crossovers...), each one physically distinct. Each child is being tied
> to a pair. Thus, I need to pass each child discriminator(s) for each
> interfaces right after having been *created*, which cannot be done
> later on. Of course, it is out-of-question to have crossover in the
> interfaces definitions.

ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.

> The best way I could achieve this currently is to pass the child's
> device to its parent, and do a lookup based on that pointer to get
> information I need, but erk....

That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.

Warner_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>> Ok, yet another Newbus' limitation. Assuming a device exports more
>> than one interface, and one of its child has need to use more than one
>> interface, each interfaces cannot register, concurrently, its own
>> ivar. While I try to always have a single child per
>> interface/resource, I need to keep some compatibility with the old way
>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>> userland). So, it would have been nice if ivar had been per-interface,
>> not global and unique to one device.
>
> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>
> So I'm not sure I understand what you are saying here.
>
dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
use both interfaces. There is no generic way for dev0 to export
independent ivars for both interface. For now, I restricted the
function of the second interface not to need ivar, but that's kind of
hackish.

- Arnaud

> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>
> enum ivar_namespace {
> IVAR_PCI = 1,
> IVAR_PCCARD,
> IVAR_USB,
> etc
> };
> #define IVAR_SHIFT 16
>
> and the above could be changed to:
>
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>
> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>
>> Unless I am mistaken, ivar are the only way for a parent can transmit
>> information to a child. I can not simply implement a new METHOD to get
>> that ivar as the device implements multiple time the same function
>> (actually, up to 4 time for one, 3 for the other, with possible
>> crossovers...), each one physically distinct. Each child is being tied
>> to a pair. Thus, I need to pass each child discriminator(s) for each
>> interfaces right after having been *created*, which cannot be done
>> later on. Of course, it is out-of-question to have crossover in the
>> interfaces definitions.
>
> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>
>> The best way I could achieve this currently is to pass the child's
>> device to its parent, and do a lookup based on that pointer to get
>> information I need, but erk....
>
> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>
> Warner
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:

> Hi,
>
> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>> than one interface, and one of its child has need to use more than one
>>> interface, each interfaces cannot register, concurrently, its own
>>> ivar. While I try to always have a single child per
>>> interface/resource, I need to keep some compatibility with the old way
>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>> userland). So, it would have been nice if ivar had been per-interface,
>>> not global and unique to one device.
>>
>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>
>> So I'm not sure I understand what you are saying here.
>>
> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
> use both interfaces. There is no generic way for dev0 to export
> independent ivars for both interface. For now, I restricted the
> function of the second interface not to need ivar, but that's kind of
> hackish.

Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.

Warner

> - Arnaud
>
>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>
>> enum ivar_namespace {
>> IVAR_PCI = 1,
>> IVAR_PCCARD,
>> IVAR_USB,
>> etc
>> };
>> #define IVAR_SHIFT 16
>>
>> and the above could be changed to:
>>
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>
>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>
>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>> information to a child. I can not simply implement a new METHOD to get
>>> that ivar as the device implements multiple time the same function
>>> (actually, up to 4 time for one, 3 for the other, with possible
>>> crossovers...), each one physically distinct. Each child is being tied
>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>> interfaces right after having been *created*, which cannot be done
>>> later on. Of course, it is out-of-question to have crossover in the
>>> interfaces definitions.
>>
>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>
>>> The best way I could achieve this currently is to pass the child's
>>> device to its parent, and do a lookup based on that pointer to get
>>> information I need, but erk....
>>
>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>
>> Warner

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>
>> Hi,
>>
>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>
>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>> than one interface, and one of its child has need to use more than one
>>>> interface, each interfaces cannot register, concurrently, its own
>>>> ivar. While I try to always have a single child per
>>>> interface/resource, I need to keep some compatibility with the old way
>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>> not global and unique to one device.
>>>
>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>
>>> So I'm not sure I understand what you are saying here.
>>>
>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>> use both interfaces. There is no generic way for dev0 to export
>> independent ivars for both interface. For now, I restricted the
>> function of the second interface not to need ivar, but that's kind of
>> hackish.
>
> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>
I think we should not be talking about the same API here. I have no
idea what you mean by "the key to value translation", nor "Ivar
numbers". What I refer to is that device_set_ivars() /
device_get_ivars() acts on a single instance variables from `struct
device': `ivars'. In that case, I do not really see how to set that
specific field to two distinct values for each interfaces.

- Arnaud

> Warner
>
>> - Arnaud
>>
>>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>>> enum pci_device_ivars {
>>> PCI_IVAR_SUBVENDOR,
>>> PCI_IVAR_SUBDEVICE,
>>> PCI_IVAR_VENDOR,
>>> ....
>>> };
>>>
>>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>>
>>> enum ivar_namespace {
>>> IVAR_PCI = 1,
>>> IVAR_PCCARD,
>>> IVAR_USB,
>>> etc
>>> };
>>> #define IVAR_SHIFT 16
>>>
>>> and the above could be changed to:
>>>
>>> enum pci_device_ivars {
>>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>>> PCI_IVAR_SUBDEVICE,
>>> PCI_IVAR_VENDOR,
>>> ....
>>> };
>>>
>>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>>
>>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>>
>>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>>> information to a child. I can not simply implement a new METHOD to get
>>>> that ivar as the device implements multiple time the same function
>>>> (actually, up to 4 time for one, 3 for the other, with possible
>>>> crossovers...), each one physically distinct. Each child is being tied
>>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>>> interfaces right after having been *created*, which cannot be done
>>>> later on. Of course, it is out-of-question to have crossover in the
>>>> interfaces definitions.
>>>
>>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>>
>>>> The best way I could achieve this currently is to pass the child's
>>>> device to its parent, and do a lookup based on that pointer to get
>>>> information I need, but erk....
>>>
>>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>>
>>> Warner
>
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

Hi folks,

Ok, yet another Newbus' limitation. Assuming a device exports more
than one interface, and one of its child has need to use more than one
interface, each interfaces cannot register, concurrently, its own
ivar. While I try to always have a single child per
interface/resource, I need to keep some compatibility with the old way
of doing thing (POLA wrt. drivers I cannot/will not convert and
userland). So, it would have been nice if ivar had been per-interface,
not global and unique to one device.

Unless I am mistaken, ivar are the only way for a parent can transmit
information to a child. I can not simply implement a new METHOD to get
that ivar as the device implements multiple time the same function
(actually, up to 4 time for one, 3 for the other, with possible
crossovers...), each one physically distinct. Each child is being tied
to a pair. Thus, I need to pass each child discriminator(s) for each
interfaces right after having been *created*, which cannot be done
later on. Of course, it is out-of-question to have crossover in the
interfaces definitions.

The best way I could achieve this currently is to pass the child's
device to its parent, and do a lookup based on that pointer to get
information I need, but erk....

my 1c,
- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
> Ok, yet another Newbus' limitation. Assuming a device exports more
> than one interface, and one of its child has need to use more than one
> interface, each interfaces cannot register, concurrently, its own
> ivar. While I try to always have a single child per
> interface/resource, I need to keep some compatibility with the old way
> of doing thing (POLA wrt. drivers I cannot/will not convert and
> userland). So, it would have been nice if ivar had been per-interface,
> not global and unique to one device.

There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.

So I'm not sure I understand what you are saying here.

The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
....
};

We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:

enum ivar_namespace {
IVAR_PCI = 1,
IVAR_PCCARD,
IVAR_USB,
etc
};
#define IVAR_SHIFT 16

and the above could be changed to:

enum pci_device_ivars {
PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
....
};

and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.

but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.

> Unless I am mistaken, ivar are the only way for a parent can transmit
> information to a child. I can not simply implement a new METHOD to get
> that ivar as the device implements multiple time the same function
> (actually, up to 4 time for one, 3 for the other, with possible
> crossovers...), each one physically distinct. Each child is being tied
> to a pair. Thus, I need to pass each child discriminator(s) for each
> interfaces right after having been *created*, which cannot be done
> later on. Of course, it is out-of-question to have crossover in the
> interfaces definitions.

ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.

> The best way I could achieve this currently is to pass the child's
> device to its parent, and do a lookup based on that pointer to get
> information I need, but erk....

That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.

Warner_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>> Ok, yet another Newbus' limitation. Assuming a device exports more
>> than one interface, and one of its child has need to use more than one
>> interface, each interfaces cannot register, concurrently, its own
>> ivar. While I try to always have a single child per
>> interface/resource, I need to keep some compatibility with the old way
>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>> userland). So, it would have been nice if ivar had been per-interface,
>> not global and unique to one device.
>
> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>
> So I'm not sure I understand what you are saying here.
>
dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
use both interfaces. There is no generic way for dev0 to export
independent ivars for both interface. For now, I restricted the
function of the second interface not to need ivar, but that's kind of
hackish.

- Arnaud

> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>
> enum ivar_namespace {
> IVAR_PCI = 1,
> IVAR_PCCARD,
> IVAR_USB,
> etc
> };
> #define IVAR_SHIFT 16
>
> and the above could be changed to:
>
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>
> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>
>> Unless I am mistaken, ivar are the only way for a parent can transmit
>> information to a child. I can not simply implement a new METHOD to get
>> that ivar as the device implements multiple time the same function
>> (actually, up to 4 time for one, 3 for the other, with possible
>> crossovers...), each one physically distinct. Each child is being tied
>> to a pair. Thus, I need to pass each child discriminator(s) for each
>> interfaces right after having been *created*, which cannot be done
>> later on. Of course, it is out-of-question to have crossover in the
>> interfaces definitions.
>
> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>
>> The best way I could achieve this currently is to pass the child's
>> device to its parent, and do a lookup based on that pointer to get
>> information I need, but erk....
>
> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>
> Warner
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:

> Hi,
>
> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>> than one interface, and one of its child has need to use more than one
>>> interface, each interfaces cannot register, concurrently, its own
>>> ivar. While I try to always have a single child per
>>> interface/resource, I need to keep some compatibility with the old way
>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>> userland). So, it would have been nice if ivar had been per-interface,
>>> not global and unique to one device.
>>
>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>
>> So I'm not sure I understand what you are saying here.
>>
> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
> use both interfaces. There is no generic way for dev0 to export
> independent ivars for both interface. For now, I restricted the
> function of the second interface not to need ivar, but that's kind of
> hackish.

Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.

Warner

> - Arnaud
>
>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>
>> enum ivar_namespace {
>> IVAR_PCI = 1,
>> IVAR_PCCARD,
>> IVAR_USB,
>> etc
>> };
>> #define IVAR_SHIFT 16
>>
>> and the above could be changed to:
>>
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>
>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>
>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>> information to a child. I can not simply implement a new METHOD to get
>>> that ivar as the device implements multiple time the same function
>>> (actually, up to 4 time for one, 3 for the other, with possible
>>> crossovers...), each one physically distinct. Each child is being tied
>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>> interfaces right after having been *created*, which cannot be done
>>> later on. Of course, it is out-of-question to have crossover in the
>>> interfaces definitions.
>>
>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>
>>> The best way I could achieve this currently is to pass the child's
>>> device to its parent, and do a lookup based on that pointer to get
>>> information I need, but erk....
>>
>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>
>> Warner

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>
>> Hi,
>>
>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>
>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>> than one interface, and one of its child has need to use more than one
>>>> interface, each interfaces cannot register, concurrently, its own
>>>> ivar. While I try to always have a single child per
>>>> interface/resource, I need to keep some compatibility with the old way
>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>> not global and unique to one device.
>>>
>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>
>>> So I'm not sure I understand what you are saying here.
>>>
>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>> use both interfaces. There is no generic way for dev0 to export
>> independent ivars for both interface. For now, I restricted the
>> function of the second interface not to need ivar, but that's kind of
>> hackish.
>
> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>
I think we should not be talking about the same API here. I have no
idea what you mean by "the key to value translation", nor "Ivar
numbers". What I refer to is that device_set_ivars() /
device_get_ivars() acts on a single instance variables from `struct
device': `ivars'. In that case, I do not really see how to set that
specific field to two distinct values for each interfaces.

- Arnaud

> Warner
>
>> - Arnaud
>>
>>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>>> enum pci_device_ivars {
>>> PCI_IVAR_SUBVENDOR,
>>> PCI_IVAR_SUBDEVICE,
>>> PCI_IVAR_VENDOR,
>>> ....
>>> };
>>>
>>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>>
>>> enum ivar_namespace {
>>> IVAR_PCI = 1,
>>> IVAR_PCCARD,
>>> IVAR_USB,
>>> etc
>>> };
>>> #define IVAR_SHIFT 16
>>>
>>> and the above could be changed to:
>>>
>>> enum pci_device_ivars {
>>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>>> PCI_IVAR_SUBDEVICE,
>>> PCI_IVAR_VENDOR,
>>> ....
>>> };
>>>
>>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>>
>>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>>
>>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>>> information to a child. I can not simply implement a new METHOD to get
>>>> that ivar as the device implements multiple time the same function
>>>> (actually, up to 4 time for one, 3 for the other, with possible
>>>> crossovers...), each one physically distinct. Each child is being tied
>>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>>> interfaces right after having been *created*, which cannot be done
>>>> later on. Of course, it is out-of-question to have crossover in the
>>>> interfaces definitions.
>>>
>>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>>
>>>> The best way I could achieve this currently is to pass the child's
>>>> device to its parent, and do a lookup based on that pointer to get
>>>> information I need, but erk....
>>>
>>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>>
>>> Warner
>
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>> Ok, yet another Newbus' limitation. Assuming a device exports more
>> than one interface, and one of its child has need to use more than one
>> interface, each interfaces cannot register, concurrently, its own
>> ivar. While I try to always have a single child per
>> interface/resource, I need to keep some compatibility with the old way
>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>> userland). So, it would have been nice if ivar had been per-interface,
>> not global and unique to one device.
>
> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>
> So I'm not sure I understand what you are saying here.
>
> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>
> enum ivar_namespace {
> IVAR_PCI = 1,
> IVAR_PCCARD,
> IVAR_USB,
> etc
> };
> #define IVAR_SHIFT 16
>
> and the above could be changed to:
>
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>
> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>
ok, I think I got it now. You and I are exactly saying the same thing,
just in different terms; there is no way to currently specify multiple
independent (/overlapping) ivars in a child...

- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

Hi folks,

Ok, yet another Newbus' limitation. Assuming a device exports more
than one interface, and one of its child has need to use more than one
interface, each interfaces cannot register, concurrently, its own
ivar. While I try to always have a single child per
interface/resource, I need to keep some compatibility with the old way
of doing thing (POLA wrt. drivers I cannot/will not convert and
userland). So, it would have been nice if ivar had been per-interface,
not global and unique to one device.

Unless I am mistaken, ivar are the only way for a parent can transmit
information to a child. I can not simply implement a new METHOD to get
that ivar as the device implements multiple time the same function
(actually, up to 4 time for one, 3 for the other, with possible
crossovers...), each one physically distinct. Each child is being tied
to a pair. Thus, I need to pass each child discriminator(s) for each
interfaces right after having been *created*, which cannot be done
later on. Of course, it is out-of-question to have crossover in the
interfaces definitions.

The best way I could achieve this currently is to pass the child's
device to its parent, and do a lookup based on that pointer to get
information I need, but erk....

my 1c,
- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
> Ok, yet another Newbus' limitation. Assuming a device exports more
> than one interface, and one of its child has need to use more than one
> interface, each interfaces cannot register, concurrently, its own
> ivar. While I try to always have a single child per
> interface/resource, I need to keep some compatibility with the old way
> of doing thing (POLA wrt. drivers I cannot/will not convert and
> userland). So, it would have been nice if ivar had been per-interface,
> not global and unique to one device.

There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.

So I'm not sure I understand what you are saying here.

The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
....
};

We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:

enum ivar_namespace {
IVAR_PCI = 1,
IVAR_PCCARD,
IVAR_USB,
etc
};
#define IVAR_SHIFT 16

and the above could be changed to:

enum pci_device_ivars {
PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
....
};

and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.

but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.

> Unless I am mistaken, ivar are the only way for a parent can transmit
> information to a child. I can not simply implement a new METHOD to get
> that ivar as the device implements multiple time the same function
> (actually, up to 4 time for one, 3 for the other, with possible
> crossovers...), each one physically distinct. Each child is being tied
> to a pair. Thus, I need to pass each child discriminator(s) for each
> interfaces right after having been *created*, which cannot be done
> later on. Of course, it is out-of-question to have crossover in the
> interfaces definitions.

ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.

> The best way I could achieve this currently is to pass the child's
> device to its parent, and do a lookup based on that pointer to get
> information I need, but erk....

That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.

Warner_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>> Ok, yet another Newbus' limitation. Assuming a device exports more
>> than one interface, and one of its child has need to use more than one
>> interface, each interfaces cannot register, concurrently, its own
>> ivar. While I try to always have a single child per
>> interface/resource, I need to keep some compatibility with the old way
>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>> userland). So, it would have been nice if ivar had been per-interface,
>> not global and unique to one device.
>
> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>
> So I'm not sure I understand what you are saying here.
>
dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
use both interfaces. There is no generic way for dev0 to export
independent ivars for both interface. For now, I restricted the
function of the second interface not to need ivar, but that's kind of
hackish.

- Arnaud

> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>
> enum ivar_namespace {
> IVAR_PCI = 1,
> IVAR_PCCARD,
> IVAR_USB,
> etc
> };
> #define IVAR_SHIFT 16
>
> and the above could be changed to:
>
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>
> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>
>> Unless I am mistaken, ivar are the only way for a parent can transmit
>> information to a child. I can not simply implement a new METHOD to get
>> that ivar as the device implements multiple time the same function
>> (actually, up to 4 time for one, 3 for the other, with possible
>> crossovers...), each one physically distinct. Each child is being tied
>> to a pair. Thus, I need to pass each child discriminator(s) for each
>> interfaces right after having been *created*, which cannot be done
>> later on. Of course, it is out-of-question to have crossover in the
>> interfaces definitions.
>
> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>
>> The best way I could achieve this currently is to pass the child's
>> device to its parent, and do a lookup based on that pointer to get
>> information I need, but erk....
>
> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>
> Warner
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:

> Hi,
>
> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>> than one interface, and one of its child has need to use more than one
>>> interface, each interfaces cannot register, concurrently, its own
>>> ivar. While I try to always have a single child per
>>> interface/resource, I need to keep some compatibility with the old way
>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>> userland). So, it would have been nice if ivar had been per-interface,
>>> not global and unique to one device.
>>
>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>
>> So I'm not sure I understand what you are saying here.
>>
> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
> use both interfaces. There is no generic way for dev0 to export
> independent ivars for both interface. For now, I restricted the
> function of the second interface not to need ivar, but that's kind of
> hackish.

Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.

Warner

> - Arnaud
>
>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>
>> enum ivar_namespace {
>> IVAR_PCI = 1,
>> IVAR_PCCARD,
>> IVAR_USB,
>> etc
>> };
>> #define IVAR_SHIFT 16
>>
>> and the above could be changed to:
>>
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>
>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>
>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>> information to a child. I can not simply implement a new METHOD to get
>>> that ivar as the device implements multiple time the same function
>>> (actually, up to 4 time for one, 3 for the other, with possible
>>> crossovers...), each one physically distinct. Each child is being tied
>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>> interfaces right after having been *created*, which cannot be done
>>> later on. Of course, it is out-of-question to have crossover in the
>>> interfaces definitions.
>>
>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>
>>> The best way I could achieve this currently is to pass the child's
>>> device to its parent, and do a lookup based on that pointer to get
>>> information I need, but erk....
>>
>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>
>> Warner

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>
>> Hi,
>>
>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>
>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>> than one interface, and one of its child has need to use more than one
>>>> interface, each interfaces cannot register, concurrently, its own
>>>> ivar. While I try to always have a single child per
>>>> interface/resource, I need to keep some compatibility with the old way
>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>> not global and unique to one device.
>>>
>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>
>>> So I'm not sure I understand what you are saying here.
>>>
>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>> use both interfaces. There is no generic way for dev0 to export
>> independent ivars for both interface. For now, I restricted the
>> function of the second interface not to need ivar, but that's kind of
>> hackish.
>
> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>
I think we should not be talking about the same API here. I have no
idea what you mean by "the key to value translation", nor "Ivar
numbers". What I refer to is that device_set_ivars() /
device_get_ivars() acts on a single instance variables from `struct
device': `ivars'. In that case, I do not really see how to set that
specific field to two distinct values for each interfaces.

- Arnaud

> Warner
>
>> - Arnaud
>>
>>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>>> enum pci_device_ivars {
>>> PCI_IVAR_SUBVENDOR,
>>> PCI_IVAR_SUBDEVICE,
>>> PCI_IVAR_VENDOR,
>>> ....
>>> };
>>>
>>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>>
>>> enum ivar_namespace {
>>> IVAR_PCI = 1,
>>> IVAR_PCCARD,
>>> IVAR_USB,
>>> etc
>>> };
>>> #define IVAR_SHIFT 16
>>>
>>> and the above could be changed to:
>>>
>>> enum pci_device_ivars {
>>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>>> PCI_IVAR_SUBDEVICE,
>>> PCI_IVAR_VENDOR,
>>> ....
>>> };
>>>
>>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>>
>>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>>
>>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>>> information to a child. I can not simply implement a new METHOD to get
>>>> that ivar as the device implements multiple time the same function
>>>> (actually, up to 4 time for one, 3 for the other, with possible
>>>> crossovers...), each one physically distinct. Each child is being tied
>>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>>> interfaces right after having been *created*, which cannot be done
>>>> later on. Of course, it is out-of-question to have crossover in the
>>>> interfaces definitions.
>>>
>>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>>
>>>> The best way I could achieve this currently is to pass the child's
>>>> device to its parent, and do a lookup based on that pointer to get
>>>> information I need, but erk....
>>>
>>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>>
>>> Warner
>
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>> Ok, yet another Newbus' limitation. Assuming a device exports more
>> than one interface, and one of its child has need to use more than one
>> interface, each interfaces cannot register, concurrently, its own
>> ivar. While I try to always have a single child per
>> interface/resource, I need to keep some compatibility with the old way
>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>> userland). So, it would have been nice if ivar had been per-interface,
>> not global and unique to one device.
>
> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>
> So I'm not sure I understand what you are saying here.
>
> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>
> enum ivar_namespace {
> IVAR_PCI = 1,
> IVAR_PCCARD,
> IVAR_USB,
> etc
> };
> #define IVAR_SHIFT 16
>
> and the above could be changed to:
>
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>
> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>
ok, I think I got it now. You and I are exactly saying the same thing,
just in different terms; there is no way to currently specify multiple
independent (/overlapping) ivars in a child...

- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote:

> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>>
>>> Hi,
>>>
>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>>
>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>>> than one interface, and one of its child has need to use more than one
>>>>> interface, each interfaces cannot register, concurrently, its own
>>>>> ivar. While I try to always have a single child per
>>>>> interface/resource, I need to keep some compatibility with the old way
>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>>> not global and unique to one device.
>>>>
>>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>>
>>>> So I'm not sure I understand what you are saying here.
>>>>
>>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>>> use both interfaces. There is no generic way for dev0 to export
>>> independent ivars for both interface. For now, I restricted the
>>> function of the second interface not to need ivar, but that's kind of
>>> hackish.
>>
>> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>>
> I think we should not be talking about the same API here. I have no
> idea what you mean by "the key to value translation", nor "Ivar
> numbers". What I refer to is that device_set_ivars() /
> device_get_ivars() acts on a single instance variables from `struct
> device': `ivars'. In that case, I do not really see how to set that
> specific field to two distinct values for each interfaces.

We are talking about the ivar interface. You are just misunderstanding how it is used.

Let us say that dev0 wants to implement interface A and B. The interface it implements is the device_read _ivar method. That method looks like:

int pci_read_ivar(device_t dev, device_t child, int which, uintptr_t *result)
{
struct pci_ivar *iv = device_get_ivar(child);

switch (which) {
case PCI_IVAR_SUBVENDOR:
*result = iv->subvendor;
break;
...
default:
return EINVAL;
}
return 0;
}

So, if you wanted to implement interface A and interface B, you would have to support reading and writing A_IVAR_* and B_IVAR_*. The above routine would look like:

struct mydev_ivar {
int a_1;
int a_2;
int b_1;
int b_2;
};

int mydev_read_ivar(device_t dev, device child, int which, uintpr_t *result)
{
struct mydev_ivar *iv = device_get_ivar(child);

switch (which) {
case A_IVAR_1:
*result = iv->a_1;
break;
case A_IVAR_2:
*result = iv->a_2;
break;
case B_IVAR_1:
*result = iv->b_1;
break;
case B_IVAR_2:
*result = iv->b_2;
break;
default:
return EINVAL;
}
return 0;
}

and similar for the write routine. Now, there are some busses that provide convenience structures and functions for dealing with the ivars. In that case, you'd be able to use the wrapper structures and routines like so:

struct mdev_ivar {
struct a_ivar a;
struct b_ivar b;
};

int mydev_read_ivar(device_t dev, device child, int which, uintpr_t *result)
{
struct mydev_ivar *iv = device_get_ivar(child);

switch (which) {
case A_IVAR_1:
case A_IVAR_2:
return a_helper_read_ivar(&iv->a, which, result);
case B_IVAR_1:
case B_IVAR_2:
return b_helper_read_ivar(&iv->b, which, result);
default:
return EINVAL;
}
return 0;
}

Both of these work only if the A_IVAR values are disjoint from the B_IVAR values. Your mydev device is the one that sets the ivar on dev1, in your example, so it would know how to malloc and create the mydev_ivar structure, even if the interfaces it is implementing provide helper functions, like I've outlined above.

Warner



> - Arnaud
>
>> Warner
>>
>>> - Arnaud
>>>
>>>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>>>> enum pci_device_ivars {
>>>> PCI_IVAR_SUBVENDOR,
>>>> PCI_IVAR_SUBDEVICE,
>>>> PCI_IVAR_VENDOR,
>>>> ....
>>>> };
>>>>
>>>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>>>
>>>> enum ivar_namespace {
>>>> IVAR_PCI = 1,
>>>> IVAR_PCCARD,
>>>> IVAR_USB,
>>>> etc
>>>> };
>>>> #define IVAR_SHIFT 16
>>>>
>>>> and the above could be changed to:
>>>>
>>>> enum pci_device_ivars {
>>>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>>>> PCI_IVAR_SUBDEVICE,
>>>> PCI_IVAR_VENDOR,
>>>> ....
>>>> };
>>>>
>>>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>>>
>>>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>>>
>>>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>>>> information to a child. I can not simply implement a new METHOD to get
>>>>> that ivar as the device implements multiple time the same function
>>>>> (actually, up to 4 time for one, 3 for the other, with possible
>>>>> crossovers...), each one physically distinct. Each child is being tied
>>>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>>>> interfaces right after having been *created*, which cannot be done
>>>>> later on. Of course, it is out-of-question to have crossover in the
>>>>> interfaces definitions.
>>>>
>>>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>>>
>>>>> The best way I could achieve this currently is to pass the child's
>>>>> device to its parent, and do a lookup based on that pointer to get
>>>>> information I need, but erk....
>>>>
>>>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>>>
>>>> Warner
>>

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

Hi folks,

Ok, yet another Newbus' limitation. Assuming a device exports more
than one interface, and one of its child has need to use more than one
interface, each interfaces cannot register, concurrently, its own
ivar. While I try to always have a single child per
interface/resource, I need to keep some compatibility with the old way
of doing thing (POLA wrt. drivers I cannot/will not convert and
userland). So, it would have been nice if ivar had been per-interface,
not global and unique to one device.

Unless I am mistaken, ivar are the only way for a parent can transmit
information to a child. I can not simply implement a new METHOD to get
that ivar as the device implements multiple time the same function
(actually, up to 4 time for one, 3 for the other, with possible
crossovers...), each one physically distinct. Each child is being tied
to a pair. Thus, I need to pass each child discriminator(s) for each
interfaces right after having been *created*, which cannot be done
later on. Of course, it is out-of-question to have crossover in the
interfaces definitions.

The best way I could achieve this currently is to pass the child's
device to its parent, and do a lookup based on that pointer to get
information I need, but erk....

my 1c,
- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
> Ok, yet another Newbus' limitation. Assuming a device exports more
> than one interface, and one of its child has need to use more than one
> interface, each interfaces cannot register, concurrently, its own
> ivar. While I try to always have a single child per
> interface/resource, I need to keep some compatibility with the old way
> of doing thing (POLA wrt. drivers I cannot/will not convert and
> userland). So, it would have been nice if ivar had been per-interface,
> not global and unique to one device.

There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.

So I'm not sure I understand what you are saying here.

The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
....
};

We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:

enum ivar_namespace {
IVAR_PCI = 1,
IVAR_PCCARD,
IVAR_USB,
etc
};
#define IVAR_SHIFT 16

and the above could be changed to:

enum pci_device_ivars {
PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
....
};

and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.

but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.

> Unless I am mistaken, ivar are the only way for a parent can transmit
> information to a child. I can not simply implement a new METHOD to get
> that ivar as the device implements multiple time the same function
> (actually, up to 4 time for one, 3 for the other, with possible
> crossovers...), each one physically distinct. Each child is being tied
> to a pair. Thus, I need to pass each child discriminator(s) for each
> interfaces right after having been *created*, which cannot be done
> later on. Of course, it is out-of-question to have crossover in the
> interfaces definitions.

ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.

> The best way I could achieve this currently is to pass the child's
> device to its parent, and do a lookup based on that pointer to get
> information I need, but erk....

That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.

Warner_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>> Ok, yet another Newbus' limitation. Assuming a device exports more
>> than one interface, and one of its child has need to use more than one
>> interface, each interfaces cannot register, concurrently, its own
>> ivar. While I try to always have a single child per
>> interface/resource, I need to keep some compatibility with the old way
>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>> userland). So, it would have been nice if ivar had been per-interface,
>> not global and unique to one device.
>
> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>
> So I'm not sure I understand what you are saying here.
>
dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
use both interfaces. There is no generic way for dev0 to export
independent ivars for both interface. For now, I restricted the
function of the second interface not to need ivar, but that's kind of
hackish.

- Arnaud

> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>
> enum ivar_namespace {
> IVAR_PCI = 1,
> IVAR_PCCARD,
> IVAR_USB,
> etc
> };
> #define IVAR_SHIFT 16
>
> and the above could be changed to:
>
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>
> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>
>> Unless I am mistaken, ivar are the only way for a parent can transmit
>> information to a child. I can not simply implement a new METHOD to get
>> that ivar as the device implements multiple time the same function
>> (actually, up to 4 time for one, 3 for the other, with possible
>> crossovers...), each one physically distinct. Each child is being tied
>> to a pair. Thus, I need to pass each child discriminator(s) for each
>> interfaces right after having been *created*, which cannot be done
>> later on. Of course, it is out-of-question to have crossover in the
>> interfaces definitions.
>
> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>
>> The best way I could achieve this currently is to pass the child's
>> device to its parent, and do a lookup based on that pointer to get
>> information I need, but erk....
>
> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>
> Warner
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:

> Hi,
>
> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>> than one interface, and one of its child has need to use more than one
>>> interface, each interfaces cannot register, concurrently, its own
>>> ivar. While I try to always have a single child per
>>> interface/resource, I need to keep some compatibility with the old way
>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>> userland). So, it would have been nice if ivar had been per-interface,
>>> not global and unique to one device.
>>
>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>
>> So I'm not sure I understand what you are saying here.
>>
> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
> use both interfaces. There is no generic way for dev0 to export
> independent ivars for both interface. For now, I restricted the
> function of the second interface not to need ivar, but that's kind of
> hackish.

Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.

Warner

> - Arnaud
>
>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>
>> enum ivar_namespace {
>> IVAR_PCI = 1,
>> IVAR_PCCARD,
>> IVAR_USB,
>> etc
>> };
>> #define IVAR_SHIFT 16
>>
>> and the above could be changed to:
>>
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>
>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>
>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>> information to a child. I can not simply implement a new METHOD to get
>>> that ivar as the device implements multiple time the same function
>>> (actually, up to 4 time for one, 3 for the other, with possible
>>> crossovers...), each one physically distinct. Each child is being tied
>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>> interfaces right after having been *created*, which cannot be done
>>> later on. Of course, it is out-of-question to have crossover in the
>>> interfaces definitions.
>>
>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>
>>> The best way I could achieve this currently is to pass the child's
>>> device to its parent, and do a lookup based on that pointer to get
>>> information I need, but erk....
>>
>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>
>> Warner

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>
>> Hi,
>>
>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>
>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>> than one interface, and one of its child has need to use more than one
>>>> interface, each interfaces cannot register, concurrently, its own
>>>> ivar. While I try to always have a single child per
>>>> interface/resource, I need to keep some compatibility with the old way
>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>> not global and unique to one device.
>>>
>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>
>>> So I'm not sure I understand what you are saying here.
>>>
>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>> use both interfaces. There is no generic way for dev0 to export
>> independent ivars for both interface. For now, I restricted the
>> function of the second interface not to need ivar, but that's kind of
>> hackish.
>
> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>
I think we should not be talking about the same API here. I have no
idea what you mean by "the key to value translation", nor "Ivar
numbers". What I refer to is that device_set_ivars() /
device_get_ivars() acts on a single instance variables from `struct
device': `ivars'. In that case, I do not really see how to set that
specific field to two distinct values for each interfaces.

- Arnaud

> Warner
>
>> - Arnaud
>>
>>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>>> enum pci_device_ivars {
>>> PCI_IVAR_SUBVENDOR,
>>> PCI_IVAR_SUBDEVICE,
>>> PCI_IVAR_VENDOR,
>>> ....
>>> };
>>>
>>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>>
>>> enum ivar_namespace {
>>> IVAR_PCI = 1,
>>> IVAR_PCCARD,
>>> IVAR_USB,
>>> etc
>>> };
>>> #define IVAR_SHIFT 16
>>>
>>> and the above could be changed to:
>>>
>>> enum pci_device_ivars {
>>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>>> PCI_IVAR_SUBDEVICE,
>>> PCI_IVAR_VENDOR,
>>> ....
>>> };
>>>
>>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>>
>>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>>
>>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>>> information to a child. I can not simply implement a new METHOD to get
>>>> that ivar as the device implements multiple time the same function
>>>> (actually, up to 4 time for one, 3 for the other, with possible
>>>> crossovers...), each one physically distinct. Each child is being tied
>>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>>> interfaces right after having been *created*, which cannot be done
>>>> later on. Of course, it is out-of-question to have crossover in the
>>>> interfaces definitions.
>>>
>>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>>
>>>> The best way I could achieve this currently is to pass the child's
>>>> device to its parent, and do a lookup based on that pointer to get
>>>> information I need, but erk....
>>>
>>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>>
>>> Warner
>
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>> Ok, yet another Newbus' limitation. Assuming a device exports more
>> than one interface, and one of its child has need to use more than one
>> interface, each interfaces cannot register, concurrently, its own
>> ivar. While I try to always have a single child per
>> interface/resource, I need to keep some compatibility with the old way
>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>> userland). So, it would have been nice if ivar had been per-interface,
>> not global and unique to one device.
>
> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>
> So I'm not sure I understand what you are saying here.
>
> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>
> enum ivar_namespace {
> IVAR_PCI = 1,
> IVAR_PCCARD,
> IVAR_USB,
> etc
> };
> #define IVAR_SHIFT 16
>
> and the above could be changed to:
>
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>
> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>
ok, I think I got it now. You and I are exactly saying the same thing,
just in different terms; there is no way to currently specify multiple
independent (/overlapping) ivars in a child...

- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote:

> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>>
>>> Hi,
>>>
>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>>
>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>>> than one interface, and one of its child has need to use more than one
>>>>> interface, each interfaces cannot register, concurrently, its own
>>>>> ivar. While I try to always have a single child per
>>>>> interface/resource, I need to keep some compatibility with the old way
>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>>> not global and unique to one device.
>>>>
>>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>>
>>>> So I'm not sure I understand what you are saying here.
>>>>
>>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>>> use both interfaces. There is no generic way for dev0 to export
>>> independent ivars for both interface. For now, I restricted the
>>> function of the second interface not to need ivar, but that's kind of
>>> hackish.
>>
>> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>>
> I think we should not be talking about the same API here. I have no
> idea what you mean by "the key to value translation", nor "Ivar
> numbers". What I refer to is that device_set_ivars() /
> device_get_ivars() acts on a single instance variables from `struct
> device': `ivars'. In that case, I do not really see how to set that
> specific field to two distinct values for each interfaces.

We are talking about the ivar interface. You are just misunderstanding how it is used.

Let us say that dev0 wants to implement interface A and B. The interface it implements is the device_read _ivar method. That method looks like:

int pci_read_ivar(device_t dev, device_t child, int which, uintptr_t *result)
{
struct pci_ivar *iv = device_get_ivar(child);

switch (which) {
case PCI_IVAR_SUBVENDOR:
*result = iv->subvendor;
break;
...
default:
return EINVAL;
}
return 0;
}

So, if you wanted to implement interface A and interface B, you would have to support reading and writing A_IVAR_* and B_IVAR_*. The above routine would look like:

struct mydev_ivar {
int a_1;
int a_2;
int b_1;
int b_2;
};

int mydev_read_ivar(device_t dev, device child, int which, uintpr_t *result)
{
struct mydev_ivar *iv = device_get_ivar(child);

switch (which) {
case A_IVAR_1:
*result = iv->a_1;
break;
case A_IVAR_2:
*result = iv->a_2;
break;
case B_IVAR_1:
*result = iv->b_1;
break;
case B_IVAR_2:
*result = iv->b_2;
break;
default:
return EINVAL;
}
return 0;
}

and similar for the write routine. Now, there are some busses that provide convenience structures and functions for dealing with the ivars. In that case, you'd be able to use the wrapper structures and routines like so:

struct mdev_ivar {
struct a_ivar a;
struct b_ivar b;
};

int mydev_read_ivar(device_t dev, device child, int which, uintpr_t *result)
{
struct mydev_ivar *iv = device_get_ivar(child);

switch (which) {
case A_IVAR_1:
case A_IVAR_2:
return a_helper_read_ivar(&iv->a, which, result);
case B_IVAR_1:
case B_IVAR_2:
return b_helper_read_ivar(&iv->b, which, result);
default:
return EINVAL;
}
return 0;
}

Both of these work only if the A_IVAR values are disjoint from the B_IVAR values. Your mydev device is the one that sets the ivar on dev1, in your example, so it would know how to malloc and create the mydev_ivar structure, even if the interfaces it is implementing provide helper functions, like I've outlined above.

Warner



> - Arnaud
>
>> Warner
>>
>>> - Arnaud
>>>
>>>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>>>> enum pci_device_ivars {
>>>> PCI_IVAR_SUBVENDOR,
>>>> PCI_IVAR_SUBDEVICE,
>>>> PCI_IVAR_VENDOR,
>>>> ....
>>>> };
>>>>
>>>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>>>
>>>> enum ivar_namespace {
>>>> IVAR_PCI = 1,
>>>> IVAR_PCCARD,
>>>> IVAR_USB,
>>>> etc
>>>> };
>>>> #define IVAR_SHIFT 16
>>>>
>>>> and the above could be changed to:
>>>>
>>>> enum pci_device_ivars {
>>>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>>>> PCI_IVAR_SUBDEVICE,
>>>> PCI_IVAR_VENDOR,
>>>> ....
>>>> };
>>>>
>>>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>>>
>>>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>>>
>>>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>>>> information to a child. I can not simply implement a new METHOD to get
>>>>> that ivar as the device implements multiple time the same function
>>>>> (actually, up to 4 time for one, 3 for the other, with possible
>>>>> crossovers...), each one physically distinct. Each child is being tied
>>>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>>>> interfaces right after having been *created*, which cannot be done
>>>>> later on. Of course, it is out-of-question to have crossover in the
>>>>> interfaces definitions.
>>>>
>>>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>>>
>>>>> The best way I could achieve this currently is to pass the child's
>>>>> device to its parent, and do a lookup based on that pointer to get
>>>>> information I need, but erk....
>>>>
>>>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>>>
>>>> Warner
>>

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 9:59 PM, Arnaud Lacombe wrote:

> Hi,
>
> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>> than one interface, and one of its child has need to use more than one
>>> interface, each interfaces cannot register, concurrently, its own
>>> ivar. While I try to always have a single child per
>>> interface/resource, I need to keep some compatibility with the old way
>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>> userland). So, it would have been nice if ivar had been per-interface,
>>> not global and unique to one device.
>>
>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>
>> So I'm not sure I understand what you are saying here.
>>
>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>
>> enum ivar_namespace {
>> IVAR_PCI = 1,
>> IVAR_PCCARD,
>> IVAR_USB,
>> etc
>> };
>> #define IVAR_SHIFT 16
>>
>> and the above could be changed to:
>>
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>
>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>
> ok, I think I got it now. You and I are exactly saying the same thing,
> just in different terms; there is no way to currently specify multiple
> independent (/overlapping) ivars in a child...

There's no way to support overlapping IVAR keys, yes. However, if you are designing the ivars for multiple inheritance, then you'll need to make them non-overlapping. Thankfully, this is trivial to do.

Warner

Warner_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

Hi folks,

Ok, yet another Newbus' limitation. Assuming a device exports more
than one interface, and one of its child has need to use more than one
interface, each interfaces cannot register, concurrently, its own
ivar. While I try to always have a single child per
interface/resource, I need to keep some compatibility with the old way
of doing thing (POLA wrt. drivers I cannot/will not convert and
userland). So, it would have been nice if ivar had been per-interface,
not global and unique to one device.

Unless I am mistaken, ivar are the only way for a parent can transmit
information to a child. I can not simply implement a new METHOD to get
that ivar as the device implements multiple time the same function
(actually, up to 4 time for one, 3 for the other, with possible
crossovers...), each one physically distinct. Each child is being tied
to a pair. Thus, I need to pass each child discriminator(s) for each
interfaces right after having been *created*, which cannot be done
later on. Of course, it is out-of-question to have crossover in the
interfaces definitions.

The best way I could achieve this currently is to pass the child's
device to its parent, and do a lookup based on that pointer to get
information I need, but erk....

my 1c,
- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
> Ok, yet another Newbus' limitation. Assuming a device exports more
> than one interface, and one of its child has need to use more than one
> interface, each interfaces cannot register, concurrently, its own
> ivar. While I try to always have a single child per
> interface/resource, I need to keep some compatibility with the old way
> of doing thing (POLA wrt. drivers I cannot/will not convert and
> userland). So, it would have been nice if ivar had been per-interface,
> not global and unique to one device.

There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.

So I'm not sure I understand what you are saying here.

The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
....
};

We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:

enum ivar_namespace {
IVAR_PCI = 1,
IVAR_PCCARD,
IVAR_USB,
etc
};
#define IVAR_SHIFT 16

and the above could be changed to:

enum pci_device_ivars {
PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
....
};

and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.

but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.

> Unless I am mistaken, ivar are the only way for a parent can transmit
> information to a child. I can not simply implement a new METHOD to get
> that ivar as the device implements multiple time the same function
> (actually, up to 4 time for one, 3 for the other, with possible
> crossovers...), each one physically distinct. Each child is being tied
> to a pair. Thus, I need to pass each child discriminator(s) for each
> interfaces right after having been *created*, which cannot be done
> later on. Of course, it is out-of-question to have crossover in the
> interfaces definitions.

ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.

> The best way I could achieve this currently is to pass the child's
> device to its parent, and do a lookup based on that pointer to get
> information I need, but erk....

That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.

Warner_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>> Ok, yet another Newbus' limitation. Assuming a device exports more
>> than one interface, and one of its child has need to use more than one
>> interface, each interfaces cannot register, concurrently, its own
>> ivar. While I try to always have a single child per
>> interface/resource, I need to keep some compatibility with the old way
>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>> userland). So, it would have been nice if ivar had been per-interface,
>> not global and unique to one device.
>
> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>
> So I'm not sure I understand what you are saying here.
>
dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
use both interfaces. There is no generic way for dev0 to export
independent ivars for both interface. For now, I restricted the
function of the second interface not to need ivar, but that's kind of
hackish.

- Arnaud

> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>
> enum ivar_namespace {
> IVAR_PCI = 1,
> IVAR_PCCARD,
> IVAR_USB,
> etc
> };
> #define IVAR_SHIFT 16
>
> and the above could be changed to:
>
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>
> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>
>> Unless I am mistaken, ivar are the only way for a parent can transmit
>> information to a child. I can not simply implement a new METHOD to get
>> that ivar as the device implements multiple time the same function
>> (actually, up to 4 time for one, 3 for the other, with possible
>> crossovers...), each one physically distinct. Each child is being tied
>> to a pair. Thus, I need to pass each child discriminator(s) for each
>> interfaces right after having been *created*, which cannot be done
>> later on. Of course, it is out-of-question to have crossover in the
>> interfaces definitions.
>
> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>
>> The best way I could achieve this currently is to pass the child's
>> device to its parent, and do a lookup based on that pointer to get
>> information I need, but erk....
>
> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>
> Warner
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:

> Hi,
>
> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>> than one interface, and one of its child has need to use more than one
>>> interface, each interfaces cannot register, concurrently, its own
>>> ivar. While I try to always have a single child per
>>> interface/resource, I need to keep some compatibility with the old way
>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>> userland). So, it would have been nice if ivar had been per-interface,
>>> not global and unique to one device.
>>
>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>
>> So I'm not sure I understand what you are saying here.
>>
> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
> use both interfaces. There is no generic way for dev0 to export
> independent ivars for both interface. For now, I restricted the
> function of the second interface not to need ivar, but that's kind of
> hackish.

Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.

Warner

> - Arnaud
>
>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>
>> enum ivar_namespace {
>> IVAR_PCI = 1,
>> IVAR_PCCARD,
>> IVAR_USB,
>> etc
>> };
>> #define IVAR_SHIFT 16
>>
>> and the above could be changed to:
>>
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>
>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>
>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>> information to a child. I can not simply implement a new METHOD to get
>>> that ivar as the device implements multiple time the same function
>>> (actually, up to 4 time for one, 3 for the other, with possible
>>> crossovers...), each one physically distinct. Each child is being tied
>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>> interfaces right after having been *created*, which cannot be done
>>> later on. Of course, it is out-of-question to have crossover in the
>>> interfaces definitions.
>>
>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>
>>> The best way I could achieve this currently is to pass the child's
>>> device to its parent, and do a lookup based on that pointer to get
>>> information I need, but erk....
>>
>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>
>> Warner

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>
>> Hi,
>>
>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>
>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>> than one interface, and one of its child has need to use more than one
>>>> interface, each interfaces cannot register, concurrently, its own
>>>> ivar. While I try to always have a single child per
>>>> interface/resource, I need to keep some compatibility with the old way
>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>> not global and unique to one device.
>>>
>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>
>>> So I'm not sure I understand what you are saying here.
>>>
>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>> use both interfaces. There is no generic way for dev0 to export
>> independent ivars for both interface. For now, I restricted the
>> function of the second interface not to need ivar, but that's kind of
>> hackish.
>
> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>
I think we should not be talking about the same API here. I have no
idea what you mean by "the key to value translation", nor "Ivar
numbers". What I refer to is that device_set_ivars() /
device_get_ivars() acts on a single instance variables from `struct
device': `ivars'. In that case, I do not really see how to set that
specific field to two distinct values for each interfaces.

- Arnaud

> Warner
>
>> - Arnaud
>>
>>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>>> enum pci_device_ivars {
>>> PCI_IVAR_SUBVENDOR,
>>> PCI_IVAR_SUBDEVICE,
>>> PCI_IVAR_VENDOR,
>>> ....
>>> };
>>>
>>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>>
>>> enum ivar_namespace {
>>> IVAR_PCI = 1,
>>> IVAR_PCCARD,
>>> IVAR_USB,
>>> etc
>>> };
>>> #define IVAR_SHIFT 16
>>>
>>> and the above could be changed to:
>>>
>>> enum pci_device_ivars {
>>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>>> PCI_IVAR_SUBDEVICE,
>>> PCI_IVAR_VENDOR,
>>> ....
>>> };
>>>
>>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>>
>>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>>
>>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>>> information to a child. I can not simply implement a new METHOD to get
>>>> that ivar as the device implements multiple time the same function
>>>> (actually, up to 4 time for one, 3 for the other, with possible
>>>> crossovers...), each one physically distinct. Each child is being tied
>>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>>> interfaces right after having been *created*, which cannot be done
>>>> later on. Of course, it is out-of-question to have crossover in the
>>>> interfaces definitions.
>>>
>>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>>
>>>> The best way I could achieve this currently is to pass the child's
>>>> device to its parent, and do a lookup based on that pointer to get
>>>> information I need, but erk....
>>>
>>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>>
>>> Warner
>
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>> Ok, yet another Newbus' limitation. Assuming a device exports more
>> than one interface, and one of its child has need to use more than one
>> interface, each interfaces cannot register, concurrently, its own
>> ivar. While I try to always have a single child per
>> interface/resource, I need to keep some compatibility with the old way
>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>> userland). So, it would have been nice if ivar had been per-interface,
>> not global and unique to one device.
>
> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>
> So I'm not sure I understand what you are saying here.
>
> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>
> enum ivar_namespace {
> IVAR_PCI = 1,
> IVAR_PCCARD,
> IVAR_USB,
> etc
> };
> #define IVAR_SHIFT 16
>
> and the above could be changed to:
>
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>
> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>
ok, I think I got it now. You and I are exactly saying the same thing,
just in different terms; there is no way to currently specify multiple
independent (/overlapping) ivars in a child...

- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote:

> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>>
>>> Hi,
>>>
>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>>
>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>>> than one interface, and one of its child has need to use more than one
>>>>> interface, each interfaces cannot register, concurrently, its own
>>>>> ivar. While I try to always have a single child per
>>>>> interface/resource, I need to keep some compatibility with the old way
>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>>> not global and unique to one device.
>>>>
>>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>>
>>>> So I'm not sure I understand what you are saying here.
>>>>
>>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>>> use both interfaces. There is no generic way for dev0 to export
>>> independent ivars for both interface. For now, I restricted the
>>> function of the second interface not to need ivar, but that's kind of
>>> hackish.
>>
>> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>>
> I think we should not be talking about the same API here. I have no
> idea what you mean by "the key to value translation", nor "Ivar
> numbers". What I refer to is that device_set_ivars() /
> device_get_ivars() acts on a single instance variables from `struct
> device': `ivars'. In that case, I do not really see how to set that
> specific field to two distinct values for each interfaces.

We are talking about the ivar interface. You are just misunderstanding how it is used.

Let us say that dev0 wants to implement interface A and B. The interface it implements is the device_read _ivar method. That method looks like:

int pci_read_ivar(device_t dev, device_t child, int which, uintptr_t *result)
{
struct pci_ivar *iv = device_get_ivar(child);

switch (which) {
case PCI_IVAR_SUBVENDOR:
*result = iv->subvendor;
break;
...
default:
return EINVAL;
}
return 0;
}

So, if you wanted to implement interface A and interface B, you would have to support reading and writing A_IVAR_* and B_IVAR_*. The above routine would look like:

struct mydev_ivar {
int a_1;
int a_2;
int b_1;
int b_2;
};

int mydev_read_ivar(device_t dev, device child, int which, uintpr_t *result)
{
struct mydev_ivar *iv = device_get_ivar(child);

switch (which) {
case A_IVAR_1:
*result = iv->a_1;
break;
case A_IVAR_2:
*result = iv->a_2;
break;
case B_IVAR_1:
*result = iv->b_1;
break;
case B_IVAR_2:
*result = iv->b_2;
break;
default:
return EINVAL;
}
return 0;
}

and similar for the write routine. Now, there are some busses that provide convenience structures and functions for dealing with the ivars. In that case, you'd be able to use the wrapper structures and routines like so:

struct mdev_ivar {
struct a_ivar a;
struct b_ivar b;
};

int mydev_read_ivar(device_t dev, device child, int which, uintpr_t *result)
{
struct mydev_ivar *iv = device_get_ivar(child);

switch (which) {
case A_IVAR_1:
case A_IVAR_2:
return a_helper_read_ivar(&iv->a, which, result);
case B_IVAR_1:
case B_IVAR_2:
return b_helper_read_ivar(&iv->b, which, result);
default:
return EINVAL;
}
return 0;
}

Both of these work only if the A_IVAR values are disjoint from the B_IVAR values. Your mydev device is the one that sets the ivar on dev1, in your example, so it would know how to malloc and create the mydev_ivar structure, even if the interfaces it is implementing provide helper functions, like I've outlined above.

Warner



> - Arnaud
>
>> Warner
>>
>>> - Arnaud
>>>
>>>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>>>> enum pci_device_ivars {
>>>> PCI_IVAR_SUBVENDOR,
>>>> PCI_IVAR_SUBDEVICE,
>>>> PCI_IVAR_VENDOR,
>>>> ....
>>>> };
>>>>
>>>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>>>
>>>> enum ivar_namespace {
>>>> IVAR_PCI = 1,
>>>> IVAR_PCCARD,
>>>> IVAR_USB,
>>>> etc
>>>> };
>>>> #define IVAR_SHIFT 16
>>>>
>>>> and the above could be changed to:
>>>>
>>>> enum pci_device_ivars {
>>>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>>>> PCI_IVAR_SUBDEVICE,
>>>> PCI_IVAR_VENDOR,
>>>> ....
>>>> };
>>>>
>>>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>>>
>>>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>>>
>>>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>>>> information to a child. I can not simply implement a new METHOD to get
>>>>> that ivar as the device implements multiple time the same function
>>>>> (actually, up to 4 time for one, 3 for the other, with possible
>>>>> crossovers...), each one physically distinct. Each child is being tied
>>>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>>>> interfaces right after having been *created*, which cannot be done
>>>>> later on. Of course, it is out-of-question to have crossover in the
>>>>> interfaces definitions.
>>>>
>>>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>>>
>>>>> The best way I could achieve this currently is to pass the child's
>>>>> device to its parent, and do a lookup based on that pointer to get
>>>>> information I need, but erk....
>>>>
>>>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>>>
>>>> Warner
>>

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 9:59 PM, Arnaud Lacombe wrote:

> Hi,
>
> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>> than one interface, and one of its child has need to use more than one
>>> interface, each interfaces cannot register, concurrently, its own
>>> ivar. While I try to always have a single child per
>>> interface/resource, I need to keep some compatibility with the old way
>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>> userland). So, it would have been nice if ivar had been per-interface,
>>> not global and unique to one device.
>>
>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>
>> So I'm not sure I understand what you are saying here.
>>
>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>
>> enum ivar_namespace {
>> IVAR_PCI = 1,
>> IVAR_PCCARD,
>> IVAR_USB,
>> etc
>> };
>> #define IVAR_SHIFT 16
>>
>> and the above could be changed to:
>>
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>
>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>
> ok, I think I got it now. You and I are exactly saying the same thing,
> just in different terms; there is no way to currently specify multiple
> independent (/overlapping) ivars in a child...

There's no way to support overlapping IVAR keys, yes. However, if you are designing the ivars for multiple inheritance, then you'll need to make them non-overlapping. Thankfully, this is trivial to do.

Warner

Warner_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Mon, Jul 9, 2012 at 12:37 AM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote:
>
>> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>>>
>>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>>>
>>>> Hi,
>>>>
>>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>>>
>>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>>>> than one interface, and one of its child has need to use more than one
>>>>>> interface, each interfaces cannot register, concurrently, its own
>>>>>> ivar. While I try to always have a single child per
>>>>>> interface/resource, I need to keep some compatibility with the old way
>>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>>>> not global and unique to one device.
>>>>>
>>>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>>>
>>>>> So I'm not sure I understand what you are saying here.
>>>>>
>>>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>>>> use both interfaces. There is no generic way for dev0 to export
>>>> independent ivars for both interface. For now, I restricted the
>>>> function of the second interface not to need ivar, but that's kind of
>>>> hackish.
>>>
>>> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>>>
>> I think we should not be talking about the same API here. I have no
>> idea what you mean by "the key to value translation", nor "Ivar
>> numbers". What I refer to is that device_set_ivars() /
>> device_get_ivars() acts on a single instance variables from `struct
>> device': `ivars'. In that case, I do not really see how to set that
>> specific field to two distinct values for each interfaces.
>
> We are talking about the ivar interface. You are just misunderstanding how it is used.
>
yes I indeed did... silly, silly me :-)

- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

Hi folks,

Ok, yet another Newbus' limitation. Assuming a device exports more
than one interface, and one of its child has need to use more than one
interface, each interfaces cannot register, concurrently, its own
ivar. While I try to always have a single child per
interface/resource, I need to keep some compatibility with the old way
of doing thing (POLA wrt. drivers I cannot/will not convert and
userland). So, it would have been nice if ivar had been per-interface,
not global and unique to one device.

Unless I am mistaken, ivar are the only way for a parent can transmit
information to a child. I can not simply implement a new METHOD to get
that ivar as the device implements multiple time the same function
(actually, up to 4 time for one, 3 for the other, with possible
crossovers...), each one physically distinct. Each child is being tied
to a pair. Thus, I need to pass each child discriminator(s) for each
interfaces right after having been *created*, which cannot be done
later on. Of course, it is out-of-question to have crossover in the
interfaces definitions.

The best way I could achieve this currently is to pass the child's
device to its parent, and do a lookup based on that pointer to get
information I need, but erk....

my 1c,
- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
> Ok, yet another Newbus' limitation. Assuming a device exports more
> than one interface, and one of its child has need to use more than one
> interface, each interfaces cannot register, concurrently, its own
> ivar. While I try to always have a single child per
> interface/resource, I need to keep some compatibility with the old way
> of doing thing (POLA wrt. drivers I cannot/will not convert and
> userland). So, it would have been nice if ivar had been per-interface,
> not global and unique to one device.

There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.

So I'm not sure I understand what you are saying here.

The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
....
};

We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:

enum ivar_namespace {
IVAR_PCI = 1,
IVAR_PCCARD,
IVAR_USB,
etc
};
#define IVAR_SHIFT 16

and the above could be changed to:

enum pci_device_ivars {
PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
....
};

and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.

but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.

> Unless I am mistaken, ivar are the only way for a parent can transmit
> information to a child. I can not simply implement a new METHOD to get
> that ivar as the device implements multiple time the same function
> (actually, up to 4 time for one, 3 for the other, with possible
> crossovers...), each one physically distinct. Each child is being tied
> to a pair. Thus, I need to pass each child discriminator(s) for each
> interfaces right after having been *created*, which cannot be done
> later on. Of course, it is out-of-question to have crossover in the
> interfaces definitions.

ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.

> The best way I could achieve this currently is to pass the child's
> device to its parent, and do a lookup based on that pointer to get
> information I need, but erk....

That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.

Warner_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>> Ok, yet another Newbus' limitation. Assuming a device exports more
>> than one interface, and one of its child has need to use more than one
>> interface, each interfaces cannot register, concurrently, its own
>> ivar. While I try to always have a single child per
>> interface/resource, I need to keep some compatibility with the old way
>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>> userland). So, it would have been nice if ivar had been per-interface,
>> not global and unique to one device.
>
> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>
> So I'm not sure I understand what you are saying here.
>
dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
use both interfaces. There is no generic way for dev0 to export
independent ivars for both interface. For now, I restricted the
function of the second interface not to need ivar, but that's kind of
hackish.

- Arnaud

> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>
> enum ivar_namespace {
> IVAR_PCI = 1,
> IVAR_PCCARD,
> IVAR_USB,
> etc
> };
> #define IVAR_SHIFT 16
>
> and the above could be changed to:
>
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>
> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>
>> Unless I am mistaken, ivar are the only way for a parent can transmit
>> information to a child. I can not simply implement a new METHOD to get
>> that ivar as the device implements multiple time the same function
>> (actually, up to 4 time for one, 3 for the other, with possible
>> crossovers...), each one physically distinct. Each child is being tied
>> to a pair. Thus, I need to pass each child discriminator(s) for each
>> interfaces right after having been *created*, which cannot be done
>> later on. Of course, it is out-of-question to have crossover in the
>> interfaces definitions.
>
> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>
>> The best way I could achieve this currently is to pass the child's
>> device to its parent, and do a lookup based on that pointer to get
>> information I need, but erk....
>
> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>
> Warner
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:

> Hi,
>
> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>> than one interface, and one of its child has need to use more than one
>>> interface, each interfaces cannot register, concurrently, its own
>>> ivar. While I try to always have a single child per
>>> interface/resource, I need to keep some compatibility with the old way
>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>> userland). So, it would have been nice if ivar had been per-interface,
>>> not global and unique to one device.
>>
>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>
>> So I'm not sure I understand what you are saying here.
>>
> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
> use both interfaces. There is no generic way for dev0 to export
> independent ivars for both interface. For now, I restricted the
> function of the second interface not to need ivar, but that's kind of
> hackish.

Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.

Warner

> - Arnaud
>
>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>
>> enum ivar_namespace {
>> IVAR_PCI = 1,
>> IVAR_PCCARD,
>> IVAR_USB,
>> etc
>> };
>> #define IVAR_SHIFT 16
>>
>> and the above could be changed to:
>>
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>
>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>
>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>> information to a child. I can not simply implement a new METHOD to get
>>> that ivar as the device implements multiple time the same function
>>> (actually, up to 4 time for one, 3 for the other, with possible
>>> crossovers...), each one physically distinct. Each child is being tied
>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>> interfaces right after having been *created*, which cannot be done
>>> later on. Of course, it is out-of-question to have crossover in the
>>> interfaces definitions.
>>
>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>
>>> The best way I could achieve this currently is to pass the child's
>>> device to its parent, and do a lookup based on that pointer to get
>>> information I need, but erk....
>>
>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>
>> Warner

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>
>> Hi,
>>
>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>
>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>> than one interface, and one of its child has need to use more than one
>>>> interface, each interfaces cannot register, concurrently, its own
>>>> ivar. While I try to always have a single child per
>>>> interface/resource, I need to keep some compatibility with the old way
>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>> not global and unique to one device.
>>>
>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>
>>> So I'm not sure I understand what you are saying here.
>>>
>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>> use both interfaces. There is no generic way for dev0 to export
>> independent ivars for both interface. For now, I restricted the
>> function of the second interface not to need ivar, but that's kind of
>> hackish.
>
> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>
I think we should not be talking about the same API here. I have no
idea what you mean by "the key to value translation", nor "Ivar
numbers". What I refer to is that device_set_ivars() /
device_get_ivars() acts on a single instance variables from `struct
device': `ivars'. In that case, I do not really see how to set that
specific field to two distinct values for each interfaces.

- Arnaud

> Warner
>
>> - Arnaud
>>
>>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>>> enum pci_device_ivars {
>>> PCI_IVAR_SUBVENDOR,
>>> PCI_IVAR_SUBDEVICE,
>>> PCI_IVAR_VENDOR,
>>> ....
>>> };
>>>
>>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>>
>>> enum ivar_namespace {
>>> IVAR_PCI = 1,
>>> IVAR_PCCARD,
>>> IVAR_USB,
>>> etc
>>> };
>>> #define IVAR_SHIFT 16
>>>
>>> and the above could be changed to:
>>>
>>> enum pci_device_ivars {
>>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>>> PCI_IVAR_SUBDEVICE,
>>> PCI_IVAR_VENDOR,
>>> ....
>>> };
>>>
>>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>>
>>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>>
>>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>>> information to a child. I can not simply implement a new METHOD to get
>>>> that ivar as the device implements multiple time the same function
>>>> (actually, up to 4 time for one, 3 for the other, with possible
>>>> crossovers...), each one physically distinct. Each child is being tied
>>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>>> interfaces right after having been *created*, which cannot be done
>>>> later on. Of course, it is out-of-question to have crossover in the
>>>> interfaces definitions.
>>>
>>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>>
>>>> The best way I could achieve this currently is to pass the child's
>>>> device to its parent, and do a lookup based on that pointer to get
>>>> information I need, but erk....
>>>
>>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>>
>>> Warner
>
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>> Ok, yet another Newbus' limitation. Assuming a device exports more
>> than one interface, and one of its child has need to use more than one
>> interface, each interfaces cannot register, concurrently, its own
>> ivar. While I try to always have a single child per
>> interface/resource, I need to keep some compatibility with the old way
>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>> userland). So, it would have been nice if ivar had been per-interface,
>> not global and unique to one device.
>
> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>
> So I'm not sure I understand what you are saying here.
>
> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>
> enum ivar_namespace {
> IVAR_PCI = 1,
> IVAR_PCCARD,
> IVAR_USB,
> etc
> };
> #define IVAR_SHIFT 16
>
> and the above could be changed to:
>
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>
> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>
ok, I think I got it now. You and I are exactly saying the same thing,
just in different terms; there is no way to currently specify multiple
independent (/overlapping) ivars in a child...

- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote:

> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>>
>>> Hi,
>>>
>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>>
>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>>> than one interface, and one of its child has need to use more than one
>>>>> interface, each interfaces cannot register, concurrently, its own
>>>>> ivar. While I try to always have a single child per
>>>>> interface/resource, I need to keep some compatibility with the old way
>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>>> not global and unique to one device.
>>>>
>>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>>
>>>> So I'm not sure I understand what you are saying here.
>>>>
>>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>>> use both interfaces. There is no generic way for dev0 to export
>>> independent ivars for both interface. For now, I restricted the
>>> function of the second interface not to need ivar, but that's kind of
>>> hackish.
>>
>> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>>
> I think we should not be talking about the same API here. I have no
> idea what you mean by "the key to value translation", nor "Ivar
> numbers". What I refer to is that device_set_ivars() /
> device_get_ivars() acts on a single instance variables from `struct
> device': `ivars'. In that case, I do not really see how to set that
> specific field to two distinct values for each interfaces.

We are talking about the ivar interface. You are just misunderstanding how it is used.

Let us say that dev0 wants to implement interface A and B. The interface it implements is the device_read _ivar method. That method looks like:

int pci_read_ivar(device_t dev, device_t child, int which, uintptr_t *result)
{
struct pci_ivar *iv = device_get_ivar(child);

switch (which) {
case PCI_IVAR_SUBVENDOR:
*result = iv->subvendor;
break;
...
default:
return EINVAL;
}
return 0;
}

So, if you wanted to implement interface A and interface B, you would have to support reading and writing A_IVAR_* and B_IVAR_*. The above routine would look like:

struct mydev_ivar {
int a_1;
int a_2;
int b_1;
int b_2;
};

int mydev_read_ivar(device_t dev, device child, int which, uintpr_t *result)
{
struct mydev_ivar *iv = device_get_ivar(child);

switch (which) {
case A_IVAR_1:
*result = iv->a_1;
break;
case A_IVAR_2:
*result = iv->a_2;
break;
case B_IVAR_1:
*result = iv->b_1;
break;
case B_IVAR_2:
*result = iv->b_2;
break;
default:
return EINVAL;
}
return 0;
}

and similar for the write routine. Now, there are some busses that provide convenience structures and functions for dealing with the ivars. In that case, you'd be able to use the wrapper structures and routines like so:

struct mdev_ivar {
struct a_ivar a;
struct b_ivar b;
};

int mydev_read_ivar(device_t dev, device child, int which, uintpr_t *result)
{
struct mydev_ivar *iv = device_get_ivar(child);

switch (which) {
case A_IVAR_1:
case A_IVAR_2:
return a_helper_read_ivar(&iv->a, which, result);
case B_IVAR_1:
case B_IVAR_2:
return b_helper_read_ivar(&iv->b, which, result);
default:
return EINVAL;
}
return 0;
}

Both of these work only if the A_IVAR values are disjoint from the B_IVAR values. Your mydev device is the one that sets the ivar on dev1, in your example, so it would know how to malloc and create the mydev_ivar structure, even if the interfaces it is implementing provide helper functions, like I've outlined above.

Warner



> - Arnaud
>
>> Warner
>>
>>> - Arnaud
>>>
>>>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>>>> enum pci_device_ivars {
>>>> PCI_IVAR_SUBVENDOR,
>>>> PCI_IVAR_SUBDEVICE,
>>>> PCI_IVAR_VENDOR,
>>>> ....
>>>> };
>>>>
>>>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>>>
>>>> enum ivar_namespace {
>>>> IVAR_PCI = 1,
>>>> IVAR_PCCARD,
>>>> IVAR_USB,
>>>> etc
>>>> };
>>>> #define IVAR_SHIFT 16
>>>>
>>>> and the above could be changed to:
>>>>
>>>> enum pci_device_ivars {
>>>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>>>> PCI_IVAR_SUBDEVICE,
>>>> PCI_IVAR_VENDOR,
>>>> ....
>>>> };
>>>>
>>>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>>>
>>>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>>>
>>>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>>>> information to a child. I can not simply implement a new METHOD to get
>>>>> that ivar as the device implements multiple time the same function
>>>>> (actually, up to 4 time for one, 3 for the other, with possible
>>>>> crossovers...), each one physically distinct. Each child is being tied
>>>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>>>> interfaces right after having been *created*, which cannot be done
>>>>> later on. Of course, it is out-of-question to have crossover in the
>>>>> interfaces definitions.
>>>>
>>>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>>>
>>>>> The best way I could achieve this currently is to pass the child's
>>>>> device to its parent, and do a lookup based on that pointer to get
>>>>> information I need, but erk....
>>>>
>>>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>>>
>>>> Warner
>>

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 9:59 PM, Arnaud Lacombe wrote:

> Hi,
>
> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>> than one interface, and one of its child has need to use more than one
>>> interface, each interfaces cannot register, concurrently, its own
>>> ivar. While I try to always have a single child per
>>> interface/resource, I need to keep some compatibility with the old way
>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>> userland). So, it would have been nice if ivar had been per-interface,
>>> not global and unique to one device.
>>
>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>
>> So I'm not sure I understand what you are saying here.
>>
>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>
>> enum ivar_namespace {
>> IVAR_PCI = 1,
>> IVAR_PCCARD,
>> IVAR_USB,
>> etc
>> };
>> #define IVAR_SHIFT 16
>>
>> and the above could be changed to:
>>
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>
>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>
> ok, I think I got it now. You and I are exactly saying the same thing,
> just in different terms; there is no way to currently specify multiple
> independent (/overlapping) ivars in a child...

There's no way to support overlapping IVAR keys, yes. However, if you are designing the ivars for multiple inheritance, then you'll need to make them non-overlapping. Thankfully, this is trivial to do.

Warner

Warner_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Mon, Jul 9, 2012 at 12:37 AM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote:
>
>> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>>>
>>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>>>
>>>> Hi,
>>>>
>>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>>>
>>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>>>> than one interface, and one of its child has need to use more than one
>>>>>> interface, each interfaces cannot register, concurrently, its own
>>>>>> ivar. While I try to always have a single child per
>>>>>> interface/resource, I need to keep some compatibility with the old way
>>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>>>> not global and unique to one device.
>>>>>
>>>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>>>
>>>>> So I'm not sure I understand what you are saying here.
>>>>>
>>>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>>>> use both interfaces. There is no generic way for dev0 to export
>>>> independent ivars for both interface. For now, I restricted the
>>>> function of the second interface not to need ivar, but that's kind of
>>>> hackish.
>>>
>>> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>>>
>> I think we should not be talking about the same API here. I have no
>> idea what you mean by "the key to value translation", nor "Ivar
>> numbers". What I refer to is that device_set_ivars() /
>> device_get_ivars() acts on a single instance variables from `struct
>> device': `ivars'. In that case, I do not really see how to set that
>> specific field to two distinct values for each interfaces.
>
> We are talking about the ivar interface. You are just misunderstanding how it is used.
>
yes I indeed did... silly, silly me :-)

- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
On Monday, July 09, 2012 12:39:03 am Warner Losh wrote:
>
> On Jul 8, 2012, at 9:59 PM, Arnaud Lacombe wrote:
>
> > Hi,
> >
> > On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
> >>
> >> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
> >>> Ok, yet another Newbus' limitation. Assuming a device exports more
> >>> than one interface, and one of its child has need to use more than one
> >>> interface, each interfaces cannot register, concurrently, its own
> >>> ivar. While I try to always have a single child per
> >>> interface/resource, I need to keep some compatibility with the old way
> >>> of doing thing (POLA wrt. drivers I cannot/will not convert and
> >>> userland). So, it would have been nice if ivar had been per-interface,
> >>> not global and unique to one device.
> >>
> >> There's one pointer for the ivars. The bus code gets to determine what
the ivar looks like, because the interface is totally private to the bus. So
long as it returns the right thing for any key that's presented, it doesn't
matter quite how things are done.
> >>
> >> So I'm not sure I understand what you are saying here.
> >>
> >> The problem, more basically, is that the ivar keys are not unique.
Currently, there's no bits used in the key to define the values to be non-
overlapping. For example:
> >> enum pci_device_ivars {
> >> PCI_IVAR_SUBVENDOR,
> >> PCI_IVAR_SUBDEVICE,
> >> PCI_IVAR_VENDOR,
> >> ....
> >> };
> >>
> >> We could easily reserve the upper 16-bits of this field to be that key.
This value could then be used to differentiate them. But this wouldn't scale
too well. Given that there's only about a dozen or two in the tree, that's
right at the moment, it wouldn't be hard to do something like:
> >>
> >> enum ivar_namespace {
> >> IVAR_PCI = 1,
> >> IVAR_PCCARD,
> >> IVAR_USB,
> >> etc
> >> };
> >> #define IVAR_SHIFT 16
> >>
> >> and the above could be changed to:
> >>
> >> enum pci_device_ivars {
> >> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
> >> PCI_IVAR_SUBDEVICE,
> >> PCI_IVAR_VENDOR,
> >> ....
> >> };
> >>
> >> and then we'd have an unambiguous key, and the bus could easily implement
multiple interfaces.
> >>
> >> but then again, most of the existing interfaces in the kernel are
mutually exclusive, so you could implement this just for your new interfaces.
> >>
> > ok, I think I got it now. You and I are exactly saying the same thing,
> > just in different terms; there is no way to currently specify multiple
> > independent (/overlapping) ivars in a child...
>
> There's no way to support overlapping IVAR keys, yes. However, if you are
designing the ivars for multiple inheritance, then you'll need to make them
non-overlapping. Thankfully, this is trivial to do.

Also, I think we should do this in general. We already have one example (e.g.
ACPI IVARs start at 100 so that things like the ACPI PCI bus driver can
provide both ACPI and PCI IVARs to child devices). I think we should assign
each bus it's own IVAR range. It would make it easier to determine if a
specific IVAR is event supported. Certainly I think ISA and PCI at a minimum
should be changed to start at, say, 200 and 300.

--
John Baldwin
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

Hi folks,

Ok, yet another Newbus' limitation. Assuming a device exports more
than one interface, and one of its child has need to use more than one
interface, each interfaces cannot register, concurrently, its own
ivar. While I try to always have a single child per
interface/resource, I need to keep some compatibility with the old way
of doing thing (POLA wrt. drivers I cannot/will not convert and
userland). So, it would have been nice if ivar had been per-interface,
not global and unique to one device.

Unless I am mistaken, ivar are the only way for a parent can transmit
information to a child. I can not simply implement a new METHOD to get
that ivar as the device implements multiple time the same function
(actually, up to 4 time for one, 3 for the other, with possible
crossovers...), each one physically distinct. Each child is being tied
to a pair. Thus, I need to pass each child discriminator(s) for each
interfaces right after having been *created*, which cannot be done
later on. Of course, it is out-of-question to have crossover in the
interfaces definitions.

The best way I could achieve this currently is to pass the child's
device to its parent, and do a lookup based on that pointer to get
information I need, but erk....

my 1c,
- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
> Ok, yet another Newbus' limitation. Assuming a device exports more
> than one interface, and one of its child has need to use more than one
> interface, each interfaces cannot register, concurrently, its own
> ivar. While I try to always have a single child per
> interface/resource, I need to keep some compatibility with the old way
> of doing thing (POLA wrt. drivers I cannot/will not convert and
> userland). So, it would have been nice if ivar had been per-interface,
> not global and unique to one device.

There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.

So I'm not sure I understand what you are saying here.

The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
....
};

We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:

enum ivar_namespace {
IVAR_PCI = 1,
IVAR_PCCARD,
IVAR_USB,
etc
};
#define IVAR_SHIFT 16

and the above could be changed to:

enum pci_device_ivars {
PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
....
};

and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.

but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.

> Unless I am mistaken, ivar are the only way for a parent can transmit
> information to a child. I can not simply implement a new METHOD to get
> that ivar as the device implements multiple time the same function
> (actually, up to 4 time for one, 3 for the other, with possible
> crossovers...), each one physically distinct. Each child is being tied
> to a pair. Thus, I need to pass each child discriminator(s) for each
> interfaces right after having been *created*, which cannot be done
> later on. Of course, it is out-of-question to have crossover in the
> interfaces definitions.

ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.

> The best way I could achieve this currently is to pass the child's
> device to its parent, and do a lookup based on that pointer to get
> information I need, but erk....

That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.

Warner_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>> Ok, yet another Newbus' limitation. Assuming a device exports more
>> than one interface, and one of its child has need to use more than one
>> interface, each interfaces cannot register, concurrently, its own
>> ivar. While I try to always have a single child per
>> interface/resource, I need to keep some compatibility with the old way
>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>> userland). So, it would have been nice if ivar had been per-interface,
>> not global and unique to one device.
>
> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>
> So I'm not sure I understand what you are saying here.
>
dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
use both interfaces. There is no generic way for dev0 to export
independent ivars for both interface. For now, I restricted the
function of the second interface not to need ivar, but that's kind of
hackish.

- Arnaud

> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>
> enum ivar_namespace {
> IVAR_PCI = 1,
> IVAR_PCCARD,
> IVAR_USB,
> etc
> };
> #define IVAR_SHIFT 16
>
> and the above could be changed to:
>
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>
> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>
>> Unless I am mistaken, ivar are the only way for a parent can transmit
>> information to a child. I can not simply implement a new METHOD to get
>> that ivar as the device implements multiple time the same function
>> (actually, up to 4 time for one, 3 for the other, with possible
>> crossovers...), each one physically distinct. Each child is being tied
>> to a pair. Thus, I need to pass each child discriminator(s) for each
>> interfaces right after having been *created*, which cannot be done
>> later on. Of course, it is out-of-question to have crossover in the
>> interfaces definitions.
>
> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>
>> The best way I could achieve this currently is to pass the child's
>> device to its parent, and do a lookup based on that pointer to get
>> information I need, but erk....
>
> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>
> Warner
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:

> Hi,
>
> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>> than one interface, and one of its child has need to use more than one
>>> interface, each interfaces cannot register, concurrently, its own
>>> ivar. While I try to always have a single child per
>>> interface/resource, I need to keep some compatibility with the old way
>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>> userland). So, it would have been nice if ivar had been per-interface,
>>> not global and unique to one device.
>>
>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>
>> So I'm not sure I understand what you are saying here.
>>
> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
> use both interfaces. There is no generic way for dev0 to export
> independent ivars for both interface. For now, I restricted the
> function of the second interface not to need ivar, but that's kind of
> hackish.

Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.

Warner

> - Arnaud
>
>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>
>> enum ivar_namespace {
>> IVAR_PCI = 1,
>> IVAR_PCCARD,
>> IVAR_USB,
>> etc
>> };
>> #define IVAR_SHIFT 16
>>
>> and the above could be changed to:
>>
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>
>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>
>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>> information to a child. I can not simply implement a new METHOD to get
>>> that ivar as the device implements multiple time the same function
>>> (actually, up to 4 time for one, 3 for the other, with possible
>>> crossovers...), each one physically distinct. Each child is being tied
>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>> interfaces right after having been *created*, which cannot be done
>>> later on. Of course, it is out-of-question to have crossover in the
>>> interfaces definitions.
>>
>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>
>>> The best way I could achieve this currently is to pass the child's
>>> device to its parent, and do a lookup based on that pointer to get
>>> information I need, but erk....
>>
>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>
>> Warner

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>
>> Hi,
>>
>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>
>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>> than one interface, and one of its child has need to use more than one
>>>> interface, each interfaces cannot register, concurrently, its own
>>>> ivar. While I try to always have a single child per
>>>> interface/resource, I need to keep some compatibility with the old way
>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>> not global and unique to one device.
>>>
>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>
>>> So I'm not sure I understand what you are saying here.
>>>
>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>> use both interfaces. There is no generic way for dev0 to export
>> independent ivars for both interface. For now, I restricted the
>> function of the second interface not to need ivar, but that's kind of
>> hackish.
>
> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>
I think we should not be talking about the same API here. I have no
idea what you mean by "the key to value translation", nor "Ivar
numbers". What I refer to is that device_set_ivars() /
device_get_ivars() acts on a single instance variables from `struct
device': `ivars'. In that case, I do not really see how to set that
specific field to two distinct values for each interfaces.

- Arnaud

> Warner
>
>> - Arnaud
>>
>>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>>> enum pci_device_ivars {
>>> PCI_IVAR_SUBVENDOR,
>>> PCI_IVAR_SUBDEVICE,
>>> PCI_IVAR_VENDOR,
>>> ....
>>> };
>>>
>>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>>
>>> enum ivar_namespace {
>>> IVAR_PCI = 1,
>>> IVAR_PCCARD,
>>> IVAR_USB,
>>> etc
>>> };
>>> #define IVAR_SHIFT 16
>>>
>>> and the above could be changed to:
>>>
>>> enum pci_device_ivars {
>>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>>> PCI_IVAR_SUBDEVICE,
>>> PCI_IVAR_VENDOR,
>>> ....
>>> };
>>>
>>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>>
>>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>>
>>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>>> information to a child. I can not simply implement a new METHOD to get
>>>> that ivar as the device implements multiple time the same function
>>>> (actually, up to 4 time for one, 3 for the other, with possible
>>>> crossovers...), each one physically distinct. Each child is being tied
>>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>>> interfaces right after having been *created*, which cannot be done
>>>> later on. Of course, it is out-of-question to have crossover in the
>>>> interfaces definitions.
>>>
>>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>>
>>>> The best way I could achieve this currently is to pass the child's
>>>> device to its parent, and do a lookup based on that pointer to get
>>>> information I need, but erk....
>>>
>>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>>
>>> Warner
>
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>> Ok, yet another Newbus' limitation. Assuming a device exports more
>> than one interface, and one of its child has need to use more than one
>> interface, each interfaces cannot register, concurrently, its own
>> ivar. While I try to always have a single child per
>> interface/resource, I need to keep some compatibility with the old way
>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>> userland). So, it would have been nice if ivar had been per-interface,
>> not global and unique to one device.
>
> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>
> So I'm not sure I understand what you are saying here.
>
> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>
> enum ivar_namespace {
> IVAR_PCI = 1,
> IVAR_PCCARD,
> IVAR_USB,
> etc
> };
> #define IVAR_SHIFT 16
>
> and the above could be changed to:
>
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>
> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>
ok, I think I got it now. You and I are exactly saying the same thing,
just in different terms; there is no way to currently specify multiple
independent (/overlapping) ivars in a child...

- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote:

> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>>
>>> Hi,
>>>
>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>>
>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>>> than one interface, and one of its child has need to use more than one
>>>>> interface, each interfaces cannot register, concurrently, its own
>>>>> ivar. While I try to always have a single child per
>>>>> interface/resource, I need to keep some compatibility with the old way
>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>>> not global and unique to one device.
>>>>
>>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>>
>>>> So I'm not sure I understand what you are saying here.
>>>>
>>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>>> use both interfaces. There is no generic way for dev0 to export
>>> independent ivars for both interface. For now, I restricted the
>>> function of the second interface not to need ivar, but that's kind of
>>> hackish.
>>
>> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>>
> I think we should not be talking about the same API here. I have no
> idea what you mean by "the key to value translation", nor "Ivar
> numbers". What I refer to is that device_set_ivars() /
> device_get_ivars() acts on a single instance variables from `struct
> device': `ivars'. In that case, I do not really see how to set that
> specific field to two distinct values for each interfaces.

We are talking about the ivar interface. You are just misunderstanding how it is used.

Let us say that dev0 wants to implement interface A and B. The interface it implements is the device_read _ivar method. That method looks like:

int pci_read_ivar(device_t dev, device_t child, int which, uintptr_t *result)
{
struct pci_ivar *iv = device_get_ivar(child);

switch (which) {
case PCI_IVAR_SUBVENDOR:
*result = iv->subvendor;
break;
...
default:
return EINVAL;
}
return 0;
}

So, if you wanted to implement interface A and interface B, you would have to support reading and writing A_IVAR_* and B_IVAR_*. The above routine would look like:

struct mydev_ivar {
int a_1;
int a_2;
int b_1;
int b_2;
};

int mydev_read_ivar(device_t dev, device child, int which, uintpr_t *result)
{
struct mydev_ivar *iv = device_get_ivar(child);

switch (which) {
case A_IVAR_1:
*result = iv->a_1;
break;
case A_IVAR_2:
*result = iv->a_2;
break;
case B_IVAR_1:
*result = iv->b_1;
break;
case B_IVAR_2:
*result = iv->b_2;
break;
default:
return EINVAL;
}
return 0;
}

and similar for the write routine. Now, there are some busses that provide convenience structures and functions for dealing with the ivars. In that case, you'd be able to use the wrapper structures and routines like so:

struct mdev_ivar {
struct a_ivar a;
struct b_ivar b;
};

int mydev_read_ivar(device_t dev, device child, int which, uintpr_t *result)
{
struct mydev_ivar *iv = device_get_ivar(child);

switch (which) {
case A_IVAR_1:
case A_IVAR_2:
return a_helper_read_ivar(&iv->a, which, result);
case B_IVAR_1:
case B_IVAR_2:
return b_helper_read_ivar(&iv->b, which, result);
default:
return EINVAL;
}
return 0;
}

Both of these work only if the A_IVAR values are disjoint from the B_IVAR values. Your mydev device is the one that sets the ivar on dev1, in your example, so it would know how to malloc and create the mydev_ivar structure, even if the interfaces it is implementing provide helper functions, like I've outlined above.

Warner



> - Arnaud
>
>> Warner
>>
>>> - Arnaud
>>>
>>>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>>>> enum pci_device_ivars {
>>>> PCI_IVAR_SUBVENDOR,
>>>> PCI_IVAR_SUBDEVICE,
>>>> PCI_IVAR_VENDOR,
>>>> ....
>>>> };
>>>>
>>>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>>>
>>>> enum ivar_namespace {
>>>> IVAR_PCI = 1,
>>>> IVAR_PCCARD,
>>>> IVAR_USB,
>>>> etc
>>>> };
>>>> #define IVAR_SHIFT 16
>>>>
>>>> and the above could be changed to:
>>>>
>>>> enum pci_device_ivars {
>>>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>>>> PCI_IVAR_SUBDEVICE,
>>>> PCI_IVAR_VENDOR,
>>>> ....
>>>> };
>>>>
>>>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>>>
>>>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>>>
>>>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>>>> information to a child. I can not simply implement a new METHOD to get
>>>>> that ivar as the device implements multiple time the same function
>>>>> (actually, up to 4 time for one, 3 for the other, with possible
>>>>> crossovers...), each one physically distinct. Each child is being tied
>>>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>>>> interfaces right after having been *created*, which cannot be done
>>>>> later on. Of course, it is out-of-question to have crossover in the
>>>>> interfaces definitions.
>>>>
>>>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>>>
>>>>> The best way I could achieve this currently is to pass the child's
>>>>> device to its parent, and do a lookup based on that pointer to get
>>>>> information I need, but erk....
>>>>
>>>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>>>
>>>> Warner
>>

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 9:59 PM, Arnaud Lacombe wrote:

> Hi,
>
> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>> than one interface, and one of its child has need to use more than one
>>> interface, each interfaces cannot register, concurrently, its own
>>> ivar. While I try to always have a single child per
>>> interface/resource, I need to keep some compatibility with the old way
>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>> userland). So, it would have been nice if ivar had been per-interface,
>>> not global and unique to one device.
>>
>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>
>> So I'm not sure I understand what you are saying here.
>>
>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>
>> enum ivar_namespace {
>> IVAR_PCI = 1,
>> IVAR_PCCARD,
>> IVAR_USB,
>> etc
>> };
>> #define IVAR_SHIFT 16
>>
>> and the above could be changed to:
>>
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>
>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>
> ok, I think I got it now. You and I are exactly saying the same thing,
> just in different terms; there is no way to currently specify multiple
> independent (/overlapping) ivars in a child...

There's no way to support overlapping IVAR keys, yes. However, if you are designing the ivars for multiple inheritance, then you'll need to make them non-overlapping. Thankfully, this is trivial to do.

Warner

Warner_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Mon, Jul 9, 2012 at 12:37 AM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote:
>
>> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>>>
>>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>>>
>>>> Hi,
>>>>
>>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>>>
>>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>>>> than one interface, and one of its child has need to use more than one
>>>>>> interface, each interfaces cannot register, concurrently, its own
>>>>>> ivar. While I try to always have a single child per
>>>>>> interface/resource, I need to keep some compatibility with the old way
>>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>>>> not global and unique to one device.
>>>>>
>>>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>>>
>>>>> So I'm not sure I understand what you are saying here.
>>>>>
>>>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>>>> use both interfaces. There is no generic way for dev0 to export
>>>> independent ivars for both interface. For now, I restricted the
>>>> function of the second interface not to need ivar, but that's kind of
>>>> hackish.
>>>
>>> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>>>
>> I think we should not be talking about the same API here. I have no
>> idea what you mean by "the key to value translation", nor "Ivar
>> numbers". What I refer to is that device_set_ivars() /
>> device_get_ivars() acts on a single instance variables from `struct
>> device': `ivars'. In that case, I do not really see how to set that
>> specific field to two distinct values for each interfaces.
>
> We are talking about the ivar interface. You are just misunderstanding how it is used.
>
yes I indeed did... silly, silly me :-)

- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
On Monday, July 09, 2012 12:39:03 am Warner Losh wrote:
>
> On Jul 8, 2012, at 9:59 PM, Arnaud Lacombe wrote:
>
> > Hi,
> >
> > On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
> >>
> >> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
> >>> Ok, yet another Newbus' limitation. Assuming a device exports more
> >>> than one interface, and one of its child has need to use more than one
> >>> interface, each interfaces cannot register, concurrently, its own
> >>> ivar. While I try to always have a single child per
> >>> interface/resource, I need to keep some compatibility with the old way
> >>> of doing thing (POLA wrt. drivers I cannot/will not convert and
> >>> userland). So, it would have been nice if ivar had been per-interface,
> >>> not global and unique to one device.
> >>
> >> There's one pointer for the ivars. The bus code gets to determine what
the ivar looks like, because the interface is totally private to the bus. So
long as it returns the right thing for any key that's presented, it doesn't
matter quite how things are done.
> >>
> >> So I'm not sure I understand what you are saying here.
> >>
> >> The problem, more basically, is that the ivar keys are not unique.
Currently, there's no bits used in the key to define the values to be non-
overlapping. For example:
> >> enum pci_device_ivars {
> >> PCI_IVAR_SUBVENDOR,
> >> PCI_IVAR_SUBDEVICE,
> >> PCI_IVAR_VENDOR,
> >> ....
> >> };
> >>
> >> We could easily reserve the upper 16-bits of this field to be that key.
This value could then be used to differentiate them. But this wouldn't scale
too well. Given that there's only about a dozen or two in the tree, that's
right at the moment, it wouldn't be hard to do something like:
> >>
> >> enum ivar_namespace {
> >> IVAR_PCI = 1,
> >> IVAR_PCCARD,
> >> IVAR_USB,
> >> etc
> >> };
> >> #define IVAR_SHIFT 16
> >>
> >> and the above could be changed to:
> >>
> >> enum pci_device_ivars {
> >> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
> >> PCI_IVAR_SUBDEVICE,
> >> PCI_IVAR_VENDOR,
> >> ....
> >> };
> >>
> >> and then we'd have an unambiguous key, and the bus could easily implement
multiple interfaces.
> >>
> >> but then again, most of the existing interfaces in the kernel are
mutually exclusive, so you could implement this just for your new interfaces.
> >>
> > ok, I think I got it now. You and I are exactly saying the same thing,
> > just in different terms; there is no way to currently specify multiple
> > independent (/overlapping) ivars in a child...
>
> There's no way to support overlapping IVAR keys, yes. However, if you are
designing the ivars for multiple inheritance, then you'll need to make them
non-overlapping. Thankfully, this is trivial to do.

Also, I think we should do this in general. We already have one example (e.g.
ACPI IVARs start at 100 so that things like the ACPI PCI bus driver can
provide both ACPI and PCI IVARs to child devices). I think we should assign
each bus it's own IVAR range. It would make it easier to determine if a
specific IVAR is event supported. Certainly I think ISA and PCI at a minimum
should be changed to start at, say, 200 and 300.

--
John Baldwin
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Mon, Jul 9, 2012 at 1:17 AM, Arnaud Lacombe <> wrote:
> Hi,
>
> On Mon, Jul 9, 2012 at 12:37 AM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote:
>>
>>> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>>>>
>>>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>>>>
>>>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>>>>> than one interface, and one of its child has need to use more than one
>>>>>>> interface, each interfaces cannot register, concurrently, its own
>>>>>>> ivar. While I try to always have a single child per
>>>>>>> interface/resource, I need to keep some compatibility with the old way
>>>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>>>>> not global and unique to one device.
>>>>>>
>>>>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>>>>
>>>>>> So I'm not sure I understand what you are saying here.
>>>>>>
>>>>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>>>>> use both interfaces. There is no generic way for dev0 to export
>>>>> independent ivars for both interface. For now, I restricted the
>>>>> function of the second interface not to need ivar, but that's kind of
>>>>> hackish.
>>>>
>>>> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>>>>
>>> I think we should not be talking about the same API here. I have no
>>> idea what you mean by "the key to value translation", nor "Ivar
>>> numbers". What I refer to is that device_set_ivars() /
>>> device_get_ivars() acts on a single instance variables from `struct
>>> device': `ivars'. In that case, I do not really see how to set that
>>> specific field to two distinct values for each interfaces.
>>
>> We are talking about the ivar interface. You are just misunderstanding how it is used.
>>
> yes I indeed did... silly, silly me :-)
>
Actually, no. I wasn't that silly, neither was I misunderstanding
anything beside how *you* wanted it to be used, which is, I sorry to
say, unacceptable. The last thing I want is to pollute an interface
with a single-purpose, hand-crafted, bus. I was to just throw away all
that ivar stuff and go into hinted child configuration for now,
waiting for FDT... but of course, I figured out after a few hours that
hinted child attachment requires `bus_hinted_child' to be set in the
parent, as does bus_enumerate_hinted_children() / bus_generic_attach()
to explicitly pollute my code. All this stuff should be done
implicitly to support N:1 interfaces/client relationship. N
*independent* interfaces being provided by a single driver; of course,
I'm not even going back to require those interface being provided by
multiple drivers, it is already a dead end.

I am not even sure any driver in the tree provides more than one interface...

For whatever reason, I am more and more thinking that this all
new-bus[0] stuff is *way* overkill, static, bloated at will, and
missing critical features; a huge PITA to use, for the intended
purpose.

/me ****.

- Arnaud

[0]: damn, why is it even called "newbus", this stuff is 14 years old.
It really belongs to a museum, not production code...
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

Hi folks,

Ok, yet another Newbus' limitation. Assuming a device exports more
than one interface, and one of its child has need to use more than one
interface, each interfaces cannot register, concurrently, its own
ivar. While I try to always have a single child per
interface/resource, I need to keep some compatibility with the old way
of doing thing (POLA wrt. drivers I cannot/will not convert and
userland). So, it would have been nice if ivar had been per-interface,
not global and unique to one device.

Unless I am mistaken, ivar are the only way for a parent can transmit
information to a child. I can not simply implement a new METHOD to get
that ivar as the device implements multiple time the same function
(actually, up to 4 time for one, 3 for the other, with possible
crossovers...), each one physically distinct. Each child is being tied
to a pair. Thus, I need to pass each child discriminator(s) for each
interfaces right after having been *created*, which cannot be done
later on. Of course, it is out-of-question to have crossover in the
interfaces definitions.

The best way I could achieve this currently is to pass the child's
device to its parent, and do a lookup based on that pointer to get
information I need, but erk....

my 1c,
- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
> Ok, yet another Newbus' limitation. Assuming a device exports more
> than one interface, and one of its child has need to use more than one
> interface, each interfaces cannot register, concurrently, its own
> ivar. While I try to always have a single child per
> interface/resource, I need to keep some compatibility with the old way
> of doing thing (POLA wrt. drivers I cannot/will not convert and
> userland). So, it would have been nice if ivar had been per-interface,
> not global and unique to one device.

There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.

So I'm not sure I understand what you are saying here.

The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
....
};

We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:

enum ivar_namespace {
IVAR_PCI = 1,
IVAR_PCCARD,
IVAR_USB,
etc
};
#define IVAR_SHIFT 16

and the above could be changed to:

enum pci_device_ivars {
PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
....
};

and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.

but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.

> Unless I am mistaken, ivar are the only way for a parent can transmit
> information to a child. I can not simply implement a new METHOD to get
> that ivar as the device implements multiple time the same function
> (actually, up to 4 time for one, 3 for the other, with possible
> crossovers...), each one physically distinct. Each child is being tied
> to a pair. Thus, I need to pass each child discriminator(s) for each
> interfaces right after having been *created*, which cannot be done
> later on. Of course, it is out-of-question to have crossover in the
> interfaces definitions.

ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.

> The best way I could achieve this currently is to pass the child's
> device to its parent, and do a lookup based on that pointer to get
> information I need, but erk....

That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.

Warner_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>> Ok, yet another Newbus' limitation. Assuming a device exports more
>> than one interface, and one of its child has need to use more than one
>> interface, each interfaces cannot register, concurrently, its own
>> ivar. While I try to always have a single child per
>> interface/resource, I need to keep some compatibility with the old way
>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>> userland). So, it would have been nice if ivar had been per-interface,
>> not global and unique to one device.
>
> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>
> So I'm not sure I understand what you are saying here.
>
dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
use both interfaces. There is no generic way for dev0 to export
independent ivars for both interface. For now, I restricted the
function of the second interface not to need ivar, but that's kind of
hackish.

- Arnaud

> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>
> enum ivar_namespace {
> IVAR_PCI = 1,
> IVAR_PCCARD,
> IVAR_USB,
> etc
> };
> #define IVAR_SHIFT 16
>
> and the above could be changed to:
>
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>
> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>
>> Unless I am mistaken, ivar are the only way for a parent can transmit
>> information to a child. I can not simply implement a new METHOD to get
>> that ivar as the device implements multiple time the same function
>> (actually, up to 4 time for one, 3 for the other, with possible
>> crossovers...), each one physically distinct. Each child is being tied
>> to a pair. Thus, I need to pass each child discriminator(s) for each
>> interfaces right after having been *created*, which cannot be done
>> later on. Of course, it is out-of-question to have crossover in the
>> interfaces definitions.
>
> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>
>> The best way I could achieve this currently is to pass the child's
>> device to its parent, and do a lookup based on that pointer to get
>> information I need, but erk....
>
> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>
> Warner
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:

> Hi,
>
> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>> than one interface, and one of its child has need to use more than one
>>> interface, each interfaces cannot register, concurrently, its own
>>> ivar. While I try to always have a single child per
>>> interface/resource, I need to keep some compatibility with the old way
>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>> userland). So, it would have been nice if ivar had been per-interface,
>>> not global and unique to one device.
>>
>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>
>> So I'm not sure I understand what you are saying here.
>>
> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
> use both interfaces. There is no generic way for dev0 to export
> independent ivars for both interface. For now, I restricted the
> function of the second interface not to need ivar, but that's kind of
> hackish.

Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.

Warner

> - Arnaud
>
>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>
>> enum ivar_namespace {
>> IVAR_PCI = 1,
>> IVAR_PCCARD,
>> IVAR_USB,
>> etc
>> };
>> #define IVAR_SHIFT 16
>>
>> and the above could be changed to:
>>
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>
>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>
>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>> information to a child. I can not simply implement a new METHOD to get
>>> that ivar as the device implements multiple time the same function
>>> (actually, up to 4 time for one, 3 for the other, with possible
>>> crossovers...), each one physically distinct. Each child is being tied
>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>> interfaces right after having been *created*, which cannot be done
>>> later on. Of course, it is out-of-question to have crossover in the
>>> interfaces definitions.
>>
>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>
>>> The best way I could achieve this currently is to pass the child's
>>> device to its parent, and do a lookup based on that pointer to get
>>> information I need, but erk....
>>
>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>
>> Warner

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>
>> Hi,
>>
>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>
>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>> than one interface, and one of its child has need to use more than one
>>>> interface, each interfaces cannot register, concurrently, its own
>>>> ivar. While I try to always have a single child per
>>>> interface/resource, I need to keep some compatibility with the old way
>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>> not global and unique to one device.
>>>
>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>
>>> So I'm not sure I understand what you are saying here.
>>>
>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>> use both interfaces. There is no generic way for dev0 to export
>> independent ivars for both interface. For now, I restricted the
>> function of the second interface not to need ivar, but that's kind of
>> hackish.
>
> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>
I think we should not be talking about the same API here. I have no
idea what you mean by "the key to value translation", nor "Ivar
numbers". What I refer to is that device_set_ivars() /
device_get_ivars() acts on a single instance variables from `struct
device': `ivars'. In that case, I do not really see how to set that
specific field to two distinct values for each interfaces.

- Arnaud

> Warner
>
>> - Arnaud
>>
>>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>>> enum pci_device_ivars {
>>> PCI_IVAR_SUBVENDOR,
>>> PCI_IVAR_SUBDEVICE,
>>> PCI_IVAR_VENDOR,
>>> ....
>>> };
>>>
>>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>>
>>> enum ivar_namespace {
>>> IVAR_PCI = 1,
>>> IVAR_PCCARD,
>>> IVAR_USB,
>>> etc
>>> };
>>> #define IVAR_SHIFT 16
>>>
>>> and the above could be changed to:
>>>
>>> enum pci_device_ivars {
>>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>>> PCI_IVAR_SUBDEVICE,
>>> PCI_IVAR_VENDOR,
>>> ....
>>> };
>>>
>>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>>
>>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>>
>>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>>> information to a child. I can not simply implement a new METHOD to get
>>>> that ivar as the device implements multiple time the same function
>>>> (actually, up to 4 time for one, 3 for the other, with possible
>>>> crossovers...), each one physically distinct. Each child is being tied
>>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>>> interfaces right after having been *created*, which cannot be done
>>>> later on. Of course, it is out-of-question to have crossover in the
>>>> interfaces definitions.
>>>
>>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>>
>>>> The best way I could achieve this currently is to pass the child's
>>>> device to its parent, and do a lookup based on that pointer to get
>>>> information I need, but erk....
>>>
>>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>>
>>> Warner
>
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>> Ok, yet another Newbus' limitation. Assuming a device exports more
>> than one interface, and one of its child has need to use more than one
>> interface, each interfaces cannot register, concurrently, its own
>> ivar. While I try to always have a single child per
>> interface/resource, I need to keep some compatibility with the old way
>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>> userland). So, it would have been nice if ivar had been per-interface,
>> not global and unique to one device.
>
> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>
> So I'm not sure I understand what you are saying here.
>
> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>
> enum ivar_namespace {
> IVAR_PCI = 1,
> IVAR_PCCARD,
> IVAR_USB,
> etc
> };
> #define IVAR_SHIFT 16
>
> and the above could be changed to:
>
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>
> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>
ok, I think I got it now. You and I are exactly saying the same thing,
just in different terms; there is no way to currently specify multiple
independent (/overlapping) ivars in a child...

- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote:

> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>>
>>> Hi,
>>>
>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>>
>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>>> than one interface, and one of its child has need to use more than one
>>>>> interface, each interfaces cannot register, concurrently, its own
>>>>> ivar. While I try to always have a single child per
>>>>> interface/resource, I need to keep some compatibility with the old way
>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>>> not global and unique to one device.
>>>>
>>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>>
>>>> So I'm not sure I understand what you are saying here.
>>>>
>>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>>> use both interfaces. There is no generic way for dev0 to export
>>> independent ivars for both interface. For now, I restricted the
>>> function of the second interface not to need ivar, but that's kind of
>>> hackish.
>>
>> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>>
> I think we should not be talking about the same API here. I have no
> idea what you mean by "the key to value translation", nor "Ivar
> numbers". What I refer to is that device_set_ivars() /
> device_get_ivars() acts on a single instance variables from `struct
> device': `ivars'. In that case, I do not really see how to set that
> specific field to two distinct values for each interfaces.

We are talking about the ivar interface. You are just misunderstanding how it is used.

Let us say that dev0 wants to implement interface A and B. The interface it implements is the device_read _ivar method. That method looks like:

int pci_read_ivar(device_t dev, device_t child, int which, uintptr_t *result)
{
struct pci_ivar *iv = device_get_ivar(child);

switch (which) {
case PCI_IVAR_SUBVENDOR:
*result = iv->subvendor;
break;
...
default:
return EINVAL;
}
return 0;
}

So, if you wanted to implement interface A and interface B, you would have to support reading and writing A_IVAR_* and B_IVAR_*. The above routine would look like:

struct mydev_ivar {
int a_1;
int a_2;
int b_1;
int b_2;
};

int mydev_read_ivar(device_t dev, device child, int which, uintpr_t *result)
{
struct mydev_ivar *iv = device_get_ivar(child);

switch (which) {
case A_IVAR_1:
*result = iv->a_1;
break;
case A_IVAR_2:
*result = iv->a_2;
break;
case B_IVAR_1:
*result = iv->b_1;
break;
case B_IVAR_2:
*result = iv->b_2;
break;
default:
return EINVAL;
}
return 0;
}

and similar for the write routine. Now, there are some busses that provide convenience structures and functions for dealing with the ivars. In that case, you'd be able to use the wrapper structures and routines like so:

struct mdev_ivar {
struct a_ivar a;
struct b_ivar b;
};

int mydev_read_ivar(device_t dev, device child, int which, uintpr_t *result)
{
struct mydev_ivar *iv = device_get_ivar(child);

switch (which) {
case A_IVAR_1:
case A_IVAR_2:
return a_helper_read_ivar(&iv->a, which, result);
case B_IVAR_1:
case B_IVAR_2:
return b_helper_read_ivar(&iv->b, which, result);
default:
return EINVAL;
}
return 0;
}

Both of these work only if the A_IVAR values are disjoint from the B_IVAR values. Your mydev device is the one that sets the ivar on dev1, in your example, so it would know how to malloc and create the mydev_ivar structure, even if the interfaces it is implementing provide helper functions, like I've outlined above.

Warner



> - Arnaud
>
>> Warner
>>
>>> - Arnaud
>>>
>>>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>>>> enum pci_device_ivars {
>>>> PCI_IVAR_SUBVENDOR,
>>>> PCI_IVAR_SUBDEVICE,
>>>> PCI_IVAR_VENDOR,
>>>> ....
>>>> };
>>>>
>>>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>>>
>>>> enum ivar_namespace {
>>>> IVAR_PCI = 1,
>>>> IVAR_PCCARD,
>>>> IVAR_USB,
>>>> etc
>>>> };
>>>> #define IVAR_SHIFT 16
>>>>
>>>> and the above could be changed to:
>>>>
>>>> enum pci_device_ivars {
>>>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>>>> PCI_IVAR_SUBDEVICE,
>>>> PCI_IVAR_VENDOR,
>>>> ....
>>>> };
>>>>
>>>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>>>
>>>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>>>
>>>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>>>> information to a child. I can not simply implement a new METHOD to get
>>>>> that ivar as the device implements multiple time the same function
>>>>> (actually, up to 4 time for one, 3 for the other, with possible
>>>>> crossovers...), each one physically distinct. Each child is being tied
>>>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>>>> interfaces right after having been *created*, which cannot be done
>>>>> later on. Of course, it is out-of-question to have crossover in the
>>>>> interfaces definitions.
>>>>
>>>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>>>
>>>>> The best way I could achieve this currently is to pass the child's
>>>>> device to its parent, and do a lookup based on that pointer to get
>>>>> information I need, but erk....
>>>>
>>>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>>>
>>>> Warner
>>

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 9:59 PM, Arnaud Lacombe wrote:

> Hi,
>
> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>> than one interface, and one of its child has need to use more than one
>>> interface, each interfaces cannot register, concurrently, its own
>>> ivar. While I try to always have a single child per
>>> interface/resource, I need to keep some compatibility with the old way
>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>> userland). So, it would have been nice if ivar had been per-interface,
>>> not global and unique to one device.
>>
>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>
>> So I'm not sure I understand what you are saying here.
>>
>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>
>> enum ivar_namespace {
>> IVAR_PCI = 1,
>> IVAR_PCCARD,
>> IVAR_USB,
>> etc
>> };
>> #define IVAR_SHIFT 16
>>
>> and the above could be changed to:
>>
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>
>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>
> ok, I think I got it now. You and I are exactly saying the same thing,
> just in different terms; there is no way to currently specify multiple
> independent (/overlapping) ivars in a child...

There's no way to support overlapping IVAR keys, yes. However, if you are designing the ivars for multiple inheritance, then you'll need to make them non-overlapping. Thankfully, this is trivial to do.

Warner

Warner_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Mon, Jul 9, 2012 at 12:37 AM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote:
>
>> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>>>
>>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>>>
>>>> Hi,
>>>>
>>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>>>
>>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>>>> than one interface, and one of its child has need to use more than one
>>>>>> interface, each interfaces cannot register, concurrently, its own
>>>>>> ivar. While I try to always have a single child per
>>>>>> interface/resource, I need to keep some compatibility with the old way
>>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>>>> not global and unique to one device.
>>>>>
>>>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>>>
>>>>> So I'm not sure I understand what you are saying here.
>>>>>
>>>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>>>> use both interfaces. There is no generic way for dev0 to export
>>>> independent ivars for both interface. For now, I restricted the
>>>> function of the second interface not to need ivar, but that's kind of
>>>> hackish.
>>>
>>> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>>>
>> I think we should not be talking about the same API here. I have no
>> idea what you mean by "the key to value translation", nor "Ivar
>> numbers". What I refer to is that device_set_ivars() /
>> device_get_ivars() acts on a single instance variables from `struct
>> device': `ivars'. In that case, I do not really see how to set that
>> specific field to two distinct values for each interfaces.
>
> We are talking about the ivar interface. You are just misunderstanding how it is used.
>
yes I indeed did... silly, silly me :-)

- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
On Monday, July 09, 2012 12:39:03 am Warner Losh wrote:
>
> On Jul 8, 2012, at 9:59 PM, Arnaud Lacombe wrote:
>
> > Hi,
> >
> > On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
> >>
> >> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
> >>> Ok, yet another Newbus' limitation. Assuming a device exports more
> >>> than one interface, and one of its child has need to use more than one
> >>> interface, each interfaces cannot register, concurrently, its own
> >>> ivar. While I try to always have a single child per
> >>> interface/resource, I need to keep some compatibility with the old way
> >>> of doing thing (POLA wrt. drivers I cannot/will not convert and
> >>> userland). So, it would have been nice if ivar had been per-interface,
> >>> not global and unique to one device.
> >>
> >> There's one pointer for the ivars. The bus code gets to determine what
the ivar looks like, because the interface is totally private to the bus. So
long as it returns the right thing for any key that's presented, it doesn't
matter quite how things are done.
> >>
> >> So I'm not sure I understand what you are saying here.
> >>
> >> The problem, more basically, is that the ivar keys are not unique.
Currently, there's no bits used in the key to define the values to be non-
overlapping. For example:
> >> enum pci_device_ivars {
> >> PCI_IVAR_SUBVENDOR,
> >> PCI_IVAR_SUBDEVICE,
> >> PCI_IVAR_VENDOR,
> >> ....
> >> };
> >>
> >> We could easily reserve the upper 16-bits of this field to be that key.
This value could then be used to differentiate them. But this wouldn't scale
too well. Given that there's only about a dozen or two in the tree, that's
right at the moment, it wouldn't be hard to do something like:
> >>
> >> enum ivar_namespace {
> >> IVAR_PCI = 1,
> >> IVAR_PCCARD,
> >> IVAR_USB,
> >> etc
> >> };
> >> #define IVAR_SHIFT 16
> >>
> >> and the above could be changed to:
> >>
> >> enum pci_device_ivars {
> >> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
> >> PCI_IVAR_SUBDEVICE,
> >> PCI_IVAR_VENDOR,
> >> ....
> >> };
> >>
> >> and then we'd have an unambiguous key, and the bus could easily implement
multiple interfaces.
> >>
> >> but then again, most of the existing interfaces in the kernel are
mutually exclusive, so you could implement this just for your new interfaces.
> >>
> > ok, I think I got it now. You and I are exactly saying the same thing,
> > just in different terms; there is no way to currently specify multiple
> > independent (/overlapping) ivars in a child...
>
> There's no way to support overlapping IVAR keys, yes. However, if you are
designing the ivars for multiple inheritance, then you'll need to make them
non-overlapping. Thankfully, this is trivial to do.

Also, I think we should do this in general. We already have one example (e.g.
ACPI IVARs start at 100 so that things like the ACPI PCI bus driver can
provide both ACPI and PCI IVARs to child devices). I think we should assign
each bus it's own IVAR range. It would make it easier to determine if a
specific IVAR is event supported. Certainly I think ISA and PCI at a minimum
should be changed to start at, say, 200 and 300.

--
John Baldwin
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Mon, Jul 9, 2012 at 1:17 AM, Arnaud Lacombe <> wrote:
> Hi,
>
> On Mon, Jul 9, 2012 at 12:37 AM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote:
>>
>>> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>>>>
>>>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>>>>
>>>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>>>>> than one interface, and one of its child has need to use more than one
>>>>>>> interface, each interfaces cannot register, concurrently, its own
>>>>>>> ivar. While I try to always have a single child per
>>>>>>> interface/resource, I need to keep some compatibility with the old way
>>>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>>>>> not global and unique to one device.
>>>>>>
>>>>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>>>>
>>>>>> So I'm not sure I understand what you are saying here.
>>>>>>
>>>>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>>>>> use both interfaces. There is no generic way for dev0 to export
>>>>> independent ivars for both interface. For now, I restricted the
>>>>> function of the second interface not to need ivar, but that's kind of
>>>>> hackish.
>>>>
>>>> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>>>>
>>> I think we should not be talking about the same API here. I have no
>>> idea what you mean by "the key to value translation", nor "Ivar
>>> numbers". What I refer to is that device_set_ivars() /
>>> device_get_ivars() acts on a single instance variables from `struct
>>> device': `ivars'. In that case, I do not really see how to set that
>>> specific field to two distinct values for each interfaces.
>>
>> We are talking about the ivar interface. You are just misunderstanding how it is used.
>>
> yes I indeed did... silly, silly me :-)
>
Actually, no. I wasn't that silly, neither was I misunderstanding
anything beside how *you* wanted it to be used, which is, I sorry to
say, unacceptable. The last thing I want is to pollute an interface
with a single-purpose, hand-crafted, bus. I was to just throw away all
that ivar stuff and go into hinted child configuration for now,
waiting for FDT... but of course, I figured out after a few hours that
hinted child attachment requires `bus_hinted_child' to be set in the
parent, as does bus_enumerate_hinted_children() / bus_generic_attach()
to explicitly pollute my code. All this stuff should be done
implicitly to support N:1 interfaces/client relationship. N
*independent* interfaces being provided by a single driver; of course,
I'm not even going back to require those interface being provided by
multiple drivers, it is already a dead end.

I am not even sure any driver in the tree provides more than one interface...

For whatever reason, I am more and more thinking that this all
new-bus[0] stuff is *way* overkill, static, bloated at will, and
missing critical features; a huge PITA to use, for the intended
purpose.

/me ****.

- Arnaud

[0]: damn, why is it even called "newbus", this stuff is 14 years old.
It really belongs to a museum, not production code...
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Mon, Jul 9, 2012 at 11:27 AM, John Baldwin <> wrote:
> Also, I think we should do this in general. We already have one example (e.g.
> ACPI IVARs start at 100 so that things like the ACPI PCI bus driver can
> provide both ACPI and PCI IVARs to child devices). I think we should assign
> each bus it's own IVAR range. It would make it easier to determine if a
> specific IVAR is event supported. Certainly I think ISA and PCI at a minimum
> should be changed to start at, say, 200 and 300.
>
What's the point doing that ? Let's just resign to the conclusion that
FreeBSD devices' subsystem provides no dynamic way for a client device
to deals with multiple bus driver. Instead all possible combination
have to be harcoded and hand-crafted, when at all possible, to look
like they're coming from a single bus...

But again, newbus is 14 years old...

- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

Hi folks,

Ok, yet another Newbus' limitation. Assuming a device exports more
than one interface, and one of its child has need to use more than one
interface, each interfaces cannot register, concurrently, its own
ivar. While I try to always have a single child per
interface/resource, I need to keep some compatibility with the old way
of doing thing (POLA wrt. drivers I cannot/will not convert and
userland). So, it would have been nice if ivar had been per-interface,
not global and unique to one device.

Unless I am mistaken, ivar are the only way for a parent can transmit
information to a child. I can not simply implement a new METHOD to get
that ivar as the device implements multiple time the same function
(actually, up to 4 time for one, 3 for the other, with possible
crossovers...), each one physically distinct. Each child is being tied
to a pair. Thus, I need to pass each child discriminator(s) for each
interfaces right after having been *created*, which cannot be done
later on. Of course, it is out-of-question to have crossover in the
interfaces definitions.

The best way I could achieve this currently is to pass the child's
device to its parent, and do a lookup based on that pointer to get
information I need, but erk....

my 1c,
- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
> Ok, yet another Newbus' limitation. Assuming a device exports more
> than one interface, and one of its child has need to use more than one
> interface, each interfaces cannot register, concurrently, its own
> ivar. While I try to always have a single child per
> interface/resource, I need to keep some compatibility with the old way
> of doing thing (POLA wrt. drivers I cannot/will not convert and
> userland). So, it would have been nice if ivar had been per-interface,
> not global and unique to one device.

There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.

So I'm not sure I understand what you are saying here.

The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
....
};

We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:

enum ivar_namespace {
IVAR_PCI = 1,
IVAR_PCCARD,
IVAR_USB,
etc
};
#define IVAR_SHIFT 16

and the above could be changed to:

enum pci_device_ivars {
PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
....
};

and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.

but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.

> Unless I am mistaken, ivar are the only way for a parent can transmit
> information to a child. I can not simply implement a new METHOD to get
> that ivar as the device implements multiple time the same function
> (actually, up to 4 time for one, 3 for the other, with possible
> crossovers...), each one physically distinct. Each child is being tied
> to a pair. Thus, I need to pass each child discriminator(s) for each
> interfaces right after having been *created*, which cannot be done
> later on. Of course, it is out-of-question to have crossover in the
> interfaces definitions.

ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.

> The best way I could achieve this currently is to pass the child's
> device to its parent, and do a lookup based on that pointer to get
> information I need, but erk....

That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.

Warner_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>> Ok, yet another Newbus' limitation. Assuming a device exports more
>> than one interface, and one of its child has need to use more than one
>> interface, each interfaces cannot register, concurrently, its own
>> ivar. While I try to always have a single child per
>> interface/resource, I need to keep some compatibility with the old way
>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>> userland). So, it would have been nice if ivar had been per-interface,
>> not global and unique to one device.
>
> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>
> So I'm not sure I understand what you are saying here.
>
dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
use both interfaces. There is no generic way for dev0 to export
independent ivars for both interface. For now, I restricted the
function of the second interface not to need ivar, but that's kind of
hackish.

- Arnaud

> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>
> enum ivar_namespace {
> IVAR_PCI = 1,
> IVAR_PCCARD,
> IVAR_USB,
> etc
> };
> #define IVAR_SHIFT 16
>
> and the above could be changed to:
>
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>
> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>
>> Unless I am mistaken, ivar are the only way for a parent can transmit
>> information to a child. I can not simply implement a new METHOD to get
>> that ivar as the device implements multiple time the same function
>> (actually, up to 4 time for one, 3 for the other, with possible
>> crossovers...), each one physically distinct. Each child is being tied
>> to a pair. Thus, I need to pass each child discriminator(s) for each
>> interfaces right after having been *created*, which cannot be done
>> later on. Of course, it is out-of-question to have crossover in the
>> interfaces definitions.
>
> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>
>> The best way I could achieve this currently is to pass the child's
>> device to its parent, and do a lookup based on that pointer to get
>> information I need, but erk....
>
> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>
> Warner
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:

> Hi,
>
> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>> than one interface, and one of its child has need to use more than one
>>> interface, each interfaces cannot register, concurrently, its own
>>> ivar. While I try to always have a single child per
>>> interface/resource, I need to keep some compatibility with the old way
>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>> userland). So, it would have been nice if ivar had been per-interface,
>>> not global and unique to one device.
>>
>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>
>> So I'm not sure I understand what you are saying here.
>>
> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
> use both interfaces. There is no generic way for dev0 to export
> independent ivars for both interface. For now, I restricted the
> function of the second interface not to need ivar, but that's kind of
> hackish.

Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.

Warner

> - Arnaud
>
>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>
>> enum ivar_namespace {
>> IVAR_PCI = 1,
>> IVAR_PCCARD,
>> IVAR_USB,
>> etc
>> };
>> #define IVAR_SHIFT 16
>>
>> and the above could be changed to:
>>
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>
>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>
>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>> information to a child. I can not simply implement a new METHOD to get
>>> that ivar as the device implements multiple time the same function
>>> (actually, up to 4 time for one, 3 for the other, with possible
>>> crossovers...), each one physically distinct. Each child is being tied
>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>> interfaces right after having been *created*, which cannot be done
>>> later on. Of course, it is out-of-question to have crossover in the
>>> interfaces definitions.
>>
>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>
>>> The best way I could achieve this currently is to pass the child's
>>> device to its parent, and do a lookup based on that pointer to get
>>> information I need, but erk....
>>
>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>
>> Warner

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>
>> Hi,
>>
>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>
>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>> than one interface, and one of its child has need to use more than one
>>>> interface, each interfaces cannot register, concurrently, its own
>>>> ivar. While I try to always have a single child per
>>>> interface/resource, I need to keep some compatibility with the old way
>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>> not global and unique to one device.
>>>
>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>
>>> So I'm not sure I understand what you are saying here.
>>>
>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>> use both interfaces. There is no generic way for dev0 to export
>> independent ivars for both interface. For now, I restricted the
>> function of the second interface not to need ivar, but that's kind of
>> hackish.
>
> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>
I think we should not be talking about the same API here. I have no
idea what you mean by "the key to value translation", nor "Ivar
numbers". What I refer to is that device_set_ivars() /
device_get_ivars() acts on a single instance variables from `struct
device': `ivars'. In that case, I do not really see how to set that
specific field to two distinct values for each interfaces.

- Arnaud

> Warner
>
>> - Arnaud
>>
>>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>>> enum pci_device_ivars {
>>> PCI_IVAR_SUBVENDOR,
>>> PCI_IVAR_SUBDEVICE,
>>> PCI_IVAR_VENDOR,
>>> ....
>>> };
>>>
>>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>>
>>> enum ivar_namespace {
>>> IVAR_PCI = 1,
>>> IVAR_PCCARD,
>>> IVAR_USB,
>>> etc
>>> };
>>> #define IVAR_SHIFT 16
>>>
>>> and the above could be changed to:
>>>
>>> enum pci_device_ivars {
>>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>>> PCI_IVAR_SUBDEVICE,
>>> PCI_IVAR_VENDOR,
>>> ....
>>> };
>>>
>>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>>
>>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>>
>>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>>> information to a child. I can not simply implement a new METHOD to get
>>>> that ivar as the device implements multiple time the same function
>>>> (actually, up to 4 time for one, 3 for the other, with possible
>>>> crossovers...), each one physically distinct. Each child is being tied
>>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>>> interfaces right after having been *created*, which cannot be done
>>>> later on. Of course, it is out-of-question to have crossover in the
>>>> interfaces definitions.
>>>
>>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>>
>>>> The best way I could achieve this currently is to pass the child's
>>>> device to its parent, and do a lookup based on that pointer to get
>>>> information I need, but erk....
>>>
>>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>>
>>> Warner
>
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>> Ok, yet another Newbus' limitation. Assuming a device exports more
>> than one interface, and one of its child has need to use more than one
>> interface, each interfaces cannot register, concurrently, its own
>> ivar. While I try to always have a single child per
>> interface/resource, I need to keep some compatibility with the old way
>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>> userland). So, it would have been nice if ivar had been per-interface,
>> not global and unique to one device.
>
> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>
> So I'm not sure I understand what you are saying here.
>
> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>
> enum ivar_namespace {
> IVAR_PCI = 1,
> IVAR_PCCARD,
> IVAR_USB,
> etc
> };
> #define IVAR_SHIFT 16
>
> and the above could be changed to:
>
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>
> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>
ok, I think I got it now. You and I are exactly saying the same thing,
just in different terms; there is no way to currently specify multiple
independent (/overlapping) ivars in a child...

- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote:

> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>>
>>> Hi,
>>>
>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>>
>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>>> than one interface, and one of its child has need to use more than one
>>>>> interface, each interfaces cannot register, concurrently, its own
>>>>> ivar. While I try to always have a single child per
>>>>> interface/resource, I need to keep some compatibility with the old way
>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>>> not global and unique to one device.
>>>>
>>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>>
>>>> So I'm not sure I understand what you are saying here.
>>>>
>>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>>> use both interfaces. There is no generic way for dev0 to export
>>> independent ivars for both interface. For now, I restricted the
>>> function of the second interface not to need ivar, but that's kind of
>>> hackish.
>>
>> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>>
> I think we should not be talking about the same API here. I have no
> idea what you mean by "the key to value translation", nor "Ivar
> numbers". What I refer to is that device_set_ivars() /
> device_get_ivars() acts on a single instance variables from `struct
> device': `ivars'. In that case, I do not really see how to set that
> specific field to two distinct values for each interfaces.

We are talking about the ivar interface. You are just misunderstanding how it is used.

Let us say that dev0 wants to implement interface A and B. The interface it implements is the device_read _ivar method. That method looks like:

int pci_read_ivar(device_t dev, device_t child, int which, uintptr_t *result)
{
struct pci_ivar *iv = device_get_ivar(child);

switch (which) {
case PCI_IVAR_SUBVENDOR:
*result = iv->subvendor;
break;
...
default:
return EINVAL;
}
return 0;
}

So, if you wanted to implement interface A and interface B, you would have to support reading and writing A_IVAR_* and B_IVAR_*. The above routine would look like:

struct mydev_ivar {
int a_1;
int a_2;
int b_1;
int b_2;
};

int mydev_read_ivar(device_t dev, device child, int which, uintpr_t *result)
{
struct mydev_ivar *iv = device_get_ivar(child);

switch (which) {
case A_IVAR_1:
*result = iv->a_1;
break;
case A_IVAR_2:
*result = iv->a_2;
break;
case B_IVAR_1:
*result = iv->b_1;
break;
case B_IVAR_2:
*result = iv->b_2;
break;
default:
return EINVAL;
}
return 0;
}

and similar for the write routine. Now, there are some busses that provide convenience structures and functions for dealing with the ivars. In that case, you'd be able to use the wrapper structures and routines like so:

struct mdev_ivar {
struct a_ivar a;
struct b_ivar b;
};

int mydev_read_ivar(device_t dev, device child, int which, uintpr_t *result)
{
struct mydev_ivar *iv = device_get_ivar(child);

switch (which) {
case A_IVAR_1:
case A_IVAR_2:
return a_helper_read_ivar(&iv->a, which, result);
case B_IVAR_1:
case B_IVAR_2:
return b_helper_read_ivar(&iv->b, which, result);
default:
return EINVAL;
}
return 0;
}

Both of these work only if the A_IVAR values are disjoint from the B_IVAR values. Your mydev device is the one that sets the ivar on dev1, in your example, so it would know how to malloc and create the mydev_ivar structure, even if the interfaces it is implementing provide helper functions, like I've outlined above.

Warner



> - Arnaud
>
>> Warner
>>
>>> - Arnaud
>>>
>>>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>>>> enum pci_device_ivars {
>>>> PCI_IVAR_SUBVENDOR,
>>>> PCI_IVAR_SUBDEVICE,
>>>> PCI_IVAR_VENDOR,
>>>> ....
>>>> };
>>>>
>>>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>>>
>>>> enum ivar_namespace {
>>>> IVAR_PCI = 1,
>>>> IVAR_PCCARD,
>>>> IVAR_USB,
>>>> etc
>>>> };
>>>> #define IVAR_SHIFT 16
>>>>
>>>> and the above could be changed to:
>>>>
>>>> enum pci_device_ivars {
>>>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>>>> PCI_IVAR_SUBDEVICE,
>>>> PCI_IVAR_VENDOR,
>>>> ....
>>>> };
>>>>
>>>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>>>
>>>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>>>
>>>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>>>> information to a child. I can not simply implement a new METHOD to get
>>>>> that ivar as the device implements multiple time the same function
>>>>> (actually, up to 4 time for one, 3 for the other, with possible
>>>>> crossovers...), each one physically distinct. Each child is being tied
>>>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>>>> interfaces right after having been *created*, which cannot be done
>>>>> later on. Of course, it is out-of-question to have crossover in the
>>>>> interfaces definitions.
>>>>
>>>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>>>
>>>>> The best way I could achieve this currently is to pass the child's
>>>>> device to its parent, and do a lookup based on that pointer to get
>>>>> information I need, but erk....
>>>>
>>>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>>>
>>>> Warner
>>

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 9:59 PM, Arnaud Lacombe wrote:

> Hi,
>
> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>> than one interface, and one of its child has need to use more than one
>>> interface, each interfaces cannot register, concurrently, its own
>>> ivar. While I try to always have a single child per
>>> interface/resource, I need to keep some compatibility with the old way
>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>> userland). So, it would have been nice if ivar had been per-interface,
>>> not global and unique to one device.
>>
>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>
>> So I'm not sure I understand what you are saying here.
>>
>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>
>> enum ivar_namespace {
>> IVAR_PCI = 1,
>> IVAR_PCCARD,
>> IVAR_USB,
>> etc
>> };
>> #define IVAR_SHIFT 16
>>
>> and the above could be changed to:
>>
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>
>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>
> ok, I think I got it now. You and I are exactly saying the same thing,
> just in different terms; there is no way to currently specify multiple
> independent (/overlapping) ivars in a child...

There's no way to support overlapping IVAR keys, yes. However, if you are designing the ivars for multiple inheritance, then you'll need to make them non-overlapping. Thankfully, this is trivial to do.

Warner

Warner_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Mon, Jul 9, 2012 at 12:37 AM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote:
>
>> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>>>
>>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>>>
>>>> Hi,
>>>>
>>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>>>
>>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>>>> than one interface, and one of its child has need to use more than one
>>>>>> interface, each interfaces cannot register, concurrently, its own
>>>>>> ivar. While I try to always have a single child per
>>>>>> interface/resource, I need to keep some compatibility with the old way
>>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>>>> not global and unique to one device.
>>>>>
>>>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>>>
>>>>> So I'm not sure I understand what you are saying here.
>>>>>
>>>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>>>> use both interfaces. There is no generic way for dev0 to export
>>>> independent ivars for both interface. For now, I restricted the
>>>> function of the second interface not to need ivar, but that's kind of
>>>> hackish.
>>>
>>> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>>>
>> I think we should not be talking about the same API here. I have no
>> idea what you mean by "the key to value translation", nor "Ivar
>> numbers". What I refer to is that device_set_ivars() /
>> device_get_ivars() acts on a single instance variables from `struct
>> device': `ivars'. In that case, I do not really see how to set that
>> specific field to two distinct values for each interfaces.
>
> We are talking about the ivar interface. You are just misunderstanding how it is used.
>
yes I indeed did... silly, silly me :-)

- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
On Monday, July 09, 2012 12:39:03 am Warner Losh wrote:
>
> On Jul 8, 2012, at 9:59 PM, Arnaud Lacombe wrote:
>
> > Hi,
> >
> > On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
> >>
> >> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
> >>> Ok, yet another Newbus' limitation. Assuming a device exports more
> >>> than one interface, and one of its child has need to use more than one
> >>> interface, each interfaces cannot register, concurrently, its own
> >>> ivar. While I try to always have a single child per
> >>> interface/resource, I need to keep some compatibility with the old way
> >>> of doing thing (POLA wrt. drivers I cannot/will not convert and
> >>> userland). So, it would have been nice if ivar had been per-interface,
> >>> not global and unique to one device.
> >>
> >> There's one pointer for the ivars. The bus code gets to determine what
the ivar looks like, because the interface is totally private to the bus. So
long as it returns the right thing for any key that's presented, it doesn't
matter quite how things are done.
> >>
> >> So I'm not sure I understand what you are saying here.
> >>
> >> The problem, more basically, is that the ivar keys are not unique.
Currently, there's no bits used in the key to define the values to be non-
overlapping. For example:
> >> enum pci_device_ivars {
> >> PCI_IVAR_SUBVENDOR,
> >> PCI_IVAR_SUBDEVICE,
> >> PCI_IVAR_VENDOR,
> >> ....
> >> };
> >>
> >> We could easily reserve the upper 16-bits of this field to be that key.
This value could then be used to differentiate them. But this wouldn't scale
too well. Given that there's only about a dozen or two in the tree, that's
right at the moment, it wouldn't be hard to do something like:
> >>
> >> enum ivar_namespace {
> >> IVAR_PCI = 1,
> >> IVAR_PCCARD,
> >> IVAR_USB,
> >> etc
> >> };
> >> #define IVAR_SHIFT 16
> >>
> >> and the above could be changed to:
> >>
> >> enum pci_device_ivars {
> >> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
> >> PCI_IVAR_SUBDEVICE,
> >> PCI_IVAR_VENDOR,
> >> ....
> >> };
> >>
> >> and then we'd have an unambiguous key, and the bus could easily implement
multiple interfaces.
> >>
> >> but then again, most of the existing interfaces in the kernel are
mutually exclusive, so you could implement this just for your new interfaces.
> >>
> > ok, I think I got it now. You and I are exactly saying the same thing,
> > just in different terms; there is no way to currently specify multiple
> > independent (/overlapping) ivars in a child...
>
> There's no way to support overlapping IVAR keys, yes. However, if you are
designing the ivars for multiple inheritance, then you'll need to make them
non-overlapping. Thankfully, this is trivial to do.

Also, I think we should do this in general. We already have one example (e.g.
ACPI IVARs start at 100 so that things like the ACPI PCI bus driver can
provide both ACPI and PCI IVARs to child devices). I think we should assign
each bus it's own IVAR range. It would make it easier to determine if a
specific IVAR is event supported. Certainly I think ISA and PCI at a minimum
should be changed to start at, say, 200 and 300.

--
John Baldwin
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Mon, Jul 9, 2012 at 1:17 AM, Arnaud Lacombe <> wrote:
> Hi,
>
> On Mon, Jul 9, 2012 at 12:37 AM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote:
>>
>>> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>>>>
>>>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>>>>
>>>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>>>>> than one interface, and one of its child has need to use more than one
>>>>>>> interface, each interfaces cannot register, concurrently, its own
>>>>>>> ivar. While I try to always have a single child per
>>>>>>> interface/resource, I need to keep some compatibility with the old way
>>>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>>>>> not global and unique to one device.
>>>>>>
>>>>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>>>>
>>>>>> So I'm not sure I understand what you are saying here.
>>>>>>
>>>>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>>>>> use both interfaces. There is no generic way for dev0 to export
>>>>> independent ivars for both interface. For now, I restricted the
>>>>> function of the second interface not to need ivar, but that's kind of
>>>>> hackish.
>>>>
>>>> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>>>>
>>> I think we should not be talking about the same API here. I have no
>>> idea what you mean by "the key to value translation", nor "Ivar
>>> numbers". What I refer to is that device_set_ivars() /
>>> device_get_ivars() acts on a single instance variables from `struct
>>> device': `ivars'. In that case, I do not really see how to set that
>>> specific field to two distinct values for each interfaces.
>>
>> We are talking about the ivar interface. You are just misunderstanding how it is used.
>>
> yes I indeed did... silly, silly me :-)
>
Actually, no. I wasn't that silly, neither was I misunderstanding
anything beside how *you* wanted it to be used, which is, I sorry to
say, unacceptable. The last thing I want is to pollute an interface
with a single-purpose, hand-crafted, bus. I was to just throw away all
that ivar stuff and go into hinted child configuration for now,
waiting for FDT... but of course, I figured out after a few hours that
hinted child attachment requires `bus_hinted_child' to be set in the
parent, as does bus_enumerate_hinted_children() / bus_generic_attach()
to explicitly pollute my code. All this stuff should be done
implicitly to support N:1 interfaces/client relationship. N
*independent* interfaces being provided by a single driver; of course,
I'm not even going back to require those interface being provided by
multiple drivers, it is already a dead end.

I am not even sure any driver in the tree provides more than one interface...

For whatever reason, I am more and more thinking that this all
new-bus[0] stuff is *way* overkill, static, bloated at will, and
missing critical features; a huge PITA to use, for the intended
purpose.

/me ****.

- Arnaud

[0]: damn, why is it even called "newbus", this stuff is 14 years old.
It really belongs to a museum, not production code...
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Mon, Jul 9, 2012 at 11:27 AM, John Baldwin <> wrote:
> Also, I think we should do this in general. We already have one example (e.g.
> ACPI IVARs start at 100 so that things like the ACPI PCI bus driver can
> provide both ACPI and PCI IVARs to child devices). I think we should assign
> each bus it's own IVAR range. It would make it easier to determine if a
> specific IVAR is event supported. Certainly I think ISA and PCI at a minimum
> should be changed to start at, say, 200 and 300.
>
What's the point doing that ? Let's just resign to the conclusion that
FreeBSD devices' subsystem provides no dynamic way for a client device
to deals with multiple bus driver. Instead all possible combination
have to be harcoded and hand-crafted, when at all possible, to look
like they're coming from a single bus...

But again, newbus is 14 years old...

- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 11, 2012, at 9:47 PM, Arnaud Lacombe wrote:

> Hi,
>
> On Mon, Jul 9, 2012 at 1:17 AM, Arnaud Lacombe <> wrote:
>> Hi,
>>
>> On Mon, Jul 9, 2012 at 12:37 AM, Warner Losh <> wrote:
>>>
>>> On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote:
>>>
>>>> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>>>>>
>>>>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>>>>>
>>>>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>>>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>>>>>> than one interface, and one of its child has need to use more than one
>>>>>>>> interface, each interfaces cannot register, concurrently, its own
>>>>>>>> ivar. While I try to always have a single child per
>>>>>>>> interface/resource, I need to keep some compatibility with the old way
>>>>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>>>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>>>>>> not global and unique to one device.
>>>>>>>
>>>>>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>>>>>
>>>>>>> So I'm not sure I understand what you are saying here.
>>>>>>>
>>>>>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>>>>>> use both interfaces. There is no generic way for dev0 to export
>>>>>> independent ivars for both interface. For now, I restricted the
>>>>>> function of the second interface not to need ivar, but that's kind of
>>>>>> hackish.
>>>>>
>>>>> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>>>>>
>>>> I think we should not be talking about the same API here. I have no
>>>> idea what you mean by "the key to value translation", nor "Ivar
>>>> numbers". What I refer to is that device_set_ivars() /
>>>> device_get_ivars() acts on a single instance variables from `struct
>>>> device': `ivars'. In that case, I do not really see how to set that
>>>> specific field to two distinct values for each interfaces.
>>>
>>> We are talking about the ivar interface. You are just misunderstanding how it is used.
>>>
>> yes I indeed did... silly, silly me :-)
>>
> Actually, no. I wasn't that silly, neither was I misunderstanding
> anything beside how *you* wanted it to be used, which is, I sorry to
> say, unacceptable. The last thing I want is to pollute an interface
> with a single-purpose, hand-crafted, bus. I was to just throw away all
> that ivar stuff and go into hinted child configuration for now,
> waiting for FDT... but of course, I figured out after a few hours that
> hinted child attachment requires `bus_hinted_child' to be set in the
> parent, as does bus_enumerate_hinted_children() / bus_generic_attach()
> to explicitly pollute my code. All this stuff should be done
> implicitly to support N:1 interfaces/client relationship. N
> *independent* interfaces being provided by a single driver; of course,
> I'm not even going back to require those interface being provided by
> multiple drivers, it is already a dead end.
>
> I am not even sure any driver in the tree provides more than one interface...
>
> For whatever reason, I am more and more thinking that this all
> new-bus[0] stuff is *way* overkill, static, bloated at will, and
> missing critical features; a huge PITA to use, for the intended
> purpose.
>
> /me ****.
>
> - Arnaud
>
> [0]: damn, why is it even called "newbus", this stuff is 14 years old.
> It really belongs to a museum, not production code...

I'm sorry you feel that way.

Honestly, though, I think you'll be more **** when you find out that the N:1 interface that you want is being done in the wrong domain. But I've been wrong before and look forward to seeing your replacement.

acpi_pcib_acpi.c, btw, implements both PCIB interfaces and ACPI interfaces.

Warner_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

Hi folks,

Ok, yet another Newbus' limitation. Assuming a device exports more
than one interface, and one of its child has need to use more than one
interface, each interfaces cannot register, concurrently, its own
ivar. While I try to always have a single child per
interface/resource, I need to keep some compatibility with the old way
of doing thing (POLA wrt. drivers I cannot/will not convert and
userland). So, it would have been nice if ivar had been per-interface,
not global and unique to one device.

Unless I am mistaken, ivar are the only way for a parent can transmit
information to a child. I can not simply implement a new METHOD to get
that ivar as the device implements multiple time the same function
(actually, up to 4 time for one, 3 for the other, with possible
crossovers...), each one physically distinct. Each child is being tied
to a pair. Thus, I need to pass each child discriminator(s) for each
interfaces right after having been *created*, which cannot be done
later on. Of course, it is out-of-question to have crossover in the
interfaces definitions.

The best way I could achieve this currently is to pass the child's
device to its parent, and do a lookup based on that pointer to get
information I need, but erk....

my 1c,
- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
> Ok, yet another Newbus' limitation. Assuming a device exports more
> than one interface, and one of its child has need to use more than one
> interface, each interfaces cannot register, concurrently, its own
> ivar. While I try to always have a single child per
> interface/resource, I need to keep some compatibility with the old way
> of doing thing (POLA wrt. drivers I cannot/will not convert and
> userland). So, it would have been nice if ivar had been per-interface,
> not global and unique to one device.

There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.

So I'm not sure I understand what you are saying here.

The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
....
};

We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:

enum ivar_namespace {
IVAR_PCI = 1,
IVAR_PCCARD,
IVAR_USB,
etc
};
#define IVAR_SHIFT 16

and the above could be changed to:

enum pci_device_ivars {
PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
....
};

and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.

but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.

> Unless I am mistaken, ivar are the only way for a parent can transmit
> information to a child. I can not simply implement a new METHOD to get
> that ivar as the device implements multiple time the same function
> (actually, up to 4 time for one, 3 for the other, with possible
> crossovers...), each one physically distinct. Each child is being tied
> to a pair. Thus, I need to pass each child discriminator(s) for each
> interfaces right after having been *created*, which cannot be done
> later on. Of course, it is out-of-question to have crossover in the
> interfaces definitions.

ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.

> The best way I could achieve this currently is to pass the child's
> device to its parent, and do a lookup based on that pointer to get
> information I need, but erk....

That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.

Warner_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>> Ok, yet another Newbus' limitation. Assuming a device exports more
>> than one interface, and one of its child has need to use more than one
>> interface, each interfaces cannot register, concurrently, its own
>> ivar. While I try to always have a single child per
>> interface/resource, I need to keep some compatibility with the old way
>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>> userland). So, it would have been nice if ivar had been per-interface,
>> not global and unique to one device.
>
> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>
> So I'm not sure I understand what you are saying here.
>
dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
use both interfaces. There is no generic way for dev0 to export
independent ivars for both interface. For now, I restricted the
function of the second interface not to need ivar, but that's kind of
hackish.

- Arnaud

> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>
> enum ivar_namespace {
> IVAR_PCI = 1,
> IVAR_PCCARD,
> IVAR_USB,
> etc
> };
> #define IVAR_SHIFT 16
>
> and the above could be changed to:
>
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>
> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>
>> Unless I am mistaken, ivar are the only way for a parent can transmit
>> information to a child. I can not simply implement a new METHOD to get
>> that ivar as the device implements multiple time the same function
>> (actually, up to 4 time for one, 3 for the other, with possible
>> crossovers...), each one physically distinct. Each child is being tied
>> to a pair. Thus, I need to pass each child discriminator(s) for each
>> interfaces right after having been *created*, which cannot be done
>> later on. Of course, it is out-of-question to have crossover in the
>> interfaces definitions.
>
> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>
>> The best way I could achieve this currently is to pass the child's
>> device to its parent, and do a lookup based on that pointer to get
>> information I need, but erk....
>
> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>
> Warner
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:

> Hi,
>
> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>> than one interface, and one of its child has need to use more than one
>>> interface, each interfaces cannot register, concurrently, its own
>>> ivar. While I try to always have a single child per
>>> interface/resource, I need to keep some compatibility with the old way
>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>> userland). So, it would have been nice if ivar had been per-interface,
>>> not global and unique to one device.
>>
>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>
>> So I'm not sure I understand what you are saying here.
>>
> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
> use both interfaces. There is no generic way for dev0 to export
> independent ivars for both interface. For now, I restricted the
> function of the second interface not to need ivar, but that's kind of
> hackish.

Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.

Warner

> - Arnaud
>
>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>
>> enum ivar_namespace {
>> IVAR_PCI = 1,
>> IVAR_PCCARD,
>> IVAR_USB,
>> etc
>> };
>> #define IVAR_SHIFT 16
>>
>> and the above could be changed to:
>>
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>
>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>
>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>> information to a child. I can not simply implement a new METHOD to get
>>> that ivar as the device implements multiple time the same function
>>> (actually, up to 4 time for one, 3 for the other, with possible
>>> crossovers...), each one physically distinct. Each child is being tied
>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>> interfaces right after having been *created*, which cannot be done
>>> later on. Of course, it is out-of-question to have crossover in the
>>> interfaces definitions.
>>
>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>
>>> The best way I could achieve this currently is to pass the child's
>>> device to its parent, and do a lookup based on that pointer to get
>>> information I need, but erk....
>>
>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>
>> Warner

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>
>> Hi,
>>
>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>
>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>> than one interface, and one of its child has need to use more than one
>>>> interface, each interfaces cannot register, concurrently, its own
>>>> ivar. While I try to always have a single child per
>>>> interface/resource, I need to keep some compatibility with the old way
>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>> not global and unique to one device.
>>>
>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>
>>> So I'm not sure I understand what you are saying here.
>>>
>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>> use both interfaces. There is no generic way for dev0 to export
>> independent ivars for both interface. For now, I restricted the
>> function of the second interface not to need ivar, but that's kind of
>> hackish.
>
> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>
I think we should not be talking about the same API here. I have no
idea what you mean by "the key to value translation", nor "Ivar
numbers". What I refer to is that device_set_ivars() /
device_get_ivars() acts on a single instance variables from `struct
device': `ivars'. In that case, I do not really see how to set that
specific field to two distinct values for each interfaces.

- Arnaud

> Warner
>
>> - Arnaud
>>
>>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>>> enum pci_device_ivars {
>>> PCI_IVAR_SUBVENDOR,
>>> PCI_IVAR_SUBDEVICE,
>>> PCI_IVAR_VENDOR,
>>> ....
>>> };
>>>
>>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>>
>>> enum ivar_namespace {
>>> IVAR_PCI = 1,
>>> IVAR_PCCARD,
>>> IVAR_USB,
>>> etc
>>> };
>>> #define IVAR_SHIFT 16
>>>
>>> and the above could be changed to:
>>>
>>> enum pci_device_ivars {
>>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>>> PCI_IVAR_SUBDEVICE,
>>> PCI_IVAR_VENDOR,
>>> ....
>>> };
>>>
>>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>>
>>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>>
>>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>>> information to a child. I can not simply implement a new METHOD to get
>>>> that ivar as the device implements multiple time the same function
>>>> (actually, up to 4 time for one, 3 for the other, with possible
>>>> crossovers...), each one physically distinct. Each child is being tied
>>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>>> interfaces right after having been *created*, which cannot be done
>>>> later on. Of course, it is out-of-question to have crossover in the
>>>> interfaces definitions.
>>>
>>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>>
>>>> The best way I could achieve this currently is to pass the child's
>>>> device to its parent, and do a lookup based on that pointer to get
>>>> information I need, but erk....
>>>
>>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>>
>>> Warner
>
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>> Ok, yet another Newbus' limitation. Assuming a device exports more
>> than one interface, and one of its child has need to use more than one
>> interface, each interfaces cannot register, concurrently, its own
>> ivar. While I try to always have a single child per
>> interface/resource, I need to keep some compatibility with the old way
>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>> userland). So, it would have been nice if ivar had been per-interface,
>> not global and unique to one device.
>
> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>
> So I'm not sure I understand what you are saying here.
>
> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>
> enum ivar_namespace {
> IVAR_PCI = 1,
> IVAR_PCCARD,
> IVAR_USB,
> etc
> };
> #define IVAR_SHIFT 16
>
> and the above could be changed to:
>
> enum pci_device_ivars {
> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
> PCI_IVAR_SUBDEVICE,
> PCI_IVAR_VENDOR,
> ....
> };
>
> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>
> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>
ok, I think I got it now. You and I are exactly saying the same thing,
just in different terms; there is no way to currently specify multiple
independent (/overlapping) ivars in a child...

- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote:

> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>>
>>> Hi,
>>>
>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>>
>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>>> than one interface, and one of its child has need to use more than one
>>>>> interface, each interfaces cannot register, concurrently, its own
>>>>> ivar. While I try to always have a single child per
>>>>> interface/resource, I need to keep some compatibility with the old way
>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>>> not global and unique to one device.
>>>>
>>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>>
>>>> So I'm not sure I understand what you are saying here.
>>>>
>>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>>> use both interfaces. There is no generic way for dev0 to export
>>> independent ivars for both interface. For now, I restricted the
>>> function of the second interface not to need ivar, but that's kind of
>>> hackish.
>>
>> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>>
> I think we should not be talking about the same API here. I have no
> idea what you mean by "the key to value translation", nor "Ivar
> numbers". What I refer to is that device_set_ivars() /
> device_get_ivars() acts on a single instance variables from `struct
> device': `ivars'. In that case, I do not really see how to set that
> specific field to two distinct values for each interfaces.

We are talking about the ivar interface. You are just misunderstanding how it is used.

Let us say that dev0 wants to implement interface A and B. The interface it implements is the device_read _ivar method. That method looks like:

int pci_read_ivar(device_t dev, device_t child, int which, uintptr_t *result)
{
struct pci_ivar *iv = device_get_ivar(child);

switch (which) {
case PCI_IVAR_SUBVENDOR:
*result = iv->subvendor;
break;
...
default:
return EINVAL;
}
return 0;
}

So, if you wanted to implement interface A and interface B, you would have to support reading and writing A_IVAR_* and B_IVAR_*. The above routine would look like:

struct mydev_ivar {
int a_1;
int a_2;
int b_1;
int b_2;
};

int mydev_read_ivar(device_t dev, device child, int which, uintpr_t *result)
{
struct mydev_ivar *iv = device_get_ivar(child);

switch (which) {
case A_IVAR_1:
*result = iv->a_1;
break;
case A_IVAR_2:
*result = iv->a_2;
break;
case B_IVAR_1:
*result = iv->b_1;
break;
case B_IVAR_2:
*result = iv->b_2;
break;
default:
return EINVAL;
}
return 0;
}

and similar for the write routine. Now, there are some busses that provide convenience structures and functions for dealing with the ivars. In that case, you'd be able to use the wrapper structures and routines like so:

struct mdev_ivar {
struct a_ivar a;
struct b_ivar b;
};

int mydev_read_ivar(device_t dev, device child, int which, uintpr_t *result)
{
struct mydev_ivar *iv = device_get_ivar(child);

switch (which) {
case A_IVAR_1:
case A_IVAR_2:
return a_helper_read_ivar(&iv->a, which, result);
case B_IVAR_1:
case B_IVAR_2:
return b_helper_read_ivar(&iv->b, which, result);
default:
return EINVAL;
}
return 0;
}

Both of these work only if the A_IVAR values are disjoint from the B_IVAR values. Your mydev device is the one that sets the ivar on dev1, in your example, so it would know how to malloc and create the mydev_ivar structure, even if the interfaces it is implementing provide helper functions, like I've outlined above.

Warner



> - Arnaud
>
>> Warner
>>
>>> - Arnaud
>>>
>>>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>>>> enum pci_device_ivars {
>>>> PCI_IVAR_SUBVENDOR,
>>>> PCI_IVAR_SUBDEVICE,
>>>> PCI_IVAR_VENDOR,
>>>> ....
>>>> };
>>>>
>>>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>>>
>>>> enum ivar_namespace {
>>>> IVAR_PCI = 1,
>>>> IVAR_PCCARD,
>>>> IVAR_USB,
>>>> etc
>>>> };
>>>> #define IVAR_SHIFT 16
>>>>
>>>> and the above could be changed to:
>>>>
>>>> enum pci_device_ivars {
>>>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>>>> PCI_IVAR_SUBDEVICE,
>>>> PCI_IVAR_VENDOR,
>>>> ....
>>>> };
>>>>
>>>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>>>
>>>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>>>
>>>>> Unless I am mistaken, ivar are the only way for a parent can transmit
>>>>> information to a child. I can not simply implement a new METHOD to get
>>>>> that ivar as the device implements multiple time the same function
>>>>> (actually, up to 4 time for one, 3 for the other, with possible
>>>>> crossovers...), each one physically distinct. Each child is being tied
>>>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>>>> interfaces right after having been *created*, which cannot be done
>>>>> later on. Of course, it is out-of-question to have crossover in the
>>>>> interfaces definitions.
>>>>
>>>> ivars are but one way to communicate this. However, they are the generic way to convert a key to a value and store a key on a value. I don't really understand what you are trying to say here, perhaps an example would help illustrate what you are trying to do, since I don't quite understand the problem here.
>>>>
>>>>> The best way I could achieve this currently is to pass the child's
>>>>> device to its parent, and do a lookup based on that pointer to get
>>>>> information I need, but erk....
>>>>
>>>> That doesn't make any sense. The child's parent already sets that child's ivar when the child is created. The child's parent already gets a pointer to the child when asked to do the key to value translation. Again, perhaps an example would help here.
>>>>
>>>> Warner
>>

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 8, 2012, at 9:59 PM, Arnaud Lacombe wrote:

> Hi,
>
> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>> than one interface, and one of its child has need to use more than one
>>> interface, each interfaces cannot register, concurrently, its own
>>> ivar. While I try to always have a single child per
>>> interface/resource, I need to keep some compatibility with the old way
>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>> userland). So, it would have been nice if ivar had been per-interface,
>>> not global and unique to one device.
>>
>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>
>> So I'm not sure I understand what you are saying here.
>>
>> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non-overlapping. For example:
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like:
>>
>> enum ivar_namespace {
>> IVAR_PCI = 1,
>> IVAR_PCCARD,
>> IVAR_USB,
>> etc
>> };
>> #define IVAR_SHIFT 16
>>
>> and the above could be changed to:
>>
>> enum pci_device_ivars {
>> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>> PCI_IVAR_SUBDEVICE,
>> PCI_IVAR_VENDOR,
>> ....
>> };
>>
>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>
>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>
> ok, I think I got it now. You and I are exactly saying the same thing,
> just in different terms; there is no way to currently specify multiple
> independent (/overlapping) ivars in a child...

There's no way to support overlapping IVAR keys, yes. However, if you are designing the ivars for multiple inheritance, then you'll need to make them non-overlapping. Thankfully, this is trivial to do.

Warner

Warner_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Mon, Jul 9, 2012 at 12:37 AM, Warner Losh <> wrote:
>
> On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote:
>
>> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>>>
>>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>>>
>>>> Hi,
>>>>
>>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>>>
>>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>>>> than one interface, and one of its child has need to use more than one
>>>>>> interface, each interfaces cannot register, concurrently, its own
>>>>>> ivar. While I try to always have a single child per
>>>>>> interface/resource, I need to keep some compatibility with the old way
>>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>>>> not global and unique to one device.
>>>>>
>>>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>>>
>>>>> So I'm not sure I understand what you are saying here.
>>>>>
>>>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>>>> use both interfaces. There is no generic way for dev0 to export
>>>> independent ivars for both interface. For now, I restricted the
>>>> function of the second interface not to need ivar, but that's kind of
>>>> hackish.
>>>
>>> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>>>
>> I think we should not be talking about the same API here. I have no
>> idea what you mean by "the key to value translation", nor "Ivar
>> numbers". What I refer to is that device_set_ivars() /
>> device_get_ivars() acts on a single instance variables from `struct
>> device': `ivars'. In that case, I do not really see how to set that
>> specific field to two distinct values for each interfaces.
>
> We are talking about the ivar interface. You are just misunderstanding how it is used.
>
yes I indeed did... silly, silly me :-)

- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
On Monday, July 09, 2012 12:39:03 am Warner Losh wrote:
>
> On Jul 8, 2012, at 9:59 PM, Arnaud Lacombe wrote:
>
> > Hi,
> >
> > On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
> >>
> >> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
> >>> Ok, yet another Newbus' limitation. Assuming a device exports more
> >>> than one interface, and one of its child has need to use more than one
> >>> interface, each interfaces cannot register, concurrently, its own
> >>> ivar. While I try to always have a single child per
> >>> interface/resource, I need to keep some compatibility with the old way
> >>> of doing thing (POLA wrt. drivers I cannot/will not convert and
> >>> userland). So, it would have been nice if ivar had been per-interface,
> >>> not global and unique to one device.
> >>
> >> There's one pointer for the ivars. The bus code gets to determine what
the ivar looks like, because the interface is totally private to the bus. So
long as it returns the right thing for any key that's presented, it doesn't
matter quite how things are done.
> >>
> >> So I'm not sure I understand what you are saying here.
> >>
> >> The problem, more basically, is that the ivar keys are not unique.
Currently, there's no bits used in the key to define the values to be non-
overlapping. For example:
> >> enum pci_device_ivars {
> >> PCI_IVAR_SUBVENDOR,
> >> PCI_IVAR_SUBDEVICE,
> >> PCI_IVAR_VENDOR,
> >> ....
> >> };
> >>
> >> We could easily reserve the upper 16-bits of this field to be that key.
This value could then be used to differentiate them. But this wouldn't scale
too well. Given that there's only about a dozen or two in the tree, that's
right at the moment, it wouldn't be hard to do something like:
> >>
> >> enum ivar_namespace {
> >> IVAR_PCI = 1,
> >> IVAR_PCCARD,
> >> IVAR_USB,
> >> etc
> >> };
> >> #define IVAR_SHIFT 16
> >>
> >> and the above could be changed to:
> >>
> >> enum pci_device_ivars {
> >> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
> >> PCI_IVAR_SUBDEVICE,
> >> PCI_IVAR_VENDOR,
> >> ....
> >> };
> >>
> >> and then we'd have an unambiguous key, and the bus could easily implement
multiple interfaces.
> >>
> >> but then again, most of the existing interfaces in the kernel are
mutually exclusive, so you could implement this just for your new interfaces.
> >>
> > ok, I think I got it now. You and I are exactly saying the same thing,
> > just in different terms; there is no way to currently specify multiple
> > independent (/overlapping) ivars in a child...
>
> There's no way to support overlapping IVAR keys, yes. However, if you are
designing the ivars for multiple inheritance, then you'll need to make them
non-overlapping. Thankfully, this is trivial to do.

Also, I think we should do this in general. We already have one example (e.g.
ACPI IVARs start at 100 so that things like the ACPI PCI bus driver can
provide both ACPI and PCI IVARs to child devices). I think we should assign
each bus it's own IVAR range. It would make it easier to determine if a
specific IVAR is event supported. Certainly I think ISA and PCI at a minimum
should be changed to start at, say, 200 and 300.

--
John Baldwin
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Mon, Jul 9, 2012 at 1:17 AM, Arnaud Lacombe <> wrote:
> Hi,
>
> On Mon, Jul 9, 2012 at 12:37 AM, Warner Losh <> wrote:
>>
>> On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote:
>>
>>> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>>>>
>>>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>>>>
>>>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>>>>> than one interface, and one of its child has need to use more than one
>>>>>>> interface, each interfaces cannot register, concurrently, its own
>>>>>>> ivar. While I try to always have a single child per
>>>>>>> interface/resource, I need to keep some compatibility with the old way
>>>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>>>>> not global and unique to one device.
>>>>>>
>>>>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>>>>
>>>>>> So I'm not sure I understand what you are saying here.
>>>>>>
>>>>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>>>>> use both interfaces. There is no generic way for dev0 to export
>>>>> independent ivars for both interface. For now, I restricted the
>>>>> function of the second interface not to need ivar, but that's kind of
>>>>> hackish.
>>>>
>>>> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>>>>
>>> I think we should not be talking about the same API here. I have no
>>> idea what you mean by "the key to value translation", nor "Ivar
>>> numbers". What I refer to is that device_set_ivars() /
>>> device_get_ivars() acts on a single instance variables from `struct
>>> device': `ivars'. In that case, I do not really see how to set that
>>> specific field to two distinct values for each interfaces.
>>
>> We are talking about the ivar interface. You are just misunderstanding how it is used.
>>
> yes I indeed did... silly, silly me :-)
>
Actually, no. I wasn't that silly, neither was I misunderstanding
anything beside how *you* wanted it to be used, which is, I sorry to
say, unacceptable. The last thing I want is to pollute an interface
with a single-purpose, hand-crafted, bus. I was to just throw away all
that ivar stuff and go into hinted child configuration for now,
waiting for FDT... but of course, I figured out after a few hours that
hinted child attachment requires `bus_hinted_child' to be set in the
parent, as does bus_enumerate_hinted_children() / bus_generic_attach()
to explicitly pollute my code. All this stuff should be done
implicitly to support N:1 interfaces/client relationship. N
*independent* interfaces being provided by a single driver; of course,
I'm not even going back to require those interface being provided by
multiple drivers, it is already a dead end.

I am not even sure any driver in the tree provides more than one interface...

For whatever reason, I am more and more thinking that this all
new-bus[0] stuff is *way* overkill, static, bloated at will, and
missing critical features; a huge PITA to use, for the intended
purpose.

/me ****.

- Arnaud

[0]: damn, why is it even called "newbus", this stuff is 14 years old.
It really belongs to a museum, not production code...
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Mon, Jul 9, 2012 at 11:27 AM, John Baldwin <> wrote:
> Also, I think we should do this in general. We already have one example (e.g.
> ACPI IVARs start at 100 so that things like the ACPI PCI bus driver can
> provide both ACPI and PCI IVARs to child devices). I think we should assign
> each bus it's own IVAR range. It would make it easier to determine if a
> specific IVAR is event supported. Certainly I think ISA and PCI at a minimum
> should be changed to start at, say, 200 and 300.
>
What's the point doing that ? Let's just resign to the conclusion that
FreeBSD devices' subsystem provides no dynamic way for a client device
to deals with multiple bus driver. Instead all possible combination
have to be harcoded and hand-crafted, when at all possible, to look
like they're coming from a single bus...

But again, newbus is 14 years old...

- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)

On Jul 11, 2012, at 9:47 PM, Arnaud Lacombe wrote:

> Hi,
>
> On Mon, Jul 9, 2012 at 1:17 AM, Arnaud Lacombe <> wrote:
>> Hi,
>>
>> On Mon, Jul 9, 2012 at 12:37 AM, Warner Losh <> wrote:
>>>
>>> On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote:
>>>
>>>> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <> wrote:
>>>>>
>>>>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <> wrote:
>>>>>>>
>>>>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>>>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>>>>>> than one interface, and one of its child has need to use more than one
>>>>>>>> interface, each interfaces cannot register, concurrently, its own
>>>>>>>> ivar. While I try to always have a single child per
>>>>>>>> interface/resource, I need to keep some compatibility with the old way
>>>>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>>>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>>>>>> not global and unique to one device.
>>>>>>>
>>>>>>> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>>>>>
>>>>>>> So I'm not sure I understand what you are saying here.
>>>>>>>
>>>>>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>>>>>> use both interfaces. There is no generic way for dev0 to export
>>>>>> independent ivars for both interface. For now, I restricted the
>>>>>> function of the second interface not to need ivar, but that's kind of
>>>>>> hackish.
>>>>>
>>>>> Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>>>>>
>>>> I think we should not be talking about the same API here. I have no
>>>> idea what you mean by "the key to value translation", nor "Ivar
>>>> numbers". What I refer to is that device_set_ivars() /
>>>> device_get_ivars() acts on a single instance variables from `struct
>>>> device': `ivars'. In that case, I do not really see how to set that
>>>> specific field to two distinct values for each interfaces.
>>>
>>> We are talking about the ivar interface. You are just misunderstanding how it is used.
>>>
>> yes I indeed did... silly, silly me :-)
>>
> Actually, no. I wasn't that silly, neither was I misunderstanding
> anything beside how *you* wanted it to be used, which is, I sorry to
> say, unacceptable. The last thing I want is to pollute an interface
> with a single-purpose, hand-crafted, bus. I was to just throw away all
> that ivar stuff and go into hinted child configuration for now,
> waiting for FDT... but of course, I figured out after a few hours that
> hinted child attachment requires `bus_hinted_child' to be set in the
> parent, as does bus_enumerate_hinted_children() / bus_generic_attach()
> to explicitly pollute my code. All this stuff should be done
> implicitly to support N:1 interfaces/client relationship. N
> *independent* interfaces being provided by a single driver; of course,
> I'm not even going back to require those interface being provided by
> multiple drivers, it is already a dead end.
>
> I am not even sure any driver in the tree provides more than one interface...
>
> For whatever reason, I am more and more thinking that this all
> new-bus[0] stuff is *way* overkill, static, bloated at will, and
> missing critical features; a huge PITA to use, for the intended
> purpose.
>
> /me ****.
>
> - Arnaud
>
> [0]: damn, why is it even called "newbus", this stuff is 14 years old.
> It really belongs to a museum, not production code...

I'm sorry you feel that way.

Honestly, though, I think you'll be more **** when you find out that the N:1 interface that you want is being done in the wrong domain. But I've been wrong before and look forward to seeing your replacement.

acpi_pcib_acpi.c, btw, implements both PCIB interfaces and ACPI interfaces.

Warner_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)
Hi,

On Thu, Jul 12, 2012 at 1:20 AM, Warner Losh <> wrote:
> I'm sorry you feel that way.
>
> Honestly, though, I think you'll be more ****ed when you find out that the N:1 interface that you want is being done in the wrong domain. But I've been wrong before and look forward to seeing your replacement.
>
> acpi_pcib_acpi.c, btw, implements both PCIB interfaces and ACPI interfaces.
>
Does it ? From the definition of `acpi_pcib_acpi_methods', I can only
see a single pcib(4) interface being exported. Moreover, I do not seem
to be able to find any clue that would led any ACPI devices to attach
on acpi_pcib_acpi(4), neither to find how could acpi_get_flags() ends
up in acpi_pcib_read_ivar() ?

Thks,
- Arnaud
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-"
)