Re: tcpdump(8) man page: sync PF reason codes
On 2013/04/29 22:32, Lawrence Teo wrote: > This diff syncs the PF reason codes on the tcpdump(8) man page with > PFRES_NAMES in net/pfvar.h. > > OK? > > > Index: tcpdump.8 > === > RCS file: /cvs/src/usr.sbin/tcpdump/tcpdump.8,v > retrieving revision 1.79 > diff -u -p -r1.79 tcpdump.8 > --- tcpdump.8 26 Sep 2012 16:19:45 - 1.79 > +++ tcpdump.8 30 Apr 2013 02:22:01 - > @@ -735,8 +735,9 @@ The known codes are: > .Ar state-insert , > .Ar state-limit , > .Ar src-limit , > +.Ar synproxy , > and > -.Ar synproxy > +.Ar translate > (applies only to packets logged by > .Xr pf 4 ) . > .It Cm rset Ar name > @@ -1066,8 +1067,12 @@ and packet length are printed. > .Pp > On the packet filter logging interface > .Xr pflog 4 , > -logging reason > -.Pq rule match, bad-offset, fragment, bad-timestamp, short, normalize, > memory , > +the logging reason > +.Po > +rule match, bad-offset, fragment, short, normalize, memory, bad-timestamp, > +congestion, ip-option, proto-cksum, state-mismatch, state-insert, > +state-limit, src-limit, synproxy, translate > +.Pc needs a , after this list, but I'm not convinced there are PFLOG_PACKET() associated with all these reason codes - i.e. I think that it's intentional that this isn't a list of every reason code. > action taken > .Pq pass/block , > direction >
Re: Test needed: ehci(4) suspend/resume rework
On 29/04/13(Mon) 13:25, patrick keshishian wrote: > On Sun, Apr 28, 2013 at 03:44:09PM +0200, Martin Pieuchot wrote: > > Diff below is a rework of the suspend/resume logic in ehci(4). > > > > If you're not interested in the full story below, please make sure > > it doesn't introduce any regression on your machine(s) and, in any > > case report to me (with your dmesg!) thanks :) > > > > Full story: > > > > So this diff changes the way we supsend/resume ehci(4) in various > > way. It started as a simple rewrite of the ehci_reset() function > > to fix a race while working on the rework of the suspend/resume > > framework with deraadt@, then later on I discovered that some of > > the magic in there was wrong or no longer needed. > > > > First of all, it removes the logic introduced in r1.46 that places > > all the ports into suspend mode because it no longer makes sense > > as we *do* detach/reattach USB devices during a suspend/resume > > cycle now. > > Naive question here, but would this be a cause for issue > reported here: > > http://marc.info/?l=openbsd-misc&m=136327530312197&w=2 Certainly. > > or at least I'm curious as to why the Wacom tablet does not > reattach after a resume. Really? Are you sure it doesn't reattach or is it just not usable in X? It's easy to check, try to suspend/resume in console with the tablet connected, does it show up again in your dmesg? And for the crash you can try to add the following in your xorg.conf: Section "ServerFlags" Option "AllowMouseOpenFail" "True" EndSection I don't know if it will be enough, I'm not sure what's the status of devices hotplugging in xenocara. If you want to be more than "curious" you can build the xf86-input-usbtablet with debug enable and try to find what the problem is ;) Diffs are always welcome! M.
Re: [NEW] ugold(4) driver for Microdia's USB TEMPer variant
On 2013/03/31 17:56, SASANO Takayoshi wrote: > Hello, > > I rewrote patched uthum(4) to new ugold(4) driver. > Thanks for advice by yuo@ and deraadt@. > > The diff for -current's /usr/src/sys is large to send mailing-list, > so here is the URL: > > http://www2192ue.sakura.ne.jp/~uaa/gomitext/2013/20130331/20130331.diff > > If you want to try ugold(4) and already use Microdia's-variant-patched > uthum(4) driver, revert original uthum(4). > > ok or comments, please. > > Cheers, > -- > SASANO Takayoshi > In the diff to usbdevs you have this: product MICRODIA_TEMPER 0x7401 TEMPer sensor it should be: product MICRODIA TEMPER 0x7401 TEMPer sensor Your diff as-is does build, but as soon as somebody runs "make" in /sys/dev/usb it will break. Generally, avoid editing usbdevs.h and usbdevs_data.h directly, just edit "usbdevs" and then run "make" to generate the other files. The driver also needs adding to GENERIC for the other USB-capable architectures. Works for me on i386 with $ dmesg|grep ugold ugold0 at uhidev0 reportid 1 ugold1 at uhidev1 ugold1: type ds75/12bit (temperature)
add nl(1)
Taken from netbsd with minor modifications. Comments? Index: Makefile === RCS file: /cvs/src/usr.bin/Makefile,v retrieving revision 1.129 diff -u -p -r1.129 Makefile --- Makefile15 Mar 2013 06:01:41 - 1.129 +++ Makefile30 Apr 2013 15:22:59 - @@ -16,7 +16,7 @@ SUBDIR= apply apropos ar arch asa asn1_c m4 mail make man mandoc mesg mg \ midiplay mixerctl mkdep mklocale mkstr mktemp modstat nc netstat \ newsyslog \ - nfsstat nice nm nohup oldrdist pagesize passwd paste patch pctr \ + nfsstat nice nm nl nohup oldrdist pagesize passwd paste patch pctr \ pkg-config pkill \ pr printenv printf quota radioctl ranlib rcs rdist rdistd \ readlink renice rev rpcgen rpcinfo rs rsh rup ruptime rusers rwall \ Index: nl/Makefile === RCS file: nl/Makefile diff -N nl/Makefile --- /dev/null 1 Jan 1970 00:00:00 - +++ nl/Makefile 30 Apr 2013 15:23:00 - @@ -0,0 +1,6 @@ +# $OpenBSD$ +# $NetBSD: Makefile,v 1.4 2011/08/16 12:00:46 christos Exp $ + +PROG= nl + +.include Index: nl/nl.1 === RCS file: nl/nl.1 diff -N nl/nl.1 --- /dev/null 1 Jan 1970 00:00:00 - +++ nl/nl.1 30 Apr 2013 15:23:00 - @@ -0,0 +1,212 @@ +.\"$OpenBSD$ +.\"$NetBSD: nl.1,v 1.12 2012/04/08 22:00:39 wiz Exp $ +.\" +.\" Copyright (c) 1999 The NetBSD Foundation, Inc. +.\" All rights reserved. +.\" +.\" This code is derived from software contributed to The NetBSD Foundation +.\" by Klaus Klein. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\"notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\"notice, this list of conditions and the following disclaimer in the +.\"documentation and/or other materials provided with the distribution. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS +.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED +.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR +.\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS +.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR +.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF +.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS +.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN +.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) +.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE +.\" POSSIBILITY OF SUCH DAMAGE. +.\" +.Dd $Mdocdate$ +.Dt NL 1 +.Os +.Sh NAME +.Nm nl +.Nd line numbering filter +.Sh SYNOPSIS +.Nm +.Op Fl p +.Op Fl b Ar type +.Op Fl d Ar delim +.Op Fl f Ar type +.Op Fl h Ar type +.Op Fl i Ar incr +.Op Fl l Ar num +.Op Fl n Ar format +.Op Fl s Ar sep +.Op Fl v Ar startnum +.Op Fl w Ar width +.Op Ar file +.Sh DESCRIPTION +The +.Nm +utility reads lines from the named +.Ar file +or the standard input if the +.Ar file +argument is omitted, +applies a configurable line numbering filter operation and writes the result +to the standard output. +.Pp +The +.Nm +utility treats the text it reads in terms of logical pages. +Unless specified otherwise, line numbering is reset at the start of each +logical page. +A logical page consists of a header, a body and a footer section; empty +sections are valid. +Different line numbering options are independently available for header, +body and footer sections. +.Pp +The starts of logical page sections are signaled by input lines containing +nothing but one of the following sequences of delimiter characters: +.Bd -unfilled -offset indent +.Bl -column "\e:\e:\e: " "header " +.It Em "Line" "Start of" +.It \e:\e:\e: header +.It \e:\e: body +.It \e:footer +.El +.Ed +.Pp +If the input does not contain any logical page section signaling directives, +the text being read is assumed to consist of a single logical page body. +.Pp +The following options are available: +.Bl -tag -width indent +.It Fl b Ar type +Specify the logical page body lines to be numbered. +Recognized +.Ar type +arguments are: +.Bl -tag -width pstringXX +.It a +Number all lines. +.It t +Number only non-empty lines. +.It n +No line numbering. +.It p Ns Ar expr +Number only those lines that contain the basic regular expression specified +by +.Ar expr . +.El +.Pp +The default +.Ar type +for logical page body lines is t. +.It Fl d Ar delim +Specify the delimiter characters used to indicate the start of a logical +page section in the input fi
Re: add nl(1)
Arto Jonsson writes: > Taken from netbsd with minor modifications. Comments? I think that would be nice since: - cat -n is clunky - nl is specified by posix - I know at least one port that needs a patch because we lack it [...] -- Jérémie Courrèges-Anglas PGP Key fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
accept(2) - mention ECONNABORTED in CAVEATS
Hi, as cvs log shows, accept(2) can error out with errno set to ECONNABORTED, and it is easy to forget that this shouldn't be a fatal error. I suggest the following diff or something similar. Index: accept.2 === RCS file: /cvs/src/lib/libc/sys/accept.2,v retrieving revision 1.25 diff -u -p -r1.25 accept.2 --- accept.221 Apr 2013 07:44:59 - 1.25 +++ accept.230 Apr 2013 16:18:38 - @@ -147,7 +147,7 @@ int retcode; retcode = accept(s, (struct sockaddr *)&addr, &len); if (retcode == -1) - err(1, "accept"); + err(1, "accept"); /* Probably too simplistic. */ .Ed .Sh ERRORS .Fn accept @@ -211,3 +211,5 @@ Thus considerable care is required in and .Xr poll 2 loops. +.Er ECONNABORTED +is often overlooked and should be handled appropriately.
Re: [NEW] ugold(4) driver for Microdia's USB TEMPer variant
On 2013/04/30 15:06, Stuart Henderson wrote: > On 2013/03/31 17:56, SASANO Takayoshi wrote: > > Hello, > > > > I rewrote patched uthum(4) to new ugold(4) driver. > > Thanks for advice by yuo@ and deraadt@. > > > > The diff for -current's /usr/src/sys is large to send mailing-list, > > so here is the URL: > > > > http://www2192ue.sakura.ne.jp/~uaa/gomitext/2013/20130331/20130331.diff > > > > If you want to try ugold(4) and already use Microdia's-variant-patched > > uthum(4) driver, revert original uthum(4). > > > > ok or comments, please. > > > > Cheers, > > -- > > SASANO Takayoshi > > > > In the diff to usbdevs you have this: > > product MICRODIA_TEMPER 0x7401 TEMPer sensor > > it should be: > > product MICRODIA TEMPER 0x7401 TEMPer sensor > > Your diff as-is does build, but as soon as somebody runs "make" in > /sys/dev/usb > it will break. Generally, avoid editing usbdevs.h and usbdevs_data.h directly, > just edit "usbdevs" and then run "make" to generate the other files. > > The driver also needs adding to GENERIC for the other USB-capable > architectures. > > Works for me on i386 with > > $ dmesg|grep ugold > ugold0 at uhidev0 reportid 1 > ugold1 at uhidev1 > ugold1: type ds75/12bit (temperature) > ... Seems to work well enough; and unlike my uthum (one of the dual-sensor ones) it seems to stay attached without dropping out all the time. These are slightly slow adapting to temperature changes (presumably due to the metal case) for example this graph from moving the sensor from the front of a server room to the back (through hot/cold air containment curtains) http://junkpile.org/ugold.png shows it took about 10 minutes to stabilise again, but that's good enough for my needs :)
Re: [UPDATE] Sendmail 8.14.7 released
Ping. -- Jérémie Courrèges-Anglas PGP Key fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
Re: accept(2) - mention ECONNABORTED in CAVEATS
New diff with .Pp suggested by jmc (which was ok otherwise - thanks). -- Jérémie Courrèges-Anglas PGP Key fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494 Index: accept.2 === RCS file: /cvs/src/lib/libc/sys/accept.2,v retrieving revision 1.25 diff -u -p -r1.25 accept.2 --- accept.221 Apr 2013 07:44:59 - 1.25 +++ accept.230 Apr 2013 18:51:46 - @@ -147,7 +147,7 @@ int retcode; retcode = accept(s, (struct sockaddr *)&addr, &len); if (retcode == -1) - err(1, "accept"); + err(1, "accept"); /* Probably too simplistic. */ .Ed .Sh ERRORS .Fn accept @@ -211,3 +211,6 @@ Thus considerable care is required in and .Xr poll 2 loops. +.Pp +.Er ECONNABORTED +is often overlooked and should be handled appropriately.
Re: [UPDATE] Sendmail 8.14.7 released
Vijay Sankar writes: > Hi, Hi Vijay, > I am running the ldap flavor and so far have had no problems that could be > traced to sendmail. I think the authentication problems and problems with ldap > vacation that i see are of my own making. [...] Note that this is not the updated sendmail port I have sent to ports@, but an update for the in-base version. I asked gilles@ and replacing sendmail with smtpd is not planned for 5.4 (right?), but the code is the same so problem reports for the sendmail port would still be useful. -- Jérémie Courrèges-Anglas PGP Key Fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
DPI for pf(4)
Hi misc@, so I have been working on a BSD licensed DPI engine. It's a very lightweight, non-intrusive approach and I know that teasers are boring, but I'd like to know if it's worth the time to work on inclusion for pf(4). So far I have about 25 supported applications and the necessary hooks for the pf.conf(5) parts. The idea is first packet on each side only, no content extraction. It's not meant to be completely accurate, but it might be a good addition to the feature set of pf(4) nonetheless. I have two blog posts with code, and more coming if anyone is interested. Regards, Franco
Re: accept(2) - mention ECONNABORTED in CAVEATS
> From: j...@wxcvbn.org (=?utf-8?Q?J=C3=A9r=C3=A9mie_Courr=C3=A8ges-Anglas?=) > Date: Tue, 30 Apr 2013 20:53:36 +0200 > > > New diff with .Pp suggested by jmc (which was ok otherwise - thanks). Sorry, but I don't think this is an improvement. > Index: accept.2 > === > RCS file: /cvs/src/lib/libc/sys/accept.2,v > retrieving revision 1.25 > diff -u -p -r1.25 accept.2 > --- accept.2 21 Apr 2013 07:44:59 - 1.25 > +++ accept.2 30 Apr 2013 18:51:46 - > @@ -147,7 +147,7 @@ int retcode; > > retcode = accept(s, (struct sockaddr *)&addr, &len); > if (retcode == -1) > - err(1, "accept"); > + err(1, "accept"); /* Probably too simplistic. */ > .Ed > .Sh ERRORS > .Fn accept > @@ -211,3 +211,6 @@ Thus considerable care is required in > and > .Xr poll 2 > loops. > +.Pp > +.Er ECONNABORTED > +is often overlooked and should be handled appropriately. > >
Re: [UPDATE] Sendmail 8.14.7 released
Hi, I am running the ldap flavor and so far have had no problems that could be traced to sendmail. I think the authentication problems and problems with ldap vacation that i see are of my own making. I hope to test it properly and get back to you this weekend. Sorry about the delay Vijay Sankar ForeTell Technologies Limited vsan...@foretell.ca Sent from my iPhone On 2013-04-30, at 1:54 PM, j...@wxcvbn.org (Jérémie Courrèges-Anglas) wrote: > > Ping. > > -- > Jérémie Courrèges-Anglas > PGP Key fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494 >
Re: accept(2) - mention ECONNABORTED in CAVEATS
Mark Kettenis writes: >> From: j...@wxcvbn.org (=?utf-8?Q?J=C3=A9r=C3=A9mie_Courr=C3=A8ges-Anglas?=) >> Date: Tue, 30 Apr 2013 20:53:36 +0200 >> >> >> New diff with .Pp suggested by jmc (which was ok otherwise - thanks). > > Sorry, but I don't think this is an improvement. I guess you're not talking about the .Pp... if so, may I ask why? -- Jérémie Courrèges-Anglas PGP Key fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
Re: accept(2) - mention ECONNABORTED in CAVEATS
On Tue, Apr 30, 2013 at 22:11, J?r?mie Courr?ges-Anglas wrote: > Mark Kettenis writes: > >>> From: j...@wxcvbn.org (=?utf-8?Q?J=C3=A9r=C3=A9mie_Courr=C3=A8ges-Anglas?=) >>> Date: Tue, 30 Apr 2013 20:53:36 +0200 >>> >>> >>> New diff with .Pp suggested by jmc (which was ok otherwise - thanks). >> >> Sorry, but I don't think this is an improvement. > > I guess you're not talking about the .Pp... if so, may I ask why? > I think a much better improvement would be an example that shows correct handling. A man page that says "do this, only better" isn't very useful if you don't know what better is. Pick a sample from the src tree and use that.
Re: DPI for pf(4)
Franco Fichtner gmail.com> writes: > so I have been working on a BSD licensed DPI engine. It's a > very lightweight, non-intrusive approach and I know that teasers > are boring, but I'd like to know if it's worth the time to > work on inclusion for pf(4). So far I have about 25 supported > applications and the necessary hooks for the pf.conf(5) parts. If DPI stands for Deep Packet Inspection, than (afaik) it was discussed before: this kind of inspection is too complex to put into a kernel. relayd already supports L7 filtering at least for http, so if something is to be improved in this area, relayd is better place, imo.
Re: DPI for pf(4)
Hi Alexey, On Apr 30, 2013, at 11:51 PM, "Alexey E. Suslikov" wrote: > Franco Fichtner gmail.com> writes: > >> so I have been working on a BSD licensed DPI engine. It's a >> very lightweight, non-intrusive approach and I know that teasers >> are boring, but I'd like to know if it's worth the time to >> work on inclusion for pf(4). So far I have about 25 supported >> applications and the necessary hooks for the pf.conf(5) parts. > > If DPI stands for Deep Packet Inspection, than (afaik) > it was discussed before: this kind of inspection is too > complex to put into a kernel. Yes, I am proposing a lightweight approach: hard-wired regex-like code, no allocations, no reassembly or state machines. I've seen far worse things being put into Kernels and I assure you that I do refrain from putting in anything that could cause segmentation faults, sleeps, or other non-suitable behaviour. > relayd already supports L7 filtering at least for http, > so if something is to be improved in this area, relayd > is better place, imo. Would a protocol like BGP have a bright future in relayd(8)? I don't know enough, maybe Reyk can clear this up? L7 filtering is cute, but ipfw-classifyd isn't maintained, DPI in Linux netfilter is not hitting it off, and there really is no BSD DPI. Franky, I don't care which way to go, but I believe that pf(4) is a suitable candidate. I especially like the one- rule-to-rule-them-all approach. Adding a keyword "app" to pf.conf(5) seems like the simplest solution -- much like "proto" does deal with IP types. And talking about complexity: 1000 LOC for 25 protocols. I'm afraid it can't be simplified any more than this. Thanks for your input, Franco
Re: DPI for pf(4)
On 2013/05/01 00:16, Franco Fichtner wrote: > Hi Alexey, > > On Apr 30, 2013, at 11:51 PM, "Alexey E. Suslikov" > wrote: > > > Franco Fichtner gmail.com> writes: > > > >> so I have been working on a BSD licensed DPI engine. It's a > >> very lightweight, non-intrusive approach and I know that teasers > >> are boring, but I'd like to know if it's worth the time to > >> work on inclusion for pf(4). So far I have about 25 supported > >> applications and the necessary hooks for the pf.conf(5) parts. > > > > If DPI stands for Deep Packet Inspection, than (afaik) > > it was discussed before: this kind of inspection is too > > complex to put into a kernel. > > Yes, I am proposing a lightweight approach: hard-wired regex-like > code, no allocations, no reassembly or state machines. I've seen > far worse things being put into Kernels and I assure you that I do > refrain from putting in anything that could cause segmentation > faults, sleeps, or other non-suitable behaviour. Would it be fair to describe it as a bit more complex than osfp, but not hugely so? > > relayd already supports L7 filtering at least for http, > > so if something is to be improved in this area, relayd > > is better place, imo. > > Would a protocol like BGP have a bright future in relayd(8)? > I don't know enough, maybe Reyk can clear this up? > > L7 filtering is cute, but ipfw-classifyd isn't maintained, DPI in > Linux netfilter is not hitting it off, and there really is no > BSD DPI. Franky, I don't care which way to go, but I believe > that pf(4) is a suitable candidate. I especially like the one- > rule-to-rule-them-all approach. Adding a keyword "app" to > pf.conf(5) seems like the simplest solution -- much like "proto" > does deal with IP types. > > And talking about complexity: 1000 LOC for 25 protocols. I'm afraid > it can't be simplified any more than this. What sort of protocols do you think could be reasonably handled by this approach, and what would be too complicated? There is definitely something appealing about being able to say, for example, 'block proto tcp on port 443; pass proto tcp on port 443 app tls', or 'block app ssh; pass proto tcp from to port 22 app ssh' without a bunch more complexity involved in passing across to a separate proxy (which would then need to implement its own completely separate filtering and would, I think, not really be able to integrate with things like PF tags and queue assignment)... Basically what I'm wondering if it's possible to go far enough to be useful whilst keeping the complexity down to a level which is sane and simple enough that it can be carefully audited.
Re: DPI for pf(4)
On Wed, May 01, 2013 at 00:16, Franco Fichtner wrote: > Yes, I am proposing a lightweight approach: hard-wired regex-like > code, no allocations, no reassembly or state machines. I've seen > far worse things being put into Kernels and I assure you that I do > refrain from putting in anything that could cause segmentation > faults, sleeps, or other non-suitable behaviour. > And talking about complexity: 1000 LOC for 25 protocols. I'm afraid > it can't be simplified any more than this. Well, it's really hard to comment on code we can't see. My thoughts on the matter have always been that it would be cool to integrate bpf into pf (though other developers surely have other opinions). Then you get filtering for as many protocols as you care to write bpf matchers for.
Re: accept(2) - mention ECONNABORTED in CAVEATS
Ted Unangst writes:
> On Tue, Apr 30, 2013 at 22:11, Jérémie Courrèges-Anglas wrote:
>> Mark Kettenis writes:
>>
From: j...@wxcvbn.org (=?utf-8?Q?J=C3=A9r=C3=A9mie_Courr=C3=A8ges-Anglas?=)
Date: Tue, 30 Apr 2013 20:53:36 +0200
New diff with .Pp suggested by jmc (which was ok otherwise - thanks).
>>>
>>> Sorry, but I don't think this is an improvement.
>>
>> I guess you're not talking about the .Pp... if so, may I ask why?
>>
>
> I think a much better improvement would be an example that shows
> correct handling. A man page that says "do this, only better" isn't
> very useful if you don't know what better is. Pick a sample from the
> src tree and use that.
I see, that makes sense.
- no addition to CAVEATS
In the example:
- include err.h
- ignore ECONNABORTED
- handle EINTR, EWOULDBLOCK, EMFILE and ENFILE
- add portability note about EAGAIN
I hope this sounds reasonable.
--
Jérémie Courrèges-Anglas
PGP Key fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
Index: accept.2
===
RCS file: /cvs/src/lib/libc/sys/accept.2,v
retrieving revision 1.25
diff -u -p -r1.25 accept.2
--- accept.221 Apr 2013 07:44:59 - 1.25
+++ accept.230 Apr 2013 23:19:12 -
@@ -134,20 +134,46 @@ The call returns \-1 on error.
If it succeeds, it returns a non-negative integer that is a descriptor
for the accepted socket.
.Sh EXAMPLES
-The following code uses struct
+The following code checks errno and uses struct
.Li sockaddr_storage
to allocate enough space for the returned address:
.Bd -literal -offset indent
#include
#include
+#include
+#include
+
struct sockaddr_storage addr;
socklen_t len = sizeof(addr);
int retcode;
+retry:
retcode = accept(s, (struct sockaddr *)&addr, &len);
-if (retcode == -1)
- err(1, "accept");
+if (retcode == -1) {
+ switch (errno) {
+ case ECONNABORTED:
+ /* Ignore this error. */
+ goto retry;
+ /* NOTREACHED */
+ case EINTR:
+ /* Possibly check for received signals here. */
+ break;
+ case EMFILE:
+ case ENFILE:
+ /* You may gracefully handle fd starvation. */
+ break;
+ case EWOULDBLOCK:
+ case EAGAIN:
+ /*
+* Portable code should check for both EAGAIN
+* and EWOULDBLOCK
+*/
+ break;
+ default:
+ err(1, "accept");
+ }
+}
.Ed
.Sh ERRORS
.Fn accept
faster fast grep
For simple patterns, grep has an optimization to avoid regex and run
about 50% faster. The problem is its idea of simple patterns is too
simple.
This diff switches the logic around from a whitelist to a blacklist. We
only need to abort the fast path if we see a magic regex character.
Index: util.c
===
RCS file: /cvs/src/usr.bin/grep/util.c,v
retrieving revision 1.45
diff -u -p -r1.45 util.c
--- util.c 29 Dec 2012 01:32:44 - 1.45
+++ util.c 1 May 2013 00:00:30 -
@@ -348,15 +348,8 @@ fastcomp(fastgrep_t *fg, const char *pat
/* Look for ways to cheat...er...avoid the full regex engine. */
for (i = 0; i < fg->patternLen; i++)
{
- /* Can still cheat? */
- if ((isalnum(fg->pattern[i])) || isspace(fg->pattern[i]) ||
- (fg->pattern[i] == '_') || (fg->pattern[i] == ',') ||
- (fg->pattern[i] == '=') || (fg->pattern[i] == '-') ||
- (fg->pattern[i] == ':') || (fg->pattern[i] == '/')) {
- /* As long as it is good, upper case it for later. */
- if (iflag)
- fg->pattern[i] = toupper(fg->pattern[i]);
- } else if (fg->pattern[i] == '.') {
+ switch (fg->pattern[i]) {
+ case '.':
hasDot = i;
if (i < fg->patternLen / 2) {
if (firstHalfDot < 0)
@@ -368,11 +361,23 @@ fastcomp(fastgrep_t *fg, const char *pat
if (firstLastHalfDot < 0)
firstLastHalfDot = i;
}
- } else {
+ break;
+ case '\\':
+ case '[':
+ case '(':
+ case '{':
+ case '?':
+ case '*':
+ case '+':
+ case '|':
/* Free memory and let others know this is empty. */
free(fg->pattern);
fg->pattern = NULL;
return (-1);
+ default:
+ if (iflag)
+ fg->pattern[i] = toupper(fg->pattern[i]);
+ break;
}
}
Re: faster fast grep
Ted Unangst writes:
> For simple patterns, grep has an optimization to avoid regex and run
> about 50% faster. The problem is its idea of simple patterns is too
> simple.
IIUC the idea is to optimize for a lazy user that didn't want to
type grep -F or fgrep:
$ grep foo /bar
$ grep -R foo /baz/
Thus I think it would make sense to test whether ERE are on, since '|',
'+', etc aren't special under BRE.
The following diff also tests for ']', ')' and '}' so that unbalanced
use of those can be catched by regcomp if the latter happens to become
stricter.
Regress passes; does it seem OK?
--
Jérémie Courrèges-Anglas
PGP Key fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
Index: util.c
===
RCS file: /cvs/src/usr.bin/grep/util.c,v
retrieving revision 1.45
diff -u -p -r1.45 util.c
--- util.c 29 Dec 2012 01:32:44 - 1.45
+++ util.c 1 May 2013 02:17:41 -
@@ -348,15 +348,8 @@ fastcomp(fastgrep_t *fg, const char *pat
/* Look for ways to cheat...er...avoid the full regex engine. */
for (i = 0; i < fg->patternLen; i++)
{
- /* Can still cheat? */
- if ((isalnum(fg->pattern[i])) || isspace(fg->pattern[i]) ||
- (fg->pattern[i] == '_') || (fg->pattern[i] == ',') ||
- (fg->pattern[i] == '=') || (fg->pattern[i] == '-') ||
- (fg->pattern[i] == ':') || (fg->pattern[i] == '/')) {
- /* As long as it is good, upper case it for later. */
- if (iflag)
- fg->pattern[i] = toupper(fg->pattern[i]);
- } else if (fg->pattern[i] == '.') {
+ switch (fg->pattern[i]) {
+ case '.':
hasDot = i;
if (i < fg->patternLen / 2) {
if (firstHalfDot < 0)
@@ -368,11 +361,28 @@ fastcomp(fastgrep_t *fg, const char *pat
if (firstLastHalfDot < 0)
firstLastHalfDot = i;
}
- } else {
+ break;
+ case '(': case ')':
+ case '{': case '}':
+ /* Special in BRE if preceded by '\\' */
+ case '?':
+ case '+':
+ case '|':
+ /* Not special in BRE. */
+ if (!Eflag)
+ goto nonspecial;
+ case '\\':
+ case '*':
+ case '[': case ']':
/* Free memory and let others know this is empty. */
free(fg->pattern);
fg->pattern = NULL;
return (-1);
+ default:
+nonspecial:
+ if (iflag)
+ fg->pattern[i] = toupper(fg->pattern[i]);
+ break;
}
}
