Re: DPI for pf(4)

2013-05-01 Thread Franco Fichtner
Hi Stuart, On May 1, 2013, at 1:11 AM, Stuart Henderson st...@openbsd.org wrote: On 2013/05/01 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

Re: DPI for pf(4)

2013-05-01 Thread Franco Fichtner
Hi Ted, On May 1, 2013, at 1:14 AM, Ted Unangst t...@tedunangst.com wrote: 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

Re: DPI for pf(4)

2013-05-01 Thread Stuart Henderson
On 2013/05/01 09:01, Franco Fichtner wrote: Hi Stuart, On May 1, 2013, at 1:11 AM, Stuart Henderson st...@openbsd.org wrote: On 2013/05/01 00:16, Franco Fichtner wrote: Yes, I am proposing a lightweight approach: hard-wired regex-like code, no allocations, no reassembly or state

Re: DPI for pf(4)

2013-05-01 Thread Jiri B
On Tue, Apr 30, 2013 at 07:14:50PM -0400, Ted Unangst wrote: 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

Re: DPI for pf(4)

2013-05-01 Thread Franco Fichtner
On May 1, 2013, at 9:41 AM, Stuart Henderson st...@openbsd.org wrote: I should have expanded the acronum to make it clear - osfp i.e. the OS fingerprinting code (pf_osfp.c). oh, sorry, my mistake. This I can comment on. :) The idea is the same. I'd say at this stage osfp has more complexity

Re: Test needed: ehci(4) suspend/resume rework

2013-05-01 Thread Ted Unangst
On Sun, Apr 28, 2013 at 15:44, Martin Pieuchot wrote: Diff below is a rework of the suspend/resume logic in ehci(4). In case this diff doesn't help or if you have a problem when resuming, I left an #ifdef 0 block in the DVACT_RESUME. Try enabling it and tell me if it changes something. Got

Re: faster fast grep

2013-05-01 Thread Ted Unangst
On Wed, May 01, 2013 at 04:28, J?r?mie Courr?ges-Anglas wrote: Ted Unangst t...@tedunangst.com 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