Re: [patch] cleanup vi

On Sat, Jan 23, 2016 at 01:45:05AM -0500, Michael McConville wrote: > Vadim Zhukov wrote: > > 2016-01-22 23:18 GMT+03:00 Martijn van Duren > > : > > > 5) 5_vi_remove_v_strdup.diff: Use strdup instead of v_strdup. > > > > Not okay: MALLOC macro prints information message to user, while > > patched

Re: [patch] cleanup vi

Vadim Zhukov wrote: > 2016-01-22 23:18 GMT+03:00 Martijn van Duren > : > > 5) 5_vi_remove_v_strdup.diff: Use strdup instead of v_strdup. > > Not okay: MALLOC macro prints information message to user, while > patched version isn't. I think refactoring shouldn't have such visible > impact on functi

Re: [patch] cleanup vi

from part 3: > diff --git cl/cl_main.c cl/cl_main.c > index ed4abda..cc48ad3 100644 > --- cl/cl_main.c > +++ cl/cl_main.c > @@ -19,6 +19,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -36,7 +37,7 @@ sigset_t __sigblockset;

Re: diff: httpd: add client side certificate checks

ping On Fri, Jan 15, 2016 at 12:54:55PM +0100, Jan Klemkow wrote: > Hi, > > this diff adds client side certificate checks to httpd. Most parts > are straight forward. But, to transfer the whole certificate > authority store to the server process through the imsg infrastructure > I had to change

Firefox, malloc(3) and threads

Firefox makes a lot of concurrent malloc(3) calls. The locking to make malloc(3) thread-safe is a bit...suboptimal. This diff makes things better by using a mutex instead of spinlock. If you're running Firefox you want to try it; it makes video watchable on some machines. If you're not running F

Re: [patch] cleanup vi

2016-01-22 23:18 GMT+03:00 Martijn van Duren : > Hello tech@, > > Attached are 6 patches to do some initial cleanup in vi (these complement > the perr patch that got comitted earlier). They are intended to be applied > in sequential order, because there may be slight overlap, but they (almost) > al

arm: handle hypervisor mode

Hi, the hypervisor mode, which virtualization-enabled boards might boot in, is basically a privilege level above the usual SVC mode the kernel is running in. It does not support the full instruction set and we, as a "guest" OS, need to step down and run in SVC. Otherwise we crash really early on

[patch] cleanup vi

Hello tech@, Attached are 6 patches to do some initial cleanup in vi (these complement the perr patch that got comitted earlier). They are intended to be applied in sequential order, because there may be slight overlap, but they (almost) all do more or less the same thing: Remove custom code

Re: Checking MAC address of incoming unicast packets

On Fri, Jan 22, 2016 at 10:47:09AM +0100, Martin Pieuchot wrote: > On 22/01/16(Fri) 08:42, Stefan Fritsch wrote: > > As there isn't any consensus for one of the other solutions, I am going to > > commit the patch that fixes this inside vio(4). > > I think that you should commit the diff that does

Re: [calendar] Addition of a New Zealand holiday file

On Fri, Jan 22, 2016 at 12:35:43PM +, Craig Skinner wrote: > On 2016-01-22 Fri 13:50 PM |, Peter Kane wrote: > > Hi Craig > > > > I don't want to file this as a bug but I think New Plymouth Anniversary Day > > would be better described as Taranaki Anniversay Day. I've never seen it > > descr

Use uiomove() in if_tun and if_pppx

The following diff prevents integer truncation of uio_resid by using ulmin() instead of min() and calls uiomove() instead of the legacy uiomove(). That's straightforward because the m_len mbuf field is unsigned. mlen can be turned to a size_t because it's set to MLEN or MCLBYTES, which is > 0. I

arm: update processor mode defines

Hi, ARM(v7) has gained two new processor modes: Hyp and Monitor. The Hyp mode is especially interesting as it is part of the Virtualization Extensions. On boards that support it, the kernel is usually booted in HYP mode. Currently HYP mode is not handled, which means that virtualization-enabled

Re: dev/video.c uiomove() conversion

Martin Natano wrote: > Below is a diff to convert videoread() to use uiomove() instead of > uiomovei(). Note, that passing sc_fsize to ulmin() is not problematic, > even though it is an int, because the value is always positive. Yes, sc_fsize *should* always be positive. I had to convince myself t

Re: mg: display wide characters

Oh goodness. My recollection is that 1 byte per character is assumed all over the place. This is going to take a *while* to test properly. Maybe this is a good time for me to start looking at mg again... On Thursday, 21 January 2016, Mark Lumsden wrote: > I am busy for the next month or so, but

Re: [calendar] Addition of a New Zealand holiday file

On 2016-01-22 Fri 13:50 PM |, Peter Kane wrote: > Hi Craig > > I don't want to file this as a bug but I think New Plymouth Anniversary Day > would be better described as Taranaki Anniversay Day. I've never seen it > described as anything else on a New Zealand calendar (especially while living >

Re: Checking MAC address of incoming unicast packets

On 22/01/16(Fri) 08:42, Stefan Fritsch wrote: > As there isn't any consensus for one of the other solutions, I am going to > commit the patch that fixes this inside vio(4). I think that you should commit the diff that does it unconditionally. If people are concerned about the supplementary cycle