On Mon, Apr 18, 2016 at 07:11:46PM -0400, Christian Heckendorf wrote:
> Hi,
> After reading the man page description of tr -s, I couldn't understand
> what it meant to "squeeze" characters. It could be that 'squeeze' is a
> mnemonic for '-s' but it's not helpful as a technical explanation.
>
> --
I noticed these stragglers today and assumed I missed a step in an upgrade then
realized this laptop never had anything older than 5.8.
Index: upgrade57.html
===
RCS file: /cvs/www/faq/upgrade57.html,v
retrieving revision 1.15
diff
Hi,
After reading the man page description of tr -s, I couldn't understand
what it meant to "squeeze" characters. It could be that 'squeeze' is a
mnemonic for '-s' but it's not helpful as a technical explanation.
--
Christian
Index: tr.1
==
> From: Mike Belopuhov
> Date: Tue, 12 Apr 2016 15:33:42 +0200
>
> >> > Another question I have is why are you using an IPL_HIGH mutex?
> >>
> >> The crypto code may be called from any subsystem, so that is the only
> >> safe choice.
> >
> > Well, it's not called from all subsystems, just those th
On 2016/04/18 20:40, Martin Natano wrote:
> I have bumping bpf_timeval to 64bit on my todo list too. However I'm not
> sure what the best course of action is there. Replacing bpf_timeval with
> timeval might be problematic, because that means bpf wouldn't be binary
> stable across platforms. (tv_us
On Sat, Apr 16, 2016 at 11:10:14AM +0100, Stuart Henderson wrote:
> On 2016/04/15 23:07, Philip Guenther wrote:
> > On Thu, Apr 14, 2016 at 3:15 PM, Martin Natano wrote:
> > > In rbootd a struct bpf_timeval (with 32bit tv_sec) is copied to a struct
> > > timeval (with 64 tv_sec) via bcopy(). This
On Mon, Apr 18, 2016 at 08:36:58AM +0200, Martin Pieuchot wrote:
> On 11/04/16(Mon) 15:29, Martin Pieuchot wrote:
> > Instead of rtfree(9)ing the cached route after using it, if it is a
> > multipath one, free it before.
> >
> > Ok?
>
> Anyone?
>
Make stuff simpler. OK claudio@
> > Index: neti
It's currently very difficult to set a breakpoint in ddb(4) and have
it work as expected on a function called in interrupt context on ppc.
The problem is that ``ddbtrap'' uses the FRAME_SETUP() macro which
contains a hack for the idle loop. Because of this hack the return
address of the saved fra
On 18 April 2016 at 15:40, Martin Pieuchot wrote:
> On 18/04/16(Mon) 12:30, Mike Belopuhov wrote:
>> On Mon, Apr 11, 2016 at 15:29 +0200, Martin Pieuchot wrote:
>> > Instead of rtfree(9)ing the cached route after using it, if it is a
>> > multipath one, free it before.
>> >
>> > Ok?
>> >
>>
>> Thi
On 18.4.2016. 15:31, Hrvoje Popovski wrote:
> On 18.4.2016. 10:50, Martin Pieuchot wrote:
>> The current goal of the Network SMP effort is to have a single CPU
>> process the IP forwarding path in a process context without holding
>> the KERNEL_LOCK(). To achieve this goal we're progressively movi
On 18/04/16(Mon) 12:30, Mike Belopuhov wrote:
> On Mon, Apr 11, 2016 at 15:29 +0200, Martin Pieuchot wrote:
> > Instead of rtfree(9)ing the cached route after using it, if it is a
> > multipath one, free it before.
> >
> > Ok?
> >
>
> This changes the case where ipforward_rt.ro_rt is NULL and
> t
On 18.4.2016. 10:50, Martin Pieuchot wrote:
> The current goal of the Network SMP effort is to have a single CPU
> process the IP forwarding path in a process context without holding
> the KERNEL_LOCK(). To achieve this goal we're progressively moving
> code from the softnet interrupt context to t
> 2 packets transmitted, 0 packets received, 100.0% packet loss :)
I see many people are doing something in persistent memory
subsystems now. Maybe this diff could get some attention now
as well. :) Resending the whole thing.
--
WBR,
Vadim Zhukov
Index: bioctl.c
==
On Mon, Apr 11, 2016 at 15:29 +0200, Martin Pieuchot wrote:
> Instead of rtfree(9)ing the cached route after using it, if it is a
> multipath one, free it before.
>
> Ok?
>
This changes the case where ipforward_rt.ro_rt is NULL and
the route that we allocate is RTF_MPATH (is that possible?).
Befo
On 18/04/16(Mon) 11:33, Mark Kettenis wrote:
> [...]
> However, this diff uses the same taskq for both the "unlocked" and
> "locked" parts. My experience with crypto code was that frequently
> grabbing and releasing the kernel lock did affect latency in a bad
> way. Some time ago dlg@ had a some
On 17/04/16 20:42, Mark Kettenis wrote:
> Ran into an interesting problem with the sparc64 pmap bootstrapping
> code. Early on, we ask the firmware what physical memory is
> available. Later we use this memory to set up the kernel page tables,
> kernel stack and per-cpu data structures. We expl
> Date: Mon, 18 Apr 2016 10:50:46 +0200
> From: Martin Pieuchot
>
> The current goal of the Network SMP effort is to have a single CPU
> process the IP forwarding path in a process context without holding
> the KERNEL_LOCK(). To achieve this goal we're progressively moving
> code from the softne
On 18/04/16(Mon) 00:22, Marcus Glocker wrote:
> On Sun, Apr 17, 2016 at 11:33:18PM +0200, Olivier Cherrier wrote:
>
> > With this diff, the fans go at their maximun speed and stay like that:
> > $ sysctl hw.sensors
> > hw.sensors.smu0.temp0=31.75 degC (CPU T-Diode)
> > hw.sensors.smu0.
The current goal of the Network SMP effort is to have a single CPU
process the IP forwarding path in a process context without holding
the KERNEL_LOCK(). To achieve this goal we're progressively moving
code from the softnet interrupt context to the if_input_task. In
the end we'll completely get r
On 2016-04-17 Tim Baumgard wrote:
>
> Below is an updated diff for the man page to address your feedback. I
> also included another small diff that fixes the QUERY_STRING variable
> when no query string is given. The RFC states:
>
> The server MUST set this variable; if the Script-URI does not i
20 matches
Mail list logo