ifnet specific data

[YAMAMOTO Takashi]

hi,

i'd like to implement something like the following:

ifnet_specific_key_t ifnet_specific_key_create(void);
void ifnet_specific_key_destroy(ifnet_specific_key_t);
void *ifnet_getspecific(struct ifnet *, ifnet_specific_key_t);
void ifnet_setspecific(struct ifnet *, ifnet_specific_key_t, void *);

the goal is to replace if_agrprivate and if_afdata[], at least.

any comments?

YAMAMOTO Takashi

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Post by YAMAMOTO Takashi
ifnet_specific_key_t ifnet_specific_key_create(void);
void ifnet_specific_key_destroy(ifnet_specific_key_t);
void *ifnet_getspecific(struct ifnet *, ifnet_specific_key_t);
void ifnet_setspecific(struct ifnet *, ifnet_specific_key_t, void *);

How about doing something like

prop_dictionary_t dv_properties;/* properties dictionary */

in struct device instead? That way we could have an analogon to
device_properties(), like ifnet_properties().

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Only if specifickey won't be used in interrupt mode.

Good point.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Matt Thomas]

Post by Martin Husemann

Post by YAMAMOTO Takashi
ifnet_specific_key_t ifnet_specific_key_create(void);
void ifnet_specific_key_destroy(ifnet_specific_key_t);
void *ifnet_getspecific(struct ifnet *, ifnet_specific_key_t);
void ifnet_setspecific(struct ifnet *, ifnet_specific_key_t, void *);

How about doing something like
prop_dictionary_t dv_properties;/* properties dictionary */
in struct device instead? That way we could have an analogon to
device_properties(), like ifnet_properties().

Only if specifickey won't be used in interrupt mode. and most network
stuff is in hard or soft interrupt mode.



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Bill Studenmund]

Post by Matt Thomas

Post by Martin Husemann

Post by YAMAMOTO Takashi
ifnet_specific_key_t ifnet_specific_key_create(void);
void ifnet_specific_key_destroy(ifnet_specific_key_t);
void *ifnet_getspecific(struct ifnet *, ifnet_specific_key_t);
void ifnet_setspecific(struct ifnet *, ifnet_specific_key_t, void *);

How about doing something like
prop_dictionary_t dv_properties;/* properties dictionary */
in struct device instead? That way we could have an analogon to
device_properties(), like ifnet_properties().

Only if specifickey won't be used in interrupt mode. and most network
stuff is in hard or soft interrupt mode.

Yes & no. What we could do is have the dictionary and have shadow
variables. Change the dict, and the shadow variables change too. Think of
these variables as caching the result of key lookups. While we can't look
in the dictionary in interrupt context, if we do it right, we _can_ look
at the shadow variables. Put another way, as long as we don't do it wrong,
we can read the shadow variables.

This does mean we need to know when the dictionary changes (as long as the
driver gets called, not hard). Also, it means that the dictionary can't
contain state that needs gathering at interrupt context. Though I doubt
anyone would use a properties dictionary for that. :-)

Take care,

Bill

[YAMAMOTO Takashi]

Post by Bill Studenmund
Yes & no. What we could do is have the dictionary and have shadow
variables. Change the dict, and the shadow variables change too. Think of
these variables as caching the result of key lookups. While we can't look
in the dictionary in interrupt context, if we do it right, we _can_ look
at the shadow variables. Put another way, as long as we don't do it wrong,
we can read the shadow variables.
This does mean we need to know when the dictionary changes (as long as the
driver gets called, not hard). Also, it means that the dictionary can't
contain state that needs gathering at interrupt context. Though I doubt
anyone would use a properties dictionary for that. :-)

what's the point to have a dictionary at all in addition to the
"shadow variables"?

YAMAMOTO Takashi

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Bill Studenmund]

Post by YAMAMOTO Takashi

Post by Bill Studenmund
Yes & no. What we could do is have the dictionary and have shadow
variables. Change the dict, and the shadow variables change too. Think of
these variables as caching the result of key lookups. While we can't look
in the dictionary in interrupt context, if we do it right, we _can_ look
at the shadow variables. Put another way, as long as we don't do it wrong,
we can read the shadow variables.
This does mean we need to know when the dictionary changes (as long as the
driver gets called, not hard). Also, it means that the dictionary can't
contain state that needs gathering at interrupt context. Though I doubt
anyone would use a properties dictionary for that. :-)

what's the point to have a dictionary at all in addition to the
"shadow variables"?

I'm assuming that not everything in the dictionary needs a shadow
variable. If that's wrong (i.e. everything needs a shadow variable),
there's no point.

I also expect that we will be adding more-general device driver uses for
a dictionary. So we will have both "non-shadow-variable" uses for a dict,
and we will need to figure out how to handle this eventually.

Take care,

Bill

[YAMAMOTO Takashi]

Post by Bill Studenmund

Post by YAMAMOTO Takashi

Post by Bill Studenmund
Yes & no. What we could do is have the dictionary and have shadow
variables. Change the dict, and the shadow variables change too. Think of
these variables as caching the result of key lookups. While we can't look
in the dictionary in interrupt context, if we do it right, we _can_ look
at the shadow variables. Put another way, as long as we don't do it wrong,
we can read the shadow variables.
This does mean we need to know when the dictionary changes (as long as the
driver gets called, not hard). Also, it means that the dictionary can't
contain state that needs gathering at interrupt context. Though I doubt
anyone would use a properties dictionary for that. :-)

what's the point to have a dictionary at all in addition to the
"shadow variables"?

I'm assuming that not everything in the dictionary needs a shadow
variable. If that's wrong (i.e. everything needs a shadow variable),
there's no point.
I also expect that we will be adding more-general device driver uses for
a dictionary. So we will have both "non-shadow-variable" uses for a dict,
and we will need to figure out how to handle this eventually.
Take care,
Bill

can you explain why you think an item should be in both of
"shadow variables" and a dictionary?
i don't see any benefit to use proplib dictionary here...

YAMAMOTO Takashi

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Bill Studenmund]

Post by YAMAMOTO Takashi

Post by Bill Studenmund
I'm assuming that not everything in the dictionary needs a shadow
variable. If that's wrong (i.e. everything needs a shadow variable),
there's no point.
I also expect that we will be adding more-general device driver uses for
a dictionary. So we will have both "non-shadow-variable" uses for a dict,
and we will need to figure out how to handle this eventually.

can you explain why you think an item should be in both of
"shadow variables" and a dictionary?
i don't see any benefit to use proplib dictionary here...

So we can have a dictionary that contains the "state" of the device. So
that all of the state moves around as one.

The whole idea is to use "shadow variables" as a way to let us effectively
use a dictionary for things we techically can't. Obviously we'd only do
this if it made sense...

Take care,

Bill