Re: DPI for pf(4)

2013-05-01 Thread Franco Fichtner
Hi Stuart, On May 1, 2013, at 1:11 AM, Stuart Henderson 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 Kernels an

Re: DPI for pf(4)

2013-05-01 Thread Franco Fichtner
Hi Ted, On May 1, 2013, at 1:14 AM, 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 Stuart Henderson
On 2013/05/01 09:01, Franco Fichtner wrote: > Hi Stuart, > > On May 1, 2013, at 1:11 AM, Stuart Henderson 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 machin

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 Kernel

Re: DPI for pf(4)

2013-05-01 Thread Franco Fichtner
On May 1, 2013, at 9:41 AM, Stuart Henderson 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 due to parsing

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

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 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 d