Currently we destroy inet devices when we remove the last interface
from an inet device, and during NETDEV_UNREGISTER. We only create
them during NETDEV_REGISTER event. The result is if you and an ipv4
address to a device delete it (so the device has no ipv4 addresses)
and attampt to add any ipv
From: YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]>
Date: Fri, 22 Jun 2007 15:15:27 +0900 (JST)
> Bug reported by Haruhito Watanabe <[EMAIL PROTECTED]>.
>
> This is also appropriate for -stable releases.
>
> Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
Thank you, I will apply this and pu
Bug reported by Haruhito Watanabe <[EMAIL PROTECTED]>.
This is also appropriate for -stable releases.
Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
---
net/ipv6/ndisc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index d8b3
Hi,
I just found this in the kernel log:
2007-06-22_05:47:50.69894 kern.info: sky2 eth0: disabling interface
2007-06-22_05:47:50.72039 kern.info: sky2 eth0: enabling interface
2007-06-22_05:47:50.72240 kern.info: sky2 eth0: ram buffer 48K
2007-06-22_05:47:52.40903 kern.info: sky2 eth0: Link is up
Ben Greear <[EMAIL PROTECTED]> writes:
> Patrick McHardy wrote:
>> Eric W. Biederman wrote:
>
>>> For the macvlan code do we need to do anything special if we transmit
>>> to a mac we would normally receive? Another unicast mac of the same
>>> nic for example.
>>
>> That doesn't happen under norm
On Fri, 22 Jun 2007 04:45:25 +0200
Ian Kumlien <[EMAIL PROTECTED]> wrote:
> On tor, 2007-06-21 at 18:57 -0700, Stephen Hemminger wrote:
> > Redirected of LKML, netdev is the proper list.
>
> Thanks =)
>
> > On Thu, 21 Jun 2007 22:51:32 +0200
> > Ian Kumlien <[EMAIL PROTECTED]> wrote:
> >
> > >
This patch adds documentation for the PF_CAN protocol family.
Signed-Off-By: Oliver Hartkopp <[EMAIL PROTECTED]>
Signed-Off-By: Urs Thuermann <[EMAIL PROTECTED]>
---
Documentation/networking/00-INDEX |2
Documentation/networking/can.txt | 635 ++
2 file
This patch adds the CAN broadcast manager (bcm) protocol.
Signed-Off-By: Oliver Hartkopp <[EMAIL PROTECTED]>
Signed-Off-By: Urs Thuermann <[EMAIL PROTECTED]>
---
include/linux/can/bcm.h | 65 +
net/can/Kconfig | 28
net/can/Makefile|3
net/can/bcm.c | 1750 +++
Hello Dave,
this is the third post of the patch series that adds the PF_CAN
protocol family for the Controller Area Network.
Since our last post we have changed the code quite a lot:
* Use sbk->sk and skb->pkt_type instead of skb->cb to pass loopback
flags and originating socket down to the dr
This patch adds entries in the CREDITS and MAINTAINERS file for CAN.
Signed-Off-By: Oliver Hartkopp <[EMAIL PROTECTED]>
Signed-Off-By: Urs Thuermann <[EMAIL PROTECTED]>
---
CREDITS | 16
MAINTAINERS |9 +
2 files changed, 25 insertions(+)
Index: linux-2.6.22-r
This patch adds the virtual CAN bus (vcan) network driver.
The vcan device is just a loopback device for CAN frames, no
real CAN hardware is involved.
Signed-Off-By: Oliver Hartkopp <[EMAIL PROTECTED]>
Signed-Off-By: Urs Thuermann <[EMAIL PROTECTED]>
---
drivers/net/Makefile |1
drivers
This patch adds the CAN raw protocol.
Signed-Off-By: Oliver Hartkopp <[EMAIL PROTECTED]>
Signed-Off-By: Urs Thuermann <[EMAIL PROTECTED]>
---
include/linux/can/raw.h | 31 +
net/can/Kconfig | 26 +
net/can/Makefile|3
net/can/raw.c | 751 ++
This patch adds a protocol/address family number, ARP hardware type,
ethernet packet type, and a line discipline number for the SocketCAN
implementation.
Signed-Off-By: Oliver Hartkopp <[EMAIL PROTECTED]>
Signed-Off-By: Urs Thuermann <[EMAIL PROTECTED]>
---
include/linux/if_arp.h |1 +
inc
Patrick McHardy wrote:
Eric W. Biederman wrote:
For the macvlan code do we need to do anything special if we transmit
to a mac we would normally receive? Another unicast mac of the same
nic for example.
That doesn't happen under normal circumstances. I don't believe
it would work.
Assumin
Patrick McHardy wrote:
Eric W. Biederman wrote:
For the macvlan hash you just use an upper byte. Is that just a
simple starting place, or do we not need a more complex hash.
That gave me an idea, since the default addresses are random
anyway I'm now using an incrementing counter for the up
On tor, 2007-06-21 at 18:57 -0700, Stephen Hemminger wrote:
> Redirected of LKML, netdev is the proper list.
Thanks =)
> On Thu, 21 Jun 2007 22:51:32 +0200
> Ian Kumlien <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > recently have started to see this in my dmesg:
> >
> > NETDEV WATCHDOG: eth0:
Redirected of LKML, netdev is the proper list.
On Thu, 21 Jun 2007 22:51:32 +0200
Ian Kumlien <[EMAIL PROTECTED]> wrote:
> Hi,
>
> recently have started to see this in my dmesg:
>
> NETDEV WATCHDOG: eth0: transmit timed out
> sky2 eth0: tx timeout
> sky2 eth0: transmit ring 449 .. 408 report=
Eric W. Biederman wrote:
For the macvlan hash you just use an upper byte. Is that just a
simple starting place, or do we not need a more complex hash.
That gave me an idea, since the default addresses are random
anyway I'm now using an incrementing counter for the upper byte.
-
To unsubsc
On Thu, 21 Jun 2007 14:27:04 -0700
PJ Waskiewicz <[EMAIL PROTECTED]> wrote:
> Add tc support for the sch_rr qdisc. This qdisc supports multiple queues
> on hardware. The syntax for sch_rr is the same as sch_prio.
>
> Signed-off-by: Peter P Waskiewicz Jr <[EMAIL PROTECTED]>
>
If the rr
On Thu, 2007-06-21 at 11:39 -0400, jamal wrote:
> I gave you two opportunities to bail out of this discussion, i am gonna
> take that your rejection to that offer implies you my friend wants to
> get to the bottom of this i.e you are on a mission to find the truth.
> So lets continue this.
It soun
Waskiewicz Jr, Peter P wrote:
The dependencies seem to be very confused. SCHED_PRIO does
not depend on anything new, SCH_RR also doesn't depend on
anything. SCH_PRIO_MQ and SCH_RR_MQ (which is missing) depend
on SCH_PRIO/SCH_RR. A single NET_SCH_MULTIQUEUE option seems
better than adding one p
Eric W. Biederman wrote:
Patrick McHardy <[EMAIL PROTECTED]> writes:
Eric W. Biederman wrote:
I'm trying to understand what the point of this patch is.
In once sense I find the concept of filtering and listening for multiple
mac addresses very interesting, especially if we could break
> The dependencies seem to be very confused. SCHED_PRIO does
> not depend on anything new, SCH_RR also doesn't depend on
> anything. SCH_PRIO_MQ and SCH_RR_MQ (which is missing) depend
> on SCH_PRIO/SCH_RR. A single NET_SCH_MULTIQUEUE option seems
> better than adding one per scheduler though.
PJ Waskiewicz wrote:
diff --git a/net/sched/Kconfig b/net/sched/Kconfig
index 475df84..ca0b352 100644
--- a/net/sched/Kconfig
+++ b/net/sched/Kconfig
@@ -102,8 +102,16 @@ config NET_SCH_ATM
To compile this code as a module, choose M here: the
module will be called sch_atm.
+
> On Sun, 17 Jun 2007 01:20:20 +0400 Ivan Kokshaysky <[EMAIL PROTECTED]> wrote:
> Hopefully this fixes http://bugzilla.kernel.org/show_bug.cgi?id=8635
>
> The struct in6_addr passed to csum_ipv6_magic() is 4 byte aligned,
> so we can't use the regular 64-bit loads.
> Since the cost of handling of
> PJ Waskiewicz wrote:
> > I did not modify other users of netif_queue_stopped() in
> > net/core/netpoll.c, net/core/dev.c, or net/core/pktgen.c, since no
> > classification occurs for the skb being sent to the device.
> > Therefore, packets should always be ending up in queue 0,
> so there's
PJ Waskiewicz wrote:
I did not modify other users of netif_queue_stopped() in net/core/netpoll.c,
net/core/dev.c, or net/core/pktgen.c, since no classification occurs for
the skb being sent to the device. Therefore, packets should always be
ending up in queue 0, so there's no need to check the s
Add tc support for the sch_rr qdisc. This qdisc supports multiple queues
on hardware. The syntax for sch_rr is the same as sch_prio.
Signed-off-by: Peter P Waskiewicz Jr <[EMAIL PROTECTED]>
---
tc/Makefile |1 +
tc/q_rr.c | 113 +++
Add the new sch_rr qdisc for multiqueue network device support.
Allow sch_prio to be compiled with or without multiqueue hardware
support.
sch_rr is part of sch_prio, and is referenced from MODULE_ALIAS. This
was done since sch_prio and sch_rr only differ in their dequeue routine.
Signed-off-by:
This patch is to support the new sch_rr (round-robin) qdisc being proposed
in NET for multiqueue network device support in the Linux network stack.
It uses q_prio.c as the template, since the qdiscs are nearly identical,
outside of the ->dequeue() routine.
I'm soliciting feedback for a 2.6.23 mult
Add a brief howto to Documentation/networking for multiqueue. It
explains how to use the multiqueue API in a driver to support
multiqueue paths from the stack, as well as the qdiscs to use for
feeding a multiqueue device.
Signed-off-by: Peter P Waskiewicz Jr <[EMAIL PROTECTED]>
---
Documentatio
Add the multiqueue hardware device support API to the core network
stack. Allow drivers to allocate multiple queues and manage them
at the netdev level if they choose to do so.
Added a new field to sk_buff, namely queue_mapping, for drivers to
know which tx_ring to select based on OS classificati
Please consider these patches for 2.6.23 inclusion.
Updates since the last submission:
1. skb->queue_mapping moved into the iff cacheline. I looked at moving
iff and queue_mapping, but there wasn't enough room anywhere else to
logically group these in a different cacheline that I could see
[EMAIL PROTECTED] wrote:
> From: [EMAIL PROTECTED] (Eric W. Biederman)
> Date: Thu, 21 Jun 2007 13:08:12 -0600
>
>> However this just seems to allow a card to decode multiple mac
>> addresses which in some oddball load balancing configurations may
>> actually be useful, but it seems fairly limited
On Tue, 2007-06-19 at 17:21 +0400, Evgeniy Polyakov wrote:
> Hi.
>
> On Thu, Jun 07, 2007 at 07:43:49AM -0400, jamal ([EMAIL PROTECTED]) wrote:
> > Folks, we need help. Please run this on different hardware. Evgeniy, i
> > thought this kind of stuff excites you, no? ;-> (wink, wink).
> > Only the
Patrick McHardy <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> I'm trying to understand what the point of this patch is.
>>
>> In once sense I find the concept of filtering and listening for multiple
>> mac addresses very interesting, especially if we could break out different
>> stream
> > Yes. This is the tc command I used to configure the qdisc (with
> > q_rr.c attached from my patches iproute2 package):
> >
> > # tc qdisc add dev eth2 root handle 1: rr bands 8 RTNETLINK
> answers:
> > No such file or directory
>
> Again, I bet you don't have CONFIG_NET_SCH_RR enabled:
Ch
Eric W. Biederman wrote:
I'm trying to understand what the point of this patch is.
In once sense I find the concept of filtering and listening for multiple
mac addresses very interesting, especially if we could break out different
streams of traffic by destination mac address into separate netwo
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Thu, 21 Jun 2007 13:08:12 -0600
> However this just seems to allow a card to decode multiple mac addresses
> which in some oddball load balancing configurations may actually be
> useful, but it seems fairly limited.
>
> Do you have a specific use
Waskiewicz Jr, Peter P wrote:
The code looks correct. Are you sure you had the config
option enabled during your test?
Yes. This is the tc command I used to configure the qdisc (with q_rr.c
attached from my patches iproute2 package):
# tc qdisc add dev eth2 root handle 1: rr bands 8
RTNETLI
Patrick McHardy <[EMAIL PROTECTED]> writes:
> These two patches contain a first short at secondary unicast address support.
> I'm still working on converting macvlan as an example, but since I'm about to
> leave for tonight I thougth I'd get them out for some comments now.
>
> The patch adds two n
> Waskiewicz Jr, Peter P wrote:
> >> Please post the code.
> >>
> >>
> >
> > Code is attached. Please forgive the attachment and any whitespace
> > damage...currently using Doubtlook to send this (cringe).
> >
>
> The code looks correct. Are you sure you had the config
> option enabled
Waskiewicz Jr, Peter P wrote:
Please post the code.
Code is attached. Please forgive the attachment and any whitespace
damage...currently using Doubtlook to send this (cringe).
The code looks correct. Are you sure you had the config option
enabled during your test?
-
To unsubscribe
> Please post the code.
>
Code is attached. Please forgive the attachment and any whitespace
damage...currently using Doubtlook to send this (cringe).
Thanks,
-PJ Waskiewicz
sch_prio.c
Description: sch_prio.c
Waskiewicz Jr, Peter P wrote:
BTw, couldn't you just merge sch_rr with prio? AFAICT you
only need a new dequeue function, a new struct Qdisc_ops and
a MODULE_ALIAS.
Ok, I have this somewhat working, but need to poll for some help from
the community. I used MODULE_ALIAS("sch_rr") in sch_prio.c
> BTw, couldn't you just merge sch_rr with prio? AFAICT you
> only need a new dequeue function, a new struct Qdisc_ops and
> a MODULE_ALIAS.
Ok, I have this somewhat working, but need to poll for some help from
the community. I used MODULE_ALIAS("sch_rr") in sch_prio.c, and
modprobe is happily
NetXen: Make use of per port interrupt scheme.
This patch makes the driver inform the firmware that it can support the
per port interrupt mask scheme. The driver too needs to check whether
the firmware also supports the per port interrupt scheme. If yes,
then interrupt for each port is enabled/dis
NetXen: Fix issue of MSI not working correctly
NetXen driver uses PCI function 0 to provide the functionality of MSI.
The patch makes driver check the bus master bit for function 0 and
enable it after the card initialization.
Signed-off-by: Milan Bag <[EMAIL PROTECTED]>
Signed-off-by: Wen Xiong <[
Hi All,
I will be sending updates for NetXen NIC 1/10 G Ethernet driver
in the following emails. These are bug fixes and better interrupt
handling schemes. These have been test on x86 machines and
PowerPC blades.
Thanks,
Mithlesh Thukral
-
To unsubscribe from this list: send the line "unsubscrib
On Thu, Jun 21, 2007 at 12:08:19PM -0400, jamal wrote:
> The results in the table for opteron and xeon are swapped when
> cutnpasting from a larger test result. So Opteron is the one with better
> results.
> In any case - off for the day over here.
You should qualify that as 'Old P4 Xeon', as the
On Thu, Jun 21, 2007 at 11:54:17AM -0400, jamal ([EMAIL PROTECTED]) wrote:
> Evgeniy, did you sync on the batching case with the git tree?
My tree contains following commits:
Latest mainline commit: fa490cfd15d7ce0900097cc4e60cfd7a76381138
Latest batch commit: 9b8cc32088abfda8be7f394cfd5ee6ac694d
Hi all,
Here is a list of some known regressions in 2.6.22-rc5
with patches available.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
(BTW. There is a new category called "Will be fixed in 2.6.23")
Memory management
Subject: bug in i386 MTR
This moves the local_irq_enable() call in net_rx_action() to before
calling the CONFIG_NET_DMA's dma_async_memcpy_issue_pending() rather
than after. This shortens the irq disabled window and allows for DMA
drivers that need to do their own irq hold.
Signed-off-by: Shannon Nelson <[EMAIL PROTECTED
On Thu, 2007-21-06 at 11:54 -0400, jamal wrote:
> The summary is: Batching always is better, jiffies is always the better
> clock source (and who would have thunk,eh? Opteron kicks a Xeons ass).
The results in the table for opteron and xeon are swapped when
cutnpasting from a larger test result.
On Tue, 2007-19-06 at 15:28 -0700, David Miller wrote:
> Converting pktgen over to ktime_t might be a nice cleanup.
Would that really solve it? i.e doesnt it still tie to what the clock
source is?
I had a friend of mine (Robert, you know Jeremy) and results are
slightly different from what Evgin
On Wed, 2007-20-06 at 13:25 +0200, Johannes Berg wrote:
> Ok. That's definitely a bug in nl80211 as we have it in development
> right now.
Sorry, have never looked at that code.
> Btw, what happens if the group id gets larger than 31?
You can use setsockopt to set the multicast groups. What yo
I gave you two opportunities to bail out of this discussion, i am gonna
take that your rejection to that offer implies you my friend wants to
get to the bottom of this i.e you are on a mission to find the truth.
So lets continue this.
On Wed, 2007-20-06 at 13:51 +0800, Zhu Yi wrote:
> No, becaus
On Mon, Jun 18, 2007 at 10:36:54PM -0700, David Miller wrote:
> This patch looks fine.
>
> I'd like it resubmitted with a proper changelog and signoff, and once
> I have that I will thus queue it up for the 2.6.23 merge window.
Introduce a new syscall TUNSETGROUP for group ownership setting of ta
Miklos Szeredi <[EMAIL PROTECTED]> writes:
> [CC'd Al Viro and Alan Cox, restored patch]
>
>> > There are races involving the garbage collector, that can throw away
>> > perfectly good packets with AF_UNIX sockets in them.
>> >
>> > The problems arise when a socket goes from installed to in-fligh
On Tue, 2007-19-06 at 16:25 -0700, Stephen Hemminger wrote:
> Using current xfrm.h from kernel headers, causes conflicts.
> Instead of XFRMA_SADCNT, it should be using XFRMA_SAD_CNT.
>
Yeah, that changed in the kernel header.
If it compiles, it should be fine; thanks Stephen.
cheers,
jamal
-
Prafulla Deuskar wrote:
On 6/19/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
David Miller wrote:
> This is actually a real issue for virtualization, and many
> if not all current generation ethernet chips support
> programming several unicast ethernet addresses in the MAC.
>
> Networking switches
Hi,
My mistake.
Resending after reformatting the patch by hand.
Looks like gmail messes the plain text patches.
Thanks
Signed-off-by: Pradeep Singh <[EMAIL PROTECTED]>
---
drivers/net/chelsio/cxgb2.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/chelsio/
Add xenbus_for_each_[back,front]end functions to iterate each bus
Signed-off-by: Kieran Mansley <[EMAIL PROTECTED]>
diff -r d5e0eb7dd069 drivers/xen/xenbus/xenbus_probe.c
--- a/drivers/xen/xenbus/xenbus_probe.c Sun Jun 10 19:50:32 2007 +0100
+++ b/drivers/xen/xenbus/xenbus_probe.c Fri Jun 15 15:
Add accel option to vif xend config
Signed-off-by: Kieran Mansley <[EMAIL PROTECTED]>
diff -r 405eb3e22887 tools/python/xen/xend/server/netif.py
--- a/tools/python/xen/xend/server/netif.py Thu Jun 14 14:50:04 2007 +0100
+++ b/tools/python/xen/xend/server/netif.py Thu Jun 14 14:52:55 2007
Backend net driver acceleration
Signed-off-by: Kieran Mansley <[EMAIL PROTECTED]>
diff -r 30c836e0575e drivers/xen/netback/Makefile
--- a/drivers/xen/netback/Makefile Fri Jun 15 15:35:17 2007 +0100
+++ b/drivers/xen/netback/Makefile Fri Jun 15 15:37:41 2007 +0100
@@ -1,5 +1,5 @@ obj-$(
This is a another iteration of some earlier patches sent to the xen-
devel mailing list, with a number of changes thanks to some useful
suggestions from others.
I've also CC'd netdev@vger.kernel.org at Herbert Xu's request as some of
the files being patched may be merged into upstream linux soon,
On 6/21/07, pradeep singh <[EMAIL PROTECTED]> wrote:
Hi,
This is second submission for a possible NULL dereference handling in
the Chelsio's 10G driver.
Thanks to Jens Axboe for pointing out my mistake of ignoring
subsequent dereferences in init_one routine.
Thanks
Apologies, looks like patch
Hi,
This is second submission for a possible NULL dereference handling in
the Chelsio's 10G driver.
Thanks to Jens Axboe for pointing out my mistake of ignoring
subsequent dereferences in init_one routine.
Thanks
Signed-off-by: Pradeep Singh <[EMAIL PROTECTED]>
---
drivers/net/chelsio/cxgb2.c |
On 6/21/07, Jens Axboe <[EMAIL PROTECTED]> wrote:
On Thu, Jun 21 2007, pradeep singh wrote:
> Hi
> On 6/21/07, Jens Axboe <[EMAIL PROTECTED]> wrote:
> >On Thu, Jun 21 2007, pradeep singh wrote:
> >> Hi,
> >>
> >> Chelsio's in kernel 10G driver does not checks the return value from
> >> t1_get_boa
On Thu, Jun 21 2007, pradeep singh wrote:
> Hi
> On 6/21/07, Jens Axboe <[EMAIL PROTECTED]> wrote:
> >On Thu, Jun 21 2007, pradeep singh wrote:
> >> Hi,
> >>
> >> Chelsio's in kernel 10G driver does not checks the return value from
> >> t1_get_board_info() in cxgb2.c.
> >> t1_get_board_info may ret
Hi
On 6/21/07, Jens Axboe <[EMAIL PROTECTED]> wrote:
On Thu, Jun 21 2007, pradeep singh wrote:
> Hi,
>
> Chelsio's in kernel 10G driver does not checks the return value from
> t1_get_board_info() in cxgb2.c.
> t1_get_board_info may return a NULL and we still go on to dereference
> it in the for l
On Thu, Jun 21 2007, pradeep singh wrote:
> Hi,
>
> Chelsio's in kernel 10G driver does not checks the return value from
> t1_get_board_info() in cxgb2.c.
> t1_get_board_info may return a NULL and we still go on to dereference
> it in the for loop without checking for the NULL.
>
> This patch fix
Hi,
Chelsio's in kernel 10G driver does not checks the return value from
t1_get_board_info() in cxgb2.c.
t1_get_board_info may return a NULL and we still go on to dereference
it in the for loop without checking for the NULL.
This patch fixes this.
Signed-off-by: Pradeep Singh <[EMAIL PROTECTED]
Hi list,
I have some trouble getting my network card to run.
when I run dmesg I can clearly see it being detected
eth0: VIA Rhine II at 0xee006000, 00:e0:c5:54:88:a8, IRQ 11.
eth0: MII PHY found at address 1, status 0x786d advertising 05e1 Link 45e1.
but when I try ifconfig eth0 up it fails wit
Hi Mark,
Networking stuff generally goes to netdev. [ Added to Cc: ]
On 6/21/07, Mark Hannessen <[EMAIL PROTECTED]> wrote:
Hi list,
I have some trouble getting my network card to run.
when I run dmesg I can clearly see it being detected
eth0: VIA Rhine II at 0xee006000, 00:e0:c5:54:88:a8, IRQ
Hi Keiichi,
> Please do consider configfs. Note that we'll have to lose the sysfs
> symlink from your target's kobject to the kobject of the ethernet
> device if we switch to configfs, but was that symlink needed for
> some essential functionality or was it simply for informational
> purpose? IM
Hi,
We will include this fix in next set of patch submission. Thanks for the
fix.
Thanks,
~Siva
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Olaf Hering
Sent: Wednesday, June 20, 2007 2:11 AM
To: Stephen Hemminger
Cc: [EMAIL PROTECTED]; netdev@vger.ke
Hello Satyam,
Hmm, I might've missed this thread, but my opinion on the
alternatives, fwiw:
1. I think adding new ioctl's to the kernel are generally disliked for
obvious reasons. Perhaps Stephen meant to add some generic
ioctl's above (and not separate ones specially implemented for
the dynami
Hello Satyam,
In any case, however, the point to extend the critical section here
to encapsulate all the three parts still stands. We wouldn't want
ioctl(NETCON_REMOVE_TARGET) on the specified target to
return without removing the target that the user specified just
because that target's etherne
Hello,
On Wed, 20 Jun 2007, Balazs Scheidler wrote:
> Is there a chance that this, or a patch with similar spirit (e.g. a way
> to send packets from non-local IP addresses) could be merged?
Last patch from Krisztian is exactly what I preferred
to see, I hope that someone really
80 matches
Mail list logo
