Just forgot to pass the disk during sparc64 tests and was surprised to
see it treating a file as disk:
# installboot -nv /usr/mdec/bootblk /ofwboot.test
Using / as root
would install bootstrap on ./usr/mdec/bootblk
using first-stage ./ofwboot.test, second-stage /usr
On Fri, Aug 19, 2022 at 10:31:30PM -0400, Daniel Dickman wrote:
> The below diff removes detection code for the Cyrix 486DLC and Cyrix 6x86
> CPUs from OpenBSD/i386.
>
> The Cyrix 486DLC is a 486-class CPU which we no longer support.
>
> The 6x86, also known as the M1, does not support CPUID by def
The below diff removes detection code for the Cyrix 486DLC and Cyrix 6x86
CPUs from OpenBSD/i386.
The Cyrix 486DLC is a 486-class CPU which we no longer support.
The 6x86, also known as the M1, does not support CPUID by default. But it
can be made to support this instruction if bit 7 in CCR4 is
On Fri, Aug 19, 2022 at 12:42 PM Vitaliy Makkoveev wrote:
> bluhm@ pointed, that many KASSERT()s are not welcomed, so I didn't
> insert them into newly introduced handlers. Anyway except the tcp(4)
> protocol, `so_pcb' cant be NULL here. But the socket lock assertion
> looks reasonable.
>
> Some
Subj. Start the (*pru_usrreq)() split.
bluhm@ pointed, that many KASSERT()s are not welcomed, so I didn't
insert them into newly introduced handlers. Anyway except the tcp(4)
protocol, `so_pcb' cant be NULL here. But the socket lock assertion
looks reasonable.
Some unp_*() functions could be merg
Hi,
This diff allows to run udp_input() in parallel. It consists of
three major parts.
- Use PR_MPSAFE flag to protocol deliver loop with shared
netlock. Queue packet and switch to deliver loop with exclusive
netlock, of a protocol is not MP safe.
- Use a rwlock to protect the inp_notify f
On Mon, Aug 15, 2022 at 01:00:22PM +0200, Jeremie Courreges-Anglas wrote:
Hello Jeremie,
[RTLD_NOLOAD from Stuart]
> I think so. The code looks good, would support a valid (IMO) use case and
> would get us rid of a few patches and possibly blocking problems in ports.
>
> ok jca@
>
> (I'm not sur
On Fri, Aug 19, 2022 at 06:35:26PM +, Klemens Nanni wrote:
> opendev(3) takes a const char *, just what getinfo() provides.
>
> I see no point in casting away the const; no amd64 object change.
> OK?
const was added in opendev.c r1.12 in 2012, time for vnconfig to catch up :)
ok
>
> Index:
On Fri, Aug 19, 2022 at 12:50:03PM -0600, Todd C. Miller wrote:
> Your original diff is OK with me, sorry if that wasn't clear.
Understood now, thanks.
Will commit the original diff unless someone objects.
On Fri, 19 Aug 2022 18:47:26 -, Klemens Nanni wrote:
> Can also do just that.
>
> For install media it could be worth it since a single fprintf(3) call
> saves some bits in text, but vnconfig(8) is not on amy install media...
Your original diff is OK with me, sorry if that wasn't clear.
- t
On Fri, Aug 19, 2022 at 12:39:41PM -0600, Todd C. Miller wrote:
> On Fri, 19 Aug 2022 18:32:12 -, Klemens Nanni wrote:
>
> > The manual has it right about -k and -K being mutually exclusive;
> > adapt the internal text.
> >
> > Merge the printf calls while here.
>
> OK millert@ for making usa
On Fri, 19 Aug 2022 18:35:26 -, Klemens Nanni wrote:
> opendev(3) takes a const char *, just what getinfo() provides.
>
> I see no point in casting away the const; no amd64 object change.
OK millert@
- todd
On Fri, 19 Aug 2022 18:32:12 -, Klemens Nanni wrote:
> The manual has it right about -k and -K being mutually exclusive;
> adapt the internal text.
>
> Merge the printf calls while here.
OK millert@ for making usage match the manual.
- todd
opendev(3) takes a const char *, just what getinfo() provides.
I see no point in casting away the const; no amd64 object change.
OK?
Index: vnconfig.c
===
RCS file: /cvs/src/sbin/vnconfig/vnconfig.c,v
retrieving revision 1.8
diff -u
The manual has it right about -k and -K being mutually exclusive;
adapt the internal text.
Merge the printf calls while here.
OK?
Index: vnconfig.c
===
RCS file: /cvs/src/sbin/vnconfig/vnconfig.c,v
retrieving revision 1.8
diff -u -p
On Fri, Aug 19, 2022 at 05:03:30PM +0200, Theo Buehler wrote:
> This implements this bit from section 2 (also mentioned in section 5) of
> the latest RSC draft:
>
> because RSCs MUST NOT be distributed through the
>global RPKI Repository system, the Subject Information Access
This implements this bit from section 2 (also mentioned in section 5) of
the latest RSC draft:
because RSCs MUST NOT be distributed through the
global RPKI Repository system, the Subject Information Access (SIA)
extension MUST be omitted from the RSC's X.509 End-Entity (EE)
On Fri, Aug 19, 2022 at 03:30:11PM +0200, Otto Moerbeek wrote:
> On Fri, Aug 19, 2022 at 12:41:33PM +0200, Theo Buehler wrote:
>
> > On Fri, Aug 19, 2022 at 12:26:41PM +0200, Otto Moerbeek wrote:
> > > Hoi,
> > >
> > > mentioned on misc@. Existing code only handles numeric ids with no
> > > error
On Fri, Aug 19, 2022 at 11:58:20AM +, Klemens Nanni wrote:
> On Fri, Aug 19, 2022 at 01:10:32PM +0200, Theo Buehler wrote:
> > On Fri, Aug 19, 2022 at 10:26:32AM +, Klemens Nanni wrote:
> > > It is parsed in three steps in this order:
> > > alphanumeric ones: 1C
> > > numerical ones: 0,
On 08/19/2022 11:24 AM Scott Cheloha wrote:
On Aug 19, 2022, at 01:52, Claudio Jeker
wrote:
On Thu, Aug 18, 2022 at 10:32:36PM -0500, Scott Cheloha wrote:
Hi,
clockframe is sometimes defined in cpu.h, sometimes in
frame.h, and sometimes defined once each in both
On Sat, Aug 13, 2022 at 04:51:05PM +0200, Theo Buehler wrote:
> On Fri, Aug 12, 2022 at 09:59:11PM +0200, Theo Buehler wrote:
> > On Wed, Aug 10, 2022 at 06:16:30PM +0200, Theo Buehler wrote:
> > > On Wed, Aug 10, 2022 at 03:10:19PM +, Job Snijders wrote:
> > > > Hi all,
> > > >
> > > > An err
On Fri, Aug 19, 2022 at 01:10:32PM +0200, Theo Buehler wrote:
> On Fri, Aug 19, 2022 at 10:26:32AM +, Klemens Nanni wrote:
> > It is parsed in three steps in this order:
> > alphanumeric ones: 1C
> > numerical ones: 0,1,5
> > alphabetic ones: C,c
> >
> > Wrt. numerical ones, the st
On Fri, Aug 19, 2022 at 10:26:32AM +, Klemens Nanni wrote:
> It is parsed in three steps in this order:
> alphanumeric ones: 1C
> numerical ones: 0,1,5
> alphabetic ones: C,c
>
> Wrt. numerical ones, the strlen(3) check could be omitted, but we do
> need it to guard against '
On Fri, Aug 19, 2022 at 12:26:41PM +0200, Otto Moerbeek wrote:
> Hoi,
>
> mentioned on misc@. Existing code only handles numeric ids with no
> error checking.
>
> Code stolen from mount_msdos.
>
> OK?
ok tb
I think the mount_ntfs and mount_msdos manpages could benefit from using
the wording in
On Fri, Aug 19, 2022 at 07:41:01PM +1000, Jonathan Gray wrote:
> On Fri, Aug 19, 2022 at 04:35:20PM +1000, Jonathan Gray wrote:
> > On Thu, Aug 18, 2022 at 10:38:38PM -0400, Brad Smith wrote:
> > > While trying to update to the latest MariaDB release I ran into an issue
> > > with the stdlib.h head
It is parsed in three steps in this order:
alphanumeric ones: 1C
numerical ones: 0,1,5
alphabetic ones: C,c
Wrt. numerical ones, the strlen(3) check could be omitted, but we do
need it to guard against '-c Cfoo', etc.
However, deferring it past the strnum(3) check results
On Fri, Aug 19, 2022 at 04:35:20PM +1000, Jonathan Gray wrote:
> On Thu, Aug 18, 2022 at 10:38:38PM -0400, Brad Smith wrote:
> > While trying to update to the latest MariaDB release I ran into an issue
> > with the stdlib.h header where it does not expose aligned_alloc() in C++11
> > mode breaking
On 2022/08/19 10:45, Claudio Jeker wrote:
> When implementing knexthop_true_nexthop() to do the lookup from BGP
> nexthop to the true nexthop used by the FIB I forgot to handle connected
> networks properly.
>
> For connected networks and connected nexthops the BGP exit nexthop is
> equal to the t
> On Aug 19, 2022, at 01:52, Claudio Jeker wrote:
>
> On Thu, Aug 18, 2022 at 10:32:36PM -0500, Scott Cheloha wrote:
>> Hi,
>>
>> clockframe is sometimes defined in cpu.h, sometimes in frame.h, and
>> sometimes defined once each in both header files.
>>
>> Can we put the clockframe definitions
On Fri, Aug 19, 2022 at 10:45:20AM +0200, Claudio Jeker wrote:
> When implementing knexthop_true_nexthop() to do the lookup from BGP
> nexthop to the true nexthop used by the FIB I forgot to handle connected
> networks properly.
>
> For connected networks and connected nexthops the BGP exit nextho
When implementing knexthop_true_nexthop() to do the lookup from BGP
nexthop to the true nexthop used by the FIB I forgot to handle connected
networks properly.
For connected networks and connected nexthops the BGP exit nexthop is
equal to the true nexthop used by the FIB since the nexthop is direc
31 matches
Mail list logo
