From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
arch/s390/appldata/appldata_base.c |4 ++--
arch/s390/kernel/debug.c |2 +-
arch/s390/mm/cmm.c |2 +-
3 files changed, 4 insertions(+), 4 deletions
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
arch/ia64/sn/kernel/xpc_main.c | 86 +--
1 files changed, 38 insertions(+), 48 deletions(-)
diff --git a/arch/ia64/sn/kernel/xpc_main.c b/arch/ia64
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
It isn't needed anymore, all of the users are gone, and all of the
ctl_table initializers have been converted to use explicit names
of the fields they are initializing.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
include/linux
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
The current logic to walk through the list of sysctl table
headers is slightly painful and implement in a way it cannot
be used by code outside sysctl.c
I am in the process of implementing a version of the sysctl
proc support that instead
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
While C99 converting the ctl_table initializers I realized
that the binary sysctl numbers were in conflict with the binary
values under CTL_KERN. Including CTL_KERN KERN_VERSION as used
by glibc. So I just removed the sysctl binary interface
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
With this change the sysctl inodes can be cached and
nothing needs to be done when removing a sysctl table.
For a costk of 2K code we will save about 4K of static tables
(when we remove de from ctl_table) and 70K in proc_dir_entries
that we
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
fs/xfs/linux-2.6/xfs_sysctl.c | 258
1 files changed, 180 insertions(+), 78 deletions(-)
diff --git a/fs/xfs/linux-2.6/xfs_sysctl.c b/fs/xfs
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
The semantic effect of insert_at_head is that it would allow
new registered sysctl entries to override existing sysctl entries
of the same name. Which is pain for caching and the proc interface
never implemented.
I have done an audit
Kirill Korotaev [EMAIL PROTECTED] writes:
Eric, really good job!
Patches: 1-13, 15-24, 26-32, 34-44, 46-49, 52-55, 57 (all except below)
Acked-By: Kirill Korotaev [EMAIL PROTECTED]
14/59 - minor (extra space)
25/59 - minor note
33/59 - not sorted sysctl IDs
45/59 - typo
50/59 -
Kirill Korotaev [EMAIL PROTECTED] writes:
Eric, though I personally don't care much:
1. I ask for not setting your authorship/copyright on the code which you just
copied
from other places. Just doesn't look polite IMHO.
I can't claim complete ownership of the code, there was plenty of feed
is a simple fix for
the fib proc iterator so it works even when there is only a single route
in a routing table.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
net/ipv4/fib_trie.c | 21 -
1 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/net/ipv4
While enhancing the neighbour code to handle multiple network
namespaces I noticed that decnet is assuming neigh_parms_alloc
will allways succeed, which is clearly wrong. So handle the
failure.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
net/decnet/dn_dev.c |5 +
1 files
David Miller [EMAIL PROTECTED] writes:
From: Robert Olsson [EMAIL PROTECTED]
Date: Wed, 24 Jan 2007 22:43:30 +0100
Yes the case when the trie is just a single leaf got wrong with the
iterator and your patchs cures it. I think we have a similar problem
with /proc/net/fib_trie
I'm happy to
While enhancing the neighbour code to handle multiple network
namespaces I noticed that decnet is assuming neigh_parms_alloc
will allways succeed, which is clearly wrong. So handle the
failure.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
net/decnet/dn_dev.c | 11 +--
1
Dmitry Mishin [EMAIL PROTECTED] writes:
On Wednesday 17 January 2007 23:16, Eric W. Biederman wrote:
Dmitry Mishin [EMAIL PROTECTED] writes:
Added functions and macros required to operate with network namespaces.
They are required in order to switch network namespace for incoming packets
Ben Greear [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
etun is a simple two headed tunnel driver that at the link layer
looks like ethernet. It's target audience is communicating
between network namespaces but it is general enough
Stephen Hemminger [EMAIL PROTECTED] writes:
+
+#define __per_net_start ((char *)0)
+#define __per_net_end ((char *)0)
Don't use these use NULL
NULL has the wrong data type. These are compiled out character array
normally generated by the linker script. I'm not even certain I need
The idea of a network namespace is fundamentally quite simple. We create
a mechanism that from the users perspective allows creation of separate
instances of the network stack. When combined with mechanism like chroot
this results in a much more complete isolation. When seen in the context
of
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
This is the network namespace from which all which all sockets
and anything else under user control ultimately get their network
namespace parameters.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
include/linux/nsproxy.h |2 ++
1
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
In combination with the sysfs support I am in the process of merging
with gregkh, creates a separate instance of the /sys/class/net directory
for each network namespace so two devices with the same name do not conflict.
Then a network namespace
for having the linker build and dynamically change
structures for us appears applicable here and a lot less nuisance then
what I did before so I am implementing a tailored version of that
technique as well, and again this makes it very simple to compile the
code out.
Signed-off-by: Eric W. Biederman [EMAIL
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
Because of the global nature of garbage collection, and
because of the cost of per namespace hash tables
unix_socket_table has been kept global. With a filter
added on lookups so we don't see sockets from the wrong
namespace.
Currently I
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
etun is a simple two headed tunnel driver that at the link layer
looks like ethernet. It's target audience is communicating
between network namespaces but it is general enough it may
have other uses as well.
Signed-off-by: Eric W. Biederman
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
Before I can enable rtnetlink to work in all network namespaces
I need to be certain that something won't break. So this
patch deliberately disables all of the methods and when they
are audited this extra check can be disabled.
Signed-off
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
This patch makes the loopback_dev per network namespace.
The loopback device registers itself as a pernet_device so
we can register the new loopback_dev instance when we add
a new network namespace and so we can unregister the
loopback device
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
I haven't a clue if this interface will meet with widespread approval but
at this point it is simple, and very useful.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
net/core/net-sysfs.c | 35 +++
1
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
Please note that network devices do not increase the count
count on the network namespace. The are inside the network
namespace and so the network namespace tag is in the nature
of a back pointer and so getting and putting the network
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
Sockets need to get a reference to their network namespace,
or possibly a simple hold if someone registers on the network
namespace notifier and will free the sockets when the namespace
is going to be destroyed.
Signed-off-by: Eric W
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
The initial network namespace is special and we need to use it for various
things. Probably the biggest initial use will be to ensure code that
can't cope with multiple namespaces only sees the initial network namespace.
For that reason
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
It turns out after a quick audit that except for removing the checks
there is really nothing to do here.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
net/core/rtnetlink.c | 21 +++--
1 files changed, 3 insertions
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
This patch allows you to create a new network namespace
using sys_clone(...).
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
include/linux/sched.h|1 +
kernel/nsproxy.c | 11 +++
net/core/net_namespace.c
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
In particalure I moved:
/proc/sys/net/core/xfrm_aevent_etime
/proc/sys/net/core/xfrm_aevent_rseqth
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
include/net/xfrm.h |4 ++--
net/core/sysctl_net_core.c | 37
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
include/linux/socket.h |3 ++-
net/core/sysctl_net_core.c | 16
net/socket.c |7 ---
3 files changed, 14 insertions(+), 12 deletions
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
Except for carefully selected pseudo devices all network
interfaces should start out in the initial network namespace.
Ultimately it will be register_netdev that examines what
dev-nd_net is set to and places a device in a network namespace
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
After this patch none of the netlink callback support anything
except the initial network namespace but the rtnetlink infrastructure
now handles multiple network namespaces.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
include/linux
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
When forcibly changing the network namespace of a device
I need something that can generate a name for the device
in the new namespace without overwriting the old name.
__dev_alloc_name provides me that functionality.
Signed-off-by: Eric W
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
Add the config option to enable multiple network namespaces.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
net/Kconfig |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/net/Kconfig b/net/Kconfig
index
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
net/core/wireless.c | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/net/core/wireless.c b/net/core/wireless.c
index 9036359..d534617 100644
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
This is done by making all of the relevant global variables
per network namespace.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
net/packet/af_packet.c | 125 +++-
1 files changed, 81
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
The user interface is: register_net_sysctl_table and
unregister_net_sysctl_table. Very much like the current
interface except there is an network namespace parameter.
This this any sysctl in the net_root_table and it's
subdirectories
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
This patch introduces NETIF_F_NETNS_LOCAL a flag to indicate
a network device is local to a single network namespace and
should never be moved. Useful for pseudo devices that we
need an instance in each network namespace (like the loopback
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
Many of the changes to the network stack will simply be adding a
network namespace parameter to function calls or moving variables
from globals to being per network namespace. When those variables
have initializers that cannot statically
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
Support is added for the .data.pernet section where all of
the variables who have a single instance in each network
namespace will live. Every architectures linker script
is modified so is should work.
Summarizing the functions:
net_ns_init
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
Each netlink socket will live in exactly one network namespace,
this includes the controlling kernel sockets.
This patch updates all of the existing netlink protocols
to only support the initial network namespace. Request
by clients in other
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
This patch passes in the namespace a new socket should be created in
and has the socket code do the appropriate reference counting. By
virtue of this all socket create methods are touched. In addition
the socket create methods are modified so
Stephen Hemminger [EMAIL PROTECTED] writes:
Can all this be a nop if a CONFIG option is not selected?
That is exactly what this infrastructure supports.
What you see is the version that comes into effect when
the CONFIG option is not selected.
From using an empty structure to replace a pointer
Robert Olsson [EMAIL PROTECTED] writes:
David Miller writes:
Yes the case when the trie is just a single leaf got wrong with the
iterator and your patchs cures it. I think we have a similar problem
with /proc/net/fib_trie
I'm happy to review a fix for that :-)
When main
Auke Kok [EMAIL PROTECTED] writes:
Adrian Bunk wrote:
This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem
Auke Kok [EMAIL PROTECTED] writes:
maybe I've been unclear, but here's how e1000 detects link changes:
1) by checking every 2 seconds in the watchdog by reading PHY registers
2) by receiving an interrupt from the NIC with the LSI bit in the interrupt
control register
if the link is down to
Auke Kok [EMAIL PROTECTED] writes:
that's explained by a driver change that did that. Since at initialization
we're
basically waiting for a link change to tell the stack that we're up, we
decided
to change the order to have the hardware fire an LSI interrupt to trigger a
watchdog run. So
Adam Kropelin [EMAIL PROTECTED] writes:
Can I get the corresponding lspci -xxx output. I suspect the BIOS
did not program the hypertransport MSI mapping capabilities correctly.
All it has to do is set the enable but still, occasionally BIOS
writers miss the most amazing things.
Here you
Adam Kropelin [EMAIL PROTECTED] writes:
Naive question... Can the pci layer (or e1000) detect that MSI is not enabled
in
the hardware and avoid using it in that case? With the number of MSI problems
showing up it seems risky to assume it's usable on any given platform without
some sort of
My apologies for not looking at this earlier I had an email
hickup so I'm having to recreate the context from email archives,
and you didn't copy me.
Have you seen my previous work in this direction?
I know I had a much much more complete implementation. The only part
I had not completed was
Daniel Lezcano [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Have you seen my previous work in this direction?
I know I had a much much more complete implementation. The only part
I had not completed was iptables support and that was about a days
more work.
No, I didn't see your
tcp_make_synack consume the dst entry so we still have
a dst_entry with a bumped refrence count at the end of
this function.
Therefore we need to call dst_release just before we return
just like tcp_v4_send_synack does.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
net/ipv6/tcp_ipv6.c |1 +
1
elevated.
Fix this by simply moving rt6_ifdown where we flush the routes after
we have removed all of the addresses from the interface.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
net/ipv6/addrconf.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions
Herbert Xu [EMAIL PROTECTED] writes:
On Wed, Jan 25, 2006 at 08:12:02PM +, Eric W. Biederman wrote:
Unfortunately because we have already call rt6_ifdown() the route is
not found in the routing table, the dst_free does not decrement the
count and is therefore unable to free the dst entry
David S. Miller [EMAIL PROTECTED] writes:
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Wed, 25 Jan 2006 13:08:53 -0700
Analysis:
Currently tcp_v6_send_synack is never called with a dst entry
so dst always comes in as NULL.
ip6_dst_lookup calls ip6_route_output which calls dst_hold
Jeff Garzik [EMAIL PROTECTED] writes:
Andi Kleen wrote:
There was already talk some time ago to make NAPI drivers use
the hardware mitigation again. The reason is when you have
This was discussed on the netdev list, and the conclusion was that you want
both
NAPI and hw mitigation. This
Herbert Xu [EMAIL PROTECTED] writes:
On Fri, Jan 27, 2006 at 01:00:49AM -0700, Eric W. Biederman wrote:
However I do know I have correctly found the leak.
Yes you are right. The locking/refcounting in addrconf.c is such
a mess. I've asked a number of times before as to why most
Christopher Friesen [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Jeff Garzik [EMAIL PROTECTED] writes:
This was discussed on the netdev list, and the conclusion was that
you want both NAPI and hw mitigation. This was implemented in a
few drivers, at least.
How does that deal
Leonid Grossman [EMAIL PROTECTED] writes:
There two facilities (at least, in our ASIC, but there is no reason this
can't be part of the generic multi-channel driver interface that I will
get to shortly) to deal with it.
- hardware supports more than one utilization-based interrupt rate (we
Leonid Grossman [EMAIL PROTECTED] writes:
I did not mean kernel bypass, just L2 hw channels that for
all practical purposes act as separate NICs -
different MAC addresses, no blocking, independent reset, etc.
Yes. Nearly all of what you need for safe kernel bypass.
In the worst case I
Herbert Poetzl [EMAIL PROTECTED] writes:
On Sat, Nov 25, 2006 at 01:21:39AM -0700, Eric W. Biederman wrote:
There are two techniques in real use.
- Bind/Accept filtering
Which layer 3 addresses a socket can bind/accept are filtered,
but otherwise the network stack remains unchanged
I do not want to get into a big debate on the merits of various
techniques at this time. We seem to be in basic agreement
about what we are talking about.
There is one thing I think we can all agree upon.
- Everything except isolation at the network device/L2 layer, does not
allow guests to
Ok. Just a quick summary of where I see the discussion.
We all agree that L2 isolation is needed at some point.
The approaches discussed for L2 and L3 are sufficiently orthogonal
that we can implement then in either order. You would need to
unshare L3 to unshare L2, but if we think of them as
jamal [EMAIL PROTECTED] writes:
I have removed the Re: just to add some freshness to the discussion
So i read quickly the rest of the discussions. I was almost suprised to
find that i agree with Eric on a lot of opinions (we also agree that
vindaloo is good for you i guess);-
The two issues
jamal [EMAIL PROTECTED] writes:
On Mon, 2006-04-12 at 05:15 -0700, Eric W. Biederman wrote:
jamal [EMAIL PROTECTED] writes:
Containers are a necessary first step to getting migration and
checkpoint/restart
assistance from the kernel.
Isnt it like a MUST have if you are doing things from
Dmitry Mishin [EMAIL PROTECTED] writes:
On Sunday 03 December 2006 19:00, Eric W. Biederman wrote:
Ok. Just a quick summary of where I see the discussion.
We all agree that L2 isolation is needed at some point.
As we all agreed on this, may be it is time to send patches one-by-one
Dmitry Mishin [EMAIL PROTECTED] writes:
On Monday 04 December 2006 18:35, Eric W. Biederman wrote:
[skip]
Where and when you look to find the network namespace that applies to
a packet is the primary difference between the OpenVZ L2
implementation and my L2 implementation
Herbert Poetzl [EMAIL PROTECTED] writes:
On Mon, Dec 04, 2006 at 06:19:00PM +0300, Dmitry Mishin wrote:
On Sunday 03 December 2006 19:00, Eric W. Biederman wrote:
Ok. Just a quick summary of where I see the discussion.
We all agree that L2 isolation is needed at some point.
As we all
Herbert Poetzl [EMAIL PROTECTED] writes:
But, ok, it is not the real point to argue so much imho and waste our
time instead of doing things.
well, IMHO better talk (and think) first, then implement
something ... not the other way round, and then start
fixing up the mess ...
Well we need a
Herbert Poetzl [EMAIL PROTECTED] writes:
On Fri, Dec 08, 2006 at 12:57:49PM -0700, Eric W. Biederman wrote:
Herbert Poetzl [EMAIL PROTECTED] writes:
But, ok, it is not the real point to argue so much imho
and waste our time instead of doing things.
well, IMHO better talk (and think
Jay Cliburn [EMAIL PROTECTED] writes:
We're trying to track down the source of a problem that occurs whenever
the atl1 network driver is activated on a 32-bit 2.6.21-rc4 kernel. We
need help from netdev.
We can load the driver just fine, but whenever we activate the
network, we see APIC
Jay Cliburn [EMAIL PROTECTED] writes:
On Tue, 27 Mar 2007 14:42:20 -0600
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
Thanks for replying, Eric. I've added atl1-devel to the cc list.
Do you have msi's working in 2.6.21-rc4 in the x86_64 kernel?
I can't personally verify it anymore
Daniel Lezcano [EMAIL PROTECTED] writes:
3. General observations
---
The objective to have no performances degrations, when the network
namespace is off in the kernel, is reached in both solutions.
When the network is used outside the container and the network
Daniel Lezcano [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Daniel Lezcano [EMAIL PROTECTED] writes:
3. General observations
---
The objective to have no performances degrations, when the network
namespace is off in the kernel, is reached in both solutions
Kirill Korotaev [EMAIL PROTECTED] writes:
Ideally we can optimize the bridge code or something equivalent to
it so that we can take one look at the destination mac address and
know which network namespace we should be in. Potentially moving this
work to hardware when the hardware supports
Benjamin Thery [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Daniel Lezcano [EMAIL PROTECTED] writes:
[...]
* When do you expect to have the network namespace into mainline ?
My current goal is to finish my rebase against 2.6.linus_lastest in
the next couple of days after having
Daniel Lezcano [EMAIL PROTECTED] writes:
Hi,
as suggested Rick, I added the Service Demand results to the matrix.
Thanks. The latency number is interesting and it confirms what we were
seeing looking at cpu usage.
We don't have an inexpesive way to get a packet from the outside world
to a
Daniel Lezcano [EMAIL PROTECTED] writes:
Hi,
as suggested Rick, I added the Service Demand results to the matrix.
A couple of random thoughts in trying to understand the numbers you are
seeing.
- Checksum offloading?
You have noted that with the bridge netfilter support disabled you
are
Benjamin Thery [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
A couple of random thoughts in trying to understand the numbers you are
seeing.
- Checksum offloading?
You have noted that with the bridge netfilter support disabled you
are still seeing additional checksum overhead
/newif
To destroy a pair of devices:
echo -n 'veth0' /sys/module/etun/parameters/delif
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
drivers/net/Kconfig | 14 ++
drivers/net/Makefile |1 +
drivers/net/etun.c | 486 ++
3 files
Daniel Lezcano [EMAIL PROTECTED] writes:
Hi,
Eric Biederman has posted a few weeks ago a RFC-patchset concerning the
network namespace.
I ported it to the 2.6.20 kernel and uploaded the patchset to
http://lxc.sourceforge.net/network.php
For the part I had to used (TCP/UDP-IPV4 with
Ben Greear [EMAIL PROTECTED] writes:
Is there any way to tell for certain if an interface is a etun or not? Maybe
a file could be found (or not) in sysfs somewhere?
Link for any decent network driver ethtool -i interface
Also, how do you find the peer device from user-space? This would be
Roland Dreier [EMAIL PROTECTED] writes:
+/*
+ * The higher levels take care of making this non-reentrant (it's
+ * called with bh's disabled).
+ */
+static int etun_xmit(struct sk_buff *skb, struct net_device *tx_dev)
You have this comment, but then...
+ dev-features
Stephen Hemminger [EMAIL PROTECTED] writes:
Why not implement a true virtual network rather than simple
tunnel pairs?
Mostly I don't even need etun. It is a cheap way to make up for
the lack of sufficient physical network adapters on the machine.
If you plug in enough network cards into the
Ben Greear [EMAIL PROTECTED] writes:
I guess that will do, but then if you ever change the strings, any user-space
that is
depending on this will break or have to be modified with additional cruft. It
seems
cleaner to me to have an ioctl or a specific place in /proc or some other
virtual
David Miller [EMAIL PROTECTED] writes:
From: Patrick McHardy [EMAIL PROTECTED]
Date: Mon, 09 Apr 2007 18:58:13 +0200
It would be nice if someone would finally come up with a generic
interface based on netlink (RTM_NEWLINK) instead of adding yet
another couple of homegrown interfaces.
I
Johannes Berg [EMAIL PROTECTED] writes:
Our virtual devices are always associated with a piece of hardware, and
we really want them to be associated with that at all times, even when
not UP. Everything else seems like a huge complication if only because
then we can't have whoever will be
David Howells [EMAIL PROTECTED] writes:
Eric W. Biederman [EMAIL PROTECTED] wrote:
What is the ETA on your patches?
That depends on Dave Miller now, I think. I'm assuming they need to go
through the network GIT tree to get to Linus. Certainly Andrew Morton seems
to think so.
Ok. I
David Howells [EMAIL PROTECTED] writes:
Eric W. Biederman [EMAIL PROTECTED] wrote:
Ok. I don't see any patches in -mm so I was assuming these patches have
not been queued up anywhere.
They haven't been quite yet. Is it your intention to kill these features in
2.6.22?
That is my goal
Andrew Morton [EMAIL PROTECTED] writes:
I note that the networking tree is adding new sysctls:
HEAD/include/linux/sysctl.h
NET_IPV6_ACCEPT_SOURCE_ROUTE=25,
===
NET_IPV6_OPTIMISTIC_DAD=24,
NET_IPV6_ACCEPT_SOURCE_ROUTE=25,
/include/linux/sysctl.h
(Well, it's
David Miller [EMAIL PROTECTED] writes:
From: Andrew Morton [EMAIL PROTECTED]
Date: Wed, 25 Apr 2007 12:29:24 -0700
I note that the networking tree is adding new sysctls:
HEAD/include/linux/sysctl.h
NET_IPV6_ACCEPT_SOURCE_ROUTE=25,
===
NET_IPV6_OPTIMISTIC_DAD=24,
David Miller [EMAIL PROTECTED] writes:
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Wed, 25 Apr 2007 14:06:34 -0600
David for clarity do you happen to know of anyone using binary
sysctl values?
None at all.
In particular is there any reason not to use CTL_UNNUMBERED
for new
Patrick McHardy [EMAIL PROTECTED] writes:
jamal wrote:
On Wed, 2007-02-05 at 14:34 +0200, Patrick McHardy wrote:
Thats a lot better than using sysfs, but I think it would be
preferrable to use rtnetlink instead of genetlink for network
configuration.
or you can just hold rtnl while
Ayaz Abdulla [EMAIL PROTECTED] writes:
Can we remove Reverse Engineered and (EXPERIMENTAL) now?
Can we get better bit names in the driver?
Having unknown xyz in half of the names is scare?
Can we have some help fixing the problem where the on some boots
the driver cannot receive packets?
Or
but that is still horribly bad.
I will work on clearing up some of those names.
Thanks.
-Original Message-
From: Eric W. Biederman [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 16, 2006 9:58 AM
To: Ayaz Abdulla
Cc: Stephen Hemminger; Manfred Spraul [EMAIL PROTECTED], Jeff
Garzik [EMAIL
Ayaz Abdulla [EMAIL PROTECTED] writes:
Its hard for me to believe that you would think that there is no
indication of the driver being actively supported. Take a look at the
revision history in the forcedeth.c file. There have been 18 revisions
in less then a year timeframe.
There is no
Jeff Garzik [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
There is no maintainer contact in the driver nor in the maintainers file.
It has clearly been bug fixed but simply didn't look like there
was a maintainer.
Then you clearly did not look at all. Simply running the command
101 - 200 of 1118 matches
Mail list logo
