On 2018 Feb 27 (Tue) at 22:04:15 +0100 (+0100), Mark Kettenis wrote:
:The "new" AAPCS-based ABI that we have been using on armv7 for a while
:now requires various 64-bit types to be aligned on an 8-byte boundary.
:Unfortunately we didn't realize this when we switched and didn't
:adjust the
On Tue, Feb 27, 2018 at 10:04:15PM +0100, Mark Kettenis wrote:
> The "new" AAPCS-based ABI that we have been using on armv7 for a while
> now requires various 64-bit types to be aligned on an 8-byte boundary.
> Unfortunately we didn't realize this when we switched and didn't
> adjust the
On Fri, Feb 23, 2018 at 12:27:14PM -0800, William Ahern wrote:
> The routine skip_empty_lines_and_read_char() is an optimization to skip over
> blocks of comment lines. When it reads an unescaped '#' it uses the helper
> routine skip_to_end_of_line(). But skip_to_end_of_line() doesn't fold lines
>
On Tue, Feb 27, 2018 at 11:04:10PM +0100, Holger Mikolon wrote:
> > hi.
> >
> > i wonder whether we could more simply just use the date format [YY]YY,
> > explain the 2050 cutoff, and forget about mentioning asn.1 time
> > structures.
> >
> > or do you think there is a practical reason why the
> hi.
>
> i wonder whether we could more simply just use the date format [YY]YY,
> explain the 2050 cutoff, and forget about mentioning asn.1 time
> structures.
>
> or do you think there is a practical reason why the user would need to
> know it? i suspect not.
Actually the mentioning of the
Other stuff from my local diffs:
* kernel_text should really be in locore0.S, or in the linker script, right now
I suspect that it would cause random ddb issues because it isn't actually
pointing at the start of the kernel text currently.
* sys/arch/armv7/armv7/armv7_machdep.c:
- msgbufphys
>However, this triggers a flag day. It changes the CMSG ABI, which
>means that file descriptor passing breaks as soon as you boot a new
>kernel with old userland. That sucks since many of our daemons use
>file descriptor passing, including sshd. Can we deal with yet another
>ABI break on armv7?
ethernet likes to attach a struct to RTF_LLINFO routes in things
like ether_rtrequest/arp_rtrequest, and then deref that struct
unconditionally in a ether_output/arpresolve.
if that struct cannot be allocated in arp_rtrequest, we should
report failure and let the routing layer unwind.
this is a
On Tue, Feb 27, 2018, at 3:40 PM, Mark Kettenis wrote:
> > Date: Tue, 27 Feb 2018 22:30:43 +0100 (CET)
> > From: Mark Kettenis
> >
> > > From: Brandon Bergren
> > > Date: Tue, 27 Feb 2018 15:05:43 -0600
> > >
> > > Oh geez, I just figured
> Date: Tue, 27 Feb 2018 22:30:43 +0100 (CET)
> From: Mark Kettenis
>
> > From: Brandon Bergren
> > Date: Tue, 27 Feb 2018 15:05:43 -0600
> >
> > Oh geez, I just figured out what my own crash was -- svcstk is not
> > being aligned properly in
On Tue, Feb 27, 2018 at 08:54:48PM +0100, Holger Mikolon wrote:
> When playing with "openssl ca" with various validity end dates I could
> not manage end dates of 2050 or later - until I started reading code and
> the RFC 5280. As far as I understand it now (and is confirmed by various
> tests),
> From: Brandon Bergren
> Date: Tue, 27 Feb 2018 15:05:43 -0600
>
> Oh geez, I just figured out what my own crash was -- svcstk is not
> being aligned properly in sys/arch/arm/arm/locore.S, so depending on
> the link order, the address of the service stack could be in
Oh geez, I just figured out what my own crash was -- svcstk is not being
aligned properly in sys/arch/arm/arm/locore.S, so depending on the link order,
the address of the service stack could be in some random place in .bss. I
*think* it's supposed to be .align 8 anyway to be
The "new" AAPCS-based ABI that we have been using on armv7 for a while
now requires various 64-bit types to be aligned on an 8-byte boundary.
Unfortunately we didn't realize this when we switched and didn't
adjust the definition of _ALIGNBYTES accordingly. The diff below
fixes that.
However,
> Date: Tue, 27 Feb 2018 23:09:24 +1100
> From: Jonathan Gray
>
> On Thu, Feb 22, 2018 at 10:51:12PM +0100, Mark Kettenis wrote:
> > I hate to loose yet another strict-alignment canary, but the reality
> > is that the rest of the world assumes that armv7 supports unaligned
> >
When playing with "openssl ca" with various validity end dates I could
not manage end dates of 2050 or later - until I started reading code and
the RFC 5280. As far as I understand it now (and is confirmed by various
tests), the openssl parameter "-enddate" expects one of two date/time
formats -
On Mon, 26 Feb 2018 19:12:20 -0600, Scott Cheloha wrote:
> Reading the latest POSIX description for times(3):
>
> > Upon successful completion, times() shall return the elapsed
> > real time, in clock ticks, since an arbitrary point in the past
> > (for example, system start-up time). This point
On Thu, Feb 22, 2018 at 10:51:12PM +0100, Mark Kettenis wrote:
> I hate to loose yet another strict-alignment canary, but the reality
> is that the rest of the world assumes that armv7 supports unaligned
> access which means that compilers generate code that assumes this
> works when compiling
Hi there,
the 'l' command in base ed currently does not mark the end of line with a '$'.
This is documented in the man page (POSIX wants each '$' escaped, and a final
'$' at EOL). Interestingly, the code to mark EOL is already there, just hidden
by the BACKWARDS flag ed is compiled with.
On 02/27/18 09:06, Stefan Sperling wrote:
> On Mon, Feb 26, 2018 at 11:55:34PM +0100, j...@posteo.de wrote:
>> When connecting to a wifi network messages like "iwm0: unhandled firmware
>> response 0xff/0xb810 rx ring" appear.
>> After looking at https://patchwork.kernel.org/patch/9869017/ I
On Tue, Feb 27, 2018 at 10:22:46AM +0100, Mark Kettenis wrote:
> > Date: Tue, 27 Feb 2018 18:47:42 +1100
> > From: Jonathan Gray
> >
> > On Mon, Feb 26, 2018 at 10:08:12PM +0100, Mark Kettenis wrote:
> > > There is a new rgepy(4) variant (rev. 6, RTL8211F). Unfortunately
> > >
On Mon, Feb 26, 2018 at 11:55:34PM +0100, j...@posteo.de wrote:
> When connecting to a wifi network messages like "iwm0: unhandled firmware
> response 0xff/0xb810 rx ring" appear.
> After looking at https://patchwork.kernel.org/patch/9869017/ I came up with
> following patch.
> The link also
22 matches
Mail list logo