On Mon, Oct 19, 2020 at 3:13 PM Tom Rollet wrote:
> Hi,
>
> I'm starting to help in the development of the dt device.
>
> I'm stuck on permission handling of memory. I'm trying to allocate a
> page in kernel with read/write protections, fill the allocated page
> with data then change the
On Fri, Oct 02, 2020 at 12:33:15PM -0700, Bryan Vyhmeister wrote:
> On Wed, Sep 30, 2020 at 04:05:51PM -0700, Bryan Vyhmeister wrote:
> > Gerhard Roth provided a patch to me to get the Qualcomm Snapdragon X20
> > umb(4) interface in my Dell Latitude 7300 working. It is also known as a
> > Dell
On Mon, Oct 19, 2020 at 07:16:46PM +1000, David Gwynne wrote:
> On Mon, Oct 19, 2020 at 10:03:29AM +0100, Stuart Henderson wrote:
> > On 2020/10/19 11:47, David Gwynne wrote:
> > > On Sun, Oct 18, 2020 at 08:57:34PM +0100, Stuart Henderson wrote:
> > > > On 2020/10/18 14:04, David Gwynne wrote:
>
Hi,
I'm starting to help in the development of the dt device.
I'm stuck on permission handling of memory. I'm trying to allocate a
page in kernel with read/write protections, fill the allocated page
with data then change the permissions to read/exec.
Snippet of my code:
addr =
Hello Klemens,
> > the change is fairly large, but mostly mechanical.
> Relocating malloc(9) and pool(9) seems good but other pf_*() calls are
> now locked inconsistently after your diff.
>
> Given that only reason about "allocations" this is either an oversight
> and should be fixed or you
On Mon, Oct 19, 2020 at 12:33:25PM +0100, Stuart Henderson wrote:
> On 2020/10/19 19:53, David Gwynne wrote:
> > On Mon, Oct 19, 2020 at 09:34:31AM +0100, Stuart Henderson wrote:
> > > On 2020/10/19 15:35, David Gwynne wrote:
> > > > every few years i try and use route-to in pf, and every time it
On Mon, 19 Oct 2020 22:06:52 +0200, Christian Weisgerber wrote:
> The patch below aligns the function prototypes with POSIX. All
> resulting warnings "passing 'const char *' to parameter of type
> 'char *' discards qualifiers" in the base system have been cleaned
> up. It successfully passes
On Mon, Oct 19, 2020 at 10:06:52PM +0200, Christian Weisgerber wrote:
> [Picking this up again after a month:]
>
> Our basename(3) and dirname(3) take a const argument:
>
> char*basename(const char *);
> char*dirname(const char *);
>
> POSIX says otherwise...
>
> char
[Picking this up again after a month:]
Our basename(3) and dirname(3) take a const argument:
char*basename(const char *);
char*dirname(const char *);
POSIX says otherwise...
char *basename(char *path);
char *dirname(char *path);
... and explicitly says the functions may modify
On Sat, 17 Oct 2020 00:15:54 +0200, Christian Weisgerber wrote:
> Accommodate POSIX basename(3) that takes a non-const parameter and
> may modify the string buffer.
>
> There were only two compiler warnings about discarded const, but
> there are numerous instances where the code assumes non-POSIX
> Date: Mon, 19 Oct 2020 20:03:01 +0200
> From: Christian Weisgerber
>
> This decodes the UDF ("permanently undefined") instruction in ddb's
> arm64 disassembler. The particular immediate16 format appears to
> be unique to this instruction.
>
> OK? Or don't bother?
ok kettenis@
> Index:
This decodes the UDF ("permanently undefined") instruction in ddb's
arm64 disassembler. The particular immediate16 format appears to
be unique to this instruction.
OK? Or don't bother?
Index: arch/arm64/arm64/disasm.c
===
RCS
Hi,
i noticed that the mouse movement on my powermac can be pretty jittery at times.
One of the reasons I have identified is our use of a position change threshold.
The driver ignores all finger position changes below a certain threshold.
If the finger position change is > threshold it is used
> From: "Theo de Raadt"
> Date: Mon, 19 Oct 2020 09:25:30 -0600
>
> Mark Kettenis wrote:
>
> > > Date: Mon, 19 Oct 2020 16:36:14 +0200
> > > From: Christian Weisgerber
> > >
> > > Belatedly, ARM has taken a slice of the reserved opcode space and
> > > assigned it as a properly defined
Mark Kettenis wrote:
> > Date: Mon, 19 Oct 2020 16:36:14 +0200
> > From: Christian Weisgerber
> >
> > Belatedly, ARM has taken a slice of the reserved opcode space and
> > assigned it as a properly defined illegal instruction, udf #imm16.
> > (Armv8 Architecture Reference Manual, edition F.c,
> Date: Mon, 19 Oct 2020 16:36:14 +0200
> From: Christian Weisgerber
>
> Belatedly, ARM has taken a slice of the reserved opcode space and
> assigned it as a properly defined illegal instruction, udf #imm16.
> (Armv8 Architecture Reference Manual, edition F.c, section C6.2.335).
> Clang already
Thanks for finding a better instruction!
ok deraadt
Christian Weisgerber wrote:
> Belatedly, ARM has taken a slice of the reserved opcode space and
> assigned it as a properly defined illegal instruction, udf #imm16.
> (Armv8 Architecture Reference Manual, edition F.c, section C6.2.335).
>
Belatedly, ARM has taken a slice of the reserved opcode space and
assigned it as a properly defined illegal instruction, udf #imm16.
(Armv8 Architecture Reference Manual, edition F.c, section C6.2.335).
Clang already knows about it.
We really should use this instead of picking something ad-hoc
On Sat, Oct 17, 2020 at 05:52:58PM +0200, Jan Stary wrote:
> Currently, mixerctl.conf(5) says
>
> Most devices have a number of digital to analogue converters
> (DACs), used for sound playback, and each DAC has a corresponding
> output mixer. The mixers are labelled “mix” or
On 2020/10/19 19:53, David Gwynne wrote:
> On Mon, Oct 19, 2020 at 09:34:31AM +0100, Stuart Henderson wrote:
> > On 2020/10/19 15:35, David Gwynne wrote:
> > > every few years i try and use route-to in pf, and every time it
> > > goes badly. i tried it again last week in a slightly different
> > >
On Mon, Oct 19, 2020 at 12:28:19PM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
>
> > >
> > > it seems to me 'route-to vs. pfsync' still needs more thought. the
> > > next-hop IP address in route-to may be different for each PF box
> > > linked by pfsync(4). To be honest I have no
Hello,
> >
> > it seems to me 'route-to vs. pfsync' still needs more thought. the
> > next-hop IP address in route-to may be different for each PF box
> > linked by pfsync(4). To be honest I have no answer to address this
> > issue at the moment.
>
> i have thought about that
On Mon, Oct 19, 2020 at 09:34:31AM +0100, Stuart Henderson wrote:
> On 2020/10/19 15:35, David Gwynne wrote:
> > every few years i try and use route-to in pf, and every time it
> > goes badly. i tried it again last week in a slightly different
> > setting, and actually tried to understand the
On Mon, Oct 19, 2020 at 09:46:19AM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
> disclaimer: I have no chance to run pfsync on production, I'm very
> inexperienced with pfsync(4).
i wrote the defer code in pfsync, and i think i wrote the code in
pfsync that calls pf_route badly, so noones
On Mon, Oct 19, 2020 at 10:03:29AM +0100, Stuart Henderson wrote:
> On 2020/10/19 11:47, David Gwynne wrote:
> > On Sun, Oct 18, 2020 at 08:57:34PM +0100, Stuart Henderson wrote:
> > > On 2020/10/18 14:04, David Gwynne wrote:
> > > > the problem i'm hitting is that i have a multihomed box where
On 2020/10/19 11:47, David Gwynne wrote:
> On Sun, Oct 18, 2020 at 08:57:34PM +0100, Stuart Henderson wrote:
> > On 2020/10/18 14:04, David Gwynne wrote:
> > > the problem i'm hitting is that i have a multihomed box where the
> > > service it provides listens on an IP address that's assigned to
Diff below is the second part of the refactoring [0] that got committed
then reverted 6 months ago.
The idea of this refactoring is to move the accounting and markers used
when collecting events to a context (struct kqueue_scan_state) such that
the collecting routine (kqueue_scan()) can be called
On 2020/10/19 15:35, David Gwynne wrote:
> every few years i try and use route-to in pf, and every time it
> goes badly. i tried it again last week in a slightly different
> setting, and actually tried to understand the sharp edges i hit
> this time instead of giving up. it turns out there are 2
> Date: Mon, 19 Oct 2020 10:00:49 +0200
> From: Martin Pieuchot
>
> uao_init() is called from uvm_km_init() which itself is called by
> uvm_init(). None of the *init() functions in UVM have a guard, so be
> coherent and remove this one.
>
> ok?
Yes, that seems redundant.
ok kettenis@
>
uvm_fault() is one of the most contended "entry point" of the kernel.
To reduce this contention I'm carefully refactoring this code to be able
to push the KERNEL_LOCK() inside the fault handler.
The first aim of this project would be to get the upper layer faults
(cases 1A and 1B) out of ze big
uao_init() is called from uvm_km_init() which itself is called by
uvm_init(). None of the *init() functions in UVM have a guard, so be
coherent and remove this one.
ok?
Index: uvm/uvm_aobj.c
===
RCS file:
Hello,
disclaimer: I have no chance to run pfsync on production, I'm very
inexperienced with pfsync(4).
>
> the third problem is that pf_route relies on information from rules to
> work correctly. this is a problem in a pfsync environment because you
> cannot have the same ruleset on both
32 matches
Mail list logo
