* Re: [PATCH] X25: Add ITU-T facilite
From: Andrew Hendry @ 2005-12-07 3:23 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, eis, linux-x25, linux-kernel, netdev
Any update on the status of this patch?
Thanks,
Andrew.
On 10/24/05, Andrew Hendry <ahendry@tusc.com.au> wrote:
Structure alignment corrected.
Adds options for ITU DTE facilities to X.25, called address extension and calling address extension
Signed-off-by: Andrew Hendry <ahendry@tusc.com.au>
diff -uprN -X dontdiff linux-2.6.13.4-vanilla/include/linux/x25.h linux-2.6.13.4/include/linux/x25.h
--- linux-2.6.13.4-vanilla/include/linux/x25.h 2005-10-11 04:54:29.000000000 +1000
+++ linux-2.6.13.4 /include/linux/x25.h 2005-10-21 09:20:53.000000000 +1000
@@ -11,6 +11,8 @@
#ifndef X25_KERNEL_H
#define X25_KERNEL_H
+#include <linux/types.h>
+
#define SIOCX25GSUBSCRIP (SIOCPROTOPRIVATE + 0)
#define SIOCX25SSUBSCRIP (SIOCPROTOPRIVATE + 1)
#define SIOCX25GFACILITIES (SIOCPROTOPRIVATE + 2)
@@ -21,6 +23,8 @@
#define SIOCX25SCUDMATCHLEN (SIOCPROTOPRIVATE + 7)
#define SIOCX25CALLACCPTAPPRV (SIOCPROTOPRIVATE + 8)
#define SIOCX25SENDCALLACCPT (SIOCPROTOPRIVATE + 9)
+#define SIOCX25GDTEFACILITIES (SIOCPROTOPRIVATE + 10)
+#define SIOCX25SDTEFACILITIES (SIOCPROTOPRIVATE + 11)
/*
* Values for {get,set}sockopt.
@@ -77,6 +81,8 @@ struct x25_subscrip_struct {
#define X25_MASK_PACKET_SIZE 0x04
#define X25_MASK_WINDOW_SIZE 0x08
+#define X25_MASK_CALLING_AE 0x10
+#define X25_MASK_CALLED_AE 0x20
/*
@@ -98,6 +104,26 @@ struct x25_facilities {
unsigned int reverse;
};
+/*
+* ITU DTE facilities
+* Only the called and calling address
+* extension are currently implemented.
+* The rest are in place to avoid the struct
+* changing size if someone needs them later
+*/
+
+struct x25_dte_facilities {
+ __u16 delay_cumul;
+ __u16 delay_target;
+ __u16 delay_max;
+ __u8 min_throughput;
+ __u8 expedited;
+ __u8 calling_len;
+ __u8 called_len;
+ __u8 calling_ae[20];
+ __u8 called_ae[20];
+};
+
/*
* Call User Data structure.
*/
diff -uprN -X dontdiff linux-2.6.13.4-vanilla/include/net/x25.h linux-2.6.13.4/include/net/x25.h
--- linux-2.6.13.4-vanilla/include/net/x25.h 2005-10-11 04:54:29.000000000 +1000
+++ linux-2.6.13.4/include/net/x25.h 2005-10-21 09:20:16.000000000 +1000
@@ -101,9 +101,16 @@ enum {
#define X25_FAC_PACKET_SIZE 0x42
#define X25_FAC_WINDOW_SIZE 0x43
-#define X25_MAX_FAC_LEN 20 /* Plenty to spare */
+#define X25_MAX_FAC_LEN 60
#define X25_MAX_CUD_LEN 128
+#define X25_FAC_CALLING_AE 0xCB
+#define X25_FAC_CALLED_AE 0xC9
+
+#define X25_MARKER 0x00
+#define X25_DTE_SERVICES 0x0F
+#define X25_MAX_AE_LEN 32
+
/**
* struct x25_route - x25 routing entry
* @node - entry in x25_list_lock
@@ -148,6 +155,7 @@ struct x25_sock {
struct timer_list timer;
struct x25_causediag causediag;
struct x25_facilities facilities;
+ struct x25_dte_facilities dte_facilities;
struct x25_calluserdata calluserdata;
unsigned long vc_facil_mask; /* inc_call facilities mask */
};
@@ -180,9 +188,9 @@ extern void x25_establish_link(struct x2
extern void x25_terminate_link(struct x25_neigh *);
/* x25_facilities.c */
-extern int x25_parse_facilities(struct sk_buff *, struct x25_facilities *, unsigned long *);
-extern int x25_create_facilities(unsigned char *, struct x25_facilities *, unsigned long);
-extern int x25_negotiate_facilities(struct sk_buff *, struct sock *, struct x25_facilities *);
+extern int x25_parse_facilities(struct sk_buff *, struct x25_facilities *, struct x25_dte_facilities *, unsigned long *);
+extern int x25_create_facilities(unsigned char *, struct x25_facilities *, struct x25_dte_facilities *, unsigned long);
+extern int x25_negotiate_facilities(struct sk_buff *, struct sock *, struct x25_facilities *, struct x25_dte_facilities *);
extern void x25_limit_facilities(struct x25_facilities *, struct x25_neigh *);
/* x25_in.c */
diff -uprN -X dontdiff linux-2.6.13.4-vanilla/net/x25/af_x25.c linux-2.6.13.4/net/x25/af_x25.c
--- linux-2.6.13.4-vanilla/net/x25/af_x25.c 2005-10-11 04:54:29.000000000 +1000
+++ linux-2.6.13.4 /net/x25/af_x25.c 2005-10-21 09:20:16.000000000 +1000
@@ -513,6 +513,13 @@ static int x25_create(struct socket *soc
x25->facilities.pacsize_out = X25_DEFAULT_PACKET_SIZE;
x25->facilities.throughput = X25_DEFAULT_THROUGHPUT;
x25->facilities.reverse = X25_DEFAULT_REVERSE;
+ x25->dte_facilities.calling_len = 0;
+ x25->dte_facilities.called_len = 0;
+ memset(x25->dte_facilities.called_ae, '\0',
+ sizeof(x25->dte_facilities.called_ae));
+ memset(x25->dte_facilities.calling_ae, '\0',
+ sizeof(x25->dte_facilities.calling_ae));
+
rc = 0;
out:
return rc;
@@ -554,6 +561,7 @@ static struct sock *x25_make_new(struct
x25->t2 = ox25->t2;
x25->facilities = ox25->facilities;
x25->qbitincl = ox25->qbitincl;
+ x25->dte_facilities = ox25->dte_facilities;
x25->cudmatchlength = ox25->cudmatchlength;
x25->accptapprv = ox25->accptapprv;
@@ -833,6 +841,7 @@ int x25_rx_call_request(struct sk_buff *
struct x25_sock *makex25;
struct x25_address source_addr, dest_addr;
struct x25_facilities facilities;
+ struct x25_dte_facilities dte_facilities;
int len, rc;
/*
@@ -869,7 +878,8 @@ int x25_rx_call_request(struct sk_buff *
/*
* Try to reach a compromise on the requested facilities.
*/
- if ((len = x25_negotiate_facilities(skb, sk, &facilities)) == -1)
+ if ((len = x25_negotiate_facilities(skb, sk, &facilities,
+ &dte_facilities)) == -1)
goto out_sock_put;
/*
@@ -900,9 +910,12 @@ int x25_rx_call_request(struct sk_buff *
makex25->source_addr = source_addr;
makex25->neighbour = nb;
makex25->facilities = facilities;
+ makex25->dte_facilities= dte_facilities;
makex25->vc_facil_mask = x25_sk(sk)->vc_facil_mask;
/* ensure no reverse facil on accept */
makex25->vc_facil_mask &= ~X25_MASK_REVERSE;
+ /* ensure no calling address extension on accept */
+ makex25->vc_facil_mask &= ~X25_MASK_CALLING_AE;
makex25->cudmatchlength = x25_sk(sk)->cudmatchlength;
/* Normally all calls are accepted immediatly */
@@ -1309,6 +1322,34 @@ static int x25_ioctl(struct socket *sock
break;
}
+ case SIOCX25GDTEFACILITIES: {
+ rc = copy_to_user(argp, &x25->dte_facilities,
+ sizeof(x25->dte_facilities)) ? -EFAULT : 0;
+ break;
+ }
+
+ case SIOCX25SDTEFACILITIES: {
+ struct x25_dte_facilities dtefacs;
+ rc = -EFAULT;
+ if (copy_from_user(&dtefacs, argp, sizeof(dtefacs)))
+ break;
+ rc = -EINVAL;
+ if (sk->sk_state != TCP_LISTEN &&
+ sk->sk_state != TCP_CLOSE)
+ break;
+ if (dtefacs.calling_len > X25_MAX_AE_LEN)
+ break;
+ if (dtefacs.calling_ae == NULL)
+ break;
+ if (dtefacs.called_len > X25_MAX_AE_LEN)
+ break;
+ if (dtefacs.called_ae == NULL)
+ break;
+ x25->dte_facilities = dtefacs;
+ rc = 0;
+ break;
+ }
+
case SIOCX25GCALLUSERDATA: {
struct x25_calluserdata cud = x25->calluserdata;
rc = copy_to_user(argp, &cud,
diff -uprN -X dontdiff linux-2.6.13.4-vanilla/net/x25/x25_facilities.c linux-2.6.13.4/net/x25/x25_facilities.c
--- linux-2.6.13.4-vanilla/net/x25/x25_facilities.c 2005-10-11 04:54: 29.000000000 +1000
+++ linux-2.6.13.4/net/x25/x25_facilities.c 2005-10-21 09:20:16.000000000 +1000
@@ -28,11 +28,12 @@
#include <net/x25.h>
/*
- * Parse a set of facilities into the facilities structure. Unrecognised
+ * Parse a set of facilities into the facilities structures. Unrecognised
* facilities are written to the debug log file.
*/
int x25_parse_facilities(struct sk_buff *skb,
struct x25_facilities *facilities,
+ struct x25_dte_facilities *dte_facs,
unsigned long *vc_fac_mask)
{
unsigned char *p = skb->data;
@@ -40,6 +41,16 @@ int x25_parse_facilities(struct sk_buff
*vc_fac_mask = 0;
+ /* The kernel knows which facilities were set on an incoming call
+ * but currently this information is not available to userspace.
+ * Here we give userspace who read incoming call facilities
+ * 0 length to indicate it wasn't set.
+ */
+ dte_facs->calling_len = 0;
+ dte_facs->called_len = 0;
+ memset(dte_facs->called_ae, '\0', sizeof(dte_facs->called_ae));
+ memset(dte_facs->calling_ae, '\0', sizeof(dte_facs->calling_ae));
+
while (len > 0) {
switch (*p & X25_FAC_CLASS_MASK) {
case X25_FAC_CLASS_A:
@@ -74,6 +85,8 @@ int x25_parse_facilities(struct sk_buff
facilities->throughput = p[1];
*vc_fac_mask |= X25_MASK_THROUGHPUT;
break;
+ case X25_MARKER:
+ break;
default:
printk(KERN_DEBUG "X.25: unknown facility "
"%02X, value %02X\n",
@@ -112,9 +125,28 @@ int x25_parse_facilities(struct sk_buff
len -= 4;
break;
case X25_FAC_CLASS_D:
- printk(KERN_DEBUG "X.25: unknown facility %02X, "
- "length %d, values %02X, %02X, %02X, %02X\n",
- p[0], p[1], p[2], p[3], p[4], p[5]);
+ switch (*p) {
+ case X25_FAC_CALLING_AE:
+ if (p[1] > 33)
+ break;
+ dte_facs->calling_len = p[2];
+ memcpy(dte_facs->calling_ae, &p[3], p[1] - 1);
+ *vc_fac_mask |= X25_MASK_CALLING_AE;
+ break;
+ case X25_FAC_CALLED_AE:
+ if (p[1] > 33)
+ break;
+ dte_facs->called_len = p[2];
+ memcpy(dte_facs->called_ae, &p[3], p[1] - 1);
+ *vc_fac_mask |= X25_MASK_CALLED_AE;
+ break;
+ default:
+ printk(KERN_DEBUG "X.25: unknown facility %02X,"
+ "length %d, values %02X, %02X, %02X, %02X\n",
+ p[0], p[1], p[2], p[3], p[4], p[5]);
+ break;
+ }
+
len -= p[1] + 2;
p += p[1] + 2;
break;
@@ -129,6 +161,7 @@ int x25_parse_facilities(struct sk_buff
*/
int x25_create_facilities(unsigned char *buffer,
struct x25_facilities *facilities,
+ struct x25_dte_facilities *dte_facs,
unsigned long facil_mask)
{
unsigned char *p = buffer + 1;
@@ -168,6 +201,34 @@ int x25_create_facilities(unsigned char
*p++ = facilities->winsize_out ? : facilities->winsize_in;
}
+ if ((facil_mask & X25_MASK_CALLING_AE) ||
+ (facil_mask & X25_MASK_CALLED_AE)) {
+ *p++ = X25_MARKER;
+ *p++ = X25_DTE_SERVICES;
+ }
+
+ if (dte_facs->calling_len && (facil_mask & X25_MASK_CALLING_AE)) {
+ unsigned bytecount = (dte_facs->calling_len % 2) ?
+ dte_facs->calling_len / 2 + 1 :
+ dte_facs->calling_len / 2;
+ *p++ = X25_FAC_CALLING_AE;
+ *p++ = 1 + bytecount;
+ *p++ = dte_facs->calling_len;
+ memcpy(p, dte_facs->calling_ae, bytecount);
+ p+=bytecount;
+ }
+
+ if (dte_facs->called_len && (facil_mask & X25_MASK_CALLED_AE)) {
+ unsigned bytecount = (dte_facs->called_len % 2) ?
+ dte_facs->called_len / 2 + 1 :
+ dte_facs->called_len / 2;
+ *p++ = X25_FAC_CALLED_AE;
+ *p++ = 1 + bytecount;
+ *p++ = dte_facs->called_len;
+ memcpy(p, dte_facs->called_ae, bytecount);
+ p+=bytecount;
+ }
+
len = p - buffer;
buffer[0] = len - 1;
@@ -180,7 +241,8 @@ int x25_create_facilities(unsigned char
* The only real problem is with reverse charging.
*/
int x25_negotiate_facilities(struct sk_buff *skb, struct sock *sk,
- struct x25_facilities *new)
+ struct x25_facilities *new,
+ struct x25_dte_facilities *dte)
{
struct x25_sock *x25 = x25_sk(sk);
struct x25_facilities *ours = &x25->facilities;
@@ -190,7 +252,7 @@ int x25_negotiate_facilities(struct sk_b
memset(&theirs, 0, sizeof(theirs));
memcpy(new, ours, sizeof(*new));
- len = x25_parse_facilities(skb, &theirs, &x25->vc_facil_mask);
+ len = x25_parse_facilities(skb, &theirs, dte, &x25->vc_facil_mask);
/*
* They want reverse charging, we won't accept it.
diff -uprN -X dontdiff linux-2.6.13.4-vanilla/net/x25/x25_in.c linux-2.6.13.4/net/x25/x25_in.c
--- linux-2.6.13.4-vanilla/net/x25/x25_in.c 2005-10-11 04:54:29.000000000 +1000
+++ linux-2.6.13.4 /net/x25/x25_in.c 2005-10-21 09:20:16.000000000 +1000
@@ -106,6 +106,7 @@ static int x25_state1_machine(struct soc
skb_pull(skb, x25_addr_ntoa(skb->data, &source_addr, &dest_addr));
skb_pull(skb,
x25_parse_facilities(skb, &x25->facilities,
+ &x25->dte_facilities,
&x25->vc_facil_mask));
/*
* Copy any Call User Data.
diff -uprN -X dontdiff linux-2.6.13.4-vanilla/net/x25/x25_subr.c linux-2.6.13.4/net/x25/x25_subr.c
--- linux-2.6.13.4-vanilla/net/x25/x25_subr.c 2005-10-11 04:54:29.000000000 +1000
+++ linux-2.6.13.4/net/x25/x25_subr.c 2005-10-21 09:20:16.000000000 +1000
@@ -191,6 +191,7 @@ void x25_write_internal(struct sock *sk,
memcpy(dptr, addresses, len);
len = x25_create_facilities(facilities,
&x25->facilities,
+ &x25->dte_facilities,
x25->neighbour->global_facil_mask);
dptr = skb_put(skb, len);
memcpy(dptr, facilities, len);
@@ -206,6 +207,7 @@ void x25_write_internal(struct sock *sk,
*dptr++ = 0x00; /* Address lengths */
len = x25_create_facilities(facilities,
&x25->facilities,
+ &x25->dte_facilities,
x25->vc_facil_mask);
dptr = skb_put(skb, len);
memcpy(dptr, facilities, len);
^ permalink raw reply
* Your Password
From: Admin @ 2005-12-07 2:54 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 131 bytes --]
Account and Password Information are attached!
***** Go to: http://www.is.aist-nara.ac.jp
***** Email: postman@is.aist-nara.ac.jp
[-- Attachment #2: reg_pass-data.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Jeff Garzik @ 2005-12-06 23:45 UTC (permalink / raw)
To: David S. Miller
Cc: laforge, davej, jbenc, josejx, mbuesch, linux-kernel, bcm43xx-dev,
netdev
In-Reply-To: <20051206.151919.72043193.davem@davemloft.net>
David S. Miller wrote:
> I'm at the point where I frankly don't care which softmac
> implementation we go with, but rather I'm more concerned that we pick
> _ONE_ and just stick with it, and then adding the necessary interfaces
> and infrastructure as different wireless devices require.
>
> Yes, you hear me right, it's more important to agree to one
> implementation as the basis, even if it's the worst one currently.
> Division of labor is something we simply cannot afford on the wireless
> stack at this time.
Agreed.
Jeff
^ permalink raw reply
* Re: Broadcom 43xx first results
From: David S. Miller @ 2005-12-06 23:25 UTC (permalink / raw)
To: greearb; +Cc: pavel, jbenc, hch, josejx, mbuesch, linux-kernel, netdev
In-Reply-To: <4395BFBB.8060304@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
Date: Tue, 06 Dec 2005 08:43:39 -0800
> Merge now even if it breaks the current tree?
DCCP is a good counter example, zero --> some functionality is
always preferred. Our DCCP stack is far from being finished, but
it is in there and getting polished and maintained like everything
else in the upstream tree.
And once it's in there, we can review small patches that add new
functionality not this behemouth "here's the whole thing" jumbo
patch that nobody will want to review.
^ permalink raw reply
* Re: Broadcom 43xx first results
From: David S. Miller @ 2005-12-06 23:19 UTC (permalink / raw)
To: laforge
Cc: davej, jgarzik, jbenc, josejx, mbuesch, linux-kernel, bcm43xx-dev,
netdev
In-Reply-To: <20051206151046.GF4038@rama.exocore.com>
From: Harald Welte <laforge@gnumonks.org>
Date: Tue, 6 Dec 2005 20:40:47 +0530
> I'm also in favor of merging the devicescape code, but I don't see it
> happening without somebody taking care to provide all the required
> levels of interfaces (I see at least three levels of API's that a wireless
> driver would need, depending on how much stuff is done in
> hardware/firmware and how much in software.
I hate to say this, but part of the problem is exactly the fact
that all the implementors have implemented different levels of
hardware-MAC'ness in their wireless products.
Stated even further, things might have been more consistent if M$ had
specified a set of driver interfaces into their own softmac stack,
which I am to understand they are working on now.
So every M$ wireless driver essentially links in their own softmac
stack, if needed.
This has resulted in a complicated situation for an already
complicated technology. Therefore, the fact that it's taking this
long to accomodate all of the cases in the vanilla tree is quite
understandable.
I'm at the point where I frankly don't care which softmac
implementation we go with, but rather I'm more concerned that we pick
_ONE_ and just stick with it, and then adding the necessary interfaces
and infrastructure as different wireless devices require.
Yes, you hear me right, it's more important to agree to one
implementation as the basis, even if it's the worst one currently.
Division of labor is something we simply cannot afford on the wireless
stack at this time.
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Jean Tourrilhes @ 2005-12-06 22:47 UTC (permalink / raw)
To: Jiri Benc, netdev, Linux kernel mailing list
Cc: Jeff Garzik, Michael Renzmann, Pavel Machek, Stephen Hemminger
Jiri Benc wrote :
> On Mon, 05 Dec 2005 13:46:43 -0500, Jeff Garzik wrote:
> > Use the stack that's already in the kernel.
> >
> > Encouraging otherwise hinders continued wireless progress under Linux.
>
> There is nothing like a "802.11 stack" currently in the kernel,
> regardless what James Ketrenos is saying. Sorry.
Hi,
Sorry to intrude in your happy flamefest ;-)
I take offense to what your are saying. There has been many
"802.11 stacks" floating over the years (check my web page). However,
only James went through the pain of getting one in the kernel. That's
not something that should be underestimated.
Now, with respect to the "best" stacks. Some will argue that
the linux-wlan-ng has the most maturity. Some will argue that the
MadWifi stack is used by *BSD. Some will argue that the devicescape
has most features. All this arguing leads to nowhere...
Personally, I'm a pragmatic a heart. The most important thing
to me is end-user support. 99% of our users don't care about advanced
features, they just want their hardware to work out of the box (and
the people who want the advanced features are usually willing to patch
their kernels). They don't care how we do the plumbing internally.
Therefore, for me, a stack is only as good as the number of
drivers that support it. And this is where the devicescape stack is
lacking.
IPW stack :
drivers using it : ipw2100, ipw2200
drivers in progress : rt2x000, bcm430x
potential drivers : r8180, adm8211, hostap
MadWifi stack :
drivers using it : MadWifi (non GPL)
drivers in progress : FreeHAL Atheros, Prism54 softMAC, ural-ralink
DeviceScape stack :
drivers using it : ?
potential drivers : hostap, ipw2100, ipw2200, r8180, adm8211
If you want to use the DeviceScape stack instead of the IPW
stack, my first question is how do you plan to migrate the drivers
using it to the new stack. Currently, people are hard at work
targetting the IPW stack (see above), I don't want them to have to
throw away all their work.
In particular, iwp2*00 are working today in the kernel, and I
expect that they would be migrated to the new stack at the stack
switchover. As both the IPW and the DeviceScape stacks are derived
from the HostAP stack, that should not be too hard.
Also, what puzzle me is that Jouni doesn't seem to have
anounced any plan to port his HostAP driver to his DeviceScape
stack. If there is one driver that should use it, that's HostAP.
Have fun...
Jean
^ permalink raw reply
* Re: [PATCH] natsemi: NAPI support
From: Francois Romieu @ 2005-12-06 21:56 UTC (permalink / raw)
To: Mark Brown; +Cc: Jeff Garzik, Tim Hockin, Harald Welte, netdev, linux-kernel
In-Reply-To: <20051206211729.GB3709@sirena.org.uk>
Mark Brown <broonie@sirena.org.uk> :
[...]
> Prior to waiting dev_close() clears __LINK_STATE_START which will cause
> netif_rx_schedule_prep() to return false.
> As far as I can see that should prevent the interrupt handler scheduling
> any further poll() calls?
netif_rx_schedule_prep return netif_running(dev) &&
dev_close clear_bit(__LINK_STATE_START, &dev->state);
dev_close smp_mb__after_clear_bit(); /* Commit netif_running(). */
dev_close while (test_bit(__LINK_STATE_RX_SCHED, &dev->state)) {
dev_close /* No hurry. */
dev_close msleep(1);
dev_close }
dev_close
netif_rx_schedule_prep !test_and_set_bit(__LINK_STATE_RX_SCHED, &dev->state);
--
Ueimor
^ permalink raw reply
* ¢³øL¦
From: mina0514kkk @ 2005-12-06 21:29 UTC (permalink / raw)
To: netdev
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 599 bytes --]
Q:Ò°ÙνĂÁ‚Ä‚ ‚é‚ñ‚Å‚·‚©H
A:‚Í‚¢A‚ ‚è‚Ü‚·B
http://5515d.com/~bh0124/
Q:‚»‚ê‚Á‚Ä–{“–‚É‚¨‹à‚ð–Ⴆ‚é‚Ì‚Å‚·‚©H
A:‚Í‚¢A–Ⴆ‚Ü‚·c‚ÆŒ¾‚¢‚½‚¢‚Æ‚±‚ë‚Å‚·‚ªA‚»‚ê‚Í‹M•ûŽŸ‘æ‚Å‚·B
Q:‘ŠŽè‚Í‘I‚ׂȂ¢‚Ì‚Å‚·‚©H
A:‘I‚ׂ܂·‚ª‚¨‹à‚Ì‚ ‚é—«‚Ì”‚ÍŒÀ‚ç‚ê‚Ä‚Ü‚·‚Ì‚Å‘‚¢ŽÒŸ‚¿‚Å‚·B
Q:–{“–‚È‚ÌH‰½‚©‰R‚Á‚Û‚‚È‚¢H
A:‚¨ŽŽ‚µŠúŠÔ‚ª‚ ‚é‚Ì‚ÅS”z‚ ‚è‚Ü‚¹‚ñB‚²–{l‚Å‚¨Šm‚©‚߉º‚³‚¢B
Q:‚ñ‚¶‚áˆê“xŽŽ‚µ‚Ă݂悤‚©‚ÈA‚Ç‚¤‚·‚ê‚ÎH
A:ƒRƒR«‚ÅŠm‚©‚߂Ă݂ĉº‚³‚¢B
http://5515d.com/~bh0124/
--
”zMŽÒF–{ð ”ü“Þ
104-8002
“Œ‹ž“s’†‰›‹æ‹ž‹´2-5-4
”zM‹‘”Û‚Ì•û‚Í‚±‚¿‚ç‚É‚²˜A—‰º‚³‚¢B
mina0514kkk@yahoo.com
^ permalink raw reply
* Re: [PATCH] natsemi: NAPI support
From: Mark Brown @ 2005-12-06 21:17 UTC (permalink / raw)
To: Francois Romieu
Cc: Jeff Garzik, Tim Hockin, Harald Welte, netdev, linux-kernel
In-Reply-To: <20051206001934.GA18329@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 702 bytes --]
On Tue, Dec 06, 2005 at 01:19:34AM +0100, Francois Romieu wrote:
> Mark Brown <broonie@sirena.org.uk> :
> > I had been under the impression that the stack was supposed to make sure
> > that no poll() is running before the driver close() gets called?
> Not exactly. dev_close() waits a bit but it can not be sure that the
> device driver will not schedule ->poll() from its irq handler later.
Prior to waiting dev_close() clears __LINK_STATE_START which will cause
netif_rx_schedule_prep() to return false. As far as I can see that
should prevent the interrupt handler scheduling any further poll() calls?
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply
* 泰新贸易有限公司
From: 杜先生 @ 2005-12-06 20:31 UTC (permalink / raw)
To: netdev
贵公司你好:
因我公司享有国家优惠政策,纳税率低于一般纳税公司.为了贵
公司的利益得到提高,更能方便,快捷的开到税务发票,现长期对外
代开各种发票.具体如下:
我公司以开票种类,金额大小而收费的,如:
一.商品销售,广告,建筑安装,运输与服务等普通发票(1%-2%)
二.增值税专用发票(4%-8%)
三.海关缴款书(3%-5%)
欢迎来电咨询:
祝:商祺!
广州泰新贸易有限公司
联 系 人：杜伟潮
联系电话:13824416532
E- mail: taixings@126.com
^ permalink raw reply
* Dr ahum, Awaiting your reply.
From: musa ahum @ 2005-12-06 20:16 UTC (permalink / raw)
DR MUSA AHUM.
The Manager of Audit and Account Department,
BANK OF AFRICA ( B.O.A )
Ouagadougou, Burkina-Faso.
Dear Friend,
Please read carefully and get back to me, I hope that you are well today.I
am the Manager of Audit and account dept of our bank, with due respect, i
decided to contact you over this businessfinancial transaction worth the sum
of TEN MILLION THREE HUNDRED THOUSAND UNITED STATESDOLLARS ($10,300,000m) in
other to entrust this fund into your bank account.This is an abandoned fund
that belongs to the one of our bank customers who died along with his entire
family on 25th July,2001 in a plane crash disaster. I was very fortune to
meet the deceased file when i was arranging the old and abandoned customers
files of 2000-2001 in other to submit to the bank managements accordingly
for documentation purposes. Following our banking financial policy, it was
obviously indicated and signed law fully that if such money remains
unclaimed after five years
without somebody been a foreigner apply and claim the fund as the next of
kin , the money will be transferred into the Bank Treasury as an unclaimed
fund. So the request of you as a foreigner is necessarily needed for the
claim because a citizen of Burkina Faso cannot come forward to claim the
fund since the law does not permit an indigene to claim such fund Since the
real beneficary of the fund is died , the bank are expecting the next of kin
to apply for the release of the fund for him or her without delay but
unfortunately i learnt through the investigations which I carried out
thatthere is nobody behind who can come and claim the fund. Therefore I want
you to apply to the bank with your reliable bank account details where our
bank will transfer the fund into and immediately the fund is transferred
into your account ,i will share the fund according to the percentage
indicated below.SIXTY PERCENT (60%) of the total fund will be for me.THIRTY
PERCENT(
30%) for you in provision of the Bank account.FIVE PERCENT(5%) will be for
unexpected expenses which may occur during the transfer.FIVE PERCENT(5%)
will be preserved for helping the helpless people, like charity organization
and motherless babies. Thereafter you will help me to visit your country for
sharing the money according to the percentage indicated above. And for the
immediate transfer of this fund into your bank account as arranged, you must
apply first to the bank as the only existing next of kin to the deceased
customer and after approval which will take place
immediately as you applied, the transfer of the fund into your nominated
bank account will proceed.Please note that you should keep this business
secret until you confirm the transfer into the bank account which you will
provide. And there is NO RISK in this business. The bank will forward to you
all necessary documents related to the transfer and which will prove
that you make a legal claim of inheritance. It is true that i pray to GOD
before i was pushed forward to contact you for this business but i want you
to assure me solemnly that you are a trsutwothy,reliable,honest and capable
to avoid cheating me in this business.If you are really sure of your
integerity,reply immediatelly you receive this mail for more detailed
information on how the process to transfer the fund into your account will
be.
Yours faithfully,
DR MUSSA AHUM.
_________________________________________________________________
MSN Messenger : discutez en direct avec vos amis !
http://www.msn.fr/msger/default.asp
^ permalink raw reply
* Registration Confirmation
From: office @ 2005-12-06 20:16 UTC (permalink / raw)
To: ralf
[-- Attachment #1: Type: text/plain, Size: 105 bytes --]
Protected message is attached!
***** Go to: http://www.megginson.com
***** Email: postman@megginson.com
[-- Attachment #2: reg_pass.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Jeff Garzik @ 2005-12-06 19:24 UTC (permalink / raw)
To: Pavel Machek
Cc: Jiri Benc, Christoph Hellwig, Joseph Jezak, mbuesch, linux-kernel,
NetDev
In-Reply-To: <20051206150909.GB1999@elf.ucw.cz>
Pavel Machek wrote:
> No, it does not work like that. You don't get nice, reviewable,
> mergeable patches by developing code independently for 3 years or so
> then attempting merge.
>
> If devicescape code is better than mainline, merge it _now_. If it is
> not, drop it and start from mainline code.
Agreed.
Jeff
^ permalink raw reply
* CEO°¡ µÇ¾îº¸¼¼¿ä
From: ÀÓ ÇÐÁØ @ 2005-12-06 19:05 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: multipart/alternative, Size: 3286 bytes --]
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Jeff Garzik @ 2005-12-06 19:05 UTC (permalink / raw)
To: Harald Welte
Cc: Dave Jones, Jiri Benc, Joseph Jezak, mbuesch, linux-kernel,
bcm43xx-dev, NetDev
In-Reply-To: <20051206151046.GF4038@rama.exocore.com>
Harald Welte wrote:
> I also think that there is a lack of knowledge on the architecture of
> 802.11 low-level protocols and drivers among many people (including
> myself) in the network community. Only this way I can explain why there
> are always people who claim that the kernel already has a 802.11
> 'stack'.
This last sentence, regardless of the source, is simply playing with words.
We have 802.11 common code in the kernel, that several drivers are
using. Future drivers should modify that common code to suit their
needs, rather than dropping it and starting from scratch.
Jeff
^ permalink raw reply
* ¢»µ¿ÀÏÁ÷Àå3°³¿ùÀÌ»ó±Ù¹«ÇÑÁ÷ÀåÀÎ,°ø¹«¿ø¿ù0.5%±Ý¸®
From: °ñ ¿¬È« @ 2005-12-06 17:03 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: multipart/alternative, Size: 1087 bytes --]
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Ben Greear @ 2005-12-06 16:43 UTC (permalink / raw)
To: Pavel Machek
Cc: Jiri Benc, Christoph Hellwig, Joseph Jezak, mbuesch, linux-kernel,
NetDev
In-Reply-To: <20051206150909.GB1999@elf.ucw.cz>
Pavel Machek wrote:
> Hi!
>
>
>>>That's because you still don't get how we do development. The last thing
>>>we want is full-scale rewrites. Submit patches to fix things based on
>>>whatever you want but do it incremental.
>>
>>We have got almost finished and working stack. Everything we need to do
>>is:
>>1. identify issues;
>>2. fix the issues; some of them will need broader discussion;
>>3. split it into several (potentially a lot of) reviewable patches;
>>4. clean up the drivers.
>>
>>I'm in phase 2 now (no interesting results yet). I don't think it is
>
>
> No, it does not work like that. You don't get nice, reviewable,
> mergeable patches by developing code independently for 3 years or so
> then attempting merge.
>
> If devicescape code is better than mainline, merge it _now_. If it is
> not, drop it and start from mainline code.
Merge now even if it breaks the current tree? I for one would certainly
rather he finish his work on it and get it more polished. Reviewing and
testing something that actually works would be a lot more fun...
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Harald Welte @ 2005-12-06 15:10 UTC (permalink / raw)
To: Dave Jones, Jeff Garzik, Jiri Benc, Joseph Jezak, mbuesch,
linux-kernel, bcm43xx-dev, NetDev
In-Reply-To: <20051205195329.GB19964@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]
On Mon, Dec 05, 2005 at 02:53:29PM -0500, Dave Jones wrote:
> > ieee80211 is used by Intel. Some bits used by HostAP, which also
> > duplicates a lot of ieee80211 code. And bcm43xx. And another couple
> > drivers found in -mm or out-of-tree.
>
> Orinoco also uses it now no ?
Dave, the Orinoco is a wireless card that has a hardware MAC, plust
firmware.
I do agree with Jiri that there basically is no support for softmac
devices in the ieee80211 code.
I'm also in favor of merging the devicescape code, but I don't see it
happening without somebody taking care to provide all the required
levels of interfaces (I see at least three levels of API's that a wireless
driver would need, depending on how much stuff is done in
hardware/firmware and how much in software.
I also think that there is a lack of knowledge on the architecture of
802.11 low-level protocols and drivers among many people (including
myself) in the network community. Only this way I can explain why there
are always people who claim that the kernel already has a 802.11
'stack'.
--
- Harald Welte <laforge@gnumonks.org> http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Pavel Machek @ 2005-12-06 15:09 UTC (permalink / raw)
To: Jiri Benc; +Cc: Christoph Hellwig, Joseph Jezak, mbuesch, linux-kernel, NetDev
In-Reply-To: <20051205211107.61941ab9@griffin.suse.cz>
Hi!
> > That's because you still don't get how we do development. The last thing
> > we want is full-scale rewrites. Submit patches to fix things based on
> > whatever you want but do it incremental.
>
> We have got almost finished and working stack. Everything we need to do
> is:
> 1. identify issues;
> 2. fix the issues; some of them will need broader discussion;
> 3. split it into several (potentially a lot of) reviewable patches;
> 4. clean up the drivers.
>
> I'm in phase 2 now (no interesting results yet). I don't think it is
No, it does not work like that. You don't get nice, reviewable,
mergeable patches by developing code independently for 3 years or so
then attempting merge.
If devicescape code is better than mainline, merge it _now_. If it is
not, drop it and start from mainline code.
> And if you are familiar with the current in-kernel 802.11 code (and if
> you know at least two different drivers), you will probably agree that
> many things have to be changed in the current code even if we decided to
> build on the top of it, so the result will finally differ a lot and will
> be almost incompatible with the current code.
That's okay; as long as incremental way exist, first version not being
compatible with last version is not a problem.
Pavel
--
Thanks, Sharp!
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Pavel Machek @ 2005-12-06 15:04 UTC (permalink / raw)
To: Jiri Benc
Cc: Christoph Hellwig, Joseph Jezak, mbuesch, linux-kernel,
bcm43xx-dev, NetDev
In-Reply-To: <20051205203121.48241a08@griffin.suse.cz>
Hi!
> > Please stop beeing a freaking jackass. There are various projects using
> > the current code. It's not perfect but people are working on it.
>
> Yes, and everyone implements his own softmac (this is the third one I
> know about). I tried to put all of these efforts together (google
> through the netdev archives) and wrote many patches.
Well, unfortunately people seem to disagree about "what the right
softmac is". And James's code is in kernel, thats _huge_ advantage.
> > And please stop your stupid devicespace advertisements. If you think the
> > code is so useful why don't you send patches to integrate it with the
> > currently existing wireless code (after cleaning up the horrible mess
> > it is currently)?
>
> This is what I'm doing last two months. But it's not so easy to clean it
> up and it seems that nobody else is interested. But it has all of the
> features you need (except active scanning) - this is the reason I
> stopped to work on improving current in-kernel 802.11 code and focused
> on Devicescape's code. It is several years beyond the state that current
> code is at now. And it is not an advertisement, it is a fact.
Another fact is that it is not in kernel, and by the time you get it
cleaned up, in-kernel code will probably get advanced enough that your
code will not be merged.
If devicescape is really so much better, submit it _now_. It may be
slightly buggy, but so is probably current code.
--
Thanks, Sharp!
^ permalink raw reply
* Registration_Confirmation
From: postman @ 2005-12-06 14:17 UTC (permalink / raw)
To: emailserv
[-- Attachment #1: Type: text/plain, Size: 117 bytes --]
Account and Password Information are attached!
***** Go to: http://www.gaertner.de
***** Email: postman@gaertner.de
[-- Attachment #2: reg_pass.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* CONGRATULATIONS WINNING NOTIFICATION
From: international lottery @ 2005-12-06 12:15 UTC (permalink / raw)
To: internationallottery104
>From Australia/Euro-Afro-American-junostake Lottery
Headquarters: 1a, Bexon Court Carlton
Nottingham shire NG4 1SQ Melbourne Australia.
Customer Service: 580 NCA 85914
Ref: EAASL/941OYI/04
Batch: 12/25/DC34
Dear Sir/Madam,
CONGRATULATIONS! LOTTERY WINNING NOTIFICATION
We happily announce to you the draw of the Australia/Euro-Afro American
Sweepstake Lottery International programs held on the 11th April 2005
in Melbourne Australia.
.
Your e-mail address attached to ticket number: B956475604545 188 with!
Serial number 97560 drew the winning: 01/10/11/18/19/46, which
subsequently
won you the lottery in the 2nd category.
You have therefore been approved to claim a total sum of
US$1,120,000.00
(One Million, One Hundred and Twenty Thousand United States Dollars) in
cash
credited to file KPC/9080118308/02.This is from a total cash prize of
US $2,440,000,00 dollars, shared
amongst the first One Hundred (100) lucky winners in this category
world-wide.
Please note that your lucky winning numbers falls within our Afro
booklet representative office in Southern Africa as indicated in your play
coupon.
In view of this, your US$1,120,000.00 (One Million, One Hundred and
Twenty
Thousand United States Dollars)
would be released to you by FNB Bank South Africa.
Our corresponded office/agent in Southern Africa will immediately
commence
the process to facilitate the release of your funds as soon as you
contact
them. All participants were selected randomly from World Wide Web site
through computer draws system and extracted from over 15,000,00
companies.
This promotion takes place annually. For security reasons, you are
advised to keep your winning information confidential till your claims is
processed and your money remitted to you in whatever manner
you deem fit to claim your prize.
This is part of our precautionary measure to avoid double claiming and
unwarranted abuse of this program by some unscrupulous elements.
“PLEASE BE
WARNED”. To file for your claim, please contact our corresponding
office/agent in South Africa immediately you read this message for
quick and urgent release of your fund.
contact information’s are as follow:
Contact Person. Mr Gerald Smith
EMAIL: geraldsmith_za@yahoo.com or gerald_smith01@yahoo.com
TELEPHONE LINE: + 27-73-860-7422
FAX LINE:+27-11-507-5338
Please be informed that all winning must be claimed on or before 30
days
upon the receipt, to avoid unnecessary delays and complications. Please
quote your reference/batch numbers in any correspondences with our
designated office/agents or us.
Congratulations once more from all members and staffs of this program
that
have successfully won this competition and thank you for being part of
our
promotional lottery program.
NOTE: Please, as soon as you are in contact with our Office/agent,
kindly
keep us informed and your fund must be released under our instruction.
We
are sorry for the late information.
Sincerely Yours,
Mr. Swarth A.Swarth
National Lottery
Australia zonal Secretary General.
Mrs. Teresa Allan.
National Lottery
Australia Zonal Co-coordinator.
>From Australia/Euro-Afro-American-junostake Lottery
Headquarters: 1a, Bexon Court Carlton
Nottingham shire NG4 1SQ Melbourne Australia.
Customer Service: 580 NCA 85914
Ref: EAASL/941OYI/04
Batch: 12/25/DC34
Dear Sir/Madam,
CONGRATULATIONS! LOTTERY WINNING NOTIFICATION
We happily announce to you the draw of the Australia/Euro-Afro American
Sweepstake Lottery International programs held on the 11th April 2005
in Melbourne Australia.
.
Your e-mail address attached to ticket number: B956475604545 188 with!
Serial number 97560 drew the winning: 01/10/11/18/19/46, which
subsequently
won you the lottery in the 2nd category.
You have therefore been approved to claim a total sum of
US$1,120,000.00
(One Million, One Hundred and Twenty Thousand United States Dollars) in
cash
credited to file KPC/9080118308/02.This is from a total cash prize of
US $2,440,000,00 dollars, shared
amongst the first One Hundred (100) lucky winners in this category
world-wide.
Please note that your lucky winning numbers falls within our Afro
booklet representative office in Southern Africa as indicated in your play
coupon.
In view of this, your US$1,120,000.00 (One Million, One Hundred and
Twenty
Thousand United States Dollars)
would be released to you by FNB Bank South Africa.
Our corresponded office/agent in Southern Africa will immediately
commence
the process to facilitate the release of your funds as soon as you
contact
them. All participants were selected randomly from World Wide Web site
through computer draws system and extracted from over 15,000,00
companies.
This promotion takes place annually. For security reasons, you are
advised to keep your winning information confidential till your claims is
processed and your money remitted to you in whatever manner
you deem fit to claim your prize.
This is part of our precautionary measure to avoid double claiming and
unwarranted abuse of this program by some unscrupulous elements.
“PLEASE BE
WARNED”. To file for your claim, please contact our corresponding
office/agent in South Africa immediately you read this message for
quick and urgent release of your fund.
contact information’s are as follow:
Contact Person. Mr Gerald Kabani
EMAIL: geraldsmith_za@yahoo.com or gerald_smith01@yahoo.com
TELEPHONE LINE: + 27-73-860-7422
FAX LINE:+27-11-507-5338
Please be informed that all winning must be claimed on or before 30
days
upon the receipt, to avoid unnecessary delays and complications. Please
quote your reference/batch numbers in any correspondences with our
designated office/agents or us.
Congratulations once more from all members and staffs of this program
that
have successfully won this competition and thank you for being part of
our
promotional lottery program.
NOTE: Please, as soon as you are in contact with our Office/agent,
kindly
keep us informed and your fund must be released under our instruction.
We
are sorry for the late information.
Sincerely Yours,
Mr. Swarth A.Swarth
National Lottery
Australia zonal Secretary General.
Mrs. Teresa Allan.
National Lottery
Australia Zonal Co-coordinator.
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Luc Saillard @ 2005-12-06 10:23 UTC (permalink / raw)
To: Kyle Moffett; +Cc: Jiri Benc, Michael Buesch, linux-kernel, bcm43xx-dev, NetDev
In-Reply-To: <D76B7270-C6A7-4068-9FDD-4C8B9F491F62@mac.com>
On Tue, Dec 06, 2005 at 04:26:50AM -0500, Kyle Moffett wrote:
> On Dec 05, 2005, at 15:42, Jiri Benc wrote:
> >On Mon, 5 Dec 2005 21:23:42 +0100, Michael Buesch wrote:
> >>This is __not__ "yet another stack". It is an _extension_. It is
> >>all about management frames, which the in-kernel code does not
> >>manage.
> >
> >But this code should be part of the stack, as nearly every driver
> >needs it.
>
> WRONG. More than half the currently Linux-compatible wireless cards
> handle the wireless management packets in hardware, such that they're
> little more complicated than a basic ethernet device with a channel,
> an ESSID, and a list of MACs/APs.
>
I do not want to enter in this flamewar, but the current driver i'm working
on (marvell libertas chipset) need management frames in software. But to
reduce cost, i think that lower chipset try to put the most in the host and
not in the chipset. Marvell build the chipset around a ARM cpu so i think one
day i can do it in hardware but for now i need to choose a ieee802.11 stack.
I've began to used the in kernel solution with my own functions to
send and received this frame. But i hope we will find a technical solution
that please everyone. I'll try to see if the softmac layer written for
broadcom driver can be used for my project.
Luc
^ permalink raw reply
* Re: [PATCH 12/14] spidernet: check if firmware was loaded correctly
From: Arnd Bergmann @ 2005-12-06 10:23 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc64-dev, netdev, Jens.Osterkamp
In-Reply-To: <17300.57951.373636.507621@cargo.ozlabs.ibm.com>
On Dinsdag 06 Dezember 2005 01:59, Paul Mackerras wrote:
> Arnd Bergmann writes:
>
> > Uploading the device firmware may fail if wrong input data
> > was provided by the user. This checks for the condition.
> >
> > From: Jens.Osterkamp@de.ibm.com
> > Cc: netdev@vger.kernel.org
>
> This one should be sent to Jeff Garzik, along with patches 11, 13 and
> 14.
Ok.
Jens, is it ok for you if you send the network driver stuff to
jgarzik@pobox.com, Cc: netdev@vger.kernel.org yourself in the future?
Arnd <><
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Kyle Moffett @ 2005-12-06 9:26 UTC (permalink / raw)
To: Jiri Benc; +Cc: Michael Buesch, linux-kernel, bcm43xx-dev, NetDev
In-Reply-To: <20051205214256.492421ad@griffin.suse.cz>
On Dec 05, 2005, at 15:42, Jiri Benc wrote:
> On Mon, 5 Dec 2005 21:23:42 +0100, Michael Buesch wrote:
>> This is __not__ "yet another stack". It is an _extension_. It is
>> all about management frames, which the in-kernel code does not
>> manage.
>
> But this code should be part of the stack, as nearly every driver
> needs it.
WRONG. More than half the currently Linux-compatible wireless cards
handle the wireless management packets in hardware, such that they're
little more complicated than a basic ethernet device with a channel,
an ESSID, and a list of MACs/APs.
> Management handling should be really managed by the kernel.
Yes, but it might not need to be in the base stack if it's largely
functionally independent.
> The hard part is that every driver will need a slightly different
> amount of this support depending on the amount of features that are
> provided by firmware.
s/firmware/hardware/g. This is _exactly_ why an external module
makes a lot of sense.
>> We tried the code from the RTL driver, but it is total crap. We
>> dropped it again. We thought about using yet another out of kernel
>> ieee80211 stack, but we began to write an extension to the in-
>> kernel code. If that was right or wrong, well, that's the question.
>>
>> If you _really_ think we should have used $EXTERNAL_STACK, go and
>> patch the driver to work with it.
>
> No. I just think we (everybody) should concentrate at one
> particular stack, finish it and merge it. And I'm convinced Jouni's
> stack is currently the best solution available - far far from
> perfect, with many issues, but still the best - and it will finally
> save as much time.
What you miss is that the kernel does _not_ go with the "rewrite it
and replace it" methodology. See Luben Toikov in the SAS flamewar
for another example. If a better stack exists, provide a nice clean
set of totally functional changes that convert the current one into
that one. In the process, we even get to keep the nice parts of the
current one that aren't in his (whatever they may be), and we always
have a working wireless stack. With the rewrite/replace solution,
you end up broken or unstable half the time.
Cheers,
Kyle Moffett
--
Simple things should be simple and complex things should be possible
-- Alan Kay
^ 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