* Re: [PATCH NEXT 09/12] netxen: fix skb alloc size for legacy firmware
From: David Miller @ 2009-07-27 17:38 UTC (permalink / raw)
To: dhananjay; +Cc: netdev
In-Reply-To: <1248674867-18821-10-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Sun, 26 Jul 2009 23:07:44 -0700
> Request 1532 bytes skb data size for NX3031. NX2031 firmware
> needs 1760 sized buffers.
>
> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Applied.
^ permalink raw reply
* Re: [PATCH NEXT 08/12] netxen: refactor net_device setup code
From: David Miller @ 2009-07-27 17:38 UTC (permalink / raw)
To: dhananjay; +Cc: netdev
In-Reply-To: <1248674867-18821-9-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Sun, 26 Jul 2009 23:07:43 -0700
> Move all net_device initialization into one function
> netxen_setup_netdev().
>
> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Applied.
^ permalink raw reply
* Re: [PATCH NEXT 07/12] netxen: clean up frimware version checks
From: David Miller @ 2009-07-27 17:38 UTC (permalink / raw)
To: dhananjay; +Cc: netdev
In-Reply-To: <1248674867-18821-8-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Sun, 26 Jul 2009 23:07:42 -0700
> NX2031 firmware version will never be > 4.0.0, so replace
> (adapter->fw_major < 4) checks with pci revision ID check.
>
> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Applied.
^ permalink raw reply
* Re: [PATCH 11/12] net/netlabel: Correct redundant test
From: Paul Moore @ 2009-07-27 17:37 UTC (permalink / raw)
To: Julia Lawall; +Cc: netdev, linux-kernel, kernel-janitors
In-Reply-To: <Pine.LNX.4.64.0907271815260.2682@ask.diku.dk>
On Monday 27 July 2009 12:15:43 pm Julia Lawall wrote:
> From: Julia Lawall <julia@diku.dk>
>
> entry was tested for NULL near the beginning of the function, followed by a
> return, and there is no intervening modification of its value.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://www.emn.fr/x-info/coccinelle/)
>
> // <smpl>
> @r exists@
> local idexpression x;
> expression E;
> position p1,p2;
> @@
>
> if (x == NULL || ...) { ... when forall
> return ...; }
> ... when != \(x=E\|x--\|x++\|--x\|++x\|x-=E\|x+=E\|x|=E\|x&=E\|&x\)
> (
> *x == NULL
>
> *x != NULL
> )
> // </smpl>
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
Good catch, thanks.
Acked-by: Paul Moore <paul.moore@hp.com>
> ---
> net/netlabel/netlabel_kapi.c | 6 ++----
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
> index b0e582f..3ff6f32 100644
> --- a/net/netlabel/netlabel_kapi.c
> +++ b/net/netlabel/netlabel_kapi.c
> @@ -185,8 +185,7 @@ int netlbl_cfg_unlbl_map_add(const char *domain,
> return 0;
>
> cfg_unlbl_map_add_failure:
> - if (entry != NULL)
> - kfree(entry->domain);
> + kfree(entry->domain);
> kfree(entry);
> kfree(addrmap);
> kfree(map4);
> @@ -385,8 +384,7 @@ int netlbl_cfg_cipsov4_map_add(u32 doi,
>
> cfg_cipsov4_map_add_failure:
> cipso_v4_doi_putdef(doi_def);
> - if (entry != NULL)
> - kfree(entry->domain);
> + kfree(entry->domain);
> kfree(entry);
> kfree(addrmap);
> kfree(addrinfo);
--
paul moore
linux @ hp
^ permalink raw reply
* Re: [PATCH] USB host CDC Phonet network interface driver
From: Dan Williams @ 2009-07-27 17:36 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Oliver Neukum, Alan Cox, Rémi Denis-Courmont,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1248458401.28545.149.camel@violet>
On Fri, 2009-07-24 at 20:00 +0200, Marcel Holtmann wrote:
> Hi Oliver,
>
> > > > No, I was thinking of having two full devices, a data channel and a
> > > > control channel for devices that really talk AT commands natively.
> > >
> > > If the hardware does it great, however for things like a 3G modem you
> > > have the problem that the PPP is over the AT command channel which may
> > > itself be multiplexed. And the muxing in question is *ugly* - sort of
> > > HDLC and LAP-B done wrong.
> >
> > Well, yes, but we would really like a separate control channel, so we
> > can query parameters like signal strength, while we do PPP over the data
> > channel.
>
> we don't want PPP at all. It is just plain stupid and a total braindead
> idea. Non of the GSM/UMTS networks talk PPP over the air interface or
> actually anywhere in their stack. The PPP is just between the host OS
> and the card. It is a pointless encapsulation of IP packets that comes
> from the POTS stuff where PPP over a telephone line made sense.
Feel free to convince all the hardware vendors to move over to that
model. Many of them are, but there are still *boatloads* of devices
that do PPP. It'll be at least 3 or 4 years before you can even think
about ignoring PPP entirely.
This is totally a firmware thing and not something under our control at
all. Either the vendor implements a non-PPP data channel, or they
don't. We have to live with that, or ignore devices that use PPP. Most
of the devices out there use PPP. Maybe 80 or 90%.
The only reason vendors ditched PPP was that it was too much overhead to
achieve full speed on HSDPA 7.2 networks. Guess how many operators have
actually deployed HSDPA 7.2? Count them on your hands. Yes, over the
next year or two we'll see a lot more HSDPA 7.2-capable networks, and
that means more devices will show up that ditch PPP. But at the moment,
PPP can't be ignored.
The next problem is that not all vendors implement the non-PPP data
channel using cdc-ether, or provide specs/drivers for that channel. So
just because a vendor ditches PPP doesn't automatically mean it's better
for Linux and a driver is available.
Dan
> And on top of that we have these magic *99# phone numbers to establish a
> PDP context, because the OS still sees them as POTS modem. All stupid
> and braindead. I am so happy that Ericsson and Option moved to proper
> high speed network devices and that Nokia Phonet had this all along.
>
> So besides the GPRS data access, the other problem with AT command
> control channels is that they are by no means async. Every single
> command is essentially blocking and so you need the TTY mux anyway so
> you can do scanning, text messaging and network monitoring at the same
> time without having your application look like a total dork.
>
> Regards
>
> Marcel
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH NEXT 05/12] netxen: refactor tso code
From: David Miller @ 2009-07-27 17:34 UTC (permalink / raw)
To: dhananjay; +Cc: netdev
In-Reply-To: <1248674867-18821-6-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Sun, 26 Jul 2009 23:07:40 -0700
> o move all tso / checksum offload code into netxen_tso_check().
> o optimize the tso header copy into simple loop.
> o clean up unnecessary unions from cmd_desc_type0 struct.
>
> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Applied.
^ permalink raw reply
* Re: [PATCH NEXT 04/12] netxen: annotate dma watchdog setup
From: David Miller @ 2009-07-27 17:33 UTC (permalink / raw)
To: dhananjay; +Cc: netdev
In-Reply-To: <1248674867-18821-5-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Sun, 26 Jul 2009 23:07:39 -0700
> o remove superfluous code to setup PCI dma watchdog for NX2031.
> o disable dma watchdog completely for NX3031 (not required).
>
> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Applied.
^ permalink raw reply
* Re: [PATCH NEXT 03/12] netxen: configure interrupt coalesce defaults
From: David Miller @ 2009-07-27 17:33 UTC (permalink / raw)
To: dhananjay; +Cc: netdev
In-Reply-To: <1248674867-18821-4-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Sun, 26 Jul 2009 23:07:38 -0700
> Initialize and configure interrupt coalesing defaults
> in the firmware, so that these also reflect in "ethool -c".
>
> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Applied.
^ permalink raw reply
* Re: [PATCH NEXT 02/12] netxen: enable ip addr hashing
From: David Miller @ 2009-07-27 17:33 UTC (permalink / raw)
To: dhananjay; +Cc: netdev, amit
In-Reply-To: <1248674867-18821-3-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Sun, 26 Jul 2009 23:07:37 -0700
> NX3031 hardware requires local IP addresses for packet
> accumulation (LRO). IP address hashing is required to
> distinguish a local TCP flow from others (forwarded or
> guest).
>
> This patch adds listener for IP and netdev events and
> configures IP address in the firmware.
>
> Signed-off-by: Amit Kumar Salecha <amit@netxen.com>
> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Applied.
^ permalink raw reply
* Re: [PATCH NEXT 01/12] netxen: refresh firmware info after reset
From: David Miller @ 2009-07-27 17:33 UTC (permalink / raw)
To: dhananjay; +Cc: netdev
In-Reply-To: <1248674867-18821-2-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Sun, 26 Jul 2009 23:07:36 -0700
> o move dma mask update to netxen_start_firmware() so that
> if firmware changes across suspend (e.g. file -> flash)
> it reflects right dma mask.
> o re-read firmware capabilities after firmware reset.
>
> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Applied.
^ permalink raw reply
* Re: [PATCH NEXT 06/12] netxen: module params for ring sizes
From: David Miller @ 2009-07-27 17:31 UTC (permalink / raw)
To: dhananjay; +Cc: netdev
In-Reply-To: <1248674867-18821-7-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Sun, 26 Jul 2009 23:07:41 -0700
> Add module parameters to set rx, jumbo and tx ring sizes
> globally. 1GbE and 10GbE ports can have different ring
> sizes.
>
> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
We do not add module parameters for stuff like this.
Invoke ethtool early enough, by whatever means, to set
such things as desired.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 5/5] fcoe: Use NETIF_F_FCOE_MTU flag to set up max frame size (lport->mfs)
From: Zou, Yi @ 2009-07-27 16:44 UTC (permalink / raw)
To: David Miller, Love, Robert W
Cc: linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org,
devel-s9riP+hp16TNLxjTenLetw@public.gmane.org,
gospo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, Kirsher, Jeffrey T
In-Reply-To: <20090726.094402.38463748.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
>Subject: Re: [Open-FCoE] [net-next-2.6 PATCH 5/5] fcoe: Use NETIF_F_FCOE_MTU
>flag to set up max frame size (lport->mfs)
>
>From: Robert Love <robert.w.love-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>Date: Thu, 23 Jul 2009 11:48:03 -0700
>
>> Yes, absolutely, but it's only this small patch that creates the
>> dependency. I figured that all of the other fcoe patches could go into
>> James' scsi-misc tree and get merged first. Then this one could go into
>> his scsi-post-merge tree and depend on net-next.
>>
>> It's really up to you and James, I just thought that would be easier.
>
>So I tried to apply just the networking bits but none of the ixgbe
>parts apply properly to net-next-2.6, so this patch series will
>need to be respun and resubmitted in it's entirety so I can
>apply it properly.
>
>It seems that the ixgbe driver now maintains feature flags differently
>than whatever revision of the driver these patches were generated
>against.
>--
>To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks, I will go back and update these patches to sync w/ the current
net-next-2.6. There seem to be patches in net-next-2.6 from net-2.6 after
rebasing which were not there at the time these patches were submitted.
Thanks,
yi
^ permalink raw reply
* Re: [PATCH] net: shrink net_device by #ifdef-ing protocol-specific members
From: Joe Perches @ 2009-07-27 16:33 UTC (permalink / raw)
To: David Miller; +Cc: lgrijincu, netdev, eric.dumazet
In-Reply-To: <20090727.092712.84381944.davem@davemloft.net>
On Mon, 2009-07-27 at 09:27 -0700, David Miller wrote:
> From: Joe Perches <joe@perches.com>
> Date: Mon, 27 Jul 2009 09:23:01 -0700
> > I think the cost of maintaining this is small and the
> > percentage of users that benefit underestimated.
> Prove it.
Cost/bit/knot valuations are arbitrary.
cheers, Joe
^ permalink raw reply
* Re: Kernel oops on setting sky2 interfaces down
From: Stephen Hemminger @ 2009-07-27 16:30 UTC (permalink / raw)
To: Rene Mayrhofer; +Cc: netdev, Richard Leitner
In-Reply-To: <4A6D8975.4050000@gibraltar.at>
On Mon, 27 Jul 2009 13:03:17 +0200
Rene Mayrhofer <rene.mayrhofer@gibraltar.at> wrote:
> Stephen Hemminger schrieb:
> > You could try commenting out sky2_shutdown which does the Wol
> > power down stuff. Maybe changing setting of Wake On Lan would
> > help as well.
> >
> > What happens if you take interface down 'ip link set eth0 down' (or ifconfig)?
> >
> > There are several different register writes in the shutdown path.
> > You could add code to check if a particular access is disabling
> > the PCI buss with:
> >
> > sky2_write(... som register...)
> > BUG_ON(sky2_read16(sky2->hw, B0_CTST) == 0xffff);
>
> I tried adding that wherever it seemed to make sense, resulting in
Does the platform use MSI? Perhaps it generates a bogus interrupt when
powered off.
^ permalink raw reply
* Re: [PATCH] net: shrink net_device by #ifdef-ing protocol-specific members
From: David Miller @ 2009-07-27 16:27 UTC (permalink / raw)
To: joe; +Cc: lgrijincu, netdev, eric.dumazet
In-Reply-To: <1248711781.10463.108.camel@Joe-Laptop.home>
From: Joe Perches <joe@perches.com>
Date: Mon, 27 Jul 2009 09:23:01 -0700
> On Mon, 2009-07-27 at 08:26 -0700, David Miller wrote:
>> From: Lucian Adrian Grijincu <lgrijincu@ixiacom.com>
>> Date: Mon, 27 Jul 2009 18:09:08 +0300
>> > Some members of net_device are used only by some protocols.
>> > If those protocols are not compiled (as modules or linked in) they
>> > should not take up space in the structure.
>> This benefits, at best, %0.000000001 of users of the Linux kernel,
>> because every distribution is going to turn on every single option.
>
> I think the cost of maintaining this is small and the
> percentage of users that benefit underestimated.
Prove it.
Prove that it helps enough to maintain this ifdef abortion in our
header files.
It only gives the false sense of satisfation that we're making our
datastructures less bloated. We're not, and in fact they keep getting
larger, and if we add these ifdefs the new excuse for bloat will be
"but it gets compiled out on embedded et al. builds that don't use
this or that feature."
Putting this crap in is just a big smoke screen which gives a
disincentive for making real improvements in this area.
If I thought this was worthwhile I would have done it 10 years ago.
^ permalink raw reply
* Re: [PATCH] net: shrink net_device by #ifdef-ing protocol-specific members
From: Joe Perches @ 2009-07-27 16:23 UTC (permalink / raw)
To: David Miller; +Cc: lgrijincu, netdev, eric.dumazet
In-Reply-To: <20090727.082644.265102452.davem@davemloft.net>
On Mon, 2009-07-27 at 08:26 -0700, David Miller wrote:
> From: Lucian Adrian Grijincu <lgrijincu@ixiacom.com>
> Date: Mon, 27 Jul 2009 18:09:08 +0300
> > Some members of net_device are used only by some protocols.
> > If those protocols are not compiled (as modules or linked in) they
> > should not take up space in the structure.
> This benefits, at best, %0.000000001 of users of the Linux kernel,
> because every distribution is going to turn on every single option.
I think the cost of maintaining this is small and the
percentage of users that benefit underestimated.
It does help handsets a trivial amount, which are unlikely
to ever enable decnet or econet.
> If you want to shrink structures, find ways to eliminate or
> shrink structure members in all cases.
Good advice.
^ permalink raw reply
* [PATCH 4/12] drivers/net: Correct redundant test
From: Julia Lawall @ 2009-07-27 16:13 UTC (permalink / raw)
To: netdev, linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
res has already been tested. It seems that this test should be on the
recently returned value mmio.
A simplified version of the semantic match that finds this problem is as
follows: (http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@r exists@
local idexpression x;
expression E;
@@
if (x == NULL || ...) { ... when forall
return ...; }
... when != \(x=E\|x--\|x++\|--x\|++x\|x-=E\|x+=E\|x|=E\|x&=E\|&x\)
(
*x == NULL
|
*x != NULL
)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
drivers/net/ethoc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethoc.c b/drivers/net/ethoc.c
index ceb6a9c..4dbe5f1 100644
--- a/drivers/net/ethoc.c
+++ b/drivers/net/ethoc.c
@@ -894,7 +894,7 @@ static int ethoc_probe(struct platform_device *pdev)
mmio = devm_request_mem_region(&pdev->dev, res->start,
res->end - res->start + 1, res->name);
- if (!res) {
+ if (!mmio) {
dev_err(&pdev->dev, "cannot request I/O memory space\n");
ret = -ENXIO;
goto free;
^ permalink raw reply related
* [PATCH 11/12] net/netlabel: Correct redundant test
From: Julia Lawall @ 2009-07-27 16:15 UTC (permalink / raw)
To: paul.moore, netdev, linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
entry was tested for NULL near the beginning of the function, followed by a
return, and there is no intervening modification of its value.
A simplified version of the semantic match that finds this problem is as
follows: (http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@r exists@
local idexpression x;
expression E;
position p1,p2;
@@
if (x == NULL || ...) { ... when forall
return ...; }
... when != \(x=E\|x--\|x++\|--x\|++x\|x-=E\|x+=E\|x|=E\|x&=E\|&x\)
(
*x == NULL
|
*x != NULL
)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
net/netlabel/netlabel_kapi.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
index b0e582f..3ff6f32 100644
--- a/net/netlabel/netlabel_kapi.c
+++ b/net/netlabel/netlabel_kapi.c
@@ -185,8 +185,7 @@ int netlbl_cfg_unlbl_map_add(const char *domain,
return 0;
cfg_unlbl_map_add_failure:
- if (entry != NULL)
- kfree(entry->domain);
+ kfree(entry->domain);
kfree(entry);
kfree(addrmap);
kfree(map4);
@@ -385,8 +384,7 @@ int netlbl_cfg_cipsov4_map_add(u32 doi,
cfg_cipsov4_map_add_failure:
cipso_v4_doi_putdef(doi_def);
- if (entry != NULL)
- kfree(entry->domain);
+ kfree(entry->domain);
kfree(entry);
kfree(addrmap);
kfree(addrinfo);
^ permalink raw reply related
* Re: [PATCH] net/9p: Insulate the client against an invalid error code sent by a 9p server.
From: Abhishek Kulkarni @ 2009-07-27 15:59 UTC (permalink / raw)
To: linux-kernel; +Cc: v9fs-developer, netdev
In-Reply-To: <1248707662-4060-1-git-send-email-adkulkar@umail.iu.edu>
Adding netdev to Cc.
---
A looney tunes server sending an invalid error code (which is !IS_ERR_VALUE)
can result in a client oops. So fix it by adding a check and converting unknown
or invalid error codes to -ESERVERFAULT.
Signed-off-by: Abhishek Kulkarni <adkulkar@umail.iu.edu>
---
:100644 100644 787ccdd... c9a5bf9... M net/9p/client.c
:100644 100644 fdebe43... 5251851... M net/9p/error.c
net/9p/client.c | 7 +------
net/9p/error.c | 2 +-
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/net/9p/client.c b/net/9p/client.c
index 787ccdd..c9a5bf9 100644
--- a/net/9p/client.c
+++ b/net/9p/client.c
@@ -411,14 +411,9 @@ static int p9_check_errors(struct p9_client *c,
struct p9_req_t *req)
if (c->dotu)
err = -ecode;
- if (!err) {
+ if (!err || !IS_ERR_VALUE(err))
err = p9_errstr2errno(ename, strlen(ename));
- /* string match failed */
- if (!err)
- err = -ESERVERFAULT;
- }
-
P9_DPRINTK(P9_DEBUG_9P, "<<< RERROR (%d) %s\n", -ecode, ename);
kfree(ename);
diff --git a/net/9p/error.c b/net/9p/error.c
index fdebe43..5251851 100644
--- a/net/9p/error.c
+++ b/net/9p/error.c
@@ -239,7 +239,7 @@ int p9_errstr2errno(char *errstr, int len)
errstr[len] = 0;
printk(KERN_ERR "%s: server reported unknown error %s\n",
__func__, errstr);
- errno = 1;
+ errno = ESERVERFAULT;
}
return -errno;
--
1.6.0.4
On Mon, Jul 27, 2009 at 9:14 AM, Abhishek Kulkarni<adkulkar@umail.iu.edu> wrote:
> A looney tunes server sending an invalid error code (which is !IS_ERR_VALUE)
> can result in a client oops. So fix it by adding a check and converting unknown
> or invalid error codes to -ESERVERFAULT.
>
> Signed-off-by: Abhishek Kulkarni <adkulkar@umail.iu.edu>
> ---
> :100644 100644 787ccdd... c9a5bf9... M net/9p/client.c
> :100644 100644 fdebe43... 5251851... M net/9p/error.c
> net/9p/client.c | 7 +------
> net/9p/error.c | 2 +-
> 2 files changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/net/9p/client.c b/net/9p/client.c
> index 787ccdd..c9a5bf9 100644
> --- a/net/9p/client.c
> +++ b/net/9p/client.c
> @@ -411,14 +411,9 @@ static int p9_check_errors(struct p9_client *c, struct p9_req_t *req)
> if (c->dotu)
> err = -ecode;
>
> - if (!err) {
> + if (!err || !IS_ERR_VALUE(err))
> err = p9_errstr2errno(ename, strlen(ename));
>
> - /* string match failed */
> - if (!err)
> - err = -ESERVERFAULT;
> - }
> -
> P9_DPRINTK(P9_DEBUG_9P, "<<< RERROR (%d) %s\n", -ecode, ename);
>
> kfree(ename);
> diff --git a/net/9p/error.c b/net/9p/error.c
> index fdebe43..5251851 100644
> --- a/net/9p/error.c
> +++ b/net/9p/error.c
> @@ -239,7 +239,7 @@ int p9_errstr2errno(char *errstr, int len)
> errstr[len] = 0;
> printk(KERN_ERR "%s: server reported unknown error %s\n",
> __func__, errstr);
> - errno = 1;
> + errno = ESERVERFAULT;
> }
>
> return -errno;
> --
> 1.6.0.4
>
>
^ permalink raw reply related
* [RFC][PATCH 3/5] IPVS: make friends with nf_conntrack
From: Hannes Eder @ 2009-07-27 13:46 UTC (permalink / raw)
To: lvs-devel; +Cc: netdev, netfilter-devel, linux-kernel
In-Reply-To: <20090727134457.12897.272.stgit@jazzy.zrh.corp.google.com>
From: Hannes Eder <hannes@hanneseder.net>
We aim at adding full NAT support to IPVS. With this patch it is
possible to use netfilters SNAT in POSTROUTING, especially with
xt_ipvs, e.g.:
iptables -t nat -A POSTROUTING -m ipvs --vaddr 192.168.100.30/32 --vport 8080 \
-j SNAT --to-source 192.168.10.10
There might be other use cases.
Current Status:
- NAT works
- DR works
- IPIP not tested
- overall: needs more testing
- Performance impact?
Signed-off-by: Hannes Eder <heder@google.com>
net/netfilter/ipvs/ip_vs_core.c | 36 ------------------------------------
net/netfilter/ipvs/ip_vs_xmit.c | 28 ++++++++++++++++++++++++++++
2 files changed, 28 insertions(+), 36 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index 8dddb17..b021464 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -518,26 +518,6 @@ int ip_vs_leave(struct ip_vs_service *svc, struct sk_buff *skb,
return NF_DROP;
}
-
-/*
- * It is hooked before NF_IP_PRI_NAT_SRC at the NF_INET_POST_ROUTING
- * chain, and is used for VS/NAT.
- * It detects packets for VS/NAT connections and sends the packets
- * immediately. This can avoid that iptable_nat mangles the packets
- * for VS/NAT.
- */
-static unsigned int ip_vs_post_routing(unsigned int hooknum,
- struct sk_buff *skb,
- const struct net_device *in,
- const struct net_device *out,
- int (*okfn)(struct sk_buff *))
-{
- if (!skb->ipvs_property)
- return NF_ACCEPT;
- /* The packet was sent from IPVS, exit this chain */
- return NF_STOP;
-}
-
__sum16 ip_vs_checksum_complete(struct sk_buff *skb, int offset)
{
return csum_fold(skb_checksum(skb, offset, skb->len - offset, 0));
@@ -1428,14 +1408,6 @@ static struct nf_hook_ops ip_vs_ops[] __read_mostly = {
.hooknum = NF_INET_FORWARD,
.priority = 99,
},
- /* Before the netfilter connection tracking, exit from POST_ROUTING */
- {
- .hook = ip_vs_post_routing,
- .owner = THIS_MODULE,
- .pf = PF_INET,
- .hooknum = NF_INET_POST_ROUTING,
- .priority = NF_IP_PRI_NAT_SRC-1,
- },
#ifdef CONFIG_IP_VS_IPV6
/* After packet filtering, forward packet through VS/DR, VS/TUN,
* or VS/NAT(change destination), so that filtering rules can be
@@ -1464,14 +1436,6 @@ static struct nf_hook_ops ip_vs_ops[] __read_mostly = {
.hooknum = NF_INET_FORWARD,
.priority = 99,
},
- /* Before the netfilter connection tracking, exit from POST_ROUTING */
- {
- .hook = ip_vs_post_routing,
- .owner = THIS_MODULE,
- .pf = PF_INET6,
- .hooknum = NF_INET_POST_ROUTING,
- .priority = NF_IP6_PRI_NAT_SRC-1,
- },
#endif
};
diff --git a/net/netfilter/ipvs/ip_vs_xmit.c b/net/netfilter/ipvs/ip_vs_xmit.c
index 425ab14..f3b6810 100644
--- a/net/netfilter/ipvs/ip_vs_xmit.c
+++ b/net/netfilter/ipvs/ip_vs_xmit.c
@@ -24,6 +24,7 @@
#include <net/ip6_route.h>
#include <linux/icmpv6.h>
#include <linux/netfilter.h>
+#include <net/netfilter/nf_conntrack.h>
#include <linux/netfilter_ipv4.h>
#include <net/ip_vs.h>
@@ -344,6 +345,29 @@ ip_vs_bypass_xmit_v6(struct sk_buff *skb, struct ip_vs_conn *cp,
}
#endif
+static void
+ip_vs_update_conntrack(struct sk_buff *skb, struct ip_vs_conn *cp)
+{
+ if (skb->nfct) {
+ struct nf_conn *ct = (struct nf_conn *)skb->nfct;
+
+ if (ct != &nf_conntrack_untracked && !nf_ct_is_confirmed(ct)) {
+ /*
+ * The connection is not yet in the hashtable, so we
+ * update it. CIP->VIP will remain the same, so leave
+ * the tuple in IP_CT_DIR_ORIGINAL untouched. When the
+ * reply comes back from the real-server we will see
+ * RIP->DIP.
+ */
+
+ ct->tuplehash[IP_CT_DIR_REPLY].tuple.src.u3 = cp->daddr;
+ /* this will also take care for UDP and */
+ ct->tuplehash[IP_CT_DIR_REPLY].tuple.src.u.tcp.port =
+ cp->dport;
+ }
+ }
+}
+
/*
* NAT transmitter (only for outside-to-inside nat forwarding)
* Not used for related ICMP
@@ -399,6 +423,8 @@ ip_vs_nat_xmit(struct sk_buff *skb, struct ip_vs_conn *cp,
IP_VS_DBG_PKT(10, pp, skb, 0, "After DNAT");
+ ip_vs_update_conntrack(skb, cp);
+
/* FIXME: when application helper enlarges the packet and the length
is larger than the MTU of outgoing device, there will be still
MTU problem. */
@@ -475,6 +501,8 @@ ip_vs_nat_xmit_v6(struct sk_buff *skb, struct ip_vs_conn *cp,
IP_VS_DBG_PKT(10, pp, skb, 0, "After DNAT");
+ ip_vs_update_conntrack(skb, cp);
+
/* FIXME: when application helper enlarges the packet and the length
is larger than the MTU of outgoing device, there will be still
MTU problem. */
^ permalink raw reply related
* [RFC][PATCH 4/5] IPVS: debugging output for ip_vs_update_conntrack
From: Hannes Eder @ 2009-07-27 13:46 UTC (permalink / raw)
To: lvs-devel; +Cc: netdev, netfilter-devel, linux-kernel
In-Reply-To: <20090727134457.12897.272.stgit@jazzy.zrh.corp.google.com>
This patch is not ment to be merged, its mere for debugging during
development.
Signed-off-by: Hannes Eder <heder@google.com>
net/netfilter/ipvs/ip_vs_xmit.c | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_xmit.c b/net/netfilter/ipvs/ip_vs_xmit.c
index f3b6810..ed6b811 100644
--- a/net/netfilter/ipvs/ip_vs_xmit.c
+++ b/net/netfilter/ipvs/ip_vs_xmit.c
@@ -24,6 +24,7 @@
#include <net/ip6_route.h>
#include <linux/icmpv6.h>
#include <linux/netfilter.h>
+#define DEBUG
#include <net/netfilter/nf_conntrack.h>
#include <linux/netfilter_ipv4.h>
@@ -345,12 +346,31 @@ ip_vs_bypass_xmit_v6(struct sk_buff *skb, struct ip_vs_conn *cp,
}
#endif
+#ifdef DEBUG
+static void
+ip_vs_dump_ct_tuple(const struct nf_conntrack_tuple *t)
+{
+ /*
+ * We ignore the fact that this is not SMP-safe. Otherwise we would
+ * have to duplicate code and this code is not ment to stay here anyway.
+ */
+ printk(KERN_DEBUG "IPVS: ");
+ nf_ct_dump_tuple(t);
+}
+#endif
+
static void
ip_vs_update_conntrack(struct sk_buff *skb, struct ip_vs_conn *cp)
{
if (skb->nfct) {
struct nf_conn *ct = (struct nf_conn *)skb->nfct;
+#ifdef DEBUG
+ ip_vs_dump_ct_tuple(&ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple);
+ ip_vs_dump_ct_tuple(&ct->tuplehash[IP_CT_DIR_REPLY].tuple);
+ printk("IPVS: nfct confirmed=%d\n", nf_ct_is_confirmed(ct));
+#endif
+
if (ct != &nf_conntrack_untracked && !nf_ct_is_confirmed(ct)) {
/*
* The connection is not yet in the hashtable, so we
@@ -365,6 +385,12 @@ ip_vs_update_conntrack(struct sk_buff *skb, struct ip_vs_conn *cp)
ct->tuplehash[IP_CT_DIR_REPLY].tuple.src.u.tcp.port =
cp->dport;
}
+
+#ifdef DEBUG
+ ip_vs_dump_ct_tuple(&ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple);
+ ip_vs_dump_ct_tuple(&ct->tuplehash[IP_CT_DIR_REPLY].tuple);
+#endif
+
}
}
^ permalink raw reply related
* [RFC][PATCH 2/5] netfilter: xt_ipvs (netfilter matcher for ipvs)
From: Hannes Eder @ 2009-07-27 13:46 UTC (permalink / raw)
To: lvs-devel; +Cc: netdev, netfilter-devel, linux-kernel
In-Reply-To: <20090727134457.12897.272.stgit@jazzy.zrh.corp.google.com>
From: Hannes Eder <hannes@hanneseder.net>
This implements the kernel-space side of the iptables matcher xt_ipvs.
Signed-off-by: Hannes Eder <heder@google.com>
include/linux/netfilter/xt_ipvs.h | 32 +++++++
net/netfilter/Kconfig | 8 ++
net/netfilter/Makefile | 1
net/netfilter/ipvs/ip_vs_proto.c | 1
net/netfilter/xt_ipvs.c | 171 +++++++++++++++++++++++++++++++++++++
5 files changed, 213 insertions(+), 0 deletions(-)
create mode 100644 include/linux/netfilter/xt_ipvs.h
create mode 100644 net/netfilter/xt_ipvs.c
diff --git a/include/linux/netfilter/xt_ipvs.h b/include/linux/netfilter/xt_ipvs.h
new file mode 100644
index 0000000..3a70289
--- /dev/null
+++ b/include/linux/netfilter/xt_ipvs.h
@@ -0,0 +1,32 @@
+#ifndef _XT_IPVS_H
+#define _XT_IPVS_H 1
+
+#ifndef _IP_VS_H
+#define IP_VS_CONN_F_FWD_MASK 0x0007 /* mask for the fwd methods */
+#define IP_VS_CONN_F_MASQ 0x0000 /* masquerading/NAT */
+#define IP_VS_CONN_F_LOCALNODE 0x0001 /* local node */
+#define IP_VS_CONN_F_TUNNEL 0x0002 /* tunneling */
+#define IP_VS_CONN_F_DROUTE 0x0003 /* direct routing */
+#define IP_VS_CONN_F_BYPASS 0x0004 /* cache bypass */
+#endif
+
+#define XT_IPVS_IPVS 0x01 /* this is implied by all other options */
+#define XT_IPVS_PROTO 0x02
+#define XT_IPVS_VADDR 0x04
+#define XT_IPVS_VPORT 0x08
+#define XT_IPVS_DIR 0x10
+#define XT_IPVS_METHOD 0x20
+#define XT_IPVS_MASK (0x40 - 1)
+#define XT_IPVS_ONCE_MASK (XT_IPVS_MASK & ~XT_IPVS_IPVS)
+
+struct xt_ipvs {
+ union nf_inet_addr vaddr, vmask;
+ __be16 vport;
+ u_int16_t l4proto;
+ u_int16_t fwd_method;
+
+ u_int8_t invert;
+ u_int8_t bitmask;
+};
+
+#endif /* _XT_IPVS_H */
diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index cb3ad74..677a880 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -678,6 +678,14 @@ config NETFILTER_XT_MATCH_IPRANGE
If unsure, say M.
+config NETFILTER_XT_MATCH_IPVS
+ tristate '"ipvs" match support'
+ depends on NETFILTER_ADVANCED
+ help
+ This option allows you to match against ipvs properties of a packet.
+
+ To compile it as a module, choos M here. If unsure, say N.
+
config NETFILTER_XT_MATCH_LENGTH
tristate '"length" match support'
depends on NETFILTER_ADVANCED
diff --git a/net/netfilter/Makefile b/net/netfilter/Makefile
index 6282060..1c18e80 100644
--- a/net/netfilter/Makefile
+++ b/net/netfilter/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_NETFILTER_XT_MATCH_HASHLIMIT) += xt_hashlimit.o
obj-$(CONFIG_NETFILTER_XT_MATCH_HELPER) += xt_helper.o
obj-$(CONFIG_NETFILTER_XT_MATCH_HL) += xt_hl.o
obj-$(CONFIG_NETFILTER_XT_MATCH_IPRANGE) += xt_iprange.o
+obj-$(CONFIG_NETFILTER_XT_MATCH_IPVS) += xt_ipvs.o
obj-$(CONFIG_NETFILTER_XT_MATCH_LENGTH) += xt_length.o
obj-$(CONFIG_NETFILTER_XT_MATCH_LIMIT) += xt_limit.o
obj-$(CONFIG_NETFILTER_XT_MATCH_MAC) += xt_mac.o
diff --git a/net/netfilter/ipvs/ip_vs_proto.c b/net/netfilter/ipvs/ip_vs_proto.c
index a01520e..84bf4e6 100644
--- a/net/netfilter/ipvs/ip_vs_proto.c
+++ b/net/netfilter/ipvs/ip_vs_proto.c
@@ -94,6 +94,7 @@ struct ip_vs_protocol * ip_vs_proto_get(unsigned short proto)
return NULL;
}
+EXPORT_SYMBOL(ip_vs_proto_get);
/*
diff --git a/net/netfilter/xt_ipvs.c b/net/netfilter/xt_ipvs.c
new file mode 100644
index 0000000..00373d9
--- /dev/null
+++ b/net/netfilter/xt_ipvs.c
@@ -0,0 +1,171 @@
+/*
+ * xt_ipvs - kernel module to match ipvs properties of a packet
+ *
+ * Author: Hannes Eder <heder@google.com>
+ */
+
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/spinlock.h>
+#include <linux/skbuff.h>
+#ifdef CONFIG_IP_VS_IPV6
+#include <net/ipv6.h>
+#endif
+#include <linux/types.h>
+#include <linux/netfilter/x_tables.h>
+#include <linux/netfilter/xt_ipvs.h>
+
+#include <net/ip_vs.h>
+
+MODULE_AUTHOR("Hannes Eder <heder@google.com>");
+MODULE_DESCRIPTION("Xtables: match ipvs");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("ipt_ipvs");
+MODULE_ALIAS("ip6t_ipvs");
+
+/* borrowed from xt_conntrack */
+static bool ipvs_mt_addrcmp(const union nf_inet_addr *kaddr,
+ const union nf_inet_addr *uaddr,
+ const union nf_inet_addr *umask,
+ unsigned int l3proto)
+{
+ if (l3proto == NFPROTO_IPV4)
+ return ((kaddr->ip ^ uaddr->ip) & umask->ip) == 0;
+#ifdef CONFIG_IP_VS_IPV6
+ else if (l3proto == NFPROTO_IPV6)
+ return ipv6_masked_addr_cmp(&kaddr->in6, &umask->in6,
+ &uaddr->in6) == 0;
+#endif
+ else
+ return false;
+}
+
+bool ipvs_mt(const struct sk_buff *skb, const struct xt_match_param *par)
+{
+ const struct xt_ipvs *data = par->matchinfo;
+ const u_int8_t family = par->family;
+ struct ip_vs_iphdr iph;
+ struct ip_vs_protocol *pp;
+ struct ip_vs_conn *cp;
+ int af;
+ bool match = true;
+
+ if (data->bitmask == XT_IPVS_IPVS) {
+ match = !!(skb->ipvs_property)
+ ^ !!(data->invert & XT_IPVS_IPVS);
+ goto out;
+ }
+
+ /* other flags than XT_IPVS_IPVS are set */
+ if (!skb->ipvs_property) {
+ match = false;
+ goto out;
+ }
+
+ switch (skb->protocol) {
+ case htons(ETH_P_IP):
+ af = AF_INET;
+ break;
+#ifdef CONFIG_IP_VS_IPV6
+ case htons(ETH_P_IPV6):
+ af = AF_INET6;
+ break;
+#endif
+ default:
+ match = false;
+ goto out;
+ }
+
+ ip_vs_fill_iphdr(af, skb_network_header(skb), &iph);
+
+ if (data->bitmask & XT_IPVS_PROTO)
+ if ((iph.protocol == data->l4proto)
+ ^ !(data->invert & XT_IPVS_PROTO)) {
+ match = false;
+ goto out;
+ }
+
+ pp = ip_vs_proto_get(iph.protocol);
+ if (unlikely(!pp)) {
+ match = false;
+ goto out;
+ }
+
+ /*
+ * Check if the packet belongs to an existing entry
+ */
+ /* TODO: why does it only match in inverse? */
+ cp = pp->conn_out_get(af, skb, pp, &iph, iph.len, 1 /* inverse */);
+ if (unlikely(!cp)) {
+ match = false;
+ goto out;
+ }
+
+ /*
+ * We found a connection, i.e. ct != 0, make sure to call
+ * __ip_vs_conn_put before returning. In our case jump to out_put_con.
+ */
+
+ if (data->bitmask & XT_IPVS_VPORT)
+ if ((cp->vport == data->vport)
+ ^ !(data->invert & XT_IPVS_VPORT)) {
+ match = false;
+ goto out_put_ct;
+ }
+
+ if (data->bitmask & XT_IPVS_DIR) {
+ /* TODO: implement */
+ }
+
+ if (data->bitmask & XT_IPVS_METHOD)
+ if (((cp->flags & IP_VS_CONN_F_FWD_MASK) == data->fwd_method)
+ ^ !(data->invert & XT_IPVS_METHOD)) {
+ match = false;
+ goto out_put_ct;
+ }
+
+ if (data->bitmask & XT_IPVS_VADDR) {
+ if (af != family) {
+ match = false;
+ goto out_put_ct;
+ }
+
+ if (ipvs_mt_addrcmp(&cp->vaddr, &data->vaddr, &data->vmask, af)
+ ^ !(data->invert & XT_IPVS_VADDR)) {
+ match = false;
+ goto out_put_ct;
+ }
+ }
+
+out_put_ct:
+ __ip_vs_conn_put(cp);
+out:
+ return match;
+}
+EXPORT_SYMBOL(ipvs_mt);
+
+static struct xt_match xt_ipvs_mt_reg[] __read_mostly = {
+ {
+ .name = "ipvs",
+ .revision = 0,
+ .family = NFPROTO_UNSPEC,
+ .match = ipvs_mt,
+ .matchsize = sizeof(struct xt_ipvs),
+ .me = THIS_MODULE,
+ },
+};
+
+static int __init ipvs_mt_init(void)
+{
+ return xt_register_matches(xt_ipvs_mt_reg,
+ ARRAY_SIZE(xt_ipvs_mt_reg));
+}
+
+static void __exit ipvs_mt_exit(void)
+{
+ xt_unregister_matches(xt_ipvs_mt_reg,
+ ARRAY_SIZE(xt_ipvs_mt_reg));
+}
+
+module_init(ipvs_mt_init);
+module_exit(ipvs_mt_exit);
^ permalink raw reply related
* Re: net-next-2.6 phonet causes build error
From: Oliver Hartkopp @ 2009-07-27 15:30 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: David Miller, remi.denis-courmont, netdev
In-Reply-To: <1248707909.28545.200.camel@violet>
Marcel Holtmann wrote:
> Hi Dave,
>
>>>> net/phonet/pn_dev.c: In function ‘phonet_init_net’:
>>>> net/phonet/pn_dev.c:221: error: implicit declaration of function
>>>> ‘proc_net_fops_create’
>>>> net/phonet/pn_dev.c: In function ‘phonet_exit_net’:
>>>> net/phonet/pn_dev.c:242: error: implicit declaration of function
>>>> ‘proc_net_remove’
>>> Oops. This makes me wonder why I did not get that one here on my test
>>> builds???
>> Because the headers on your platform with your configuration end up
>> including linux/proc_fs.h indirectly.
>
> this and similar automatic includes on x86 are still a problem. I always
> try to compile test with a PPC based system, but even that architecture
> has a lot of indirect includes. I would be happy if we could get rid of
> these for x86 systems, but that seems a little bit wishful thinking.
>
I second this. But in this special case i was using a x86 architecture, that
behaved correct.
Maybe one of the script wizards has an idea how to identify and /probably/ fix
these automatic includes ...
Regards,
Oliver
^ permalink raw reply
* Re: net-next-2.6 phonet causes build error
From: David Miller @ 2009-07-27 15:30 UTC (permalink / raw)
To: marcel; +Cc: remi.denis-courmont, netdev
In-Reply-To: <1248707909.28545.200.camel@violet>
From: Marcel Holtmann <marcel@holtmann.org>
Date: Mon, 27 Jul 2009 17:18:29 +0200
> Hi Dave,
>
>> >> net/phonet/pn_dev.c: In function ‘phonet_init_net’:
>> >> net/phonet/pn_dev.c:221: error: implicit declaration of function
>> >> ‘proc_net_fops_create’
>> >> net/phonet/pn_dev.c: In function ‘phonet_exit_net’:
>> >> net/phonet/pn_dev.c:242: error: implicit declaration of function
>> >> ‘proc_net_remove’
>> >
>> > Oops. This makes me wonder why I did not get that one here on my test
>> > builds???
>>
>> Because the headers on your platform with your configuration end up
>> including linux/proc_fs.h indirectly.
>
> this and similar automatic includes on x86 are still a problem. I always
> try to compile test with a PPC based system, but even that architecture
> has a lot of indirect includes. I would be happy if we could get rid of
> these for x86 systems, but that seems a little bit wishful thinking.
I always do an allmodconfig build on sparc64 before pushing anything
out to my trees so I'm surprised I didn't hit this one.
^ permalink raw reply
* Re: [PATCH] net: shrink net_device by #ifdef-ing protocol-specific members
From: David Miller @ 2009-07-27 15:26 UTC (permalink / raw)
To: lgrijincu; +Cc: netdev, eric.dumazet
In-Reply-To: <4A6DC314.2010303@ixiacom.com>
From: Lucian Adrian Grijincu <lgrijincu@ixiacom.com>
Date: Mon, 27 Jul 2009 18:09:08 +0300
> Some members of net_device are used only by some protocols.
>
> If those protocols are not compiled (as modules or linked in) they
> should not take up space in the structure.
This benefits, at best, %0.000000001 of users of the Linux kernel,
because every distribution is going to turn on every single option.
If you want to shrink structures, find ways to eliminate or
shrink structure members in all cases.
I'm not applying this.
^ 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