On 3/11/10, Qing Li wrote:
> Author: qingli
> Date: Thu Mar 11 17:56:46 2010
> New Revision: 205024
> URL: http://svn.freebsd.org/changeset/base/205024
>
> Log:
> The if_tap interface is of IFT_ETHERNET type, but it
> does not set or update the if_link_state variable.
> As such RT_LINK_IS_UP
julian> probably should add a flag that means "we have media state"
julian> and if it is not set, assume it is always on.
qing> That's a good idea. I will take your approach.
I do too. While I have many of the older cards that don't support
media detect (because the chips don't report that info)
On Mar 12, 2010, at 6:56 PM, Qing Li wrote:
> Right now I like to implement Robert's suggestion of using if_capabilities
> field. I'd like to create a new flag, IFCAP_LINKSTATE_NOTIFY flag.
> The routing decision will check against the if_link_state if this bit
> is set.
>
> Only a handful of dr
>
> We've got LINK_STATE_UNKNOWN, we can just initialize if_link_state to
> this value in ether_ifattach(). And Qing should treat this value as
> LINK_STATE_UP in routing decision until better times.
>
Thanks everyone for your input.
I generally try to avoid overloading a variable to have more th
In message:
Juli Mallett writes:
: On Thu, Mar 11, 2010 at 15:30, Qing Li wrote:
: >>
: >> A couple of questions:
: >>
: >> (1) It used to be the case that quite a few interface drivers and types
: >> didn't have a notion of "link up" -- especially older ethernet devices. Do
: >> th
On Thu, Mar 11, 2010 at 11:15:21PM -0800, Julian Elischer wrote:
J> Juli Mallett wrote:
J> > On Thu, Mar 11, 2010 at 15:39, Qing Li wrote:
J> >> I guess it's a good time to clean things up. The if_link_state code has
been
J> >> around for quite some time, either it be fully utilized or not be the
Any objections to making AF_NETLINK Foundation proposal public?
Might help FreeBSD get out of the niche a bit more; energy quantum wells
are never great.
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To
On Mar 12, 2010, at 8:44 AM, Julian Elischer wrote:
> I'm confused about Julian's proposal because it seems to me that we
> already know when a driver hasn't set or is unable to determine the link
> state: it will (should) be set to LINK_STATE_UNKNOWN by default.
>
> the question i
Julian Elischer wrote:
Robert N. M. Watson wrote:
Today, we support three link state values:
170 /*
171 * Values for if_link_state.
172 */
173 #define LINK_STATE_UNKNOWN 0 /* link invalid/unknown */
174 #define LINK_STATE_DOWN 1 /* link is down */
175 #define LINK_
Robert N. M. Watson wrote:
On Mar 12, 2010, at 8:30 AM, Qing Li wrote:
I believe what Julian means is the following:
1. in the driver, I do this
ifp->if_flags |= IFF_KNOWS_LINK_STATE;
2. In route.h, I do this
if (ifp->flags & IFF_KNOWS_LINK_STATE) && (ifp->if_link_state ==
LINK_STATE
On Mar 12, 2010, at 8:30 AM, Qing Li wrote:
> I believe what Julian means is the following:
>
> 1. in the driver, I do this
>
> ifp->if_flags |= IFF_KNOWS_LINK_STATE;
>
> 2. In route.h, I do this
>
>if (ifp->flags & IFF_KNOWS_LINK_STATE) && (ifp->if_link_state ==
> LINK_STATE_UP)
>
Nope, I meant Julian, and what he proposed, and if I understood
correctly, is the simplest
approach and easily done.
-- Qing
On Fri, Mar 12, 2010 at 12:29 AM, Robert N. M. Watson
wrote:
>
> On Mar 12, 2010, at 8:11 AM, Qing Li wrote:
>
>> I like Julian's suggestion because it is simple and very
I believe what Julian means is the following:
1. in the driver, I do this
ifp->if_flags |= IFF_KNOWS_LINK_STATE;
2. In route.h, I do this
if (ifp->flags & IFF_KNOWS_LINK_STATE) && (ifp->if_link_state ==
LINK_STATE_UP)
return 1;
-- Qing
On Fri, Mar 12, 2010 at 12:26 AM, Robert
On Mar 12, 2010, at 8:11 AM, Qing Li wrote:
> I like Julian's suggestion because it is simple and very low risk.
> And there isn't a need to check for interface type any more.
> Here is why:
Re-reading this e-mail: perhaps you mean Juli, not Julian?
Robert
>
> 1. The interfaces that are popul
On Fri, Mar 12, 2010 at 00:11, Qing Li wrote:
> I like Julian's suggestion because it is simple and very low risk.
> And there isn't a need to check for interface type any more.
> Here is why:
For actual link state, you can already see whether a driver is in
UNKNOWN state, like:
%%%
/*
* Values
On Mar 12, 2010, at 8:11 AM, Qing Li wrote:
> I like Julian's suggestion because it is simple and very low risk.
> And there isn't a need to check for interface type any more.
> Here is why:
>
> 1. The interfaces that are popular and modern are already supporting
>link_state. So for these dr
I like Julian's suggestion because it is simple and very low risk.
And there isn't a need to check for interface type any more.
Here is why:
1. The interfaces that are popular and modern are already supporting
link_state. So for these drivers, and there are just a few, I will go set
its if
On Mar 12, 2010, at 7:52 AM, Qing Li wrote:
>> Is there any way we can pick up via an assertion that an interface driver
>> has failed to implement this functionality? This has never been a historic
>> requirement, so I suspect there are a lot of drivers floating around that
>> fail to meet th
>
> Is there any way we can pick up via an assertion that an interface driver has
> failed to implement this functionality? This has never been a historic
> requirement, so I suspect there are a lot of drivers floating around that
> fail to meet the requirement. Also, is this for IFT_ETHER only,
On Mar 12, 2010, at 12:18 AM, Qing Li wrote:
> You definitely have a very good point here. I was a bit surprised
> during debugging that the link state is not consistently initialized
> and by far not enforced across all of the drivers. Admittedly I checked
> the most commonly deployed devic
On Mar 11, 2010, at 11:30 PM, Qing Li wrote:
> What you raised is definitely a possibility and these fixes take the
> similar approach. I am going to try and go through each of these
> drivers in /sys/dev/ and converting them, very soon.
Is there any way we can pick up via an assertion that a
That's a good idea. I will take your approach.
-- Qing
On Thu, Mar 11, 2010 at 11:15 PM, Julian Elischer wrote:
> Juli Mallett wrote:
>>
>> On Thu, Mar 11, 2010 at 15:39, Qing Li wrote:
>>>
>>> I guess it's a good time to clean things up. The if_link_state code has
>>> been
>>> around for quit
Juli Mallett wrote:
On Thu, Mar 11, 2010 at 15:39, Qing Li wrote:
I guess it's a good time to clean things up. The if_link_state code has been
around for quite some time, either it be fully utilized or not be there at all.
The inconsistency is the root cause.
Sure. There is an increasing amo
On Thu, Mar 11, 2010 at 03:35:13PM -0800, Juli Mallett wrote:
> On Thu, Mar 11, 2010 at 15:30, Qing Li wrote:
> >>
> >> A couple of questions:
> >>
> >> (1) It used to be the case that quite a few interface drivers and types
> >> didn't have a notion of "link up" -- especially older ethernet devic
>
> If you can think of a way to add some invariants (warn the first time
> a driver receives a packet without having ever set the link state,
> make sure the media status callback sets the valid flag in the
> request, etc) that would probably be very helpful for people who are
> writing network dr
On Thu, Mar 11, 2010 at 15:39, Qing Li wrote:
> I guess it's a good time to clean things up. The if_link_state code has been
> around for quite some time, either it be fully utilized or not be there at
> all.
> The inconsistency is the root cause.
Sure. There is an increasing amount of stuff th
I guess it's a good time to clean things up. The if_link_state code has been
around for quite some time, either it be fully utilized or not be there at all.
The inconsistency is the root cause.
I will try going through these tonight and hopefully the fix all take a
common approach.
-- Qing
On T
On Thu, Mar 11, 2010 at 15:30, Qing Li wrote:
>>
>> A couple of questions:
>>
>> (1) It used to be the case that quite a few interface drivers and types
>> didn't have a notion of "link up" -- especially older ethernet devices. Do
>> those all have the same problem? It was probably a design over
>
> A couple of questions:
>
> (1) It used to be the case that quite a few interface drivers and types
> didn't have a notion of "link up" -- especially older ethernet devices. Do
> those all have the same problem? It was probably a design oversight that
> devices don't declare an explicit capabi
On Thu, 11 Mar 2010, Qing Li wrote:
The if_tap interface is of IFT_ETHERNET type, but it
does not set or update the if_link_state variable.
As such RT_LINK_IS_UP() fails for the if_tap interface.
Also, the RT_LINK_IS_UP() needs to bypass all loopback
interfaces because loopback interfaces
Author: qingli
Date: Thu Mar 11 17:56:46 2010
New Revision: 205024
URL: http://svn.freebsd.org/changeset/base/205024
Log:
The if_tap interface is of IFT_ETHERNET type, but it
does not set or update the if_link_state variable.
As such RT_LINK_IS_UP() fails for the if_tap interface.
Also,
31 matches
Mail list logo
