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 avai
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
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;
> >> + re
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 (co
Ted Unangst 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: unset: KSH_VE
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
fOn Thu, May 02, 2013 at 04:03:05PM +0200, Franco Fichtner wrote:
> On May 2, 2013, at 3:20 PM, Damien Miller 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 no
On May 2, 2013, at 3:20 PM, Damien Miller 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 against some
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?
On May 2, 2013, at 2:40 PM, Damien Miller 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 that smal
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 ran
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 becom
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 u
On May 2, 2013, at 1:23 PM, Damien Miller 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 gues
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
On May 2, 2013, at 10:45 AM, Damien Miller 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 something worth d
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 -
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
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
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:
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 * large_n
Hi Damien,
On May 2, 2013, at 10:03 AM, Damien Miller 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 functions, whic
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 ap
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
24 matches
Mail list logo
