Hi David, here is an updated version with the following changes: -split the patch: First adds the userspace notification, the other (depends on the first) RFC2863 semantics. I am aware that we are we
Pardon my dumb question, but what parts of RFC2863 require kernel additions over and above your link state patch? Your second patch I am less enthusiastic about than the first... :( I wonder if users
the kernel does not know LOWERLAYERDOWN, TESTING, DORMANT, UNKNOWN. They can be useful when drivers adopt to this scheme. Well, with your opinion I count two against two: I want it, Jamal has propos
Stefans curtrent patch makes the info available via netlink. What dont you like about it Jeff? Take a quick look at RFC2863 and scan for IfAdminStatus and IfOperStatus. The modelling RFC2863 has is p
jamal wrote: Stefans curtrent patch makes the info available via netlink. He has two patches: link change notification, and RFC2863 operstatus. I agree with the first one and support its inclusion; t
Stefan Rompf wrote: Your second patch I am less enthusiastic about than the first... :( Well, with your opinion I count two against two: I want it, Jamal has proposed the semantics, and Alexey doesn'
I somehow deleted the original email he sent with the patches. What two patches? I thought he had one which was a backport and another which was for 2.5.x (sorry, i actually have seen those patches a
I've splitted the patch into userspace notification and RFC2863 part to separate the features clearly and get the discussion running again. That seem to have worked ;-) As an example, how do we flag
I would summarize his patch as adding variable to represent literally ifOperStatus, along with a lock and apparatus to set this variable. The value may be deduced, without having to literally track i
If it can be deduced then no point in tracking it. i think my shepherding of the patch is done at this point. I'll let you take it from here. BTW, I still think theres need to clean up the qdisc queu
Hi David, here is an updated version with the following changes: -split the patch: First adds the userspace notification, the other (depends on the first) RFC2863 semantics. I am aware that we are we
Pardon my dumb question, but what parts of RFC2863 require kernel additions over and above your link state patch? Your second patch I am less enthusiastic about than the first... :( I wonder if users
Hi, the kernel does not know LOWERLAYERDOWN, TESTING, DORMANT, UNKNOWN. They can be useful when drivers adopt to this scheme. Well, with your opinion I count two against two: I want it, Jamal has pro
Stefans curtrent patch makes the info available via netlink. What dont you like about it Jeff? Take a quick look at RFC2863 and scan for IfAdminStatus and IfOperStatus. The modelling RFC2863 has is p
He has two patches: link change notification, and RFC2863 operstatus. I agree with the first one and support its inclusion; the second one I question its need. (just for context, I am referring to me
Well, with your opinion I count two against two: I want it, Jamal has proposed the semantics, and Alexey doesn't want to waste a single bit of a netlink message for this. Well, for generic net stack
I somehow deleted the original email he sent with the patches. What two patches? I thought he had one which was a backport and another which was for 2.5.x (sorry, i actually have seen those patches a
Hi, I've splitted the patch into userspace notification and RFC2863 part to separate the features clearly and get the discussion running again. That seem to have worked ;-) As an example, how do we f