From: jamal <[EMAIL PROTECTED]>
Date: Fri, 29 Jun 2007 21:30:53 -0400
> On Fri, 2007-29-06 at 14:31 -0700, David Miller wrote:
> > Maybe for the control node switch, yes, but not for the guest network
> > devices.
>
> And that is precisely what i was talking about - and i am sure thats how
> the
one possibility would be to merge e1000new with support only for chips
not supported by e1000, and semi-freeze e1000 (fixes only, new device
support goes into e1000new). Then if there are some devices that are
more naturally supported by e1000new, we could later on merge patches
to move support fo
Jim McCullough wrote:
It goes back to ICH7 for the PCIe support. That also includes models used
as plugin PCIe devices. I dont remember if ICH6 erra devices were PCI or
PCIe. I'll leave that part for Auke.
On 6/29/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
Andrew Grover wrote:
I think makin
Jeff Garzik wrote:
Andrew Grover wrote:
I think making e1000new ICH9-and-newer isn't really the best place to
split it. The Windows e1000 driver got split on the PCI->PCIe
transition, something that clearly delineated what nics one driver
supported, and the other. There's no real technical reaso
On Fri, 2007-29-06 at 14:31 -0700, David Miller wrote:
> This conversation begins to go into a pointless direction already, as
> I feared it would.
>
> Nobody is going to configure bridges, classification, tc, and all of
> this other crap just for a simple virtualized guest networking device.
>
>
Sorry if this is a duplication, I forgot to switch to plain text.
On 6/29/07, Jim McCullough <[EMAIL PROTECTED]> wrote:
It goes back to ICH7 for the PCIe support. That also includes models used as
plugin PCIe devices. I dont remember if ICH6 erra devices were PCI or PCIe.
I'll leave that pa
Andrew Grover wrote:
I think making e1000new ICH9-and-newer isn't really the best place to
split it. The Windows e1000 driver got split on the PCI->PCIe
transition, something that clearly delineated what nics one driver
supported, and the other. There's no real technical reason for
splitting now
On 6/29/07, Andrew Grover <[EMAIL PROTECTED]> wrote:
I think making e1000new ICH9-and-newer isn't really the best place to
split it. The Windows e1000 driver got split on the PCI->PCIe
transition, something that clearly delineated what nics one driver
supported, and the other. There's no real tec
On 6/29/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
Given past history with duplicate drivers and the problems that they
cause -- I know, I've caused some of those problems :( -- I strongly
recommend against when it can be avoided.
Leaving e1000 with current hardware, and a new e1001 for newer ha
Kok, Auke wrote:
Jeff Garzik wrote:
Andrew Morton wrote:
On Fri, 29 Jun 2007 14:39:20 -0700
"Kok, Auke" <[EMAIL PROTECTED]> wrote:
That's why we want to introduce a second e1000 driver (named
differently, pick any name) that contains the new code base,
side-by-side into the kernel with the c
Jeff Garzik wrote:
Andrew Morton wrote:
On Fri, 29 Jun 2007 14:39:20 -0700
"Kok, Auke" <[EMAIL PROTECTED]> wrote:
That's why we want to introduce a second e1000 driver (named differently, pick
any name) that contains the new code base, side-by-side into the kernel with the
current e1000.
Sou
Andrew Morton wrote:
On Fri, 29 Jun 2007 14:39:20 -0700
"Kok, Auke" <[EMAIL PROTECTED]> wrote:
That's why we want to introduce a second e1000 driver (named differently, pick
any name) that contains the new code base, side-by-side into the kernel with the
current e1000.
Sounds like a reasonab
Andrew Morton wrote:
On Fri, 29 Jun 2007 14:39:20 -0700
"Kok, Auke" <[EMAIL PROTECTED]> wrote:
That's why we want to introduce a second e1000 driver (named differently, pick
any name) that contains the new code base, side-by-side into the kernel with the
current e1000.
Sounds like a reasonab
Kok, Auke wrote:
That's why we want to introduce a second e1000 driver (named
differently, pick any name) that contains the new code base,
side-by-side into the kernel with the current e1000.
We do not want to introduce duplicate drivers for the same hardware. We
spend -years- before the old
On Fri, 29 Jun 2007 14:39:20 -0700
"Kok, Auke" <[EMAIL PROTECTED]> wrote:
>
> That's why we want to introduce a second e1000 driver (named differently,
> pick
> any name) that contains the new code base, side-by-side into the kernel with
> the
> current e1000.
Sounds like a reasonable approa
On Fri, Jun 29, 2007 at 10:50:07AM -0700, Jason Lunz wrote:
> On Fri, Jun 29, 2007 at 06:29:18PM +0100, Mark McLoughlin wrote:
> > I understand there is some delay in getting e1000-7.5.5 into the
> > upstream kernel given the major re-working of the chipset specific
> > parts.
> >
> > I wo
Jeff Garzik wrote:
Jason Lunz wrote:
What's the prognosis for the 7.5.5-series e1000 reorg going into
netdev-2.6?
As I have posted previously, I am not keen on merging basically an e1000
rewrite. That basically throws away all Internet-wide testing so far.
The rewrite was not done according
From: Ben Greear <[EMAIL PROTECTED]>
Date: Fri, 29 Jun 2007 08:33:06 -0700
> Patrick McHardy wrote:
> > Right, but the current bridging code always uses promiscous mode
> > and its nice to avoid that if possible. Looking at the code, it
> > should be easy to avoid though by disabling learning (and
This conversation begins to go into a pointless direction already, as
I feared it would.
Nobody is going to configure bridges, classification, tc, and all of
this other crap just for a simple virtualized guest networking device.
It's a confined and well defined case that doesn't need any of that
Kok, Auke wrote:
I disagree, we should not break the current e1000 driver in the kernel
while there is a new driver coming up that introduces ich9 support
without breaking (the old e1000) support for all other devices. This is
why we want to drop a new version of the e1000 driver upstream inste
Jason Lunz wrote:
What's the prognosis for the 7.5.5-series e1000 reorg going into
netdev-2.6?
As I have posted previously, I am not keen on merging basically an e1000
rewrite. That basically throws away all Internet-wide testing so far.
The rewrite was not done according to Linux kernel st
Arjan van de Ven wrote:
+ pci_write_config_byte(tp->pci_dev, PCI_LATENCY_TIMER, 0x40);
can you create a pci_set_latency_timer() for this please?
+
+ if (tp->mac_version <= RTL_GIGA_MAC_VER_06)
+ pci_write_config_byte(tp->pci_dev, PCI_CACHE_LINE_SIZE, 0x08);
and som
Francois Romieu wrote:
Please pull from branch 'r8169-for-jeff-20070629' in repository
git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git
r8169-for-jeff-20070629
to get the changes below.
Following mails on netdev describe each patch.
Distance from 'netd
> + pci_write_config_byte(tp->pci_dev, PCI_LATENCY_TIMER, 0x40);
can you create a pci_set_latency_timer() for this please?
> +
> + if (tp->mac_version <= RTL_GIGA_MAC_VER_06)
> + pci_write_config_byte(tp->pci_dev, PCI_CACHE_LINE_SIZE, 0x08);
and something for this as well?
-
It does not really make sense to update the RX config register
before the mac filtering registers.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/r
It does not cost much and it will ease the identification of (so far)
unknown devices.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/r8169.c b/
Merged from Realtek's r8169-6.001 driver.
I have added some locking to protect against the arp monitoring
timer in the bonding driver. Accessing the configuration registers
is otherwise performed under RTNL locking.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECT
No functionnal change:
- trim the old history log
- whitespace/indent/case police
- unsigned int where signedness does not matter
- removal of obsolete assert
- needless cast from void * (dev_instance)
- remove dead code once related to power management
- use netdev_alloc_skb.
Signed-off-by: Franc
...still a bit yucky though.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 56b9040..eb793fa
Align the IP header when the chipset can DMA at any location (plain 0x8169).
Otherwise (0x8136/0x8168) obey the constraint imposed by the hardware.
This patch complements the previous alignment rework done for copybreak.
Original idea from Philip Craig <[EMAIL PROTECTED]>
Signed-off-by: Francois
Same thing as the previous change for rtl_hw_start_8168.
The 8101 related code in rtl_hw_start_8169 (see RTL_GIGA_MAC_VER_13)
goes away.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c | 47 ++
This one includes:
- more tweaks to rtl_hw_start_8168
- a work around for a Rx FiFO overflow issue on the 8168Bb
- rtl8169_{intr_mask/napi_event} are replaced with per-device fields,
namely tp->{intr/napi}_event
- rtl_cfg_info is converted to C99 for readability but the values are
not
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 5d9e754..d8862cd 100644
--- a/drivers/net/r8169.c
+++ b/drive
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 1942bf
It has been documented as deprecated:
- in MODULE_PARM_DESC since may 2005 ;
- at the top of the source file and in printk since june 2004.
Good bye.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c | 72 +++--
The rx copybreak part is straightforward.
The align field in struct rtl_cfg_info is related to the alignment
requirements of the DMA operation. Its value is set at 2 to limit the
scale of possible regression but my old v1.21 8169 datasheet claims a
8 bytes requirements (which never appeared in the
Extracted from version 1.001.00 of Realtek's r8101.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index a6fea19..49
- new identifier for the 8110SCe
- the PCI latency timer is set unconditionally. This part is identical
in Realtek's r8168 (8.001.00) and r8101 (1.001.00)
- initialization of the cache line size register is for the 8169s only
- more magic in rtl_hw_start_8169
- it is not possible to factor ou
Rationale: rtl8169_hw_start will not help maintaining an unified
driver for different chipsets but people at Realtek are probably
too polite to say it distinctly.
Let's add the hook and keep hw_start handler unchanged.
As can be seen from the content of rtl8169_pci_tbl, the RTL_CFG_1
entry in rtl
They aim to limit the amount of moved code when the hw_start
handler gets more specialized.
No functional change.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c | 53 +-
1 files chang
rtl_hw_start_8168 inherits the content of rtl_hw_start_8169 minus
the code which depends on RTL_GIGA_MAC_VER_XY (XY != {11/12}).
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c | 34 +++---
1 files changed
On Fri, Jun 29, 2007 at 12:51:02PM -0700, Kok, Auke wrote:
> For distro's not following kernel.org releases we have the perfect
> solution: A fully tested 7.5.5 driver on sourceforge that was extensively
> tested against RHEL5 for instance, but also a lot of other older kernels.
I'm sure you and
It hasn't "summed" anything in over 7 years, and it's
just a straight mempcy ala skb_copy_to_linear_data()
so just get rid of it.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c |2
The former style suggests a modulo arithmetic misuse but
the expression should never be < 0. Even if it does, the
driver will simply loop longer than expected (not that
the remaining parts of the system will necessarily
appreciate it...).
Let's warn the user when something goes wrong and try
to go
- pci_dma_sync_single_for_cpu is not needed for a single large packet
- remove the function pointer to help gcc optimizing the inline
pci_dma functions.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
Use netdev_alloc_skb and remove the useless sk_buff * argument of
rtl8169_alloc_rx_skb.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c | 27 ++-
1 files ch
Please pull from branch 'r8169-for-jeff-20070629' in repository
git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git
r8169-for-jeff-20070629
to get the changes below.
Following mails on netdev describe each patch.
Distance from 'netd
Jason Lunz wrote:
On Fri, Jun 29, 2007 at 06:29:18PM +0100, Mark McLoughlin wrote:
I understand there is some delay in getting e1000-7.5.5 into the
upstream kernel given the major re-working of the chipset specific
parts.
I wonder would it be feasible in the meantime to backport
> That works ok for some things, like new global counters, but some
> items really fit best in existing files and the concern there is about
> other uses of them beyond the standard tools.
> Examples:
> -addition of route age in /proc/net/route and /proc/net/ipv6_route
Routing information
Jens Stroebel <[EMAIL PROTECTED]> :
[...]
> It seems like the patch is able to change things in a way which makes
> the machine lock up hard. Pity that, looked so promising at first...
As a 8168 user, you should really apply the serie I sent yesterday before
anything else. Then you can try again t
This patch makes the PHY optional for ucc_geth.c ethernet driver.
This is useful to support a direct mii to mii connection to, for example,
a onboard swicth.
Signed-off-by: Joakim Tjernlund <[EMAIL PROTECTED]>
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 32bb748..8630294
[EMAIL PROTECTED] wrote on 06/29/2007 10:30:23 AM:
> David Stevens <[EMAIL PROTECTED]> writes:
>
> > I think there's a more general problem that's a huge hassle. There are
> > lots of
> > new SNMP MIB's, but no conventions (that I'm aware of, at least) to
allow
> > for
> > changes to the /pro
On Fri, Jun 29, 2007 at 06:29:18PM +0100, Mark McLoughlin wrote:
> I understand there is some delay in getting e1000-7.5.5 into the
> upstream kernel given the major re-working of the chipset specific
> parts.
>
> I wonder would it be feasible in the meantime to backport the ich9
> sup
Hi Auke,
I understand there is some delay in getting e1000-7.5.5 into the
upstream kernel given the major re-working of the chipset specific
parts.
I wonder would it be feasible in the meantime to backport the ich9
support and push it upstream?
A first-cut at the backport
David Stevens <[EMAIL PROTECTED]> writes:
> I think there's a more general problem that's a huge hassle. There are
> lots of
> new SNMP MIB's, but no conventions (that I'm aware of, at least) to allow
> for
> changes to the /proc entries that get them to applications.
Actually /proc/net/snmp a
Patrick McHardy wrote:
Ben Greear wrote:
Could someone give a quick example of when I am wrong and promisc mode
would allow
a NIC to receive a significant number of packets not really destined for
it?
In a switched environment it won't have a big effect, I agree.
It might help avoid r
Ben Greear wrote:
> Patrick McHardy wrote:
>
>> Right, but the current bridging code always uses promiscous mode
>> and its nice to avoid that if possible. Looking at the code, it
>> should be easy to avoid though by disabling learning (and thus
>> promisous mode) and adding unicast filters for al
Jens Stroebel wrote:
> Francois Romieu wrote:
>> [...]
>> It may help and/or accelerate things if you can narrow the fix(es) in
>> the current r8169 serie.
> Instead, I built 2.6.21.5+[a patch I snatched from a mail communication
> you had on 2007-06-20
> (Msg-ID: <[EMAIL PROTECTED]> )].
> I will
Patrick McHardy wrote:
Right, but the current bridging code always uses promiscous mode
and its nice to avoid that if possible. Looking at the code, it
should be easy to avoid though by disabling learning (and thus
promisous mode) and adding unicast filters for all static fdb entries.
I am cur
On Fri, Jun 29, 2007 at 10:50:20AM +0200, Jean-Baptiste Vignaud wrote:
> Update...
> I did 2 tests :
>
> 1) booted with option acpi=off
> It booted correctly, i managed to get some load on one of the card
> and after a while (10 minutes i guess) the Timeout occurs. Side effect,
> at the same mome
On Fri, 2007-06-29 at 16:19 +0200, Johannes Berg wrote:
> Uh huh, this reallocation is buggy. Fixed version below.
More breakage, sorry about the patch-spam.
Btw, I notice that the bug we talked about isn't present in practice
since we have no multicast users except for the always-present
contro
Sivakumar Subramani wrote:
Hi Jeff,
Any update on these patch submission? Is it in queue?
it's in my mbox queue, to be reviewed.
-
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/m
On Fri, 2007-06-29 at 16:05 +0200, Johannes Berg wrote:
> + mc_groups =
> + kzalloc(mc_groups_bits/BITS_PER_LONG + 1,
> + GFP_KERNEL);
> + if (!mc_groups)
> + return
On Fri, 29 Jun 2007 11:48:37 +0200 (CEST)
Pierre Capillon <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I'm a french IT engineering student and as part of my
> internship, I'm writing a congestion avoidance module
> based on research by my tutor. It aims at better
> efficiency and throughput on mobile
On Fri, 2007-06-29 at 15:53 +0200, Patrick McHardy wrote:
> If you're worried about patch size, you could sell that part as a
> bugfix :)
Heh. Actually, right now I'm more worried about how much work I have to
do short-term.
This patch keeps the bitmap but does dynamic group allocation. Just to
Johannes Berg wrote:
> On Fri, 2007-06-29 at 15:44 +0200, Patrick McHardy wrote:
>
>
>>>How about for now I only allow dynamic registration (no unregistration)
>>>and just send out when new groups are registered, and also give
>>>userspace a list of registered mc groups when they ask for a family
On Fri, 2007-06-29 at 15:44 +0200, Patrick McHardy wrote:
> > How about for now I only allow dynamic registration (no unregistration)
> > and just send out when new groups are registered, and also give
> > userspace a list of registered mc groups when they ask for a family
> > description? That sh
Johannes Berg wrote:
> On Fri, 2007-06-29 at 15:23 +0200, Patrick McHardy wrote:
>
>>If you do want the dynamic unregistation *and* the non-root mc
>>listening then I guess you don't have a choice but to unbind
>>sockets at unregistration. That shouln't be a real problem,
>>without having though m
On Fri, 2007-06-29 at 15:23 +0200, Patrick McHardy wrote:
> I'm not sure that "the only sensible thing to do" is right, we
> do allow dynamic registration of netlink families and do the
> module reference thing anyway (admittedly, I never liked that
> and the autoloading part very much). I guess i
jamal wrote:
> On Fri, 2007-29-06 at 15:12 +0200, Patrick McHardy wrote:
>
>>jamal wrote:
>>
>>>On Fri, 2007-29-06 at 14:48 +0200, Patrick McHardy wrote:
>
>
>>>Our philosophy in genetlink is to have dynamic resources allocated and
>>>released - remember the real reason we even have this is beca
On Fri, 2007-29-06 at 15:12 +0200, Patrick McHardy wrote:
> jamal wrote:
> > On Fri, 2007-29-06 at 14:48 +0200, Patrick McHardy wrote:
> > Our philosophy in genetlink is to have dynamic resources allocated and
> > released - remember the real reason we even have this is because we were
> > running
On Fri, 2007-29-06 at 15:15 +0200, Johannes Berg wrote:
> (1) register group X with non-root
> (2) non-root app A binds group X
> (3) kernel unregisters group X
Kernel sends event (controller) "Group X is gone" or "family Y which
used to own group X is gone"
> (4) something else in kernel rer
Johannes Berg wrote:
> On Fri, 2007-06-29 at 15:11 +0200, Patrick McHardy wrote:
>
>
>>>Hm. I'm starting to dislike the dynamic registration the more I think
>>>about it. Now when a group is unregistered I'd have to unbind everybody
>>>who's currently using it... At least when I want to enforce
>
On Fri, 2007-29-06 at 15:08 +0200, Patrick McHardy wrote:
> jamal wrote:
> > On Fri, 2007-29-06 at 13:59 +0200, Patrick McHardy wrote:
> Right, but the current bridging code always uses promiscous mode
> and its nice to avoid that if possible.
> Looking at the code, it
> should be easy to avoid t
On Fri, 2007-06-29 at 15:11 +0200, Patrick McHardy wrote:
> > Hm. I'm starting to dislike the dynamic registration the more I think
> > about it. Now when a group is unregistered I'd have to unbind everybody
> > who's currently using it... At least when I want to enforce
> > root/non-root binds wh
On Fri, 2007-06-29 at 09:02 -0400, jamal wrote:
> Maybe a mix (of a few static and mostly dynamic) as Patrick says - but
> that would mean more coding for you ;-> Actually i like the idea of at
> least your ID being your static mcast group and the rest are in the
> dynamic pool (Hey, thanks Patric
jamal wrote:
> On Fri, 2007-29-06 at 14:48 +0200, Patrick McHardy wrote:
>
>>Johannes Berg wrote:
>
>
>>>Hmm, another thought: since we have 32 bits for group numbers and 16
>>>bits for families we could just reserve 16 bits for groups within each
>>>family. Or do we get trouble with that becaus
On Fri, 2007-29-06 at 14:57 +0200, Johannes Berg wrote:
> On Wed, 2007-06-27 at 19:24 -0400, jamal wrote:
> Hm. I'm starting to dislike the dynamic registration the more I think
> about it. Now when a group is unregistered I'd have to unbind everybody
> who's currently using it...
I understood y
Johannes Berg wrote:
> On Wed, 2007-06-27 at 19:24 -0400, jamal wrote:
>
>
>>a) i.e other than the reserved group for controller (which you seem to
>>be taking care of), every other genetlink user has to explicitly
>>register when they need a mcast group.
>
>
> Hm. I'm starting to dislike the
jamal wrote:
> On Fri, 2007-29-06 at 13:59 +0200, Patrick McHardy wrote:
>
>
>>The difference to a real bridge is that the
>>all addresses are completely known in advance, so it doesn't need
>>promiscous mode for learning.
>
>
> You mean the per-virtual MAC addresses are known in advance, right
On Fri, 2007-29-06 at 14:48 +0200, Patrick McHardy wrote:
> Johannes Berg wrote:
> > Hmm, another thought: since we have 32 bits for group numbers and 16
> > bits for families we could just reserve 16 bits for groups within each
> > family. Or do we get trouble with that because in some place ther
On Wed, 2007-06-27 at 19:24 -0400, jamal wrote:
> a) i.e other than the reserved group for controller (which you seem to
> be taking care of), every other genetlink user has to explicitly
> register when they need a mcast group.
Hm. I'm starting to dislike the dynamic registration the more I thi
On Fri, 2007-29-06 at 13:59 +0200, Patrick McHardy wrote:
> I'm guessing that that wouldn't allow to do unicast filtering for
> the guests on the real device without hacking the bridge code for
> this special case.
For ingress (i guess you could say for egress as well): we can do it as
well toda
On Fri, 2007-06-29 at 14:48 +0200, Patrick McHardy wrote:
> > Hmm, another thought: since we have 32 bits for group numbers and 16
> > bits for families we could just reserve 16 bits for groups within each
> > family. Or do we get trouble with that because in some place there's a
> > group bitmap
Johannes Berg wrote:
> On Fri, 2007-06-29 at 13:51 +0200, Patrick McHardy wrote:
>
>
>>Do multicast groups have to have a seperate name? Or would it suffice
>>to have them associated with the genl family and be able to find out
>>the starting group number? In that case something like
>>
>>struct
On Fri, 2007-06-29 at 13:51 +0200, Patrick McHardy wrote:
> Do multicast groups have to have a seperate name? Or would it suffice
> to have them associated with the genl family and be able to find out
> the starting group number? In that case something like
>
> struct genl_mc_groups {
> str
I'm getting this on current -git after adding an obexfs mount
to my fstab:
=
[ INFO: possible recursive locking detected ]
2.6.22-rc6 #2
-
obexfs/3786 is trying to acquire lock:
(sk_lock-AF_BLUETOOTH){--..}, a
Francois Romieu wrote:
> Jens Stroebel <[EMAIL PROTECTED]> :
> [...]
>> Would it
>> be possible to apply the single patch to 2.6.21.5 and get a working
>> driver?
> Mantra: mainline first, stable later.
hm .. OK.
> In the next future, most of this patchset will hopefully go into
> 2.6.23-rc1. So
jamal wrote:
> On Fri, 2007-29-06 at 13:51 +0200, Patrick McHardy wrote:
>
>
>>Do multicast groups have to have a seperate name?
>
>
> As i see it: the name would be unique per family
> Its like DNS IP to name mapping essentially (in the simple case of IP
> being globaly reachable). You do a d
Johannes Berg wrote:
> On Fri, 2007-06-29 at 13:51 +0200, Patrick McHardy wrote:
>
>
>>Do multicast groups have to have a seperate name? Or would it suffice
>>to have them associated with the genl family and be able to find out
>>the starting group number? In that case something like
>>
>>struct
On Fri, 2007-29-06 at 13:51 +0200, Patrick McHardy wrote:
> Do multicast groups have to have a seperate name?
As i see it: the name would be unique per family
Its like DNS IP to name mapping essentially (in the simple case of IP
being globaly reachable). You do a discovery of the ID by knowing t
On Fri, 2007-06-29 at 13:51 +0200, Patrick McHardy wrote:
> Do multicast groups have to have a seperate name? Or would it suffice
> to have them associated with the genl family and be able to find out
> the starting group number? In that case something like
>
> struct genl_mc_groups {
> str
jamal wrote:
> On Thu, 2007-28-06 at 21:20 -0700, David Miller wrote:
>
>>Each guest gets a unique MAC address. There is a queue per-port
>>that can fill up.
>>
>>What all the drivers like this do right now is stop the queue if
>>any of the per-port queues fill up, and that's why my sunvnet
>>dri
On Fri, 2007-06-29 at 07:48 -0400, jamal wrote:
> sure - if you rush you can make it into Daves 2.6.23; then both can
> conform at the same time.
Yeah, I'll have to see whether I can make that. If not, no big deal
either.
> > Ok :) Though I'm not sure I understood the suggestion of sending just
Johannes Berg wrote:
> On Wed, 2007-06-27 at 19:24 -0400, jamal wrote:
>
>>c) Use a global hash table to store all the genl_multicast_groups;
>>I think this (handwaving) should be searchable by i) name ii)ID and iii)
>>family.
>
>
> Yeah, makes sense, I never liked the bitmap stuff I did there.
On Fri, 2007-29-06 at 13:28 +0200, Johannes Berg wrote:
> On Fri, 2007-06-29 at 07:17 -0400, jamal wrote:
>
> Because of this I'd really prefer if we could hold off on adding groups,
> but I can handle both cases fine by just reserving a family and group ID
> for the current users.
>
sure - if
Ive changed the topic for you friend - otherwise most people wont follow
(as youve said a few times yourself ;->).
On Thu, 2007-28-06 at 21:20 -0700, David Miller wrote:
> Now I get to pose a problem for everyone, prove to me how useful
> this new code is by showing me how it can be used to solv
On Fri, 2007-06-29 at 07:17 -0400, jamal wrote:
> > No, the controller is the only other generic netlink multicast user
> > according to what I've found. :)
>
> Scanning the code - true ;-> Iam a little suprised that the task
> accounting folks didnt use it to periodically dump stats.
:)
Becaus
On Thu, 2007-28-06 at 11:45 +0200, Johannes Berg wrote:
> No, the controller is the only other generic netlink multicast user
> according to what I've found. :)
Scanning the code - true ;-> Iam a little suprised that the task
accounting folks didnt use it to periodically dump stats.
> actually
Kumar Gala wrote:
Please pull from 'for_linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for_linus
to receive the following updates:
drivers/net/gianfar.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Kumar Gala (1):
gianfar: Fix typo bu
1 - 100 of 105 matches
Mail list logo
