Am Freitag, 7. Dezember 2007 04:20 schrieb David Miller:
> If IPSEC takes a long time to resolve, and we don't block, the
> connect() can hard fail (we will just keep dropping the outgoing SYN
> packet send attempts, eventually hitting the retry limit) in cases
> where if we did block it would not
Am Donnerstag, 6. Dezember 2007 14:55 schrieb David Miller:
> You keep ignoring the fact that, as Herbert and I discussed, not
> blocking for IPSEC resolution will make some connect() cases fail that
> would otherwise not fail.
>
> There are two sides to this issue, and we need to consider them
>
Am Donnerstag, 6. Dezember 2007 12:39 schrieb David Miller:
> > Because you just will put enough RAM modules into you server when
> > setting up a scalable system.
>
> This suggestion is avoiding the important semantic issue, and
> won't lead to a real discussion of the core problem.
When writing
Am Donnerstag, 6. Dezember 2007 12:13 schrieb David Miller:
> And that's why this is a grey area. Why is waiting for memory
> allocation on a O_NONBLOCK socket OK but waiting for IPSEC route
> resolution is not?
Because you just will put enough RAM modules into you server when setting up a
scal
Am Donnerstag, 6. Dezember 2007 09:53 schrieb David Miller:
> > I think the words "shall fail" and "immediately" are quite clear.
>
> They are, but the context in which they apply is vague.
"socket is connection-mode" => SOCK_STREAM
> I can equally generate examples where the non-blocking behavi
Am Donnerstag, 6. Dezember 2007 03:25 schrieb David Miller:
> POSIX says nothing about the semantics of route resolution.
Of course not. Applications must not care about what happens at the transport
layer.
> Non-blocking doesn't mean "cannot sleep no matter what".
... and as O_CREAT on open()
Am Mittwoch, 5. Dezember 2007 07:51 schrieb Herbert Xu:
> > If he sets this sysctl to "1" as I detailed in my reply, he'll
> > get the behavior he wants.
>
> Does anybody actually need the 0 setting? What would we break if
> the default became 1?
I'd strongly suggest doing so. AFAIK, behaviour of
Am Mittwoch, 5. Dezember 2007 08:12 schrieb David Miller:
> Actually, consider even a case like DNS. Let's say the timeout
> is set to 2 seconds or something and you have 3 DNS servers
> listed, on different IPSEC destinations, in your resolv.conf
>
> Each IPSEC route that isn't currently resolve
Am Freitag, 20. Juli 2007 09:33 schrieben Sie:
> Well, these useless abstractions are really annoying and nothing we allow
> into other drivers either.
However, they make it easier for multiple developers to work as a team. This
is useful for development pace and makes maintainance less dependan
Am Freitag, 2. März 2007 22:26 schrieb David Miller:
> The DHCP client should only care about a particular interface's
> traffic, the one it wants to listen on.
Also, a DHCP client should close the socket between address acquisition and
renewal. The only interesting events in that period are ope
Am Mittwoch, 20. Dezember 2006 16:34 schrieb Arjan van de Ven:
> 5 seconds is unfair and unrealistic though. The *hardware* negotiation
> before link is seen can easily take upto 45 seconds already.
> That's a network topology/hardware issue (spanning tree fun) that
> software or even the hardware
Am Sonntag, 10. Dezember 2006 13:15 schrieb Thomas Graf:
> > Please send me the list of bugs you've spotted. Of course I want to fix
> > them.
>
> Sure...
>
> static void nl_handlemsg(struct nlmsghdr *msg, unsigned int len) {
> if (len < sizeof(*msg)) return;
>
> while(NLMSG_OK(msg,len)) {
>
Am Samstag, 9. Dezember 2006 13:55 schrieb Thomas Graf:
> Please calm down a bit. I didn't claim that glibc should be linking to
> libnl. glibc is obviously a special case which can simply copy the existing
> macros into some internal compat header just like any other application
> that doesn't wi
Am Samstag, 9. Dezember 2006 11:39 schrieb Thomas Graf:
[Added linux-kernel to CC]
> Index: net-2.6/Documentation/feature-removal-schedule.txt
> ===
> --- net-2.6.orig/Documentation/feature-removal-schedule.txt 2006-12-09
NAK.
>
Am Freitag, 8. Dezember 2006 22:33 schrieb David Miller:
> [IF(L)A_(RTA|PAYLOAD) macros]
>
> iproute got fixed, dhcpclient and friends should get fixed to not use
> them either
Today's git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git
contains stuff like
#ifndef IFA_RTA
#def
Hi Thomas,
Am Donnerstag, 7. Dezember 2006 11:55 schrieb Thomas Graf:
> --- net-2.6.orig/include/linux/rtnetlink.h2006-12-07 11:25:29.0
> +0100 +++ net-2.6/include/linux/rtnetlink.h 2006-12-07 11:32:25.0
> +0100 @@ -3,6 +3,8 @@
>
> #include
> #include
> +#include
> +#in
Am Montag, 4. Dezember 2006 10:13 schrieb Thomas Graf:
> I do not agree with the change to include if_addr.h in rtnetlink.h.
> The point is to move bits apart and have multiple small pieces
> of header files defining a specific rtnetlink family which are a
> lot easier to maintain for both kernel
Am Montag, 9. Oktober 2006 13:49 schrieb Johannes Berg:
> Yeah, probably makes sense. Though, maybe not just the band but a set of
> channels instead?
Yes, this would allow us to keep the definition of a band out of kernel. But
to distinguish between 802.11 b and g, we'd need a set of channels a
Am Freitag, 6. Oktober 2006 16:59 schrieben Sie:
> anyway, it's getting large, so... straight from quilt:
> http://johannes.sipsolutions.net/files/cfg80211/
nice work! Is there any possibility to limit the card to a specific band (e.g.
802.11 a/b/g) using cfg80211? I'm asking because I haven't s
Am Mittwoch, 23. August 2006 19:22 schrieb Jiri Benc:
> > Send Layer 2 Update frame from the 802.11 code in kernel to the netdev
> > that the STA is bound to. If the STA is bound to another VLAN netdev,
> > send another update frame. This fixes an issue in which a local bridge
> > table was not up
Am Dienstag, 11. Juli 2006 23:28 schrieb Stephen Hemminger:
> Untested, but here is the basic idea of how I think up/down should be
> handled. Basically, rather than changing the flags directly the VLAN code
> should call dev_open/dev_close. The notifier end's up recursively calling
> but this i
stopped at initialization time
or the device is marked "not present", the state will be propagated to the
vlan device and never change. This also fixes VLAN devices being wrongly
registered as admin up since 2.6.17. Based on an analysis by Patrick
McHardy.
Signed-off-by: Stefan Rompf <[EM
y.
Signed-off-by: Stefan Rompf <[EMAIL PROTECTED]>
--- linux-2.6.17/net/8021q/vlan.c.orig 2006-07-07 13:00:56.0 +0200
+++ linux-2.6.17/net/8021q/vlan.c 2006-07-11 23:20:32.0 +0200
@@ -67,10 +67,6 @@ static struct packet_type vlan_packet_ty
.func = vlan_skb_recv,
Am Sonntag, 9. Juli 2006 17:49 schrieb Ivo Van Doorn:
> I have been quite busy lately, hence the reason for this late continuance
> of the Hardware button support for Wireless cards discussion.
> I have CC'ed the people who discussed this in earlier threads.
no problem. Look good, just one thing
Am Montag, 10. Juli 2006 18:56 schrieb Stephen Hemminger:
> 1. I think vlan code should never be using the state bits directly at all.
> It makes the code error prone if the bits ever change, and it means
> that the proper callbacks are not being done. The existing
> vlan_transfer_operstate does w
Am Montag, 10. Juli 2006 14:01 schrieb Krzysztof Halasa:
> > You've got two independant flags of which one does not stop the queue.
>
> Is it ok to set that flag without synchronization with other flags?
> I.e, from within another module and without using cross-module locks,
> as I've shown at the
[Trimmed CC list as we're off topic]
Am Sonntag, 9. Juli 2006 22:05 schrieb Krzysztof Halasa:
> >> ... and where the maintainer doesn't seem to care to use it now that the
> >> infrastructure is there. Sigh.
>
> This is very different from what I proposed and doesn't fit very well.
> We've been d
Am Freitag, 7. Juli 2006 23:33 schrieb Stephen Hemminger:
> Not really. The flag code last major change was to do the dormant
> stuff that HDLC wanted.
... and where the maintainer doesn't seem to care to use it now that the
infrastructure is there. Sigh.
> IMHO VLAN device's should mirror the
Am Donnerstag 06 Juli 2006 09:42 schrieb Patrick McHardy:
> > I believe this link-state logic was added by someone else. I'm not
> > sure exactly what these flags are supposed to do, so I am not sure if
> > they should be propagated to the VLAN or not.
>
> I looked into this. The present flag use
Am Dienstag 04 Juli 2006 12:07 schrieb Patrick McHardy:
> > - new_dev->state = real_dev->state & VLAN_LINK_STATE_MASK;
> > + new_dev->state = real_dev->state & ~(1<<__LINK_STATE_START);
> This introduced a regression by propagating the __LINK_STATE_XOFF flag,
> when the queue of the underlyin
Am Mittwoch 21 Juni 2006 17:08 schrieb Luis R. Rodriguez:
> Since d80211 is already being patched for sysfs how about we use sysfs
> (and kobjects) to maintain the state at suspend() and resume(). This
> would allow userspace tools like supplicant running in the background
> to pick up from sysfs
Am Freitag 16 Juni 2006 20:36 schrieb Stefan Rompf:
> (But that's an interesting point. Will sniff whether ipw2200 hardware sends
> a final packet on suspend.)
neither on suspend to RAM nor on suspend to disk a disassociation is sent by
ipw2200 - for the AP, the client just vanish
Am Donnerstag 15 Juni 2006 21:58 schrieb Michael Buesch:
> I am currently thinking about the best way to correctly
> implement PM suspending for wireless drivers.
> Currently, the 802.11 stack is not suspend aware (if I talk
> about "stack" here, I mostly mean devicescape).
> For example, if we su
Am Sonntag 04 Juni 2006 10:02 schrieb Ivo van Doorn:
> Except for the bluetooth radio key (which should be supported by the
> radiobtn interface as well) the other buttons have support through already
> excisting input devices if I am correct.
You are wrong for quite a bunch of laptop models. Tha
Am Freitag 02 Juni 2006 16:30 schrieb Ivo van Doorn:
> > Or actually, I don't think the radiobtn/ won't be actually needed as
> > prefix. The name passed to the radiobtn driver by the driver should be
> > sufficient.
>
> Updated version,
>
> Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
I don't
Am Dienstag 30 Mai 2006 20:07 schrieb Ben Greear:
> May 30 11:01:37 x64-1u avahi-daemon[2022]: Joining mDNS multicast group on
> inter face eth2#18.IPv4 with address 172.1.2.20.
> May 30 11:01:37 x64-1u avahi-daemon[2022]: IP_ADD_MEMBERSHIP failed: No
> buffer s pace available
there is a configur
Am Dienstag 09 Mai 2006 20:31 schrieb Stephen Hemminger:
> > > I moved iproute2 out of CVS. New home is:
>
> fixed. stupid git
maybe you should have kept CVS. *Ducks and runs* ;-)
Stefan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTE
ond delay for one second every
49 days, avoiding 64bit operations. David, please prefer this patch over mine.
> Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Acked-by: Stefan Rompf <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev"
Am Montag 08 Mai 2006 08:07 schrieb David S. Miller:
> What is so special about what linkwatch is doing such
> that it needs this kind of treatment and other similar
> pieces or code do not?
>
> We have all sorts of interfaces such as time_after() et el.
> in order to deal with wrapping issues.
t
Hi,
seems documentation got lost when the RFC2863-patch was applied. Having
documentation is good, so I resend it ;-)
Signed-off-by: Stefan Rompf <[EMAIL PROTECTED]>
--- /dev/null 2005-03-19 20:36:14.0 +0100
+++ linux-2.6.17-rc3/Documentation/networking/operstates.txt2006
s happen with any possible delay in between.
This should be 2.6.17 stuff.
Signed-off-by: Stefan Rompf <[EMAIL PROTECTED]>
--- linux-2.6.17-rc3/net/core/link_watch.c.orig 2006-04-27 20:37:09.0
+0200
+++ linux-2.6.17-rc3/net/core/link_watch.c 2006-04-27 21:49:00.0
+0200
Am Samstag 01 April 2006 14:50 schrieb jamal:
> No stefan - check arpd. Infact if you really want to scale ARP to many
> many entries, you do it in user space. This has been proven more than
> once in the past: Thats the main reason the current daemons exist. It is
AFAIK the primary purpose of ar
Am Samstag 01 April 2006 12:27 schrieb David S. Miller:
> > Neighbor address resolution is such a basic networking feature that
> > it should not depend on a running userspace daemon to function
> > properly.
>
> Routing is a pretty basic network feature, yet userspace manages it
> and the kernel
Am Samstag 01 April 2006 06:25 schrieb Herbert Xu:
> BTW, I like your idea of moving STP to user-space. In fact I think we
> can extend it to move ARP to user-space as well.
Neighbor address resolution is such a basic networking feature that it should
not depend on a running userspace daemon to
Am Sonntag 12 März 2006 17:50 schrieb Michael Richardson:
> I recently got a bug in my ear to try and get multiple-dhclients to
> work on separate interfaces under Linux (a one-daemon-per-interface
> model). Could use some advice from the linux masters (Jason, Andrew?)
> if you can spare some tim
Hi,
this makes me curious: What's the reason that e1000 driver intercepts and
somehow parses outgoing DHCP packets on the 82573?
Stefan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
Hi,
Am Freitag 17 Februar 2006 20:39 schrieb Simon Barber:
> In 802.11 networks when connecting to a new AP on the same networks
> (same SSID & security settings) you typically don't have to do DHCP
> again - but with some networks setups you do. In order to detect this,
> when connecting to a ne
Am Samstag 25 Februar 2006 11:53 schrieb Christoph Hellwig:
>From a short glance over the driver code, the protocol between the _open
source_ driver and the binary user space daemon seems to be quite defined and
unobfuscated. Obviously, someone owning the device has to verify that the
daemon do
Am Freitag 17 Februar 2006 20:39 schrieb Simon Barber:
> In 802.11 networks when connecting to a new AP on the same networks
> (same SSID & security settings) you typically don't have to do DHCP
> again - but with some networks setups you do. In order to detect this,
> when connecting to a new AP
Am Freitag 17 Februar 2006 19:39 schrieb Jean Tourrilhes:
> I congratulate you on your good work.
Thanks!
> I will share with you my personal gripe on most DHCP clients :
> they depend too much on those link signalling. I hope you appreciate
> the irony ;-)
Someone needs a feature,
dhcpclient
A DHCP client for linux 2.6, using modern kernel features, (c) 2006
Stefan Rompf.
Motivation
Using a notebook, I'm often traveling between different networks.
After replugging, I always needed to issue a ifdown/ifup sequence
be
Am Samstag 28 Januar 2006 02:23 schrieb Jouni Malinen:
> I could try to do this for Prism2/2.5/3 which takes care of management
> frame processing in client mode. Please let me know if you have already
> done some changes for ipw2100 that would be generic to cover other
> drivers.
sorry, haven't
Am Dienstag 17 Januar 2006 22:52 schrieb Stefan Rompf:
> This patch implements suspend and resume methods for the starfire driver.
> It allows me to put my desktop PC with a starfire dual board into S4.
Jeff, all email addresses of Ionut Badulescu I am aware of
(<[EMAIL PROTECTED]>
Am Mittwoch 25 Januar 2006 07:55 schrieb James Ketrenos:
> The purpose for this code ever coming into existence within ieee80211
> was based on discussions at OLS this past year in how to support for the
> ability to start/stop independent Tx queues within a single net device
> in order to support
Am Mittwoch 25 Januar 2006 07:18 schrieb Zhu Yi:
> > This is what leads to the high ksoftirqd usage I reported October 2005
> > into the ipw bugzilla
> > (http://www.bughost.org/bugzilla/show_bug.cgi?id=825).
>
> Sorry, I'm not aware of this bug since I'm not on the cc list.
Hmm, frankly the ipw
Am Dienstag 24 Januar 2006 09:36 schrieb Zhu Yi:
> Two problems in ipw2200:
> 1. We now have the ieee_device->is_queue_full interface, and it will be
>called at the beginning of ieee80211_xmit function. So no need to call
>it at the driver xmit function.
This interface is totally broken.
Am Montag 23 Januar 2006 15:32 schrieb Johannes Berg:
> Shouldn't you BSS-filter management packets too?
no, management packets are used to populate f.e. scanning results.
Stefan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
Mor
Am Samstag 21 Januar 2006 19:48 schrieb Herbert Xu:
> > Kind of odd that we don't have carrier=off by default..
>
> If someone could have a look at all the drivers to see what might
> break if we changed the default, then we might be able to change it.
Actually all drivers that don't have carrier
Am Samstag 21 Januar 2006 11:49 schrieb Lennert Buytenhek:
> I ran into this problem with ixp2000 too. However, calling
> netif_carrier_off calls into linkwatch_fire_event and I wasn't sure
> whether this is the right thing to do when the netdev isn't even
> registered yet.
This is not the right
Am Donnerstag 19 Januar 2006 16:56 schrieb John W. Linville:
> The above represents my thinking on the issue. Ultimately the WiPHY
> (aka radio) device should be thought of as a new class of driver,
> distinct from a netdev. If we have to reroute some infrastructure
> (i.e. qdisc) to make that p
Am Sonntag 15 Januar 2006 16:39 schrieb Stuffed Crust:
> Internally, we're pure 802.11. One thing to keep in mind that we're not
> going to be bridging/translating non-data traffic to other networks, and
> with that in mind, 802.3<->802.11 translation is trivial, and won't lose
> anything except
Am Dienstag 17 Januar 2006 19:37 schrieb Jirka Bohac:
> - DeviceScape can be there so it can be polished and new drivers can
> start using it.
> - ieee80211 could be there with a big fat warning that it will go
> away soon, just to allow ipw2x00 to work while DeviceScape and
> the ipw2x00 po
Am Sonntag 15 Januar 2006 21:11 schrieb Johannes Berg:
> [iwconfig mode ...]
>
> Yeah, I agree with this, it is much cleaner to handle in the kernel.
> Think about the issues if you have a struct net_device that has 250
> bytes of "payload" for the struct virtual_sta_device in it and you want
> to
Am Dienstag 17 Januar 2006 20:42 schrieb Jouni Malinen:
> Sure, you can do it that way, too. However, this is not the only use. I
> just remembered another one: QoS. Devicescape 802.11 code uses a qdisc
> on the master interface to take care of determining which hardware TX
> queue to use with WMM
This patch implements suspend and resume methods for the starfire driver. It
allows me to put my desktop PC with a starfire dual board into S4.
Signed-Off-By: Stefan Rompf <[EMAIL PROTECTED]>
--- linux-2.6.15/drivers/net/starfire.c.orig2006-01-04 01:01:18.0
+0100
+++ linux-
Am Sonntag 15 Januar 2006 16:51 schrieb Johannes Berg:
> Isn't that rather a question of having good user-space tools that make
> deactivating one type of interface and activating another seamless?
Well, it's always easy to point to userspace. However, unregister_netdev()
initiates a lot of acti
Am Samstag 14 Januar 2006 14:47 schrieb Ulrich Kunitz:
> They one problem I can see is scanning over several frequencies.
> If two virtual devices are doing this at the same time, we have a
> conflict. Maybe each WiPHY would have only one active interface,
I think scanning can be easily serialize
Am Samstag 14 Januar 2006 13:28 schrieb Krzysztof Halasa:
> What's the real current status of your RFC2863 patch?
Dunno, but wondering why new features for 2.6.16 have been closed without any
feedback on it.
Davem? (And frankly, if the RFC2863 and user/kernel operstate interaction
stuff is so
Am Donnerstag 12 Januar 2006 13:57 schrieben Sie:
> Unfortunately, I don't have time to do this right now as there are other
> issues that should be addressed first - like the overall concept of
> using net_devices. If you write some patches, I will really appreciate
> it.
Let's first wait for th
Am Freitag 13 Januar 2006 23:32 schrieb Johannes Berg:
> [Changing mode of virtual devices]
>
> IMHO there's not much point in allowing changes. I have a feeling that
> might create icky issues you don't want to have to tackle when the
> solution is easy by just not allowing it. Part of my thinkin
Am Mittwoch 11 Januar 2006 15:49 schrieb Jiri Benc:
> - There should be only as few net_devices as needed. I. e. when the card
> acts as a client to one AP, only one device is present.
> - The type of a device (AP, client, WDS link, monitor, etc.) should be
> specified in the usual way (by iwc
Am Mittwoch 11 Januar 2006 20:23 schrieb Jeff Garzik:
> They may mean carrying some compat code in the kernel for a while, or
> some other solution... The compat code could simply call netlink
> internally, for example.
after all, the most important achievement for driver writers is that there i
Am Mittwoch 11 Januar 2006 16:05 schrieb Mike Kershaw:
> As far as link type, theres no real reason radiotap couldn't be used
> internally, but theres also no reason it's needed on anything other than
> rfmon if we don't think we'll ever care about per-frame stats in
> non-rfmon.
a software AP co
Hi Jiri,
to evaluate the Devicescape stack, I started porting the ipw2100 driver to it.
However I do have one major problem. At least the snapshort from January 2nd
does not seem to support devices that do scanning and associating controlled
by firmware.
Is this assumptions right, and if so, w
Hi,
so, can we agree on this:
a)we want to distinguish between physical devices and virtual devices.
Physical devices represent a network card, virtual devices a function based
on the card (access point, sta, ...). Some cards can handle multiple
functions parallel, we support it this way.
Cav
Am Freitag 06 Januar 2006 12:46 schrieb Dominik Brodowski:
> From someone who has no idea at all (yet) about 802.11: why character
> device, and not sysfs or configfs files? Like
sysfs shares the main problem with wireless extensions: It configures one
value per file / per ioctl. Setting up a wi
Am Donnerstag 05 Januar 2006 12:27 schrieb Ingo Oeser:
> What about doing it in two steps (first RAM then FLASH)?
> [...]
> Is this possible or too simple to be true?
RAM firmware and flash firmware are different files, so if one works, it's no
guarantee that the other will, too.
Stefan
-
To un
Hi all,
to learn about the in kernel 802.11 subsystem, driver writing and wireless in
general, I started a project to develop a driver for the prism2/prism3 usb
chipset. Goal was to get WPA support and the possibility to configure with
wireless extensions.
Unfortunately, I was rudely interrupt
ing iflink on the VLAN device, not on the device the VLAN is stacked
on (as it happens in the two ;-) other places that use iflink)
Signed-Off-By: Stefan Rompf <[EMAIL PROTECTED]>
diff -X dontdiff -uNrp linux-2.6.14/net/8021q/vlan.c linux-2.6.14-rfc2863/net/8021q/vlan.c
--- linux-2.6.14/net/
ht now?
Done. Also removed one ASSERT_RTNL() and report IF_OPER_DOWN via netlink when
device is admin down.
Signed-Off-By: Stefan Rompf <[EMAIL PROTECTED]>
diff -X dontdiff -uNrp linux-2.6.14/Documentation/networking/operstates.txt linux-2.6.14-rfc2863/Documentation/networking/operstates.t
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 link
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)
s to care for IFF_RUNNING or
waiting for operstate to go IF_OPER_UP/IF_OPER_UNKNOWN before
considering the interface / querying a DHCP address.
For technical questions and/or comments please e-mail to Stefan Rompf
(stefan at loplof.de).
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 VLA
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 en
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 th
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 netif_oper_up()
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 swit
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
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 __LIN
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 all
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 oper state IFF_XXX flags which are sent via
> netlink to user
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 woul
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. Even though I'm
not convinced, I should accept this and therefore T
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
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 req
Am Dienstag 15 November 2005 17:41 schrieb Krzysztof Halasa:
> > * The @dev_base list is protected by @dev_base_lock and the rtln
> > * semaphore.
> > *
> > * Pure readers hold dev_base_lock for reading.
> > *
> > * Writers must hold the rtnl semaphore while they loop through the
> > * dev_
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 userspa
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.
*
* P
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 ch
1 - 100 of 114 matches
Mail list logo
