Re: multitouch support again

Are there any reviews, tests, OKs, or NOs pending? And if not, may I ask if someone knows a better way to make progress in this area? I'm at a loss here. As far as I can see, I cannot offer a smaller diff; this one contains the minimum that technically makes sense. And as it just adds the basics,

Re: tcp syn cache random reseed

Alexander Bluhm wrote: > On Sat, Mar 19, 2016 at 10:41:06PM +0100, Alexander Bluhm wrote: > > The drawback is that the the cache lookup has to be done in two syn > > caches when an ACK arrives. > > This can be prevented most of the time. Switch the cache only after > 10 uses. So most of the

Re: mpsafe aesni

On 24 March 2016 at 20:53, Mark Kettenis wrote: > Diff below makes aesni crypto "mpsafe". It adds a CRYPTOCAP_F_MPSAFE > flag that makes the crypto framework dispatch to an mpsafe taskq if it > is set. In order to make the aesni_process() function that does the > actual

mpsafe aesni

Diff below makes aesni crypto "mpsafe". It adds a CRYPTOCAP_F_MPSAFE flag that makes the crypto framework dispatch to an mpsafe taskq if it is set. In order to make the aesni_process() function that does the actual crypto work mpsafe, it moves the code over to a per-session working buffer. This

Re: Scheduler hack for multi-threaded processes

> Date: Wed, 23 Mar 2016 22:16:36 +0100 > From: Martin Pieuchot > > On 23/03/16(Wed) 21:35, Mark Kettenis wrote: > > > Date: Mon, 21 Mar 2016 16:51:16 +0100 (CET) > > > From: Mark Kettenis > > > > > > This doesn't only change the sched_yield()

Re: Route priorities missing in route messages

On 03/24/16 15:47, Alexander Bluhm wrote: > On Thu, Mar 24, 2016 at 03:03:18PM +0100, Florian Riehm wrote: >> -void rt_missmsg(int, struct rt_addrinfo *, int, u_int, int, u_int); >> +void rt_missmsg(int, struct rt_addrinfo *, int, u_char, u_int, int, >> u_int); > >>

Re: Route priorities missing in route messages

On Thu, Mar 24, 2016 at 03:03:18PM +0100, Florian Riehm wrote: > -void rt_missmsg(int, struct rt_addrinfo *, int, u_int, int, u_int); > +void rt_missmsg(int, struct rt_addrinfo *, int, u_char, u_int, int, u_int); > -rt_missmsg(int type, struct rt_addrinfo *rtinfo, int flags, u_int ifidx, > -

Route priorities missing in route messages

Hi, Routing daemons like ospfd use two interfaces to obtain route information from the kernel: - sysctl - route messages Route information from sysctl contain correct route priorities, route messages not. This can lead to incorrect routes inside the daemons. If daemons see routes with different

Re: Scheduler hack for multi-threaded processes

On 23/03/16(Wed) 23:58, Alexandre Ratchov wrote: > On Wed, Mar 23, 2016 at 09:35:50PM +0100, Mark Kettenis wrote: > > > > > > This doesn't only change the sched_yield() behaviour, but also > > > modifies how in-kernel yield() calls behave for threaded processes. > > > That is probably not right.

Re: Scheduler hack for multi-threaded processes

On Wed, Mar 23, 2016 at 09:35:50PM +0100, Mark Kettenis wrote: > So here is a diff that keeps yield() the same and adds the code in the > sched_yield(2) implementation instead. I'm going to now run with this diff for a while. On first glance, browser performance is good. Video seems to work well

Re: remove simple lock from arm

Though it seems processing is never set for armish/armv7 which could explain a few things... On Thu, Mar 24, 2016 at 08:51:16PM +1100, Jonathan Gray wrote: > The only user of simple lock on arm is the pxa2x0_do_pending() > code used by zaurus. > > Switch to using a normal static variable like

remove simple lock from arm

The only user of simple lock on arm is the pxa2x0_do_pending() code used by zaurus. Switch to using a normal static variable like i80321intc_do_pending() does for armish and remove simple lock. I've built armv7/armish/zaurus kernels on armv7. I've no zaurus hw to test against. Index:

Heads up: ART enabled in -current

I just enabled ART [0] in -current, it will be the default routing table backend in the next snapshots. The plan is to squash the possible regressions with this new routing table backend then when we're confident enough, take its route lookup out of the KERNEL_LOCK(). Yes, this is one of the big