jamal [EMAIL PROTECTED] writes:
How is this different, conceptually, from any other flag setting being
lost - for example a promisc or admin up/down?
How do you lose promisc or admin up/down flag setting? Do you mean
userspace listening? It has to poll then.
In other words if you want to
Jamal's address ommited as requested.
Stefan Rompf [EMAIL PROTECTED] writes:
I'm more unhappy about the fact that a driver can (and could) do a
netif_carrier_off()/-on() sequence too fast for the workqueue to follow.
Precisely. So there will always be the glitches. And we can't fix
it. Nor,
On Tue, 2005-06-12 at 15:11 +0100, Krzysztof Halasa wrote:
Jamal's address ommited as requested.
I dont remember asking you not to CC me. What i remember asking you is
to _stop_ talking about your useless patch. But the way this is going i
am probably going to ask you to _not CC_ me.
The
jamal [EMAIL PROTECTED] writes:
I dont remember asking you not to CC me. What i remember asking you is
to _stop_ talking about your useless patch.
I will, of course, not mention my patch to you anymore but could you
please leave decisions related to me and third parties just to me and
those
On Tue, 2005-06-12 at 16:19 +0100, Krzysztof Halasa wrote:
jamal [EMAIL PROTECTED] writes:
I think I made myself clear. If you don't understand something, just ask
for explanation.
Ok, please explain again, slowly if you can.
What is it that wont work for you that is in Stefans patch or
On Tue, 2005-06-12 at 17:10 +0100, Krzysztof Halasa wrote:
jamal [EMAIL PROTECTED] writes:
Ok, please explain again, slowly if you can.
What is it that wont work for you that is in Stefans patch or missing
from his patch?
Please ask for a specific thing.
Lets start with the basics:
jamal [EMAIL PROTECTED] writes:
Ok, please explain again, slowly if you can.
What is it that wont work for you that is in Stefans patch or missing
from his patch?
Please ask for a specific thing.
[I am going to leave the rest of your message out so we avoid
conflicts].
I can't see any
jamal [EMAIL PROTECTED] writes:
Lets start with the basics: With this patch, can you still do what you
used to do before the change that broke things for you?
I have put workarounds in place and my drivers are currently working,
without any additional patch. So unless something is broken
On Tue, 2005-06-12 at 20:45 +0100, Krzysztof Halasa wrote:
jamal [EMAIL PROTECTED] writes:
Lets start with the basics: With this patch, can you still do what you
used to do before the change that broke things for you?
I have put workarounds in place and my drivers are currently working,
jamal [EMAIL PROTECTED] writes:
I ask you a very specific question, you start playing silly games with
words. This is why it has been hard to make progress with you.
I didnt ask what you are doing without the patch or whether you will use
the patch at all, rather whether it will restore the
Am Dienstag 06 Dezember 2005 22:25 schrieb Krzysztof Halasa:
Is Stefan's patch going to restore the functionality that you need?
I hope so. If done correctly, it would not only provide the
functionality my drivers were using before the breakage, it would
enable me to cut the dirty links
On Tue, 2005-06-12 at 23:34 +0100, Stefan Rompf wrote:
Am Dienstag 06 Dezember 2005 22:25 schrieb Krzysztof Halasa:
Is Stefan's patch going to restore the functionality that you need?
I hope so. If done correctly, it would not only provide the
functionality my drivers were using
Am Donnerstag 01 Dezember 2005 13:48 schrieb Krzysztof Halasa:
- kernel driver signals lower-level down
- kernel driver signals lower-level up (dormant = 1)
- slow userspace (in this case, could be a kernel module if strict
serialization of all operational status changes isn't required)
Hi,
Stefan Rompf [EMAIL PROTECTED] writes:
ok, seems we are getting near submission for kernel inclusion. If no new
comments arise, the only thing missing from my side is documentation.
I understand it's supposed to be race and race free?
+ unsigned char operstate; /* RFC2863
Hi Stefan,
Looking good.
On Wed, 2005-30-11 at 23:29 +0100, Stefan Rompf wrote:
Changes since last version:
-remove NETIF_F_STACKED, use dev-iflink instead. Change VLAN to set
dev-iflink properly
There is only one gotcha i noticed with vlan - as you keep stacking you
set the iflink;
On Thu, 2005-01-12 at 13:48 +0100, Krzysztof Halasa wrote:
Hi,
Stefan Rompf [EMAIL PROTECTED] writes:
+}
This is of course much much more correct than those strange operations
on dev-char_type, though netif_dormant* is still misnamed - dormant
isn't one bit but rather a combination of
jamal [EMAIL PROTECTED] writes:
This bit alone doesn't tell if it's dormant or, for example, simply down
(either admin or carrier).
dormant is an operational state and _not_ an admin state.
And, in your opinion, changing admin state has not effect on operational
state?
How is this
On Thu, 2005-01-12 at 16:39 +0100, Krzysztof Halasa wrote:
jamal [EMAIL PROTECTED] writes:
This bit alone doesn't tell if it's dormant or, for example, simply down
(either admin or carrier).
dormant is an operational state and _not_ an admin state.
And, in your opinion, changing
jamal [EMAIL PROTECTED] writes:
Sure. But the changes are said to fix it, without success (of course,
they can't succeed without doing what I outlined, that's just
theoretically impossible, and OTOH not needed at all).
And i fail to see how.
I think I can only agree with you on that.
Hi,
ok, seems we are getting near submission for kernel inclusion. If no new
comments arise, the only thing missing from my side is documentation. VLAN is
again included in this patch to show one use case.
Changes since last version:
-remove NETIF_F_STACKED, use dev-iflink instead. Change
On Tue, 2005-29-11 at 00:26 +0100, Stefan Rompf wrote:
Am Montag 28 November 2005 23:13 schrieb Thomas Graf:
The effort is nice but why do we need sysfs? Isn't netlink enough for
you?
Well, there are already a *lot* of device attributes in sysfs (just ls
-l /sys/class/net/eth0 f.e.),
Hi,
ok, at least some progress has happened:
-Replaced device-specific oper_state method with NETIF_F_STACKED flag to
select between IF_OPER_DOWN or IF_OPER_LOWERLAYERDOWN
-sysfs support to read operstate
-completed netlink support (Jamal, Thomas, can you verify the code?)
-added
Am Montag 28 November 2005 14:15 schrieb Stefan Rompf:
-complete sysfs
-test netlink userspace interaction
both done, next patch will follow when docs are written. Thomas: Thanks for
libnl, it made sending netlink messages a lot easier!
Stefan
-
To unsubscribe from this list: send the line
* Stefan Rompf [EMAIL PROTECTED] 2005-11-28 14:15
Hi,
ok, at least some progress has happened:
Looks good, it would be nice if you could separate the vlan part as a
separate patch for later on though.
-Replaced device-specific oper_state method with NETIF_F_STACKED flag to
select between
Am Montag 28 November 2005 23:13 schrieb Thomas Graf:
Looks good, it would be nice if you could separate the vlan part as a
separate patch for later on though.
This will happen when I submit the final patch for kernel inclusion.
The effort is nice but why do we need sysfs? Isn't netlink
Stefan,
On Tue, 2005-22-11 at 21:38 +0100, Stefan Rompf wrote:
we could protect operstate with a spinlock_irqsave() and then change it
either
from netif_[carrier|dormant]_on/off() or userspace-supplicant. However, I'm
not feeling good about it.
Ok, what you have is fine by me.
Look at
On Wed, Nov 23, 2005 at 09:24:05AM -0500, jamal wrote:
Well, thats certainly one way. Then the oper state machines you are
working on + stacking will work well. But this depends on if you can
justify the reason for those virtual devices. With wireless you can
probably justify to map the radio
I just changed the topic so as not to distract the original discussion
On Wed, 2005-23-11 at 06:41 -0800, Jouni Malinen wrote:
The case where one radio in client mode is associating with multiple APs
is usually done by having multiple virtual netdevs, i.e., one for each
association.
Sounds
On Wed, 2005-23-11 at 09:54 -0500, jamal wrote:
yes, this would work. However, i am still interested in the case where
you have a single radio but multiple AP connections - unless this is
impossible. I have to go back and look at that paper - I know they were
using very basic 802.11
Hi Jamal,
be transitioned to up/dormant etc. So an ethernet driver doesnt know it
needs to go from detecting peer link is up to next being authenticated
in the case of 802.1x. It just calls netif_carrier_on which checks
link_mode to decide on transition.
we could protect operstate with a
Hi Krzysztof,
No big deal with my generic HDLC (I may leave it one-layer though it's
quite dirty, and would be even less logical with the new
dormant/whatever).
Sorry, I don't get that and want to avoid further misunderstandings. So can
you use _ONE_ netdev_set_operstate() function to switch
Stefan Rompf [EMAIL PROTECTED] writes:
Sorry, I don't get that and want to avoid further misunderstandings. So can
you use _ONE_ netdev_set_operstate() function to switch between OPER_DOWN
(!carrier), OPER_DORMANT (!protocol) and OPER_UP (both fine) or not?
I can use whatever is available
Hi Stefan,
I looked at the patch and while there are some stylistic/implementation
differences between us, I think generally all the concepts seem to be in
place. So we are almost there.
More comments below:
On Fri, 2005-18-11 at 21:52 +0100, Stefan Rompf wrote:
This is the data flow:
Am Freitag 18 November 2005 04:03 schrieb jamal:
ok, I'll produce a patch then - first version will be available tomorrow
evening.
beauty.
Ok, here is the first 'merger' patch. At this stage, it is only compilation
tested against 2.6.14.
This is the data flow:
-Device changes
Am Donnerstag 17 November 2005 04:29 schrieb jamal:
1) There are read_only oper state IFF_XXX flags which are sent via
netlink to user space. These are set by the kernel (and not by user
space); they reflect the state of link.
We can avoid a myriad of new IFF_*-flags if we allow a
On Thu, 2005-17-11 at 22:03 -0500, jamal wrote:
I will attempt some ascii art shortly. Actually if you agree with it
please include it in your patch so it is easier for people to make
changes in the future.
ok, ascii art is hard - instead in pseudo code (please double check with
the RFC);
* jamal [EMAIL PROTECTED] 2005-11-15 21:16
3) There is a kernel dev-operstate_kernel which is accessible via
user space in the same manner IFF_UP flags are set etc.
Just be careful about synchronization, that's one issue with the
currently proposed implementation. The callers cannot be made
jamal [EMAIL PROTECTED] writes:
I am afraid I would have to agree with Stefan on this Krzysztof.
Supporting false statements doesn't make them less false :-)
OTOH I hope your opinions about people have no influence on your view
of the code they write so it's not exactly important here.
You
On Wed, 2005-16-11 at 16:46 +0100, Stefan Rompf wrote:
Am Mittwoch 16 November 2005 03:16 schrieb jamal:
I will not respond to the rest of your email - I wanna make sure we are
in sync first on the above. So let me summarize:
Ok, let's see if I understood you:
1) There are read_only
On Tue, 2005-15-11 at 08:02 -0500, jamal wrote:
I didnt see this issue as any different than setting any other current
netdevice flags which goes via dev_change_flags; i gave the example of
IFF_UP in my email because it sets the dev-state (invoked via
dev-open/close). In the case of user
jamal [EMAIL PROTECTED] writes:
1) I dont think operstare_useroverride is needed.
I don't either. We should ask potential users, though - doing things
we think are best but nobody is going to use is nonsense.
a) We need new flags which get reflected to user space; i.e new IFF_XXX
flags.
Stefan Rompf [EMAIL PROTECTED] writes:
You said the same to Thomas on IFF_WAIT. Both operstate_useroverride and
IFF_WAIT exist to allow userspace 802.1X/wpa supplicant interaction.
Are we sure about this? It might be the case but I don't think I've seen
such request.
--
Krzysztof Halasa
-
To
Am Dienstag 15 November 2005 18:54 schrieb Krzysztof Halasa:
You said the same to Thomas on IFF_WAIT. Both operstate_useroverride and
IFF_WAIT exist to allow userspace 802.1X/wpa supplicant interaction.
Are we sure about this? It might be the case but I don't think I've seen
such request.
Am Dienstag 15 November 2005 15:16 schrieb jamal:
Having said that, perhaps thats where the concept of useroverride you
have or IFF_WAIT needs to go. What should be done though is to select an
operational mode via admin flags - example the device is set by the
admin to dormant state or the
Stefan Rompf [EMAIL PROTECTED] writes:
Please reread what is written about locking in net/core/dev.c. It has
looked a
bit strange to me, too, when I needed to use it for the first time, but my
code does the right thing here. Remember, linkwatch_fire_event() is _NOT_ a
pure reader.
It
Am Dienstag 15 November 2005 21:22 schrieb Krzysztof Halasa:
I even responded to it. Show me where he requests anything similar to
operstate_useroverride or IFF_WAIT?
operstate_useroverride or IFF_WAIT are possible solutions to
-handle this part of Jouni's mail:
[...]
however, this would
Stefan Rompf [EMAIL PROTECTED] writes:
I even responded to it. Show me where he requests anything similar to
operstate_useroverride or IFF_WAIT?
operstate_useroverride or IFF_WAIT are possible solutions to
[Jouni's mail]
For now they are just broken and that haven't changed since the first
On Tue, 2005-15-11 at 20:28 +0100, Stefan Rompf wrote:
Am Dienstag 15 November 2005 15:16 schrieb jamal:
Having said that, perhaps thats where the concept of useroverride you
have or IFF_WAIT needs to go. What should be done though is to select an
operational mode via admin flags -
On Tue, 2005-15-11 at 20:36 -0500, jamal wrote:
* The first thing you do is configure the netdevice to the admin mode of
operation. This is very close to what BSD (and some vendors) allow for
sync PPP (I will try to find a url or look up ifconfig man pages on
BSD). IOW, you do this when you
On Tue, 2005-15-11 at 21:18 +0100, Stefan Rompf wrote:
Am Dienstag 15 November 2005 04:19 schrieb jamal:
1) I think we need to separate the oper state from the rest; so
no need to add dormant to be in netdev_state_t.
ok, it seems that everybody else wants to go with state flags.
I am
Am Montag 14 November 2005 14:57 schrieb jamal:
My suggestion is at this point to ignore any L3 issues and have people
post their patches. RFC 2863 states MUST be taken into consideration.
Proper naming must be taken into account.
here we go. I've removed OPER_DORMANTL3* as requested and
jamal [EMAIL PROTECTED] writes:
My suggestion is at this point to ignore any L3 issues and have people
post their patches. RFC 2863 states MUST be taken into consideration.
Proper naming must be taken into account.
I'll not repost my patch because you already have it and it lacks only
I want to apologize in advance - I wont be able to comment on anything
for another 10 hours or so. I will comment tonight.
cheers,
jamal
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Stefan Rompf [EMAIL PROTECTED] writes:
+++ linux-2.6.14/net/core/link_watch.c
@@ -75,7 +75,14 @@ void linkwatch_run_queue(void)
clear_bit(__LINK_STATE_LINKWATCH_PENDING, dev-state);
if (dev-flags IFF_UP) {
- if (netif_carrier_ok(dev)) {
+
Am Montag 14 November 2005 17:44 schrieb Krzysztof Halasa:
[As Jamal answers later, I'll just comment on the technical questions]
Why do you do that instead of atomic write?
as described in net/core/dev.c:
* The @dev_base list is protected by @dev_base_lock and the rtln
* semaphore.
*
*
My suggestion is at this point to ignore any L3 issues and have people
post their patches. RFC 2863 states MUST be taken into consideration.
Proper naming must be taken into account.
Split up in 3 patches, not implementing the bits allowing userspace to
trigger leaving dormant state.
[NET]:
On Mon, 2005-14-11 at 16:53 +0100, Krzysztof Halasa wrote:
jamal [EMAIL PROTECTED] writes:
Dormant is not a flag (1 bit) but rather a specific set of flags
(exactly as there is no running nor l2down bits). So set_dormant*()
(with bit flags) doesn't make much sense unless it changes multiple
As in the case of Stefan, only the negative comments:
1) I think we need to separate the oper state from the rest; so
no need to add dormant to be in netdev_state_t.
2) Events need only be generated from/to down state
3) IFF_WAIT is not needed. A device goes from NOTPRESENT
to DOWN; and may
Am Dienstag 15 November 2005 03:43 schrieb jamal:
I'll have more time for a comment this evening, but let me ask one question
until then:
1) I dont think operstare_useroverride is needed.
You said the same to Thomas on IFF_WAIT. Both operstate_useroverride and
IFF_WAIT exist to allow
59 matches
Mail list logo
