On Fri, Oct 26, 2018 at 09:47:51PM +0200, Mark Kettenis wrote:
> Diff below adds support to uvm to create wtite-combining mappings and
> uses this to implement support for the I915_MMAP_WC flag in
> inteldrm(4). With this diff I can re-enable support for the
> I915_PARAM_MMAP_VERSION.
>
> Please
Hi,
I am sending this email on tech@, as I assume it could be interesting
for base developers to be aware of a slightly difference between ld.bfd
and ld.lld regarding -rpath option (and as I sent a previous mail on
ports@ and not everybody follow ports@).
while I investigated a problem on
> Date: Sat, 27 Oct 2018 10:00:01 +0200
> From: Sebastien Marie
>
> Hi,
>
> I am sending this email on tech@, as I assume it could be interesting
> for base developers to be aware of a slightly difference between ld.bfd
> and ld.lld regarding -rpath option (and as I sent a previous mail on
>
On Wed, Oct 24, 2018 at 05:51:08PM +0200, Anton Lindqvist wrote:
> On Mon, Oct 22, 2018 at 11:05:13AM -0700, Greg Steuck wrote:
> > Hi Reyk & Anton,
> >
> > I upgraded the syzkaller machine from Oct 11 to Oct 21 snapshot and started
> > seeing:
> > Oct 22 10:00:21 ci-openbsd vmd[15707]: qc2_open:
> Date: Sat, 27 Oct 2018 17:16:57 +1100
> From: Jonathan Gray
>
> On Fri, Oct 26, 2018 at 09:47:51PM +0200, Mark Kettenis wrote:
> > Diff below adds support to uvm to create wtite-combining mappings and
> > uses this to implement support for the I915_MMAP_WC flag in
> > inteldrm(4). With this
On Sat, Oct 27, 2018 at 01:01:10PM +0200, Mark Kettenis wrote:
>
> Correct. More recent GNU linkers behave the same way as lld, which is
> why I think the change in behaviour is a good thing.
>
> It is possible to make ld.lld emit DT_RPATH by passing
> -Wl,-disable-new-dtags. And if you pass
When submitting a command in bgplg(8), argument is not kept in its entirety
(split on space) which can be annoying ie. when querying extended community.
Fix this by printing request before splitting.
Index: bgplg.c
===
RCS file:
On Sat, Oct 27, 2018 at 06:28:41PM +0200, Klemens Nanni wrote:
> + } else
> + uidp =
> + ps.huid = -1;
And here I was sloppy. Sorry.
Index: top.c
===
RCS file: /cvs/src/usr.bin/top/top.c,v
retrieving
Reduce four almost identical uid_from_user(3) calls into one by handling
negation once in a way show/hide agnostic way.
I want to add support for UIDs besides usernames, so this diff is a
preliminary cleanup to allow for this feature addition to happen in the
newly introduced function.
The
On Sat, Oct 27, 2018 at 06:05:33PM +0200, Klemens Nanni wrote:
> Reduce four almost identical uid_from_user(3) calls into one by handling
> negation once in a way show/hide agnostic way.
>
> I want to add support for UIDs besides usernames, so this diff is a
> preliminary cleanup to allow for
On Sun, Oct 28, 2018 at 12:58:57AM +0200, Reyk Floeter wrote:
> Most of these are fatal and log_debug. Keep the __func__ there! But we’ll
> remove it from other logging functions where it was never intended to be used
> and potentially reword the warnings nicely.
>
> Reyk
>
Yep.
If I added
On Wed, 24 Oct 2018 16:23:29 +0800, Michael Mikonos wrote:
> On Tue, Oct 23, 2018 at 09:44:24PM -0700, Ori Bernstein wrote:
> > This patch turns most warnings into errors, and uses the
> > appropriate fatal/fatalx so that we don't print bogus error
> > strings. It also adds checks for
On Fri, 26 Oct 2018 01:57:15 +0200, Reyk Floeter wrote:
> On Tue, Oct 23, 2018 at 10:21:08PM -0700, Ori Bernstein wrote:
> > On Mon, 8 Oct 2018 07:59:15 -0700, Bob Beck wrote:
> >
> > > works here and I like it. but probably for after unlock
> > >
> >
> > It's after unlock -- pinging for
Remi Locherer wrote:
> On Fri, Oct 26, 2018 at 10:19:01AM -0600, Theo de Raadt wrote:
> > Remi Locherer wrote:
> >
> > > On Fri, Oct 26, 2018 at 06:01:40PM +0200, Florian Obser wrote:
> > > > This breaks usage of the "include" keyword. Something that all the
> > > > parse.y daemons support.
>
I quite dislike when software uses __func__ to tell me what internal
function had an error.
Why should a user see an error with the string virtio_qcow2_get_base,
qc2_open, qc2_pwrite, etc?
It feels unpolished.
On Sat, 27 Oct 2018 16:15:32 -0600, "Theo de Raadt" wrote:
> I quite dislike when software uses __func__ to tell me what internal
> function had an error.
>
> Why should a user see an error with the string virtio_qcow2_get_base,
> qc2_open, qc2_pwrite, etc?
>
> It feels unpolished.
>
> > I quite dislike when software uses __func__ to tell me what internal
> > function had an error.
> >
> > Why should a user see an error with the string virtio_qcow2_get_base,
> > qc2_open, qc2_pwrite, etc?
> >
> > It feels unpolished.
> >
>
> Possibly, but it is consistent with the rest of
Most of these are fatal and log_debug. Keep the __func__ there! But we’ll
remove it from other logging functions where it was never intended to be used
and potentially reword the warnings nicely.
Reyk
> Am 28.10.2018 um 00:39 schrieb Ori Bernstein :
>
>> On Sat, 27 Oct 2018 16:15:32 -0600,
On Fri, Oct 26, 2018 at 10:19:01AM -0600, Theo de Raadt wrote:
> Remi Locherer wrote:
>
> > On Fri, Oct 26, 2018 at 06:01:40PM +0200, Florian Obser wrote:
> > > This breaks usage of the "include" keyword. Something that all the
> > > parse.y daemons support.
> > >
> >
> > Oh, of course!
> >
On Mon, Oct 08, 2018 at 09:44:35PM +0200, Alexander Bluhm wrote:
> Hi,
>
> On May 14 we did split kernel spinning time from system time. Goal
> was to see what the kernel is doing.
>
> I just realized that user land time accounting has also changed.
> The commit changed system time of a process
20 matches
Mail list logo
