* Re: [RFC] ip / ifconfig redesign
From: Jesper Juhl @ 2005-12-02 22:49 UTC (permalink / raw)
To: linux-os (Dick Johnson); +Cc: Al Boldi, netdev, linux-net, Linux kernel
In-Reply-To: <Pine.LNX.4.61.0512021527090.11277@chaos.analogic.com>
On 12/2/05, linux-os (Dick Johnson) <linux-os@analogic.com> wrote:
>
> On Fri, 2 Dec 2005, Al Boldi wrote:
>
> > The current ip / ifconfig configuration is arcane and inflexible. The reason
> > being, that they are based on design principles inherited from the last
> > century.
> >
> > In a GNU/OpenSource environment, OpenMinds should not inhibit themselves
> > achieving new design-goals to enable a flexible non-redundant configuration.
> >
> > Specifically, '#> ip addr ' exhibits this issue clearly, by requiring to
> > associate the address to a link instead of the other way around.
> >
> > Consider this new approach for better address management:
> > 1. Allow the definition of an address pool
> > 2. Relate links to addresses
> > 3. Implement to make things backward-compatible.
> >
> > The obvious benefit here, would be the transparent ability for apps to bind
> > to addresses, regardless of the link existence.
> >
>
> A link needs to exist for it to have an address.
>
I'm only guessing since I'm not entirely sure what Mr. Boldi means,
but my guess is that he's proposing that an app can bind to an IP
address without that address being assigned to any currently available
interface and then later if that IP does get assigned to an interface
the app will start recieving traffic then. Also possibly allowing the
address to be removed from one interface and then later assigned to
another one without apps noticing.
I don't know /if/ that is what was meant, but that's how I read it.
> > Another benefit includes the ability to scale the link level transparently,
> > regardless of the application bind state.
> >
>
> That doesn't make any sense. Multiple applications can bind to the
> same address. Then can't bind to the same port because they won't
> get all their data.
>
> > And there may be many other benefits... (i.e. 100% OSI compliance)
> >
> What does Open Source Initiative have to do with this at all???
> You are just spewing stuff out.
>
I'm believe Mr. Boldi is refering to OSI as in Open Systems
Interconnection (http://en.wikipedia.org/wiki/OSI_model), not as in
Open Source Initiative.
> > --
> > Al
>
> Also, how does this involve the kernel? The interface to the kernel
> for hardware configuration is via ioctl(). For logic, sockets.
>
> If the user-level tools suck, then they should be fixed. It
> really doesn't have anything to do with the kernel.
>
> Cheers,
> Dick Johnson
>
[snip]
>
> Thank you.
>
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: Jeff V. Merkey @ 2005-12-02 22:40 UTC (permalink / raw)
To: Al Boldi; +Cc: netdev, linux-net, linux-kernel
In-Reply-To: <200512022253.19029.a1426z@gawab.com>
Al Boldi wrote:
>The current ip / ifconfig configuration is arcane and inflexible. The reason
>being, that they are based on design principles inherited from the last
>century.
>
>In a GNU/OpenSource environment, OpenMinds should not inhibit themselves
>achieving new design-goals to enable a flexible non-redundant configuration.
>
>Specifically, '#> ip addr ' exhibits this issue clearly, by requiring to
>associate the address to a link instead of the other way around.
>
>Consider this new approach for better address management:
>1. Allow the definition of an address pool
>2. Relate links to addresses
>3. Implement to make things backward-compatible.
>
>The obvious benefit here, would be the transparent ability for apps to bind
>to addresses, regardless of the link existence.
>
>Another benefit includes the ability to scale the link level transparently,
>regardless of the application bind state.
>
>And there may be many other benefits... (i.e. 100% OSI compliance)
>
>--
>Al
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
Just what we need, another broken utility without backward
compatibility. Make certain you preserve the existing commands so the whole
planet isn't broken as a result.
Jeff
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: linux-os (Dick Johnson) @ 2005-12-02 20:38 UTC (permalink / raw)
To: Al Boldi; +Cc: netdev, linux-net, Linux kernel
In-Reply-To: <200512022253.19029.a1426z@gawab.com>
On Fri, 2 Dec 2005, Al Boldi wrote:
> The current ip / ifconfig configuration is arcane and inflexible. The reason
> being, that they are based on design principles inherited from the last
> century.
>
> In a GNU/OpenSource environment, OpenMinds should not inhibit themselves
> achieving new design-goals to enable a flexible non-redundant configuration.
>
> Specifically, '#> ip addr ' exhibits this issue clearly, by requiring to
> associate the address to a link instead of the other way around.
>
> Consider this new approach for better address management:
> 1. Allow the definition of an address pool
> 2. Relate links to addresses
> 3. Implement to make things backward-compatible.
>
> The obvious benefit here, would be the transparent ability for apps to bind
> to addresses, regardless of the link existence.
>
A link needs to exist for it to have an address.
> Another benefit includes the ability to scale the link level transparently,
> regardless of the application bind state.
>
That doesn't make any sense. Multiple applications can bind to the
same address. Then can't bind to the same port because they won't
get all their data.
> And there may be many other benefits... (i.e. 100% OSI compliance)
>
What does Open Source Initiative have to do with this at all???
You are just spewing stuff out.
> --
> Al
Also, how does this involve the kernel? The interface to the kernel
for hardware configuration is via ioctl(). For logic, sockets.
If the user-level tools suck, then they should be fixed. It
really doesn't have anything to do with the kernel.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.44 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: Ben Greear @ 2005-12-02 20:08 UTC (permalink / raw)
To: Al Boldi; +Cc: netdev, linux-net, linux-kernel
In-Reply-To: <200512022253.19029.a1426z@gawab.com>
Al Boldi wrote:
> The current ip / ifconfig configuration is arcane and inflexible. The reason
> being, that they are based on design principles inherited from the last
> century.
>
> In a GNU/OpenSource environment, OpenMinds should not inhibit themselves
> achieving new design-goals to enable a flexible non-redundant configuration.
>
> Specifically, '#> ip addr ' exhibits this issue clearly, by requiring to
> associate the address to a link instead of the other way around.
>
> Consider this new approach for better address management:
> 1. Allow the definition of an address pool
> 2. Relate links to addresses
> 3. Implement to make things backward-compatible.
>
> The obvious benefit here, would be the transparent ability for apps to bind
> to addresses, regardless of the link existence.
>
> Another benefit includes the ability to scale the link level transparently,
> regardless of the application bind state.
Can you do this with the current code by using scripts/whatever to move
virtual IPs around the interfaces?
I guess I don't really understand what you are proposing...
Ben
>
> And there may be many other benefits... (i.e. 100% OSI compliance)
>
> --
> Al
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: Pekka Savola @ 2005-12-02 19:59 UTC (permalink / raw)
To: Al Boldi; +Cc: netdev, linux-net, linux-kernel
In-Reply-To: <200512022253.19029.a1426z@gawab.com>
On Fri, 2 Dec 2005, Al Boldi wrote:
> Consider this new approach for better address management:
> 1. Allow the definition of an address pool
> 2. Relate links to addresses
> 3. Implement to make things backward-compatible.
>
> The obvious benefit here, would be the transparent ability for apps to bind
> to addresses, regardless of the link existence.
That's called 'the loopback address', right? :)
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
^ permalink raw reply
* [RFC] ip / ifconfig redesign
From: Al Boldi @ 2005-12-02 19:53 UTC (permalink / raw)
To: netdev; +Cc: linux-net, linux-kernel
The current ip / ifconfig configuration is arcane and inflexible. The reason
being, that they are based on design principles inherited from the last
century.
In a GNU/OpenSource environment, OpenMinds should not inhibit themselves
achieving new design-goals to enable a flexible non-redundant configuration.
Specifically, '#> ip addr ' exhibits this issue clearly, by requiring to
associate the address to a link instead of the other way around.
Consider this new approach for better address management:
1. Allow the definition of an address pool
2. Relate links to addresses
3. Implement to make things backward-compatible.
The obvious benefit here, would be the transparent ability for apps to bind
to addresses, regardless of the link existence.
Another benefit includes the ability to scale the link level transparently,
regardless of the application bind state.
And there may be many other benefits... (i.e. 100% OSI compliance)
--
Al
^ permalink raw reply
* Re: [RFC] [PATCH 0/3] ioat: DMA engine support
From: Jon Mason @ 2005-12-02 17:06 UTC (permalink / raw)
To: Jeff Garzik
Cc: Andrew Grover, netdev, linux-kernel, john.ronciak,
christopher.leech
In-Reply-To: <4384F110.4060908@pobox.com>
On Wed, Nov 23, 2005 at 05:45:36PM -0500, Jeff Garzik wrote:
> Andrew Grover wrote:
> >As presented in our talk at this year's OLS, the Bensley platform, which
> >will be out in early 2006, will have an asyncronous DMA engine. It can be
> >used to offload copies from the CPU, such as the kernel copies of received
> >packets into the user buffer.
>
> More than a one-paragraph description would be nice... URLs to OLS and
> IDF presentations, other info?
>
> Jeff
>
FYI,
OLS paper can be found at
http://www.linuxsymposium.org/2005/linuxsymposium_procv1.pdf
Starting at page 281.
Other info can be found at
http://www.intel.com/technology/ioacceleration/index.htm
^ permalink raw reply
* Re: Data corruption when using TCP sockets
From: Benjamin LaHaise @ 2005-12-02 15:07 UTC (permalink / raw)
To: madanagopal; +Cc: linux-net, netdev
In-Reply-To: <Pine.LNX.4.58.0512022028230.9779@fileserver.nmsworks.co.in>
On Fri, Dec 02, 2005 at 08:31:01PM +0530, madanagopal wrote:
> hai,
> Sorry to ask again. Was this exact problem noticed and fixed in some
> kernel version? If so which version is it? If it is not possible to get
> that info, which version should we use and are we guaranteed that this
> problem will not be present in it?
It certainly isn't a known problem with any recent 2.4 or 2.6 kernels.
-ben
^ permalink raw reply
* Re: Data corruption when using TCP sockets
From: madanagopal @ 2005-12-02 15:01 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: linux-net, netdev
In-Reply-To: <20051202142625.GA12152@kvack.org>
hai,
Sorry to ask again. Was this exact problem noticed and fixed in some
kernel version? If so which version is it? If it is not possible to get
that info, which version should we use and are we guaranteed that this
problem will not be present in it?
> That kernel is beyond ancient -- a 2.4.9 errata kernel was released on
> the day that Red Hat 7.2 shipped. It is known buggy and superceeded by
> many kernels with substantial bugfixes.
>
> -ben
>
> On Fri, Dec 02, 2005 at 05:05:28PM +0530, madanagopal wrote:
> > hai,
> > We have a socket application in C which connects to a Java application
> > through TCP sockets. We use read() system call to read from the socket.
> > The Java application sends more than 20000 bytes of data sometimes. In the
> > C program, we read those bytes as Type,Length,Value fields where a
> > separate read() call is used for each field. This sometimes creates a data
> > corruption while it works other times.
> > We observe that the first 16384 bytes get read properly. Extra byte or
> > bytes get added in the 16385 th location and this shifts the bytes from
> > 16385 onwards. Because of this our C program gets confused and we are
> > forced to reopen the socket. This is not predictable. Suddenly this
> > problem occurs. Is this an already known issue and if so what
> > is it? How to solve it?
> > We are running both the applications in the same machine which runs
> > Red Hat Linux release 7.2 and its kernel version is 2.4.7-10
> > -
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* Re: Data corruption when using TCP sockets
From: Benjamin LaHaise @ 2005-12-02 14:26 UTC (permalink / raw)
To: madanagopal; +Cc: linux-net, netdev
In-Reply-To: <Pine.LNX.4.58.0512021638130.3304@fileserver.nmsworks.co.in>
That kernel is beyond ancient -- a 2.4.9 errata kernel was released on
the day that Red Hat 7.2 shipped. It is known buggy and superceeded by
many kernels with substantial bugfixes.
-ben
On Fri, Dec 02, 2005 at 05:05:28PM +0530, madanagopal wrote:
> hai,
> We have a socket application in C which connects to a Java application
> through TCP sockets. We use read() system call to read from the socket.
> The Java application sends more than 20000 bytes of data sometimes. In the
> C program, we read those bytes as Type,Length,Value fields where a
> separate read() call is used for each field. This sometimes creates a data
> corruption while it works other times.
> We observe that the first 16384 bytes get read properly. Extra byte or
> bytes get added in the 16385 th location and this shifts the bytes from
> 16385 onwards. Because of this our C program gets confused and we are
> forced to reopen the socket. This is not predictable. Suddenly this
> problem occurs. Is this an already known issue and if so what
> is it? How to solve it?
> We are running both the applications in the same machine which runs
> Red Hat Linux release 7.2 and its kernel version is 2.4.7-10
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
"You know, I've seen some crystals do some pretty trippy shit, man."
Don't Email: <dont@kvack.org>.
^ permalink raw reply
* Data corruption when using TCP sockets
From: madanagopal @ 2005-12-02 11:35 UTC (permalink / raw)
To: linux-net; +Cc: netdev
hai,
We have a socket application in C which connects to a Java application
through TCP sockets. We use read() system call to read from the socket.
The Java application sends more than 20000 bytes of data sometimes. In the
C program, we read those bytes as Type,Length,Value fields where a
separate read() call is used for each field. This sometimes creates a data
corruption while it works other times.
We observe that the first 16384 bytes get read properly. Extra byte or
bytes get added in the 16385 th location and this shifts the bytes from
16385 onwards. Because of this our C program gets confused and we are
forced to reopen the socket. This is not predictable. Suddenly this
problem occurs. Is this an already known issue and if so what
is it? How to solve it?
We are running both the applications in the same machine which runs
Red Hat Linux release 7.2 and its kernel version is 2.4.7-10
^ permalink raw reply
* Re: 2.6.15-rc3: adduser: unable to lock password file
From: JaniD++ @ 2005-12-02 11:26 UTC (permalink / raw)
To: Marc Koschewski; +Cc: linux-kernel, netdev
In-Reply-To: <20051202110805.GA7224@stiffy.osknowledge.org>
Hi,
> > OK, i will try it, if i can.... (this is a productive online system,
maybe
> > next reboot)
>
> I'd rather suggest to _not_ run -rc kernels on productive systems. :)
Thanks for the warning! :-)
I know it, already.
But have no choice. :(
The older kernels didnt know what i have needed! :-/
eg: i try the 2.6.15-rc3 because 2.6.14.2 gives me this messages:
KERNEL: assertion (!sk->sk_forward_alloc) failed at net/core/stream.c (279)
KERNEL: assertion (!sk->sk_forward_alloc) failed at net/ipv4/af_inet.c (148)
nfs: server 192.168.2.100 not responding, still trying
nfs: server 192.168.2.100 not responding, still trying
nfs: server 192.168.2.100 not responding, still trying
nfs: server 192.168.2.100 not responding, still trying
nfs: server 192.168.2.100 not responding, still trying
NETDEV WATCHDOG: eth0: transmit timed out
e1000: eth0: e1000_watchdog_task: NIC Link is Up 1000 Mbps Full Duplex
nfs: server 192.168.2.100 OK
nfs: server 192.168.2.100 OK
nfs: server 192.168.2.100 OK
nfs: server 192.168.2.100 OK
nfs: server 192.168.2.100 OK
So, i really did not see different! :-D
Cheers,
Janos
>
> Marc
^ permalink raw reply
* netdev queue updated
From: Jeff Garzik @ 2005-12-01 10:05 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, akpm
Here is the current contents of netdev-2.6.git#ALL, which is
auto-propagated to Andrew Morton's -mm tree.
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.15-rc4-netdev1.patch.bz2
Adrian Bunk:
drivers/net/sk98lin/skge.c: make SkPciWriteCfgDWord() a static inline
hostap: rename hostap.c to hostap_main.c
Ananda Raju:
s2io: UFO support
Andrew Morton:
sky2 needs dma_mapping.h
Andy Fleming:
Gianfar update and sysfs support
Brice Goglin:
Duplicate IPW_DEBUG option for ipw2100 and 2200
Carlo Perassi:
atmel: CodingStyle cleanup
Christophe Lucas:
atmel: audit return code of create_proc_read_entry
Dan Streetman:
airo.c: add support for IW_ENCODE_TEMP (i.e. xsupplicant)
Daniele Venzano:
Add Wake on LAN support to sis900 (2)
Eugene Surovegin:
ibm_emac: fix graceful stop timeout handling
Francois Romieu:
b44: early return in dev->do_ioctl when the device is not up
b44: increase version number
Jeff Garzik:
[netdrvr 8139too] replace hand-crafted kernel thread with workqueue
[netdrvr 8139too] use cancel_rearming_delayed_work() to cancel thread
[netdrvr 8139too] use rtnl_shlock_nowait() rather than rtnl_lock_interruptible()
[netdrvr 8139too] fast poll for thread, if an unlikely race occurs
[bonding] Remove superfluous changelog.
[netdrvr skge] fix typo, fix build
Jesse Brandeburg:
e1000: fix for dhcp issue
John W. Linville:
skge: fix warning from inlining SkPciWriteCfgDWord()
e1000: avoid leak when e1000_setup_loopback_test fails
e1000: zero-out pointers in e1000_free_desc_rings
Komuro:
[netdrvr fmvj18x_cs] fix multicast bug
Lennert Buytenhek:
intel ixp2000 network driver
ixp2000: register netdevices last
pm3386: zero stats properly
pm3386: remove unnecessary udelays
caleb/pm3386: include proper header files
ixp2000: use netif_rx_schedule_test
enp2611: don't check netif_running() in link status timer
enp2611: use 'dev' in link status timer
enp2611: report link up/down events
ixp2000: report MAC addresses for each port on init
pm3386: add hook for setting MAC address
pm3386: add hook for setting carrier
pm3386: implement reset
enp2611: disable/enable SERDES carrier on interface down/up
ixp2000: add netpoll support
ixp2000: add driver version, bump version to 0.2
Mark Lord:
b44: missing netif_wake_queue() in b44_open()
Matthieu CASTET:
[wireless airo] reset card in init
Mitch Williams:
net: allow newline terminated IP addresses in in_aton
net: make dev_valid_name public
bonding: add bond name to all error messages
bonding: expand module param descriptions
bonding: Add transmit policy to /proc
bonding: get slave name from actual slave instead of param list
bonding: move kmalloc out of spinlock in ALB init
bonding: explicitly clear RLB flag during ALB init
bonding: expose some structs
bonding: make functions not static
bonding: move bond creation into separate function
bonding: make bond_init not __init
bonding: Allow ARP target table to have empty entries
bonding: add ARP entries to /proc
bonding: add sysfs functionality to bonding (large)
bonding: version update
bonding: spelling and whitespace corrections
bonding: comments and changelog
Pavel Roskin:
orinoco: fix setting power management parameters
Ralf Baechle:
mipsnet: Fix Copyright notice.
jazzsonic: Fix build error.
jazzsonic: Fix platform device code
Scott Feldman:
[netdrvr e100] experiment with doing RX in a similar manner to eepro100
shemminger@osdl.org:
sky2: changing mtu doesn't have to reset link
sky2: cleanup interrupt processing
sky2: add hardware VLAN acceleration support
sky2: explicit set power state
sky2: version 0.6
sky2: remove unused definitions
sky2: use kzalloc
sky2: spelling fixes
sky2: fix NAPI and receive handling
sky2: version 0.7
sky2: eliminate special case for EC-A1
sky2: add MII support
sky2: fix receive flush/pause issues
sky2: improve receive performance
sky2: add Yukon-EC ultra support
sky2: handle DMA boundary crossing
sky2: change netif_rx_schedule_test to __netif_schedule_prep
sky2: race with MTU change
sky2: dual port tx completion
sky2: byteorder annotation
sky2: remove pci-express hacks
sky2: use pci_register_driver
sky2: update version number
sk98lin: fix checksumming code
sk98lin: add permanent address support
sk98lin: avoid message confusion with skge
sk98lin: allow ethtool checksum on/off per port
sk98lin: remove redundant fields in device info
sk98lin: remove /proc interface
Stephen Hemminger:
sky2: new experimental Marvell Yukon2 driver
sky2: driver update.
sky2: fix FIFO DMA alignment problems
sky2: allow ethtool debug access to all of PCI space
sky2: version 0.5
sky2: nway reset (BONUS FEATURE)
sky2: add permanent address support.
skge: handle VLAN checksum correctly on yukon rev 0
Takis:
ipw2200: kzalloc conversion and Kconfig dependency fix
Tobias Klauser:
Remove drivers/net/wan/lmc/lmc_prot.h
drivers/net/sk98lin/skcsum.c | 871 --------
drivers/net/sk98lin/skproc.c | 265 --
drivers/net/wan/lmc/lmc_prot.h | 15
Documentation/networking/gianfar.txt | 72
drivers/net/8139too.c | 86
drivers/net/Kconfig | 15
drivers/net/Makefile | 7
drivers/net/b44.c | 13
drivers/net/bonding/Makefile | 2
drivers/net/bonding/bond_3ad.c | 106 -
drivers/net/bonding/bond_3ad.h | 13
drivers/net/bonding/bond_alb.c | 75
drivers/net/bonding/bond_alb.h | 9
drivers/net/bonding/bond_main.c | 781 +------
drivers/net/bonding/bond_sysfs.c | 1358 +++++++++++++
drivers/net/bonding/bonding.h | 52
drivers/net/e100.c | 72
drivers/net/e1000/e1000_ethtool.c | 16
drivers/net/e1000/e1000_main.c | 14
drivers/net/gianfar.c | 233 +-
drivers/net/gianfar.h | 69
drivers/net/gianfar_ethtool.c | 2
drivers/net/gianfar_mii.h | 1
drivers/net/gianfar_sysfs.c | 311 ++
drivers/net/ibm_emac/ibm_emac_core.c | 38
drivers/net/ibm_emac/ibm_emac_core.h | 2
drivers/net/ixp2000/Kconfig | 6
drivers/net/ixp2000/Makefile | 3
drivers/net/ixp2000/caleb.c | 137 +
drivers/net/ixp2000/caleb.h | 22
drivers/net/ixp2000/enp2611.c | 245 ++
drivers/net/ixp2000/ixp2400-msf.c | 213 ++
drivers/net/ixp2000/ixp2400-msf.h | 115 +
drivers/net/ixp2000/ixp2400_rx.uc | 408 +++
drivers/net/ixp2000/ixp2400_rx.ucode | 130 +
drivers/net/ixp2000/ixp2400_tx.uc | 272 ++
drivers/net/ixp2000/ixp2400_tx.ucode | 98
drivers/net/ixp2000/ixpdev.c | 421 ++++
drivers/net/ixp2000/ixpdev.h | 27
drivers/net/ixp2000/ixpdev_priv.h | 57
drivers/net/ixp2000/pm3386.c | 334 +++
drivers/net/ixp2000/pm3386.h | 28
drivers/net/jazzsonic.c | 4
drivers/net/mipsnet.h | 30
drivers/net/pcmcia/fmvj18x_cs.c | 32
drivers/net/s2io.c | 186 +
drivers/net/s2io.h | 3
drivers/net/sis900.c | 73
drivers/net/sis900.h | 45
drivers/net/sk98lin/Makefile | 6
drivers/net/sk98lin/h/skdrv2nd.h | 13
drivers/net/sk98lin/h/skvpd.h | 8
drivers/net/sk98lin/skethtool.c | 50
drivers/net/sk98lin/skge.c | 388 +--
drivers/net/skge.c | 4
drivers/net/sky2.c | 3123 ++++++++++++++++++++++++++++++
drivers/net/sky2.h | 1917 ++++++++++++++++++
drivers/net/wireless/Kconfig | 6
drivers/net/wireless/airo.c | 19
drivers/net/wireless/atmel.c | 1490 +++++++-------
drivers/net/wireless/hostap/Makefile | 1
drivers/net/wireless/hostap/hostap_main.c | 0
drivers/net/wireless/ipw2100.c | 40
drivers/net/wireless/ipw2100.h | 2
drivers/net/wireless/ipw2200.c | 21
drivers/net/wireless/ipw2200.h | 6
drivers/net/wireless/orinoco.c | 3
include/linux/netdevice.h | 11
net/core/dev.c | 3
net/core/utils.c | 2
70 files changed, 11156 insertions(+), 3344 deletions(-)
^ permalink raw reply
* Flyer Delivery Service in San Diego County
From: Mike @ 2005-12-01 8:31 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 125 bytes --]
We deliver flyers in San Diego County, please email back for addtional information or call 619-258-1297
Thanks
Mike
[-- Attachment #2: Type: text/html, Size: 460 bytes --]
^ permalink raw reply
* Re: [PATCH] Add MIPS dependency for dm9000 driver
From: Franck @ 2005-12-01 8:05 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, netdev
In-Reply-To: <20051130132757.36e1cca0.akpm@osdl.org>
Hi Andrew
2005/11/30, Andrew Morton <akpm@osdl.org>:
> Franck <vagabon.xyz@gmail.com> wrote:
> >
> > The attached patch adds MIPS dependency for dm9000 ethernet
> > controller. Indeed this controller is used by some embedded platforms
> > based on MIPS CPUs.
> >
>
> Is there any reason why we cannot enable this driver on all architectures?
>
> It's moderately important for quality and maintainability reasons that it
> be included in the x86 build, at least..
>
Actually there's a discussion about that. I previously sent a RFC
(subject is "[NET] Remove ARM dependency for dm9000 driver") for that.
Now some people are reacting so we should wait for the last words
before applying something.
thanks
--
Franck
^ permalink raw reply
* Re: [PATCH] orinoco: fix setting power management parameters
From: Jeff Garzik @ 2005-12-01 7:29 UTC (permalink / raw)
To: Pavel Roskin; +Cc: orinoco-devel, NetDev
In-Reply-To: <1133251167.27750.93.camel@dv>
applied
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply
* Re: [PATCH] ibm_emac: fix graceful stop timeout handling
From: Jeff Garzik @ 2005-12-01 7:23 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: netdev, linuxppc-embedded
In-Reply-To: <20051124224840.GB21929@gate.ebshome.net>
applied
^ permalink raw reply
* Registration Confirmation
From: info @ 2005-12-01 6:05 UTC (permalink / raw)
To: majordomo
[-- Attachment #1: Type: text/plain, Size: 123 bytes --]
Account and Password Information are attached!
***** Go to: http://www.comet.ucar.edu
***** Email: postman@comet.ucar.edu
[-- Attachment #2: reg_pass-data.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Re: [PATCH 06/13]: [IPV4/6]: Netfilter IPsec input hooks
From: Herbert Xu @ 2005-12-01 1:27 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, netfilter-devel, davem
In-Reply-To: <20051120163135.16666.76993.sendpatchset@localhost.localdomain>
On Sun, Nov 20, 2005 at 04:31:36PM +0000, Patrick McHardy wrote:
>
> @@ -145,7 +149,17 @@ int xfrm4_rcv_encap(struct sk_buff *skb,
> netif_rx(skb);
> return 0;
> } else {
> +#ifdef CONFIG_NETFILTER
> + __skb_push(skb, skb->data - skb->nh.raw);
> + skb->nh.iph->tot_len = htons(skb->len);
> + ip_send_check(skb->nh.iph);
> +
> + NF_HOOK(PF_INET, NF_IP_PRE_ROUTING, skb, skb->dev, NULL,
> + ip_xfrm_transport_hook);
> + return 0;
> +#else
> return -skb->nh.iph->protocol;
> +#endif
I'm worried about this bit. This looks like it'll go back to the top
of the IP stack with the existing call chain. So could grow as the
number of transforms increase.
Perhaps we need to play a dst_input/netif_rx trick here.
Actually, was there a problem with your original netif_rx approach
apart from the issue with double counting?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] Add MIPS dependency for dm9000 driver
From: Andrew Morton @ 2005-11-30 21:27 UTC (permalink / raw)
To: Franck; +Cc: linux-kernel, netdev
In-Reply-To: <cda58cb80511300918i7df1c60au@mail.gmail.com>
Franck <vagabon.xyz@gmail.com> wrote:
>
> The attached patch adds MIPS dependency for dm9000 ethernet
> controller. Indeed this controller is used by some embedded platforms
> based on MIPS CPUs.
>
> Signed-Off-By: Franck Bui-Huu <franck.bui@gmail.com>
> ---
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index f15f909..1b00169 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -856,7 +856,7 @@ config SMC9194
>
> config DM9000
> tristate "DM9000 support"
> - depends on ARM && NET_ETHERNET
> + depends on (ARM || MIPS) && NET_ETHERNET
> select CRC32
> select MII
Is there any reason why we cannot enable this driver on all architectures?
It's moderately important for quality and maintainability reasons that it
be included in the x86 build, at least..
^ permalink raw reply
* [PATCH] Add MIPS dependency for dm9000 driver
From: Franck @ 2005-11-30 17:18 UTC (permalink / raw)
To: lkml, netdev
The attached patch adds MIPS dependency for dm9000 ethernet
controller. Indeed this controller is used by some embedded platforms
based on MIPS CPUs.
Signed-Off-By: Franck Bui-Huu <franck.bui@gmail.com>
---
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index f15f909..1b00169 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -856,7 +856,7 @@ config SMC9194
config DM9000
tristate "DM9000 support"
- depends on ARM && NET_ETHERNET
+ depends on (ARM || MIPS) && NET_ETHERNET
select CRC32
select MII
---help---
^ permalink raw reply related
* Re: 3C905C-TX
From: Jesper Juhl @ 2005-11-30 14:02 UTC (permalink / raw)
To: linux-os (Dick Johnson); +Cc: Daniel Höhnle, Linux kernel, andrewm, netdev
In-Reply-To: <Pine.LNX.4.61.0511300813190.18193@chaos.analogic.com>
On 11/30/05, linux-os (Dick Johnson) <linux-os@analogic.com> wrote:
>
> On Wed, 30 Nov 2005, [iso-8859-1] Daniel Höhnle wrote:
>
> > Hello i have Suse Linux 9.3 and a 3Com 3C905C-TX Networkcard. But she
> > don't works. Where can I get a Driver??? Or give it a Dokumentation
> > how I can make the Driver??
> >
> > Thanks
> > Daniel Höhnle
>
> The 3c59x driver should work for this device. If it's real
> new, you may have to add its ID to the structure at line
> 3365 in 3x59x.c or contact the maintainer.
>
The 3c90x driver available from 3COM themselves is another alternative
: http://support.3com.com/infodeli/tools/nic/linuxdownload.htm
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply
* Re: 3C905C-TX
From: linux-os (Dick Johnson) @ 2005-11-30 13:18 UTC (permalink / raw)
To: Daniel Höhnle; +Cc: Linux kernel, andrewm, netdev
In-Reply-To: <eab8d9e30511300459j695ed942n@mail.gmail.com>
On Wed, 30 Nov 2005, [iso-8859-1] Daniel Höhnle wrote:
> Hello i have Suse Linux 9.3 and a 3Com 3C905C-TX Networkcard. But she
> don't works. Where can I get a Driver??? Or give it a Dokumentation
> how I can make the Driver??
>
> Thanks
> Daniel Höhnle
The 3c59x driver should work for this device. If it's real
new, you may have to add its ID to the structure at line
3365 in 3x59x.c or contact the maintainer.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
^ permalink raw reply
* Re: 3C905C-TX
From: Denis Vlasenko @ 2005-11-30 13:07 UTC (permalink / raw)
To: Daniel Höhnle; +Cc: andrewm, netdev
In-Reply-To: <eab8d9e30511300459j695ed942n@mail.gmail.com>
On Wednesday 30 November 2005 14:59, Daniel Höhnle wrote:
> Hello i have Suse Linux 9.3 and a 3Com 3C905C-TX Networkcard.
> But she don't works.
Please read http://www.catb.org/~esr/faqs/smart-questions.html
> Where can I get a Driver??? Or give it a Dokumentation
> how I can make the Driver??
--
vda
^ permalink raw reply
* 3C905C-TX
From: Daniel Höhnle @ 2005-11-30 12:59 UTC (permalink / raw)
To: linux-kernel, andrewm, netdev
Hello i have Suse Linux 9.3 and a 3Com 3C905C-TX Networkcard. But she
don't works. Where can I get a Driver??? Or give it a Dokumentation
how I can make the Driver??
Thanks
Daniel Höhnle
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox