On Sun, Feb 13, 2022 at 02:30:21PM +0100, Tobias Heider wrote:
> OF_getproplen() will return -1 if "reset-gpios" is not found which
> currently causes a panic:
>
> panic: malloc: allocation too large, type = 2, size = 4294967295
>
> Below is a fix.
>
> ok?
OK kn
>
> Index: mvpcie.c
>
On Mon, Feb 07, 2022 at 02:12:52PM +0100, Mark Kettenis wrote:
> > Date: Mon, 7 Feb 2022 12:11:42 +
> > From: Klemens Nanni
> >
> > On Mon, Feb 07, 2022 at 12:41:27PM +0100, Mark Kettenis wrote:
> > > So there is the existing UVM_MAP_REQ_WRITE(). Compa
On Mon, Feb 07, 2022 at 12:41:27PM +0100, Mark Kettenis wrote:
> > Date: Mon, 7 Feb 2022 11:12:50 +
> > From: Klemens Nanni
> >
> > On Thu, Jan 27, 2022 at 11:11:48AM +, Klemens Nanni wrote:
> > > On Tue, Jan 25, 2022 at 07:54:52AM +, Klemens Na
On Thu, Jan 27, 2022 at 11:11:48AM +, Klemens Nanni wrote:
> On Tue, Jan 25, 2022 at 07:54:52AM +0000, Klemens Nanni wrote:
> > > Could we use a vm_map_assert_locked() or something similar that reflect
> > > the exclusive or shared (read) lock comments? I don't trust com
On Fri, Feb 04, 2022 at 01:37:41PM -0300, Martin Pieuchot wrote:
> On 04/02/22(Fri) 03:39, Klemens Nanni wrote:
> > [...]
> > ... with the lock grabbed in uvm_map_teardown() that is, otherwise
> > the first call path can lock against itself (regress/misc/posixtestsui
On Thu, Feb 03, 2022 at 04:49:26PM +, Klemens Nanni wrote:
> On Mon, Jan 31, 2022 at 11:11:25AM -0300, Martin Pieuchot wrote:
> > On 31/01/22(Mon) 10:24, Klemens Nanni wrote:
> > > Running with my uvm assert diff showed that uvm_fault_unwire_locked()
> > > was ca
On Mon, Jan 31, 2022 at 11:11:25AM -0300, Martin Pieuchot wrote:
> On 31/01/22(Mon) 10:24, Klemens Nanni wrote:
> > Running with my uvm assert diff showed that uvm_fault_unwire_locked()
> > was called without any locks held.
> >
> > This happened
Running with my uvm assert diff showed that uvm_fault_unwire_locked()
was called without any locks held.
This happened when I rebooted my machine:
uvm_fault_unwire_locked()
uvm_unmap_kill_entry_withlock()
uvm_unmap_kill_entry()
uvm_map_teardown()
On Tue, Jan 25, 2022 at 07:54:52AM +, Klemens Nanni wrote:
> > Could we use a vm_map_assert_locked() or something similar that reflect
> > the exclusive or shared (read) lock comments? I don't trust comments.
> > It's too easy to miss a lock in a code path.
>
> Thi
On Mon, Jan 24, 2022 at 12:08:33PM -0300, Martin Pieuchot wrote:
> On 24/01/22(Mon) 12:06, Klemens Nanni wrote:
> > On Sun, Jan 16, 2022 at 09:22:50AM -0300, Martin Pieuchot wrote:
> > > IMHO this approach of let's try if it works now and revert if it isn't
> > > do
On Sun, Jan 16, 2022 at 09:22:50AM -0300, Martin Pieuchot wrote:
> IMHO this approach of let's try if it works now and revert if it isn't
> doesn't help us make progress. I'd be more confident seeing diffs that
> assert for the right lock in the functions called by uvm_mapanon() and
>
On Mon, Jan 17, 2022 at 04:51:37PM -0800, Philip Guenther wrote:
> On Mon, Jan 17, 2022 at 5:02 AM Klemens Nanni wrote:
>
> > These don't hurt on !VMM architectures but I was still surprised to see
> > them on e.g. sparc64:
> >
> > # arch -s ; btrace -l
On Tue, Jan 18, 2022 at 07:59:20AM +0300, Andrew Krasavin wrote:
> Hello!
>
> Is there a reason not to enable dt(4) on macppc by default? I have
> built a kernel with dt enabled for test purposes and it seems to work
> correctly - commands like 'btrace /usr/share/btrace/kprofile.bt'
> work and I
On Tue, Jan 18, 2022 at 01:03:04AM +0100, Alexander Hall wrote:
> On Mon, Jan 17, 2022 at 02:23:52PM +0000, Klemens Nanni wrote:
> > I keep doing `btrace -l | sort' to help myself searching for traces.
> >
> > Would it be worh making btrace sort the list of probes
While intended for more architectures, DDBPROF is strictly amd64 and
i386 only, so the machine-independent sys/conf/GENERIC does not seem fit
(until all architectures are supported).
Index: conf/GENERIC
===
RCS file:
I keep doing `btrace -l | sort' to help myself searching for traces.
Would it be worh making btrace sort the list of probes
lexicographically in the first place or is there any value in seeing
them sorted by id?
Index: btrace.c
===
These don't hurt on !VMM architectures but I was still surprised to see
them on e.g. sparc64:
# arch -s ; btrace -l | grep vmm
sparc64
tracepoint:vmm:guest_enter
tracepoint:vmm:guest_exit
Like some network drivers, we could use __amd64__ to limit those to
amd64
One small mechanical diff to get rid of the boolean_t signature and
reduce difference to NetBSD.
uvm_flush() aka. uao_flush()/udv_flush()/pgo_flush()/uvn_flush() returns
TRUE/FALSE only to make uvm_map_clean() conditionally return EFAULT.
This makes the *_flush() return 0/EFAULT themselves and
On Wed, Jan 05, 2022 at 05:36:42PM -0800, Andrew Hewus Fresh wrote:
> After getting fw_update(8) into a state where it could get some testing,
> I found that the man page indicated that -v should indicate different
> levels of verbosity and I currently only had one.
>
> This was useful as I
On Wed, Jan 12, 2022 at 02:32:31AM +0300, Vitaliy Makkoveev wrote:
> Does it make sense to document that kernel lock protects
> `ps_wxcounter’? We have such [K] in other structure definitions.
>
> + u_int64_t ps_wxcounter; /* [K] number of W^X violations */
Yes, that would be in
On Tue, Jan 11, 2022 at 09:54:44AM -0700, Theo de Raadt wrote:
> > Now this is clearly a "slow" path. I don't think there is any reason
> > not to put all the code in that if (uvw_wxabort) block under the
> > kernel lock. For now I think making access to ps_wxcounter atomic is
> > just too fine
On Mon, Jan 10, 2022 at 12:06:44PM +, Klemens Nanni wrote:
> On Fri, Dec 31, 2021 at 07:54:53PM +0300, Vitaliy Makkoveev wrote:
> > The uvm_wxabort path within uvm_wxcheck() looks not MP-safe.
>
> Right, I did not pay enough attention to W^X handling.
New diff, either
On Fri, Dec 31, 2021 at 09:54:23AM -0700, Theo de Raadt wrote:
> >Now that mpi has unlocked uvm's fault handler, we can unlock the mmap
> >syscall to handle MAP_ANON without the big lock.
> ...
> >So here's a first small step. I've been running with this for months
> >on a few amd64, arm64 and
ock or atomic
operations.
The kernel lock could be pushed into uvm_wxabort() but there it'd still
be grabbed for every mmap(2) call.
>
> > On 31 Dec 2021, at 12:14, Klemens Nanni wrote:
> >
> > Now that mpi has unlocked uvm's fault handler, we can unlock the mmap
> > sysc
Now that mpi has unlocked uvm's fault handler, we can unlock the mmap
syscall to handle MAP_ANON without the big lock.
sys_mmap() still protects the !MAP_ANON case, i.e. file based mappings,
with the KERNEL_LOCK() itself, which is why unlocking the syscall will
only change locking behaviour for
On Sat, Dec 25, 2021 at 04:45:11PM +0100, Alexandre Ratchov wrote:
> On Sat, Dec 25, 2021 at 02:51:08PM +0000, Klemens Nanni wrote:
> >
> > either "devices that are" or "device that is", I'd say the latter.
> >
>
> commited with "dev
On Sat, Dec 25, 2021 at 03:46:48PM +0100, Alexandre Ratchov wrote:
> On Sat, Dec 25, 2021 at 01:34:19PM +0000, Klemens Nanni wrote:
> >
> > This reads OK kn, but I suspect others will object to the hotplugd(8)
> > reference.
> >
>
> here's a new one, with atta
On Mon, Dec 20, 2021 at 10:11:25AM +0100, Alexandre Ratchov wrote:
> On Fri, Dec 17, 2021 at 07:11:41PM +0000, Klemens Nanni wrote:
> >
> > So we've concluded that the hotplpugging framework needs work, fine.
> >
> > I'd still like to improve sndiod(8) regarding its
On Fri, Dec 24, 2021 at 11:17:46PM +0100, Alexander Bluhm wrote:
> ip_deliver() has been called without kernel lock from ip_ours() and
> ip6_ours() for a long time. It looks like these two callers in ip6
> input were forgotten to be unlocked.
OK kn
On Sat, Dec 18, 2021 at 04:37:17PM +0300, Andrew Krasavin wrote:
> On Fri, Dec 17, 2021 at 01:04:35PM +0000, Klemens Nanni wrote:
> > An upcoming port uses ElfW(). I first patched the port, but looking
> > around shows that both NetBSD and FreeBSD adopted the macro:
> &
On Thu, Dec 09, 2021 at 11:29:04PM +, Klemens Nanni wrote:
> On Thu, Dec 09, 2021 at 10:21:56AM +0100, Alexandre Ratchov wrote:
> > On Wed, Dec 08, 2021 at 10:30:08PM +, Klemens Nanni wrote:
> > > Following https://www.openbsd.org/faq/faq13.html#usbaudio and reading
An upcoming port uses ElfW(). I first patched the port, but looking
around shows that both NetBSD and FreeBSD adopted the macro:
https://mail-index.netbsd.org/source-changes-hg/2018/07/31/msg027523.html
+#defineElfW(x) CONCAT(Elf,CONCAT(ELFSIZE,CONCAT(_,x)))
On Thu, Dec 09, 2021 at 10:21:56AM +0100, Alexandre Ratchov wrote:
> On Wed, Dec 08, 2021 at 10:30:08PM +0000, Klemens Nanni wrote:
> > Following https://www.openbsd.org/faq/faq13.html#usbaudio and reading
> > sndiod(8)'s
> >
> > -F device
> > S
Following https://www.openbsd.org/faq/faq13.html#usbaudio and reading
sndiod(8)'s
-F device
Specify an alternate device to use. If it doesn't work, the one
given with the last -f or -F options will be used. For
instance,
specifying a USB
On Tue, Nov 23, 2021 at 01:17:14AM +, Klemens Nanni wrote:
> On Tue, Nov 16, 2021 at 11:09:40PM +0000, Klemens Nanni wrote:
> > Run on boot without arguments, netstart(8) creates all virtual
> > interfaces *for which hostname.if files exist* before configuring them.
> &g
On Mon, Nov 29, 2021 at 10:50:32PM +0100, Martin Pieuchot wrote:
> On 24/11/21(Wed) 11:16, Martin Pieuchot wrote:
> > Diff below unlock the bottom part of the UVM fault handler. I'm
> > interested in squashing the remaining bugs. Please test with your usual
> > setup & report back.
>
> Thanks
On Thu, Dec 02, 2021 at 01:24:36AM +0100, Alexander Bluhm wrote:
> ipsec_common_input_cb() extracts the inner IP header of IPsec
> tunnels. It is never used, so this is useless code.
OK kn
Just enabled hotplugd(8) to handle a single device I'm interested in and
saw it basically duplicating kernel de/attach messages in
/var/log/daemon:
Dec 1 23:36:27 eru hotplugd[26475]: started
Dec 1 23:36:27 eru hotplugd[26475]: uhidev4 attached, class 0
Dec 1 23:36:27 eru hotplugd[26475]:
On Fri, Nov 26, 2021 at 01:35:14PM +0100, Krzysztof Kanas wrote:
> Hi. When remote side in sppp doesn't reply for to PPP IPCP IP-Address
> sppp will try to negotiate remote IP in endless loop. Instead use
> 10.64.64.1 + if_index as remote IP.
Why add some arbitrary RFC 1918 IP if negotiation
On Thu, Nov 18, 2021 at 09:02:00AM +0100, Florian Obser wrote:
> This is split in two for easier review and I also intend to commit it
> like this.
>
> The first diff shuffles setting of if_index around so that it's
> available in all switch cases and uses it consistently instead of
>
On Wed, Nov 24, 2021 at 02:30:08AM +0100, Klemens Nanni wrote:
> On Tue, Nov 16, 2021 at 09:22:26AM +1000, David Gwynne wrote:
> > On Mon, Nov 15, 2021 at 02:31:42PM +, Klemens Nanni wrote:
> > > On Mon, Nov 15, 2021 at 01:37:49PM +, Stuart Henderson wrote:
> >
On Tue, Nov 16, 2021 at 09:22:26AM +1000, David Gwynne wrote:
> On Mon, Nov 15, 2021 at 02:31:42PM +0000, Klemens Nanni wrote:
> > On Mon, Nov 15, 2021 at 01:37:49PM +, Stuart Henderson wrote:
> > > On 2021/11/15 12:27, Klemens Nanni wrote:
> > > > On Sun, No
On Tue, Nov 16, 2021 at 11:09:40PM +, Klemens Nanni wrote:
> Run on boot without arguments, netstart(8) creates all virtual
> interfaces *for which hostname.if files exist* before configuring them.
>
> This prevents ordering problems with bridges and its members, as dlg's
>
On Wed, Nov 17, 2021 at 08:51:38AM +0100, Bjorn Ketelaars wrote:
> Like umb(4), sppp(4) natively learns DNS information. Among the
> differences between these two devices is that umb prints this
> information from ifconfig(8) and sppp does not. I would like to equalize
> this behaviour, and add
Run on boot without arguments, netstart(8) creates all virtual
interfaces *for which hostname.if files exist* before configuring them.
This prevents ordering problems with bridges and its members, as dlg's
commit message from 2018 reminds us.
But it also helps interface types like pair(4) which
On Mon, Nov 15, 2021 at 04:25:54PM -0700, Theo de Raadt wrote:
> > + _cmds[${#_cmds[*]}]="ifconfig $_if $_ifup"
>
> I will be surprised if you can simply add "up" to potential
> ifconfig commandlines.
This does not amend "ifconfig foo0 bar ..." to ifconfig foo0 bar ... up"
if that's what
On Mon, Nov 15, 2021 at 01:37:49PM +, Stuart Henderson wrote:
> On 2021/11/15 12:27, Klemens Nanni wrote:
> > On Sun, Nov 14, 2021 at 07:04:42PM -0700, Theo de Raadt wrote:
> > > I think physical interfaces should come up when something is configured
> > > on t
ostname.em0 will do the trick but
hostname.vport0 would need another "up" for the same behaviour: that's
rather confusing me as a user.
> David Gwynne wrote:
>
> > On Sat, Nov 13, 2021 at 11:59:59PM +, Klemens Nanni wrote:
> > > Practically all interfaces pull
On Mon, Nov 15, 2021 at 12:00:18PM +1000, David Gwynne wrote:
> On Sat, Nov 13, 2021 at 11:59:59PM +0000, Klemens Nanni wrote:
> > Practically all interfaces pull itself up when IPs get assigned, but
> > vport(4) does not.
>
> Yes, I do (or don't do) this very deliberately
On Mon, Nov 15, 2021 at 02:08:33PM +1000, David Gwynne wrote:
> The subject line only tells half the story. The other half is that
> instead of hoping it only identifies Ethernet interfaces it now actually
> checks and restricts itself to Ethernet interfaces. I couldn't help
> myself.
>
> If it
Since march 2021 setting AUTOCONF{4,6} sets UP as well unconditionally.
I have lots of hostname.if files containing only "inet6 autoconf"
without "up" and it works, but I noticed this isn't documented anywhere.
Neither do we remove UP and/or RUNNING on `-autoconf' and neither do we
document this.
Practically all interfaces pull itself up when IPs get assigned, but
vport(4) does not.
This broke IPv4 networking for me on a router I switched from bridge(4)
to veb(4) because hostname.vport0 only contained the equivalent of
descr LAN
inet 192.0.2.1
inet6 2001:db8::1
On Tue, Nov 02, 2021 at 05:43:03PM +, Klemens Nanni wrote:
> On Tue, Nov 02, 2021 at 05:26:17PM +0000, Klemens Nanni wrote:
> > At least bwfm(4) does not support WEP:
> >
> > # ifconfig bwfm0 nwkey 12345
> > ifconfig: SIOCS80211NWKEY: Operat
On Sat, Dec 26, 2020 at 05:19:55PM +0100, Klemens Nanni wrote:
> Our make(1) is behind NetBSD's and FreeBSD's make(1) on at least the
> rules of variable substitution.
>
> Our DESCRIPION says
>
> There are seven different types of lines in a makefile: dependency lines,
>
On Thu, Nov 11, 2021 at 08:13:13PM +, Jason McIntyre wrote:
> i don;t think this bit of text works well now because you say it runs
> ifconfig 3 times then ... respectively. but you only list two things
> (even though i understand dynamic config is two). since your text is
> already clear, i'd
On Thu, Nov 11, 2021 at 05:48:24PM +, Stuart Henderson wrote:
> On 2021/11/11 16:30, Klemens Nanni wrote:
> > On Thu, Nov 11, 2021 at 04:11:10PM +, Raf Czlonka wrote:
> > > Hello,
> > >
> > > It seems like this has been missed in recent thread[0].
&g
On Thu, Nov 04, 2021 at 10:49:46PM +, Klemens Nanni wrote:
> amd64, alpha, i386 and macppc strip all symbols off the ramdisk bsd.rd
> (before gzipping it) and thus break config(8)'s modification feature:
>
> $ gzcat bsd.rd > bsd.rd.raw
> $ config -e bsd.rd.r
On Thu, Nov 11, 2021 at 04:11:10PM +, Raf Czlonka wrote:
> Hello,
>
> It seems like this has been missed in recent thread[0].
>
> Not entirely sure whether the sentence "flows" any longer but here
> it goes anyway.
>
> [0] https://marc.info/?l=openbsd-tech=163507448118443=2
Thanks, I
On Thu, Nov 11, 2021 at 07:01:42AM +0100, Bjorn Ketelaars wrote:
> On Wed 10/11/2021 21:20, Klemens Nanni wrote:
> > I think only unwind(8) should list all the inputs and unwindctl(8)
> > should just say "Show learned nameservers".
> >
> > unwind(8) is al
On Wed, Nov 10, 2021 at 04:28:10PM +0100, Bjorn Ketelaars wrote:
> Like umb(4), sppp(4) is natively learning DNS information. Diff below
> adds this information to the manpages of resolv(8) and unwindctl(8).
> While here, also mention umb(4) in unwindctl's manpage.
>
> Thanks to kn@ for noticing
On Wed, Nov 10, 2021 at 07:35:26AM +0100, Bjorn Ketelaars wrote:
> On Mon 08/11/2021 11:52, Bjorn Ketelaars wrote:
> > Diff below does two things:
> > 1. add PPP IPCP extensions for name server addresses (rfc1877) to
> >sppp(4)
> > 2. propose negotiated name servers from sppp(4) to resolvd(8)
On Wed, Nov 10, 2021 at 12:07:37AM +0100, Jan Stary wrote:
> On Nov 09 15:43:04, k...@openbsd.org wrote:
> > This populates `systat sensors' with the correct lid status on my
> > Pinebook Pro:
> >
> > -gpio-key-lid at mainbus0 not configured
> > -gpio-key-power at mainbus0 not configured
On Tue, Nov 09, 2021 at 08:05:10PM +0100, Claudio Jeker wrote:
> On Tue, Nov 09, 2021 at 07:44:41PM +0100, Claudio Jeker wrote:
> > ip_addr_print() can be simplified. ip4_addr2str() and ip6_addr2str() are
> > the same apart from the different AF argument to inet_ntop(). Just collaps
> > all into
On Tue, Nov 09, 2021 at 07:52:06PM +0100, Claudio Jeker wrote:
> kn@ removed '~' from unsafe_chars but also changed the code at the same
> time. This tries to bring the version in rpki-client back in sync with the
> code in ftp(1).
Didn't know there was such a copy.
OK kn
2820ebd7692d7efbe17ceae (mode 644)
--- /dev/null
+++ share/man/man4/gpiokeys.4
@@ -0,0 +1,50 @@
+.\"$OpenBSD: $
+.\"
+.\" Copyright (c) 2021 Klemens Nanni
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fe
On Mon, Nov 08, 2021 at 12:59:51AM +0100, Theo Buehler wrote:
> > rpki-client seems to be the one-off under regress/ in this regard.
>
> Maybe. I wish I had a better idea than this
There is: pull the test into the proper Makefile as done in
regress/sys/net/inetinet/pmtu/Makefile and not
On Mon, Nov 08, 2021 at 11:52:52AM +0100, Bjorn Ketelaars wrote:
> Diff below does two things:
> 1. add PPP IPCP extensions for name server addresses (rfc1877) to
>sppp(4)
You could add that RFC to sppp(4)'s STANDARDS section.
> 2. propose negotiated name servers from sppp(4) to resolvd(8)
On Sun, Nov 07, 2021 at 11:33:29PM +0100, Theo Buehler wrote:
> On Sun, Nov 07, 2021 at 10:28:22PM +0000, Klemens Nanni wrote:
> > On Sun, Nov 07, 2021 at 11:16:57PM +0100, Theo Buehler wrote:
> > > On Sun, Nov 07, 2021 at 10:13:44PM +0000, Klemens Nanni wrote:
> > > &
I built arm64 media on a new machine and forgot to install firmware
from packages.
It took me some digging to find out which packages these were, plus it
failed in the middle of the build rather than up-front.
While here, I noticed that arm64 does not use the "dtb" package like
armv7 does, but
On Sun, Nov 07, 2021 at 11:16:57PM +0100, Theo Buehler wrote:
> On Sun, Nov 07, 2021 at 10:13:44PM +0000, Klemens Nanni wrote:
> > Spotted in `make obj' from /usr/src:
> >
> > ===> regress/usr.sbin/rpki-client/libressl
> > /usr/src/regress/usr.sbin/rpki-cl
Spotted in `make obj' from /usr/src:
===> regress/usr.sbin/rpki-client/libressl
/usr/src/regress/usr.sbin/rpki-client/libressl/obj ->
/usr/obj/regress/usr.sbin/rpki-client/libressl
Run "pkg_add openssl--%1.1" to run tests against OpenSSL 1.1
SKIPPED
===>
On Sat, Nov 06, 2021 at 07:02:39PM +, Stuart Henderson wrote:
> On 2021/11/06 17:29, Klemens Nanni wrote:
> > Encoding URL paths changes the requested URL and therefore may yield
> > different responses (opposed to an unencoded URL), solely depending on
> > how the
On Thu, Nov 04, 2021 at 04:21:12PM +0100, Alexandre Ratchov wrote:
> The current sndiod latency (minimum time between when the program
> plays something and when sound reaches Joe's ears) is too large and
> makes OpenBSD unpleasant to use for telephony, games, and makes
> controls of video players
On Sat, Nov 06, 2021 at 11:33:21AM -0600, Theo de Raadt wrote:
> > This matches exactly what is seen on the wire, e.g. with tshark(1).
>
> I don't see why this is important. Users don't need to see what is
> on the wire.
>
> Why intentionaly expose them to a translation they are not supposed
>
Encoding URL paths changes the requested URL and therefore may yield
different responses (opposed to an unencoded URL), solely depending on
how the server implements de/encoding.
Thus it is imperative to inform users about the factually requested URL
in case servers behave unexpectedly. Consider
On Fri, Nov 05, 2021 at 05:36:48PM -0700, Andrew Hewus Fresh wrote:
> I like it, some comments in-line but overall I think this would have
> helped me get started with siteXX stuff, so OK afresh1@
Great, I'll commit with tweaks as per below, thanks!
> > +If existent and executable,
>
> This
ftp(1) implements RFC 1738 from Dec. 1994 but RFC 2396 from Aug. 1998
updated this and the tl;dr is: do not encode the tilde character.
In theory, this shouldn't make a difference as servers should decode
"%7e" to "~", BUT not all servers do so and thus some respond with 404.
I've hit this in
On Wed, Oct 27, 2021 at 07:35:28PM -0500, Aaron Poffenberger wrote:
> Looks good. Nice to see this moving forward. Thanks.
>
> On 2021-10-27 21:13 +, Klemens Nanni wrote:
> > On Mon, Sep 06, 2021 at 02:29:50PM -0500, Aaron Poffenberger wrote:
> > > Ping.
> >
On Thu, Nov 04, 2021 at 10:49:46PM +, Klemens Nanni wrote:
> amd64, alpha, i386 and macppc strip all symbols off the ramdisk bsd.rd
> (before gzipping it) and thus break config(8)'s modification feature:
>
> $ gzcat bsd.rd > bsd.rd.raw
> $ config -e bsd.rd.r
amd64, alpha, i386 and macppc strip all symbols off the ramdisk bsd.rd
(before gzipping it) and thus break config(8)'s modification feature:
$ gzcat bsd.rd > bsd.rd.raw
$ config -e bsd.rd.raw
WARNING no output file specified
WARNING this kernel doesn't contain all
All volume IDs use a dash and now I can't unsee it missing.
OK?
Index: alpha/miniroot/Makefile
===
RCS file: /cvs/src/distrib/alpha/miniroot/Makefile,v
retrieving revision 1.23
diff -u -p -r1.23 Makefile
--- alpha/miniroot/Makefile
Old diff laying around.
OK?
Index: libc/asr/asr.c
===
RCS file: /cvs/src/lib/libc/asr/asr.c,v
retrieving revision 1.65
diff -u -p -r1.65 asr.c
--- libc/asr/asr.c 6 Jan 2021 19:54:17 - 1.65
+++ libc/asr/asr.c 5
Some device trees such as on my Raspberry Pi 4b use the deprecated
"label" property rather than "function".
Fall back to it such that LEDs won't be skipped:
-gpioleds0 at mainbus0: no LEDs
+gpioleds0 at mainbus0: "led0", "led1"
OK?
Index: gpioleds.c
No idea what it was supposed to do back then; cvs blame points at
revision 1.19
date: 1998/09/03 06:24:18; author: jason; state: Exp; lines: +502
-38;
o OpenBSD gets if_media support (from NetBSD)
o rework/simplify if_xl to use
OK?
Index: ifconfig.c
I looked at
I had to look at the source to be sure what the three different return
codes 0, 1 and 2 would mean and if there was more to it.
Depending on the error, config(8) exists 1 or 2. 0 on success as usual.
OK?
Index: config.8
On Tue, Nov 02, 2021 at 06:38:24PM +0100, Stefan Sperling wrote:
> It looks like bwfm(4) does support WEP but the C_WEP capability is missing
> from ic_caps so net80211 believes WEP was not supported by this driver.
>
> I don't think we have any supported wifi device that does not support WEP.
>
On Tue, Nov 02, 2021 at 11:30:11AM -0600, Theo de Raadt wrote:
> Klemens Nanni wrote:
>
> > At least bwfm(4) does not support WEP:
> >
> > # ifconfig bwfm0 nwkey 12345
> > ifconfig: SIOCS80211NWKEY: Operation not supported by devi
On Tue, Nov 02, 2021 at 05:26:17PM +, Klemens Nanni wrote:
> At least bwfm(4) does not support WEP:
>
> # ifconfig bwfm0 nwkey 12345
> ifconfig: SIOCS80211NWKEY: Operation not supported by device
> # echo $?
> 0
>
> ifconfig
At least bwfm(4) does not support WEP:
# ifconfig bwfm0 nwkey 12345
ifconfig: SIOCS80211NWKEY: Operation not supported by device
# echo $?
0
ifconfig(8) must return non-zero in this case.
This is relevant for an upcoming installer fix, but also worth
On Tue, Oct 26, 2021 at 01:24:30PM +, Klemens Nanni wrote:
> Mentioning `route nameserver' relevance made it obvious that the
> `preference' block duplicates lots of information and I despise adding
> to that.
route(8) is fixed/polished, unwind.conf(5) still lacks behind.
>
9, 2021 at 01:59:38PM +0100:
> > > On 2021/10/29 14:08, Ingo Schwarze wrote:
> > >> Stuart Henderson wrote on Fri, Oct 29, 2021 at 10:53:41AM +0100:
> > >>> On 2021/10/28 23:19, Klemens Nanni wrote:
> > >>>> On Fri, Oct 29, 2021 at 12:57:54AM +0200,
On Fri, Oct 29, 2021 at 12:57:54AM +0200, Ingo Schwarze wrote:
> MANPAGER=firefox man -T html $(ifconfig -C)
This doesn't work if firefox is already running as the MANPAGER firefox
process exits immediately after sending the file/link to the running
process, which causes mandoc to exit after
share/man/man8/site.8 27 Oct 2021 21:11:48 -
@@ -0,0 +1,87 @@
+.\" $OpenBSD: $
+.\"
+.\" Copyright (c) 2021 Klemens Nanni
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby gr
On Tue, Oct 26, 2021 at 04:06:20PM +0100, Jason McIntyre wrote:
> On Tue, Oct 26, 2021 at 08:57:40AM -0600, Theo de Raadt wrote:
> > Jason McIntyre wrote:
> >
> > > On Tue, Oct 26, 2021 at 12:21:52PM +, Klemens Nanni wrote:
> > > > While designed to popul
Mentioning `route nameserver' relevance made it obvious that the
`preference' block duplicates lots of information and I despise adding
to that.
So rearrange the list of types such that conceptually related ones are
subsequent and can reference each user to not repeat things.
This looks like
While designed to populate resolv.conf(5), there is nothing resolvd(8)
specific about the route message route(8) sends.
At least unwind(8) consumes and acts upon it; there might as well be
other programs in ports that do such things, so describe it generically
while going into required detail
Patrick's "bootloader: remove unsued variables" mail reminded me about
this diff I still have.
M sbin/vnconfig/vnconfig.c
M usr.sbin/pcidump/pcidump.c
M usr.sbin/wsfontload/wsfontload.c
M usr.bin/less/line.c
M usr.bin/make/engine.c
M
On Sun, Oct 24, 2021 at 01:24:23PM +0100, Stuart Henderson wrote:
> On 2021/10/24 11:57, Klemens Nanni wrote:
> > On Sun, Oct 24, 2021 at 12:41:11PM +0100, Stuart Henderson wrote:
> > > On 2021/10/24 11:20, Klemens Nanni wrote:
> > > > @@ -174,7 +174,7 @@ The foll
On Sun, Oct 24, 2021 at 12:41:11PM +0100, Stuart Henderson wrote:
> On 2021/10/24 11:20, Klemens Nanni wrote:
> > @@ -174,7 +174,7 @@ The following
> > example creates a host-based access point on boot:
> > .Bd -literal -offset indent
> > mediaopt hostap
>
I reckon the adoption of `join' was fairly successful and lots of people
use it exclusively, so upon install I suggest to provide hostname.if(5)
using it instead of `nwid'.
Likewise, reflect that trend in our driver manuals.
Feedback? Objection? OK?
Index: distrib/miniroot/install.sub
1 - 100 of 1253 matches
Mail list logo
