On Thu, Feb 22, 2018 at 4:54 AM, David Gwynne wrote:
>
>
>> On 22 Feb 2018, at 5:00 pm, Ayaka Koshibe wrote:
>>
>> On Wed, Feb 21, 2018 at 03:42:58PM +0100, Sebastian Benoit wrote:
>>> Ayaka Koshibe(akosh...@openbsd.org) on 2018.02.20 21:20:20 -0800:
On Tue, Feb 20, 2018 at 4:48 AM, Reyk Flo
* Martin Pieuchot [2018-02-21 09:37]:
> On 21/02/18(Wed) 02:37, Henning Brauer wrote:
> I'd suggest moving the pool allocation and the function in net/pf*.c
> and only have a function call under #if NPF > 0.
worth discussing, but imo that part doesn't really have all that much
to do with pf.
> I
No dice. Still seeing lockup / watchdog reset at some point before consinit().
I guess I'll try messing with the CCR from the bootloader instead to see what
state it's in before transfer-of-control. I still suspect an alignment issue,
as it happens reliably on the kernel images that it happens o
FWIW I've been chasing a failure on beaglebone black where a random subset of
relinked kernels fail to get as far as console init and am pretty flummoxed
about it.
Turning off the strictness might fix whatever issue that was, and save me the
pain of soldering on a JTAG connector and learning Op
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 code for armv7 and later (e.g. NEON code) and
that hand-written assembler c
On Thu, Feb 22, 2018 at 02:13:16PM -0700, Todd C. Miller wrote:
> On Thu, 22 Feb 2018 15:06:04 -0600, Scott Cheloha wrote:
>
> > Could that difference effect the behavior of the program in practice?
>
> I don't think so.
>
> > [...]
> >
> > So unless you or someone else has concerns about breaka
On Thu, 22 Feb 2018 15:06:04 -0600, Scott Cheloha wrote:
> Could that difference effect the behavior of the program in practice?
I don't think so.
> Attached diff is using the file stream functions still, for comparison.
>
> But the dprintf diff feels more natural; keeping the stream functions
>
On Thu, Feb 22, 2018 at 01:09:02PM -0700, Todd C. Miller wrote:
> On Thu, 22 Feb 2018 13:50:13 -0600, Scott Cheloha wrote:
>
> > I think setjmping from a signal handler to put a time limit on
> > pclose is too magical, especially when the alternative doesn't
> > require much more code.
>
> Agreed
On Thu, 22 Feb 2018 13:50:13 -0600, Scott Cheloha wrote:
> I think setjmping from a signal handler to put a time limit on
> pclose is too magical, especially when the alternative doesn't
> require much more code.
Agreed.
> But I do think putting a time limit on our wait for wall to do its
> job
Hey,
I think setjmping from a signal handler to put a time limit on
pclose is too magical, especially when the alternative doesn't
require much more code.
But I do think putting a time limit on our wait for wall to do its
job is a reasonable precaution, though, so:
* Replace popen with pipe/fo
> On 22 Feb 2018, at 5:00 pm, Ayaka Koshibe wrote:
>
> On Wed, Feb 21, 2018 at 03:42:58PM +0100, Sebastian Benoit wrote:
>> Ayaka Koshibe(akosh...@openbsd.org) on 2018.02.20 21:20:20 -0800:
>>> On Tue, Feb 20, 2018 at 4:48 AM, Reyk Floeter wrote:
> Am 20.02.2018 um 11:15 schrieb Klem
Ayaka Koshibe(akosh...@openbsd.org) on 2018.02.21 23:00:22 -0800:
> On Wed, Feb 21, 2018 at 03:42:58PM +0100, Sebastian Benoit wrote:
> > Ayaka Koshibe(akosh...@openbsd.org) on 2018.02.20 21:20:20 -0800:
> > > On Tue, Feb 20, 2018 at 4:48 AM, Reyk Floeter wrote:
> > > >
> > > >> Am 20.02.2018 um 1
On Wed, Feb 21, 2018 at 11:00:22PM -0800, Ayaka Koshibe wrote:
> Ah, right. I hope I can just update the man page to explicitly mention
> this. I've also made it a bit more concise as jmc had suggested.
Looks good and works as advertised in a quick test. ok stsp@
> Index: sbin/ifconfig/ifconfig.8
13 matches
Mail list logo