* Re: RFC: New BPF 'LOOP' instruction
From: Paul LeoNerd Evans @ 2010-08-03 14:13 UTC (permalink / raw)
To: Rémi Denis-Courmont, netdev
In-Reply-To: <72ff93eb4581b198faa6ce62d2b5162b@chewa.net>
[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]
On Tue, Aug 03, 2010 at 04:09:53PM +0200, Rémi Denis-Courmont wrote:
>
> On Tue, 3 Aug 2010 14:34:43 +0100, Paul LeoNerd Evans
> <leonerd@leonerd.org.uk> wrote:
> > What if we added a new constant SKF_TRANS_OFF to store the start address
> > of the transport header, and a new SKF_AD storage area for the transport
> > protocol:
> (...)
> > Does this sound workable?
>
> The network header has not been processed by the time the skbuff hits the
> packet socket. So the transport header offset is not defined yet.
Is there any way it could be done lazily, at the moment that filter.c
knows it has to provide either SKF_TRANS_OFF or SKF_AD_TRANSPROTO? It
doesn't even need to do a full parse, just enough to find the length and
protocol type.
That processing -has- to be done one way or another, if BPF is ever to
support filtering on TCP headers in IPv6 in a sane way. Either encode
the algorithm in BPF, or in compiled C code - the latter would be more
performant.
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: RFC: New BPF 'LOOP' instruction
From: Rémi Denis-Courmont @ 2010-08-03 14:16 UTC (permalink / raw)
To: Paul LeoNerd Evans; +Cc: netdev
In-Reply-To: <20100803141313.GU11110@cel.leo>
On Tue, 3 Aug 2010 15:13:13 +0100, Paul LeoNerd Evans
<leonerd@leonerd.org.uk> wrote:
> Is there any way it could be done lazily, at the moment that filter.c
> knows it has to provide either SKF_TRANS_OFF or SKF_AD_TRANSPROTO?
You would essentially need to implement dedicated parsing for each
protocols family.
So you might as well add an opcode dedicated to IPv6...
--
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis
^ permalink raw reply
* Re: RFC: New BPF 'LOOP' instruction
From: Paul LeoNerd Evans @ 2010-08-03 14:19 UTC (permalink / raw)
To: Rémi Denis-Courmont, netdev
In-Reply-To: <f350f48de92da479bfb224527bc70c10@chewa.net>
[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]
On Tue, Aug 03, 2010 at 04:16:02PM +0200, Rémi Denis-Courmont wrote:
> > Is there any way it could be done lazily, at the moment that filter.c
> > knows it has to provide either SKF_TRANS_OFF or SKF_AD_TRANSPROTO?
>
> You would essentially need to implement dedicated parsing for each
> protocols family.
> So you might as well add an opcode dedicated to IPv6...
And what happens when IPv8 comes along? Or we want to parse IPX/SPX or
any of those thousands of other network protocols?
I'd prefer to keep the BPF layer (relatively) protocol-neutral. Yes, we
have LDX MSH which with hindsight I'd say looks like a very
protocol-specific instruction. But there's nothing protocol-specific
about asking for where the transport header is and what type it is, no
moreso than asking where the network offset and type are, out of the
link-level header. This just extends that layer model.
How to -implement- it is quite another matter.
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH 2/8] davinci: add mdio platform devices
From: Cyril Chemparathy @ 2010-08-03 14:32 UTC (permalink / raw)
To: Igor Grinberg
Cc: netdev@vger.kernel.org,
davinci-linux-open-source@linux.davincidsp.com,
linux-omap@vger.kernel.org, Nori, Sekhar,
Govindarajan, Sriramakrishnan
In-Reply-To: <4C58227A.4080502@compulab.co.il>
Hi Igor,
> Shouldn't arch/arm/mach-omap2/board-am3517evm.c be on your list?
> I think it should, or else it will be broken by:
> [PATCH 5/8] netdev: cleanup unused davinci mdio emac code
Correct. As stated in the series summary:
> Additional omap tree patches will be required for am35xx as well
> (not included here).
Regards
Cyril.
^ permalink raw reply
* Re: RFC: New BGF 'LOOP' instruction
From: Paul LeoNerd Evans @ 2010-08-03 14:34 UTC (permalink / raw)
To: Andi Kleen, netdev; +Cc: David Miller
In-Reply-To: <20100803141110.GT11110@cel.leo>
[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]
On Tue, Aug 03, 2010 at 03:11:10PM +0100, Paul LeoNerd Evans wrote:
> switch(hdrtype)
> {
> case 1:
> length = someconst; break;
> case 2:
> length = someotherconst; break;
> case 3:
> length = b[someoffset]; break;
> ...
> }
Of course, I completely forgot about finding also the offset of the
'next header' from the current header. That results in some code which,
in C, would look like:
int hdrtype = b[IPv6_nexthdr];
int x = size_of_IPv6_header;
while(hdrtype != hdr_wanted) {
int len;
switch(hdrtype) {
case 1:
len = someconst;
hdrtype = someotherconst;
break;
case 2:
len = b[x+someoffs];
hdrtype = b[x+someotheroffs];
break;
/* other IPv6 header types here */
}
x += len;
}
You can't compile that idea into BPF without using a scratch memory
cell, because you can't have both 'len' and 'hdrtype' live in A at the
same time, nor can you atomically x += b[x+someoffs].
In short, much much easier if the C code did this part...
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [patch] usbnet: fix 100% CPU use on suspended device
From: Oliver Neukum @ 2010-08-03 14:39 UTC (permalink / raw)
To: Elly Jones
Cc: Alan Stern, David Miller, netdev-u79uwXL29TY76Z2rM5mHXA, USB list
In-Reply-To: <AANLkTi=KbThErL-jXXSVGdkod-p7B7u6eDL5LtnU5SG--JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Am Montag, 2. August 2010, 15:31:33 schrieb Elly Jones:
> On Mon, Jul 26, 2010 at 12:21 PM, Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org> wrote:
> > Am Montag, 26. Juli 2010, 17:13:23 schrieb Alan Stern:
> >> On Mon, 26 Jul 2010, Elly Jones wrote:
> >>
> >> > > This isn't right. The problem should be fixed some other way. Under
> >> > > what circumstances are URBs submitted incorrectly?
> >> >
> >> > When the device is autosuspended. What is the proper thing for a
> >> > device to do here?
> >>
> >> From looking at the code, it appears that the EVENT_DEV_ASLEEP flag
> >> should be tested in usbnet_bh() the way it is in rx_submit(). But I'm
> >> not an expert on usbnet; we should ask someone who is, like Oliver.
> >
> > Sorry, I didn't notice this thread.
> >
> > The correct way to check for autosuspend in usbnet is to look
> > at EVENT_DEV_ASLEEP under txq.lock. That being said, usbnet_bh()
> > uses rx_submit() which does the correct check. The bug seems to be
> > a lack of error handling in usbnet_bh() regarding the return of rx_submit()
>
> If rx_submit() fails, should usbnet_bh() just not tasklet_schedule() itself?
That would not work unless the cause of the failure would be removed.
If you get -ENOLINK the sane option seems to me to give up.
Regards
Oliver
--
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 net-next 3/3] drivers/net/bfin_mac.c: Misc function cleanups, neatening
From: Denis Kirjanov @ 2010-08-03 14:48 UTC (permalink / raw)
To: Robin Getz
Cc: Joe Perches, Mike Frysinger, Hennerich, Michael,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <201008030940.28831.rgetz@blackfin.uclinux.org>
On Tue, Aug 3, 2010 at 5:40 PM, Robin Getz <rgetz@blackfin.uclinux.org> wrote:
> On Thu 29 Jul 2010 21:45, Joe Perches pondered:
>> On Thu, 2010-07-29 at 20:18 -0400, Mike Frysinger wrote:
>> > i'll ack the idea, but i think it better i pull these patches into the
>> > Blackfin repo to get some real hardware testing before i forward them
>> > back to David/netdev ...
>> >
>> > that OK with you ?
>>
>> Fine by me. These are trivial patches.
>> I don't have the hardware.
>
> Do you want the hardware?
>
> I'm moving my office, and found some extras if anyone wants them...
I can take one if that is no problem..
>
> -Robin
> --
> 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
>
--
Regards,
Denis
^ permalink raw reply
* [ANNOUNCE]: Release of iptables-1.4.9
From: Patrick McHardy @ 2010-08-03 15:17 UTC (permalink / raw)
To: Netfilter Development Mailinglist
Cc: Linux Netdev List, 'netfilter@vger.kernel.org',
netfilter-announce
[-- Attachment #1: Type: text/plain, Size: 769 bytes --]
The netfilter coreteam presents:
iptables version 1.4.9
the iptables release for the 2.6.35 kernel. Changes include:
- support for the LED target, which hadn't been merged so far because
the kernel module had some bugs
- a new version of the set extension for the upcoming release supporting
IPv6
- negation support for the quota match
- support for the SACK-IMMEDIATELY SCTP extension and FORWARD_TSN
chunk type in the sctp match
- documentation updates and various smaller bugfixes
See the Changelog for more details.
Version 1.4.9 can be obtained from:
http://www.netfilter.org/projects/iptables/downloads.html
ftp://ftp.netfilter.org/pub/iptables/
git://git.netfilter.org/iptables.git
On behalf of the Netfilter Core Team.
Happy firewalling!
[-- Attachment #2: changes-iptables-1.4.9.txt --]
[-- Type: text/plain, Size: 1338 bytes --]
Adam Nielsen (1):
extensions: add the LED target
Eric Dumazet (1):
extensions: REDIRECT: add random help
Jan Engelhardt (10):
utils: add missing include flags to Makefile
doc: xt_string: correct copy-and-pasting in manpage
doc: xt_hashlimit: fix a typo
doc: xt_LED: nroff formatting requirements
includes: sync header files from Linux 2.6.35-rc1
xtables: another try at chain name length checking
xtables: remove xtables_set_revision function
libxt_hashlimit: always print burst value
libxt_conntrack: do print netmask
xt_quota: also document negation
Jozsef Kadlecsik (1):
libxt_set: new revision added
Luciano Coelho (2):
extensions: libxt_rateest: fix typo in the man page
extensions: libxt_rateest: fix bps options for iptables-save
Patrick McHardy (5):
Revert "Revert "Merge branch 'iptables-next'""
Merge branch 'master' of git://dev.medozas.de/iptables
Merge branch 'master' of git://dev.medozas.de/iptables
Merge branch 'master' of vishnu.netfilter.org:/data/git/iptables
Bump version to 1.4.9
Samuel Ortiz (1):
extensions: libxt_quota.c: Support option negation
Shan Wei (2):
xt_sctp: Trace DATA chunk that supports SACK-IMMEDIATELY extension
xt_sctp: support FORWARD_TSN chunk type
^ permalink raw reply
* Re: RFC: New BPF 'LOOP' instruction
From: Rémi Denis-Courmont @ 2010-08-03 15:17 UTC (permalink / raw)
To: netdev
In-Reply-To: <20100803141924.GV11110@cel.leo>
Le mardi 3 août 2010 17:19:24 Paul LeoNerd Evans, vous avez écrit :
> On Tue, Aug 03, 2010 at 04:16:02PM +0200, Rémi Denis-Courmont wrote:
> > > Is there any way it could be done lazily, at the moment that filter.c
> > > knows it has to provide either SKF_TRANS_OFF or SKF_AD_TRANSPROTO?
> >
> > You would essentially need to implement dedicated parsing for each
> > protocols family.
> > So you might as well add an opcode dedicated to IPv6...
>
> And what happens when IPv8 comes along?
> Or we want to parse IPX/SPX or
> any of those thousands of other network protocols?
It does not work. That's why your SKB_TRANS_OFF proposal sucks totally because
it is not implementable. On the other hand, n IPv6-specific opcode sucks only
a little due to its ugliness and lack of forward compatibility.
--
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis
^ permalink raw reply
* Re: [PATCH] can-raw: Fix skb_orphan_try handling
From: Oliver Hartkopp @ 2010-08-03 15:22 UTC (permalink / raw)
To: David Miller
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
patrick.ohly-ral2JQCrhuEAvxtiuMwx3w,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20100803.003056.216763358.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On 03.08.2010 09:30, David Miller wrote:
> From: Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
> Date: Sun, 01 Aug 2010 12:50:16 +0200
>
>> On 01.08.2010 10:03, David Miller wrote:
>>> From: Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
>>> Date: Fri, 30 Jul 2010 11:44:27 +0200
>>>
>>>> Hello Eric, hello Patrick,
>>>>
>>>> Commit fc6055a5ba31e2c14e36e8939f9bf2b6d586a7f5 (net: Introduce
>>>> skb_orphan_try()) allows an early orphan of the skb and takes care on
>>>> tx timestamping, which needs the sk-reference in the skb on driver level.
>>>> So does the can-raw socket, which has not been taken into account here.
>>>>
>>>> The patch below adds a 'prevent_sk_orphan' bit in the skb tx shared info,
>>>> which fixes the problem discovered by Matthias Fuchs here:
>>>>
>>>> http://marc.info/?t=128030411900003&r=1&w=2
>>>
>>> Your patch sets this new value, but I never see it getting tested anywhere.
>>>
>>> How does this work?
>>
>>
>> The flags are tested all together in skb_orphan_try() ...
>
> This is why I hate using unions in situations like this... it makes
> code impossible to audit easily.
>
> This damn thing should just be a "u8 flags" and a bunch of bit mask
> CPP macro defines for the various boolean values.
Yep! I also felt like this.
Maybe Patrick Ohly can give some feedback, if he's ok with that kind of
change. So far there are only a few places that would need to be changed for
the flags bitops.
> Anyways, I'll apply your patch thanks.
Thanks!
^ permalink raw reply
* Re: softirq warnings when calling dev_kfree_skb_irq - bug in conntrack?
From: Jeremy Fitzhardinge @ 2010-08-03 15:24 UTC (permalink / raw)
To: David Miller
Cc: johannes, netdev, dongxiao.xu, Xen-devel, Ian.Campbell, kaber,
eric.dumazet
In-Reply-To: <20100803.002318.209965574.davem@davemloft.net>
On 08/03/2010 12:23 AM, David Miller wrote:
> From: Johannes Berg<johannes@sipsolutions.net>
> Date: Tue, 03 Aug 2010 09:04:34 +0200
>
>> I had this too:
>> http://article.gmane.org/gmane.linux.network/167590
>>
>> But I'm not convinced it's conntrack, I'd think it's
>>
>> commit 15e83ed78864d0625e87a85f09b297c0919a4797
>> Author: Eric Dumazet<eric.dumazet@gmail.com>
>> Date: Wed May 19 23:16:03 2010 +0000
>>
>> net: remove zap_completion_queue
>>
>> which, from the looks of it, ought to be reverted because it failed to
>> take into account that dev_kfree_skb() can do more things that require
>> non-irq-context than just calling skb->destructor, like for instance the
>> conntrack thing we see here.
> Agreed. I'll revert this and queue that up for 2.6.35-stable
>
FWIW I only see this in linux-next, not released 2.6.35. But it does
look like a likely root cause.
J
^ permalink raw reply
* Re: RFC: New BPF 'LOOP' instruction
From: Paul LeoNerd Evans @ 2010-08-03 15:27 UTC (permalink / raw)
To: Rémi Denis-Courmont, netdev
In-Reply-To: <201008031817.40664.remi@remlab.net>
[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]
On Tue, Aug 03, 2010 at 06:17:40PM +0300, Rémi Denis-Courmont wrote:
> > And what happens when IPv8 comes along?
> > Or we want to parse IPX/SPX or
> > any of those thousands of other network protocols?
>
> It does not work. That's why your SKB_TRANS_OFF proposal sucks totally because
> it is not implementable. On the other hand, n IPv6-specific opcode sucks only
> a little due to its ugliness and lack of forward compatibility.
Huh? So now you want to make every BPF program IPv6-specific, so we've
no hope in hell of making them cope with The Next Big Thing? As opposed
to my idea, which makes them neutral on the subject, and puts all the
knowledge of the protocol in the -kernel-, where we can easily implement
new things?
When some brandnew protocol comes long we'd like to filter on, kernel is
going to have to know about it. Which is -exactly- the same as the
current situation with regards SKF_NET_OFF / SKF_AD_PROTO, so I don't
really see what difference that makes.
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* [PATCH] about net/core/pktgen.c module.
From: ustc.mail @ 2010-08-03 15:20 UTC (permalink / raw)
To: robert, netdev; +Cc: robert.olsson
Hi,
I find that there is a bug in the pktgen kernel packet generator. It's
my first time to add a patch, so welcome to give me suggestion about
patch work.
description: the bug makes the first generated packets (one or more
which depend on the configuration from usespace script.)enter to the
same NIC queue of multi-queue NIC for the wrong position of
mod_cur_headers(pkt_dev) call while building the IPV4 and IPV6
skb_buff.
kernel version: linux-2.6.33.3
file: linux-2.6.33.3/net/core/pktgen.c
result: while setting skb_clone more than one, specially for a
considerable number, the multiqueue function is not efficient for its
wrong queue_map value.
patch as following:
--- pktgen.c 2010-08-03 22:46:55.001682745 +0800
+++ pktgen.patch.c 2010-08-03 22:48:03.367409102 +0800
@@ -2567,8 +2567,8 @@
/* Update any of the values, used when we're incrementing various
* fields.
*/
- queue_map = pkt_dev->cur_queue_map;
mod_cur_headers(pkt_dev);
+ queue_map = pkt_dev->cur_queue_map;
datalen = (odev->hard_header_len + 16) & ~0xf;
skb = __netdev_alloc_skb(odev,
@@ -2913,8 +2913,8 @@
/* Update any of the values, used when we're incrementing various
* fields.
*/
- queue_map = pkt_dev->cur_queue_map;
mod_cur_headers(pkt_dev);
+ queue_map = pkt_dev->cur_queue_map;
skb = __netdev_alloc_skb(odev,
pkt_dev->cur_pkt_size + 64
--------------------------------------patch
end-------------------------------------------------
Best regards!
from backyes
---------------------------------------reply
end-------------------------------------------------
On Tue, Aug 3, 2010 at 10:30 PM, ustc.mail <backyes@mail.ustc.edu.cn> wrote:
> Thanks for your reply!
> It's my pleasure to patch it.
> -Yanfei
>
> On Tue, Aug 3, 2010 at 7:44 PM, <robert@herjulf.net> wrote:
>>
>> > Dear robert, I am doing some research on the
>> >pktgen.c implementation. While reading the source code, I find some
>> >doubts about cur->cur_queue_map for multiqueue NIC . The following
>> >code is from pktgen.c in kernel 2.6.33.3. For line 2919 and line
>> >2920, the first generated packets is sent to same queue of NIC for
>> >every thread. Because the the first generated packets is sent while
>> >the cur_queue_map is not setted yet. "reverse the two line" is OK.
>> >Am I right?
>>
>> Right first time we're using queue_map that's not been set by
>> set_cur_queue_map(pkt_dev);
>>
>> queue_map = pkt_dev->cur_queue_map;
>> mod_cur_headers(pkt_dev);
>>
>> Can you make a patch and submit to netdev?
>>
>>
>> --ro
>>
>
>
^ permalink raw reply
* [PATCH] hso: Add new product ID
From: Filip Aben @ 2010-08-03 15:36 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q, gregkh-l3A5Bk7waGM
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
This patch adds a new product ID to the hso driver.
Signed-off-by: Filip Aben <f.aben-x9gZzRpC1QbQT0dZR+AlfA@public.gmane.org>
---
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index 4dd2351..041f0e3 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -478,6 +478,7 @@ static const struct usb_device_id hso_ids[] = {
{USB_DEVICE(0x0af0, 0x8600)},
{USB_DEVICE(0x0af0, 0x8800)},
{USB_DEVICE(0x0af0, 0x8900)},
+ {USB_DEVICE(0x0af0, 0x9000)},
{USB_DEVICE(0x0af0, 0xd035)},
{USB_DEVICE(0x0af0, 0xd055)},
{USB_DEVICE(0x0af0, 0xd155)},
--
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 related
* [PATCH 03/11] cxgb3: do not use PCI resources before pci_enable_device()
From: Kulikov Vasiliy @ 2010-08-03 15:43 UTC (permalink / raw)
To: kernel-janitors
Cc: Divy Le Ray, David S. Miller, Roland Dreier, Steve Wise,
Ben Hutchings, netdev, linux-kernel
IRQ and resource[] may not have correct values until
after PCI hotplug setup occurs at pci_enable_device() time.
The semantic match that finds this problem is as follows:
// <smpl>
@@
identifier x;
identifier request ~= "pci_request.*|pci_resource.*";
@@
(
* x->irq
|
* x->resource
|
* request(x, ...)
)
...
*pci_enable_device(x)
// </smpl>
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
---
drivers/net/cxgb3/cxgb3_main.c | 25 +++++++++++++------------
1 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index 066fd5b..ad19585 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -3198,17 +3198,17 @@ static int __devinit init_one(struct pci_dev *pdev,
}
}
- err = pci_request_regions(pdev, DRV_NAME);
+ err = pci_enable_device(pdev);
if (err) {
- /* Just info, some other driver may have claimed the device. */
- dev_info(&pdev->dev, "cannot obtain PCI resources\n");
- return err;
+ dev_err(&pdev->dev, "cannot enable PCI device\n");
+ goto out;
}
- err = pci_enable_device(pdev);
+ err = pci_request_regions(pdev, DRV_NAME);
if (err) {
- dev_err(&pdev->dev, "cannot enable PCI device\n");
- goto out_release_regions;
+ /* Just info, some other driver may have claimed the device. */
+ dev_info(&pdev->dev, "cannot obtain PCI resources\n");
+ goto out_disable_device;
}
if (!pci_set_dma_mask(pdev, DMA_BIT_MASK(64))) {
@@ -3217,11 +3217,11 @@ static int __devinit init_one(struct pci_dev *pdev,
if (err) {
dev_err(&pdev->dev, "unable to obtain 64-bit DMA for "
"coherent allocations\n");
- goto out_disable_device;
+ goto out_release_regions;
}
} else if ((err = pci_set_dma_mask(pdev, DMA_BIT_MASK(32))) != 0) {
dev_err(&pdev->dev, "no usable DMA configuration\n");
- goto out_disable_device;
+ goto out_release_regions;
}
pci_set_master(pdev);
@@ -3234,7 +3234,7 @@ static int __devinit init_one(struct pci_dev *pdev,
adapter = kzalloc(sizeof(*adapter), GFP_KERNEL);
if (!adapter) {
err = -ENOMEM;
- goto out_disable_device;
+ goto out_release_regions;
}
adapter->nofail_skb =
@@ -3370,11 +3370,12 @@ out_free_dev:
out_free_adapter:
kfree(adapter);
-out_disable_device:
- pci_disable_device(pdev);
out_release_regions:
pci_release_regions(pdev);
+out_disable_device:
+ pci_disable_device(pdev);
pci_set_drvdata(pdev, NULL);
+out:
return err;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH 05/11] via-velocity: do not use PCI resources before pci_enable_device()
From: Kulikov Vasiliy @ 2010-08-03 15:43 UTC (permalink / raw)
To: kernel-janitors
Cc: Francois Romieu, David S. Miller, Simon Kagstrom, Ben Hutchings,
Jiri Pirko, Eric Dumazet, netdev, linux-kernel
IRQ and resource[] may not have correct values until
after PCI hotplug setup occurs at pci_enable_device() time.
The semantic match that finds this problem is as follows:
// <smpl>
@@
identifier x;
identifier request ~= "pci_request.*|pci_resource.*";
@@
(
* x->irq
|
* x->resource
|
* request(x, ...)
)
...
*pci_enable_device(x)
// </smpl>
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
---
drivers/net/via-velocity.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c
index 42dffd3..fd69095 100644
--- a/drivers/net/via-velocity.c
+++ b/drivers/net/via-velocity.c
@@ -2763,12 +2763,12 @@ static int __devinit velocity_found1(struct pci_dev *pdev, const struct pci_devi
vptr->dev = dev;
- dev->irq = pdev->irq;
-
ret = pci_enable_device(pdev);
if (ret < 0)
goto err_free_dev;
+ dev->irq = pdev->irq;
+
ret = velocity_get_pci_info(vptr, pdev);
if (ret < 0) {
/* error message already printed */
--
1.7.0.4
^ permalink raw reply related
* [PATCH 04/11] cxgb4vf: do not use PCI resources before pci_enable_device()
From: Kulikov Vasiliy @ 2010-08-03 15:43 UTC (permalink / raw)
To: kernel-janitors; +Cc: David S. Miller, netdev, linux-kernel
IRQ and resource[] may not have correct values until
after PCI hotplug setup occurs at pci_enable_device() time.
The semantic match that finds this problem is as follows:
// <smpl>
@@
identifier x;
identifier request ~= "pci_request.*|pci_resource.*";
@@
(
* x->irq
|
* x->resource
|
* request(x, ...)
)
...
*pci_enable_device(x)
// </smpl>
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
---
drivers/net/cxgb4vf/cxgb4vf_main.c | 31 ++++++++++++++++---------------
1 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/net/cxgb4vf/cxgb4vf_main.c b/drivers/net/cxgb4vf/cxgb4vf_main.c
index a165632..7b6d07f 100644
--- a/drivers/net/cxgb4vf/cxgb4vf_main.c
+++ b/drivers/net/cxgb4vf/cxgb4vf_main.c
@@ -2462,23 +2462,24 @@ static int __devinit cxgb4vf_pci_probe(struct pci_dev *pdev,
version_printed = 1;
}
+
/*
- * Reserve PCI resources for the device. If we can't get them some
- * other driver may have already claimed the device ...
+ * Initialize generic PCI device state.
*/
- err = pci_request_regions(pdev, KBUILD_MODNAME);
+ err = pci_enable_device(pdev);
if (err) {
- dev_err(&pdev->dev, "cannot obtain PCI resources\n");
+ dev_err(&pdev->dev, "cannot enable PCI device\n");
return err;
}
/*
- * Initialize generic PCI device state.
+ * Reserve PCI resources for the device. If we can't get them some
+ * other driver may have already claimed the device ...
*/
- err = pci_enable_device(pdev);
+ err = pci_request_regions(pdev, KBUILD_MODNAME);
if (err) {
- dev_err(&pdev->dev, "cannot enable PCI device\n");
- goto err_release_regions;
+ dev_err(&pdev->dev, "cannot obtain PCI resources\n");
+ goto err_disable_device;
}
/*
@@ -2491,14 +2492,14 @@ static int __devinit cxgb4vf_pci_probe(struct pci_dev *pdev,
if (err) {
dev_err(&pdev->dev, "unable to obtain 64-bit DMA for"
" coherent allocations\n");
- goto err_disable_device;
+ goto err_release_regions;
}
pci_using_dac = 1;
} else {
err = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
if (err != 0) {
dev_err(&pdev->dev, "no usable DMA configuration\n");
- goto err_disable_device;
+ goto err_release_regions;
}
pci_using_dac = 0;
}
@@ -2514,7 +2515,7 @@ static int __devinit cxgb4vf_pci_probe(struct pci_dev *pdev,
adapter = kzalloc(sizeof(*adapter), GFP_KERNEL);
if (!adapter) {
err = -ENOMEM;
- goto err_disable_device;
+ goto err_release_regions;
}
pci_set_drvdata(pdev, adapter);
adapter->pdev = pdev;
@@ -2750,13 +2751,13 @@ err_free_adapter:
kfree(adapter);
pci_set_drvdata(pdev, NULL);
-err_disable_device:
- pci_disable_device(pdev);
- pci_clear_master(pdev);
-
err_release_regions:
pci_release_regions(pdev);
pci_set_drvdata(pdev, NULL);
+ pci_clear_master(pdev);
+
+err_disable_device:
+ pci_disable_device(pdev);
err_out:
return err;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 06/11] rt2x00: do not use PCI resources before pci_enable_device()
From: Kulikov Vasiliy @ 2010-08-03 15:43 UTC (permalink / raw)
To: kernel-janitors
Cc: Ivo van Doorn, Gertjan van Wingerde, John W. Linville,
Helmut Schaa, Alban Browaeys, linux-wireless, users, netdev,
linux-kernel
IRQ and resource[] may not have correct values until
after PCI hotplug setup occurs at pci_enable_device() time.
The semantic match that finds this problem is as follows:
// <smpl>
@@
identifier x;
identifier request ~= "pci_request.*|pci_resource.*";
@@
(
* x->irq
|
* x->resource
|
* request(x, ...)
)
...
*pci_enable_device(x)
// </smpl>
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
---
drivers/net/wireless/rt2x00/rt2x00pci.c | 21 ++++++++++-----------
1 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2x00pci.c b/drivers/net/wireless/rt2x00/rt2x00pci.c
index 19b262e..63c2cc4 100644
--- a/drivers/net/wireless/rt2x00/rt2x00pci.c
+++ b/drivers/net/wireless/rt2x00/rt2x00pci.c
@@ -240,16 +240,16 @@ int rt2x00pci_probe(struct pci_dev *pci_dev, const struct pci_device_id *id)
struct rt2x00_dev *rt2x00dev;
int retval;
- retval = pci_request_regions(pci_dev, pci_name(pci_dev));
+ retval = pci_enable_device(pci_dev);
if (retval) {
- ERROR_PROBE("PCI request regions failed.\n");
+ ERROR_PROBE("Enable device failed.\n");
return retval;
}
- retval = pci_enable_device(pci_dev);
+ retval = pci_request_regions(pci_dev, pci_name(pci_dev));
if (retval) {
- ERROR_PROBE("Enable device failed.\n");
- goto exit_release_regions;
+ ERROR_PROBE("PCI request regions failed.\n");
+ goto exit_disable_device;
}
pci_set_master(pci_dev);
@@ -260,14 +260,14 @@ int rt2x00pci_probe(struct pci_dev *pci_dev, const struct pci_device_id *id)
if (dma_set_mask(&pci_dev->dev, DMA_BIT_MASK(32))) {
ERROR_PROBE("PCI DMA not supported.\n");
retval = -EIO;
- goto exit_disable_device;
+ goto exit_release_regions;
}
hw = ieee80211_alloc_hw(sizeof(struct rt2x00_dev), ops->hw);
if (!hw) {
ERROR_PROBE("Failed to allocate hardware.\n");
retval = -ENOMEM;
- goto exit_disable_device;
+ goto exit_release_regions;
}
pci_set_drvdata(pci_dev, hw);
@@ -300,13 +300,12 @@ exit_free_reg:
exit_free_device:
ieee80211_free_hw(hw);
-exit_disable_device:
- if (retval != -EBUSY)
- pci_disable_device(pci_dev);
-
exit_release_regions:
pci_release_regions(pci_dev);
+exit_disable_device:
+ pci_disable_device(pci_dev);
+
pci_set_drvdata(pci_dev, NULL);
return retval;
--
1.7.0.4
^ permalink raw reply related
* RE: [RFC PATCH v8 00/16] Provide a zero-copy method on KVM virtio-net.
From: Shirley Ma @ 2010-08-03 15:50 UTC (permalink / raw)
To: Xin, Xiaohui
Cc: netdev@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, mst@redhat.com, mingo@elte.hu,
davem@davemloft.net, herbert@gondor.apana.org.au,
jdike@linux.intel.com
In-Reply-To: <F2E9EB7348B8264F86B6AB8151CE2D791BAB307B7E@shsmsx502.ccr.corp.intel.com>
Hello Xiaohui,
On Tue, 2010-08-03 at 16:48 +0800, Xin, Xiaohui wrote:
> May you share me with your performance results (including BW and
> latency)on
> vhost-net and how you get them(your configuration and especially with
> the affinity
> settings)?
My macvtap zero copy is incomplete, I am testing sendmsg only now. The
initial performance is not good especially for latency (zero copy vs.
copy). I am still working on it to find out why and how to improve.
That's the reason I am eager to know your performance results and how
much performance gain you have seen.
Since your patch has completed. I would try your patch here for
performance. If you have some performance results to share here that
would be great.
Thanks
Shirley
^ permalink raw reply
* [PATCH] ixgbe: ixgbe_fcoe build break
From: Jon Mason @ 2010-08-03 15:57 UTC (permalink / raw)
To: Jeff Kirsher, Jesse Brandeburg, Bruce Allan, Alex Duyck, PJ
Cc: David Miller, netdev, e1000-devel
struct ixgbe_fcoe has fields that are #ifdef'ed with CONFIG_IXGBE_DCB.
However, not all references to those fields check for CONFIG_IXGBE_DCB.
This patch adds the necessary check to allow for ixgbe to compile.
Signed-off-by: Jon Mason <jon.mason@exar.com>
---
drivers/net/ixgbe/ixgbe_main.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 7d6a415..9ec3dfe 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -6155,9 +6155,11 @@ static u16 ixgbe_select_queue(struct net_device *dev, struct sk_buff *skb)
txq &= (adapter->ring_feature[RING_F_FCOE].indices - 1);
txq += adapter->ring_feature[RING_F_FCOE].mask;
return txq;
+#ifdef CONFIG_IXGBE_DCB
} else if (adapter->flags & IXGBE_FLAG_DCB_ENABLED) {
txq = adapter->fcoe.up;
return txq;
+#endif
}
}
#endif
@@ -6218,8 +6220,10 @@ static netdev_tx_t ixgbe_xmit_frame(struct sk_buff *skb,
skb->protocol == htons(ETH_P_FIP))) {
tx_flags &= ~(IXGBE_TX_FLAGS_VLAN_PRIO_MASK
<< IXGBE_TX_FLAGS_VLAN_SHIFT);
+#ifdef CONFIG_IXGBE_DCB
tx_flags |= ((adapter->fcoe.up << 13)
<< IXGBE_TX_FLAGS_VLAN_SHIFT);
+#endif
/* flag for FCoE offloads */
if (skb->protocol == htons(ETH_P_FCOE))
tx_flags |= IXGBE_TX_FLAGS_FCOE;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 06/11] rt2x00: do not use PCI resources before pci_enable_device()
From: Gertjan van Wingerde @ 2010-08-03 16:14 UTC (permalink / raw)
To: Kulikov Vasiliy
Cc: kernel-janitors, Ivo van Doorn, John W. Linville, Helmut Schaa,
Alban Browaeys, linux-wireless, users, netdev, linux-kernel
In-Reply-To: <1280850203-5532-1-git-send-email-segooon@gmail.com>
On Tue, Aug 3, 2010 at 5:43 PM, Kulikov Vasiliy <segooon@gmail.com> wrote:
> IRQ and resource[] may not have correct values until
> after PCI hotplug setup occurs at pci_enable_device() time.
>
> The semantic match that finds this problem is as follows:
>
> // <smpl>
> @@
> identifier x;
> identifier request ~= "pci_request.*|pci_resource.*";
> @@
>
> (
> * x->irq
> |
> * x->resource
> |
> * request(x, ...)
> )
> ...
> *pci_enable_device(x)
> // </smpl>
>
> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Good catch.
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2x00pci.c | 21 ++++++++++-----------
> 1 files changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2x00pci.c b/drivers/net/wireless/rt2x00/rt2x00pci.c
> index 19b262e..63c2cc4 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00pci.c
> +++ b/drivers/net/wireless/rt2x00/rt2x00pci.c
> @@ -240,16 +240,16 @@ int rt2x00pci_probe(struct pci_dev *pci_dev, const struct pci_device_id *id)
> struct rt2x00_dev *rt2x00dev;
> int retval;
>
> - retval = pci_request_regions(pci_dev, pci_name(pci_dev));
> + retval = pci_enable_device(pci_dev);
> if (retval) {
> - ERROR_PROBE("PCI request regions failed.\n");
> + ERROR_PROBE("Enable device failed.\n");
> return retval;
> }
>
> - retval = pci_enable_device(pci_dev);
> + retval = pci_request_regions(pci_dev, pci_name(pci_dev));
> if (retval) {
> - ERROR_PROBE("Enable device failed.\n");
> - goto exit_release_regions;
> + ERROR_PROBE("PCI request regions failed.\n");
> + goto exit_disable_device;
> }
>
> pci_set_master(pci_dev);
> @@ -260,14 +260,14 @@ int rt2x00pci_probe(struct pci_dev *pci_dev, const struct pci_device_id *id)
> if (dma_set_mask(&pci_dev->dev, DMA_BIT_MASK(32))) {
> ERROR_PROBE("PCI DMA not supported.\n");
> retval = -EIO;
> - goto exit_disable_device;
> + goto exit_release_regions;
> }
>
> hw = ieee80211_alloc_hw(sizeof(struct rt2x00_dev), ops->hw);
> if (!hw) {
> ERROR_PROBE("Failed to allocate hardware.\n");
> retval = -ENOMEM;
> - goto exit_disable_device;
> + goto exit_release_regions;
> }
>
> pci_set_drvdata(pci_dev, hw);
> @@ -300,13 +300,12 @@ exit_free_reg:
> exit_free_device:
> ieee80211_free_hw(hw);
>
> -exit_disable_device:
> - if (retval != -EBUSY)
> - pci_disable_device(pci_dev);
> -
> exit_release_regions:
> pci_release_regions(pci_dev);
>
> +exit_disable_device:
> + pci_disable_device(pci_dev);
> +
> pci_set_drvdata(pci_dev, NULL);
>
> return retval;
> --
> 1.7.0.4
>
>
^ permalink raw reply
* Re: [PATCH] can-raw: Fix skb_orphan_try handling
From: Patrick Ohly @ 2010-08-03 16:14 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: David Miller, eric.dumazet@gmail.com, netdev@vger.kernel.org,
socketcan-core@lists.berlios.de, matthias.fuchs@esd.eu
In-Reply-To: <4C583447.8010004@hartkopp.net>
On Tue, 2010-08-03 at 18:22 +0300, Oliver Hartkopp wrote:
> >> The flags are tested all together in skb_orphan_try() ...
> >
> > This is why I hate using unions in situations like this... it makes
> > code impossible to audit easily.
> >
> > This damn thing should just be a "u8 flags" and a bunch of bit mask
> > CPP macro defines for the various boolean values.
>
> Yep! I also felt like this.
>
> Maybe Patrick Ohly can give some feedback, if he's ok with that kind of
> change. So far there are only a few places that would need to be changed for
> the flags bitops.
I'm fine with using a simple u8. I'm not sure where I picked up the
union thing, it's not something that I usually do in my own code.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
^ permalink raw reply
* Re: [ANNOUNCE]: Release of iptables-1.4.9
From: Gabor Z. Papp @ 2010-08-03 16:34 UTC (permalink / raw)
To: Patrick McHardy
Cc: Netfilter Development Mailinglist, Linux Netdev List,
'netfilter@vger.kernel.org', netfilter-announce
In-Reply-To: <4C5832F9.50004@trash.net>
* Patrick McHardy <kaber@trash.net>:
| iptables version 1.4.9
make[2]: Entering directory `/home/gzp/src/iptables-1.4.9'
/bin/sh ./libtool --tag=CC --mode=link gcc -D_LARGEFILE_SOURCE=1
-D_LARGE_FILES -D_FILE_OFFSET_BITS=64 -D_REENTRANT -Wall
-Waggregate-return -Wmissing-declarations -Wmissing-prototypes
-Wredundant-decls -Wshadow -Wstrict-prototypes -Winline -pipe
-DXTABLES_LIBDIR=\"/pkg/lib/xtables\" -DXTABLES_INTERNAL -I./include
-I./include -DIPTABLES_MULTI -DALL_INCLUSIVE -g -O2 -rdynamic -o
iptables-multi iptables_multi-iptables-multi.o
iptables_multi-iptables-save.o iptables_multi-iptables-restore.o
iptables_multi-iptables-xml.o iptables_multi-iptables-standalone.o
iptables_multi-iptables.o iptables_multi-xshared.o libiptc/libip4tc.la
extensions/libext4.a libxtables.la -lm
libtool: link: gcc -D_LARGEFILE_SOURCE=1 -D_LARGE_FILES
-D_FILE_OFFSET_BITS=64 -D_REENTRANT -Wall -Waggregate-return
-Wmissing-declarations -Wmissing-prototypes -Wredundant-decls -Wshadow
-Wstrict-prototypes -Winline -pipe
-DXTABLES_LIBDIR=\"/pkg/lib/xtables\" -DXTABLES_INTERNAL -I./include
-I./include -DIPTABLES_MULTI -DALL_INCLUSIVE -g -O2 -rdynamic -o
iptables-multi iptables_multi-iptables-multi.o
iptables_multi-iptables-save.o iptables_multi-iptables-restore.o
iptables_multi-iptables-xml.o iptables_multi-iptables-standalone.o
iptables_multi-iptables.o iptables_multi-xshared.o
libiptc/.libs/libip4tc.a extensions/libext4.a ./.libs/libxtables.a -lm
collect2: ld terminated with signal 11 [Segmentation fault]
extensions/libext4.a(initext4.o): In function `init_extensions':
/home/gzp/src/iptables-1.4.9/extensions/initext4.c:138: undefined reference to `libxt_TEE_init'
make[2]: *** [iptables-multi] Error 1
[kernel]
Linux gzp1 2.6.32.17-gzp1 #1 SMP PREEMPT Tue Aug 3 17:17:10 CEST 2010
i686 GNU/Linux
[glibc]
GNU C Library stable release version 2.11.2, by Roland McGrath et al.
Compiled by GNU CC version 4.4.4.
Compiled on a Linux 2.6.34 system on 2010-06-01.
Native POSIX Threads Library by Ulrich Drepper et al
[gcc]
gcc (GCC) 4.4.4
[binutils]
GNU ld (Linux/GNU Binutils) 2.20.51.0.10.20100707
^ permalink raw reply
* Re: [ANNOUNCE]: Release of iptables-1.4.9
From: Patrick McHardy @ 2010-08-03 17:05 UTC (permalink / raw)
To: Gabor Z. Papp
Cc: Netfilter Development Mailinglist, Linux Netdev List,
'netfilter@vger.kernel.org', netfilter-announce
In-Reply-To: <x6bp9jy7sj@gzp>
Am 03.08.2010 18:34, schrieb Gabor Z. Papp:
> * Patrick McHardy <kaber@trash.net>:
>
> | iptables version 1.4.9
>
> ...
> libiptc/.libs/libip4tc.a extensions/libext4.a ./.libs/libxtables.a -lm
> collect2: ld terminated with signal 11 [Segmentation fault]
> extensions/libext4.a(initext4.o): In function `init_extensions':
> /home/gzp/src/iptables-1.4.9/extensions/initext4.c:138: undefined reference to `libxt_TEE_init'
> make[2]: *** [iptables-multi] Error 1
Did you use a git checkout/patch against 1.4.8 or the tar.bz2?
In case its the former, try running make clean, sh autogen.sh and
sh configure again before the build.
^ permalink raw reply
* Re: [PATCH] can-raw: Fix skb_orphan_try handling
From: Oliver Hartkopp @ 2010-08-03 17:11 UTC (permalink / raw)
To: Patrick Ohly
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, David Miller,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
In-Reply-To: <1280852081.3266.834.camel-/oqbx4SGF9pV+x+AlpbFz62pdiUAq4bhAL8bYrjMMd8@public.gmane.org>
On 03.08.2010 18:14, Patrick Ohly wrote:
> On Tue, 2010-08-03 at 18:22 +0300, Oliver Hartkopp wrote:
>>>> The flags are tested all together in skb_orphan_try() ...
>>>
>>> This is why I hate using unions in situations like this... it makes
>>> code impossible to audit easily.
>>>
>>> This damn thing should just be a "u8 flags" and a bunch of bit mask
>>> CPP macro defines for the various boolean values.
>>
>> Yep! I also felt like this.
>>
>> Maybe Patrick Ohly can give some feedback, if he's ok with that kind of
>> change. So far there are only a few places that would need to be changed for
>> the flags bitops.
>
> I'm fine with using a simple u8. I'm not sure where I picked up the
> union thing, it's not something that I usually do in my own code.
>
:-)
Im currently busy until next week, would you like to provide a patch?
Regards,
Oliver
^ 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