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

2013-05-02 Thread Martin Pieuchot
On 01/05/13(Wed) 17:44, Ted Unangst wrote: 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

Re: DPI for pf(4)

2013-05-02 Thread Damien Miller
On Wed, 1 May 2013, Franco Fichtner wrote: Not sure if that's a fitting comparison; and I know too little OSPF to answer. Let me try another route. The logic consists of an array of application detection functions, which can be invoked via their respective IP types. I don't like this

Re: DPI for pf(4)

2013-05-02 Thread Franco Fichtner
Hi Damien, On May 2, 2013, at 10:03 AM, Damien Miller d...@mindrot.org wrote: On Wed, 1 May 2013, Franco Fichtner wrote: Not sure if that's a fitting comparison; and I know too little OSPF to answer. Let me try another route. The logic consists of an array of application detection

Re: DPI for pf(4)

2013-05-02 Thread Damien Miller
On Thu, 2 May 2013, Franco Fichtner wrote: as stated before, breaking down complexity to the bare minimum is my requirement for this to be happening at all. You all get to be the judges. I'm just trying to work on something worth doing. Well, bare minimum complexity per-protocol *

Re: [NEW] ugold(4) driver for Microdia's USB TEMPer variant

2013-05-02 Thread Martin Pieuchot
On 30/04/13(Tue) 17:39, Stuart Henderson wrote: 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@. Some comments inline. Index:

Re: DPI for pf(4)

2013-05-02 Thread Stuart Henderson
On 2013/05/02 18:03, Damien Miller wrote: I find C to be quite flexible and empowering if one doesn't overcomplicate[2]. [2] https://github.com/fichtner/OpenDPI/blob/master/src/lib/protocols/ssl.c That's complicated and scary code for a kernel, e.g. multiple opportunities for unsigned

Re: DPI for pf(4)

2013-05-02 Thread Alexandre Ratchov
On Thu, May 02, 2013 at 10:35:19AM +0200, Franco Fichtner wrote: as stated before, breaking down complexity to the bare minimum is my requirement for this to be happening at all. You all get to be the judges. I'm just trying to work on something worth doing. The last thing we want it a

stop gcc warning about missing newlines at eof

2013-05-02 Thread Jonathan Gray
upstream gcc stopped warning about missing newlines at eof five years ago, here is a diff to do the same for our gcc3/gcc4. Index: gcc/libcpp/lex.c === RCS file: /cvs/src/gnu/gcc/libcpp/lex.c,v retrieving revision 1.1.1.1 diff -u -p

Re: DPI for pf(4)

2013-05-02 Thread Franco Fichtner
On May 2, 2013, at 10:45 AM, Damien Miller d...@mindrot.org wrote: On Thu, 2 May 2013, Franco Fichtner wrote: as stated before, breaking down complexity to the bare minimum is my requirement for this to be happening at all. You all get to be the judges. I'm just trying to work on

Re: DPI for pf(4)

2013-05-02 Thread Damien Miller
On Thu, 2 May 2013, Franco Fichtner wrote: Well, bare minimum complexity per-protocol * large_number_of_protocols = a lot of complexity. The incentive is always going to be to add more protocols and never retire them. I guess that's true for most software projects. We try not to

Re: DPI for pf(4)

2013-05-02 Thread Franco Fichtner
On May 2, 2013, at 1:23 PM, Damien Miller d...@mindrot.org wrote: On Thu, 2 May 2013, Franco Fichtner wrote: Well, bare minimum complexity per-protocol * large_number_of_protocols = a lot of complexity. The incentive is always going to be to add more protocols and never retire them. I

Behaviour of ksh(1)

2013-05-02 Thread Daode
Hi, you should try echo BEFORE unset KSH_VERSION echo AFTER in your ~/.shrc (note: i include that from within my ~/.profile and let it auto-protect itself against multiple inclusions since my shell startup scripts are multi-platform multi-shell, all in two). Note it doesn't matter if you

Re: DPI for pf(4)

2013-05-02 Thread Damien Miller
On Thu, 2 May 2013, Franco Fichtner wrote: Moving implementations to user space does not necessarily make them better or less of a problem. The big difference is that its possible to sandbox a userspace implementation so that small integer overflow bugs or length checking failures don't become

Re: DPI for pf(4)

2013-05-02 Thread Damien Miller
On Thu, 2 May 2013, Franco Fichtner wrote: OK, the implementation only pulls a couple of bytes from the packet's payload. It will never pull bytes that are not verified. It will never allocate anything. It will never test against something that's neither hard-coded nor available in the range

Re: DPI for pf(4)

2013-05-02 Thread Franco Fichtner
On May 2, 2013, at 2:40 PM, Damien Miller d...@mindrot.org wrote: On Thu, 2 May 2013, Franco Fichtner wrote: Moving implementations to user space does not necessarily make them better or less of a problem. The big difference is that its possible to sandbox a userspace implementation so

Re: Behaviour of ksh(1)

2013-05-02 Thread Ted Unangst
On Thu, May 02, 2013 at 13:12, Steffen Daode Nurpmeso wrote: Hi, you should try echo BEFORE unset KSH_VERSION echo AFTER ksh: unset: KSH_VERSION is read only So don't unset it?

Re: DPI for pf(4)

2013-05-02 Thread Franco Fichtner
On May 2, 2013, at 3:20 PM, Damien Miller d...@mindrot.org wrote: On Thu, 2 May 2013, Franco Fichtner wrote: OK, the implementation only pulls a couple of bytes from the packet's payload. It will never pull bytes that are not verified. It will never allocate anything. It will never test

Re: DPI for pf(4)

2013-05-02 Thread Otto Moerbeek
fOn Thu, May 02, 2013 at 04:03:05PM +0200, Franco Fichtner wrote: On May 2, 2013, at 3:20 PM, Damien Miller d...@mindrot.org wrote: On Thu, 2 May 2013, Franco Fichtner wrote: OK, the implementation only pulls a couple of bytes from the packet's payload. It will never pull bytes that

UPDATE: xf86-input-synaptics 1.7.0

2013-05-02 Thread Alexandr Shadchin
Hi, This update xf86-input-synaptics to the latest release 1.7.0. http://koba.devio.us/distfiles/xf86-input-synaptics-1.7.0.diff Tested on amd64 and i386. Comments ? OK ? -- Alexandr Shadchin

Re: Behaviour of ksh(1)

2013-05-02 Thread Daode
Ted Unangst t...@tedunangst.com wrote: |On Thu, May 02, 2013 at 13:12, Steffen Daode Nurpmeso wrote: | Hi, you should try | | echo BEFORE | unset KSH_VERSION | echo AFTER | |ksh: unset: KSH_VERSION is read only | |So don't unset it? Yep it's nasty hah. Still, you get BEFORE ksh:

Re: [NEW] ugold(4) driver for Microdia's USB TEMPer variant

2013-05-02 Thread SASANO Takayoshi
Hello, sorry for late reply. wow, there is many comments... But anyway, I think that in your case you don't need it. Why don't you update directly your sensor values when you receive the data in ugold_intr() instead of copying to a intermediate buffer? The device always works command

Re: [NEW] ugold(4) driver for Microdia's USB TEMPer variant

2013-05-02 Thread Stuart Henderson
On 2013/05/02 23:57, SASANO Takayoshi wrote: +int +ugold_issue_cmd(struct ugold_softc *sc, uint8_t *cmd, int len, int delay) +{ + usb_device_request_t req; + + bzero(sc-sc_ibuf, sc-sc_ilen); + + req.bmRequestType = UT_WRITE_CLASS_INTERFACE; + req.bRequest = UR_SET_REPORT;

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

2013-05-02 Thread patrick keshishian
On Tue, Apr 30, 2013 at 09:51:21AM +0200, Martin Pieuchot wrote: 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

Re: DPI for pf(4)

2013-05-02 Thread Damien Miller
On Thu, 2 May 2013, Damien Miller wrote: You've just described bpf, right down to no endless loops and the amount of data it returns. For a little more code that it takes to write one packet parser (basically: loading bpf rules from pf and making the bpf_filter()'s return value available