Re: hostctl: Change from fixed length to variable length

2022-11-18 Thread YASUOKA Masahiko 
On Sat, 19 Nov 2022 14:41:18 +0900 (JST)
YASUOKA Masahiko  wrote:
> On Wed, 12 Oct 2022 07:58:20 +0900 (JST)
> YASUOKA Masahiko  wrote:
>> On Wed, 05 Oct 2022 13:37:35 +0900 (JST)
>> Masato Asou  wrote:
>>> From: "Theo de Raadt" 
>>> Date: Tue, 04 Oct 2022 21:58:13 -0600
 Userland may not ask the kernel to allocate such a huge object.  The
 kernel address space is quite small.  First off, huge allocations will
 fail.
 
 But it is worse -- the small kernel address space is shared for many
 purposes, so large allocations will harm the other subsystems.
 
 As written, this diff is too dangerous.  Arbitrary allocation inside
 the kernel is not reasonable.  object sizes requested by userland must
 be small, or the operations must be cut up, which does create impact
 on atomicity or other things.
>>> 
>>> As you pointed out, it is not a good idea to allocate large spaces
>>> in kernel.
>>> 
>>> Would it be better to keep the current fixed length?
>> 
>> Currently the value on VMware may be truncated silently.  It's simply
>> broken.  I think we should fix it by having a way to know if the value
>> is reached the limit.
>> 
>> Also I think we should be able to pass larger size of data.  Since at
>> least on VMware, people is useing for parameters when deployment
>> through OVF tamplate.  Sometimes the parameter includes large data
>> like X.509 certificate.
>> 
>> https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-D0F9E3B9-B77B-4DEF-A982-49B9F6358FF3.html
>> 
>> What do you think?
>> 
>>> Prepare a variable like kern.maxpvbus and default it to
>>> 4096.  Futhermore, how about free() after copyout() to user space?
>> 
>> I suppose we can use the space prepared by the userland directly.
> 
> I admit there is no way to use the user space directly in case of the
> vmware.
> 
> But current vmt(4) uses the buffer in vmt_softc for all RPC commands.
> The buffer seems to have beeen created for RPC done by the tclo
> process.  The tclo process executes RPC periodically, so having a long
> term buffer does make sense.
> 
> On the otherhand, pvbus(4) prepares a buffer for
> PVBUSIOC_KV{READ|WRITE} and pass it to the driver handler.  So vmt(4)
> can use the buffer.
> 
> The diff is to change vmt(4) to use the buffer given by pvbuf(4) for
> the rpc output directly.  Also make it return EMSGSIZE when the buffer
> is not enough instead of truncating silently.
> 
> The diff is first step.  We need to more hack for pvbus(4) and
> vmt(4).  For example, the buffer size pvbuf(4) allocates is not enough
> to store the size user requested, since vmt(4) neeeds extra 2 bytes
> for the RPC output.
> 
> + bcopy(value + 2, value, valuelen - 2);
> 
> 
> But I'd like to commit this first.
> 
> ok?

sorry, using existing vm_rpc_send_rpci_tx_buf() or
vm_rpci_response_successful() wasn't good idea and had a bug.

Let me update the diff.

Index: sys/dev/pv/vmt.c
===
RCS file: /var/cvs/openbsd/src/sys/dev/pv/vmt.c,v
retrieving revision 1.26
diff -u -p -r1.26 vmt.c
--- sys/dev/pv/vmt.c8 Sep 2022 10:22:06 -   1.26
+++ sys/dev/pv/vmt.c19 Nov 2022 07:32:47 -
@@ -491,9 +491,12 @@ int
 vmt_kvop(void *arg, int op, char *key, char *value, size_t valuelen)
 {
struct vmt_softc *sc = arg;
-   char *buf = NULL, *ptr;
+   struct vm_rpc rpci;
+   char *buf = NULL;
size_t bufsz;
int error = 0;
+   uint32_t rlen;
+   uint16_t ack;
 
bufsz = VMT_RPC_BUFLEN;
buf = malloc(bufsz, M_TEMP, M_WAITOK | M_ZERO);
@@ -520,25 +523,52 @@ vmt_kvop(void *arg, int op, char *key, c
goto done;
}
 
-   if (vm_rpc_send_rpci_tx(sc, "%s", buf) != 0) {
-   DPRINTF("%s: error sending command: %s\n", DEVNAME(sc), buf);
+   if (vm_rpc_open(&rpci, VM_RPC_OPEN_RPCI) != 0) {
+   DPRINTF("%s: rpci channel open failed\n", DEVNAME(sc));
sc->sc_rpc_error = 1;
error = EIO;
goto done;
}
 
-   if (vm_rpci_response_successful(sc) == 0) {
-   DPRINTF("%s: host rejected command: %s\n", DEVNAME(sc), buf);
-   error = EINVAL;
+   if (vm_rpc_send(&rpci, buf, bufsz) != 0) {
+   DPRINTF("%s: unable to send rpci command\n", DEVNAME(sc));
+   sc->sc_rpc_error = 1;
+   error = EIO;
goto done;
}
 
-   /* skip response that was tested in vm_rpci_response_successful() */
-   ptr = sc->sc_rpc_buf + 2;
+   if (vm_rpc_get_length(&rpci, &rlen, &ack) != 0) {
+   DPRINTF("%s: failed to get length of rpci response data\n",
+   DEVNAME(sc));
+   sc->sc_rpc_error = 1;
+   error = EIO;
+   goto done;
+   }
 
-   /* might truncate, copy anyway but return error */
-   if (strlcpy(value, ptr, valuelen) >= valuelen)
-

Re: hostctl: Change from fixed length to variable length

2022-11-18 Thread YASUOKA Masahiko 
On Wed, 12 Oct 2022 07:58:20 +0900 (JST)
YASUOKA Masahiko  wrote:
> On Wed, 05 Oct 2022 13:37:35 +0900 (JST)
> Masato Asou  wrote:
>> From: "Theo de Raadt" 
>> Date: Tue, 04 Oct 2022 21:58:13 -0600
>>> Userland may not ask the kernel to allocate such a huge object.  The
>>> kernel address space is quite small.  First off, huge allocations will
>>> fail.
>>> 
>>> But it is worse -- the small kernel address space is shared for many
>>> purposes, so large allocations will harm the other subsystems.
>>> 
>>> As written, this diff is too dangerous.  Arbitrary allocation inside
>>> the kernel is not reasonable.  object sizes requested by userland must
>>> be small, or the operations must be cut up, which does create impact
>>> on atomicity or other things.
>> 
>> As you pointed out, it is not a good idea to allocate large spaces
>> in kernel.
>> 
>> Would it be better to keep the current fixed length?
> 
> Currently the value on VMware may be truncated silently.  It's simply
> broken.  I think we should fix it by having a way to know if the value
> is reached the limit.
> 
> Also I think we should be able to pass larger size of data.  Since at
> least on VMware, people is useing for parameters when deployment
> through OVF tamplate.  Sometimes the parameter includes large data
> like X.509 certificate.
> 
> https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-D0F9E3B9-B77B-4DEF-A982-49B9F6358FF3.html
> 
> What do you think?
> 
>> Prepare a variable like kern.maxpvbus and default it to
>> 4096.  Futhermore, how about free() after copyout() to user space?
> 
> I suppose we can use the space prepared by the userland directly.

I admit there is no way to use the user space directly in case of the
vmware.

But current vmt(4) uses the buffer in vmt_softc for all RPC commands.
The buffer seems to have beeen created for RPC done by the tclo
process.  The tclo process executes RPC periodically, so having a long
term buffer does make sense.

On the otherhand, pvbus(4) prepares a buffer for
PVBUSIOC_KV{READ|WRITE} and pass it to the driver handler.  So vmt(4)
can use the buffer.

The diff is to change vmt(4) to use the buffer given by pvbuf(4) for
the rpc output directly.  Also make it return EMSGSIZE when the buffer
is not enough instead of truncating silently.

The diff is first step.  We need to more hack for pvbus(4) and
vmt(4).  For example, the buffer size pvbuf(4) allocates is not enough
to store the size user requested, since vmt(4) neeeds extra 2 bytes
for the RPC output.

+   bcopy(value + 2, value, valuelen - 2);


But I'd like to commit this first.

ok?

Index: sys/dev/pv/vmt.c
===
RCS file: /var/cvs/openbsd/src/sys/dev/pv/vmt.c,v
retrieving revision 1.26
diff -u -p -r1.26 vmt.c
--- sys/dev/pv/vmt.c8 Sep 2022 10:22:06 -   1.26
+++ sys/dev/pv/vmt.c19 Nov 2022 04:13:47 -
@@ -277,7 +277,8 @@ int  vm_rpc_send(const struct vm_rpc *, 
 int vm_rpc_send_str(const struct vm_rpc *, const uint8_t *);
 int vm_rpc_get_length(const struct vm_rpc *, uint32_t *, uint16_t *);
 int vm_rpc_get_data(const struct vm_rpc *, char *, uint32_t, uint16_t);
-int vm_rpc_send_rpci_tx_buf(struct vmt_softc *, const uint8_t *, uint32_t);
+int vm_rpc_send_rpci_tx_buf(struct vmt_softc *, const uint8_t *, uint32_t,
+   uint8_t *, uint32_t);
 int vm_rpc_send_rpci_tx(struct vmt_softc *, const char *, ...)
__attribute__((__format__(__kprintf__,2,3)));
 int vm_rpci_response_successful(struct vmt_softc *);
@@ -491,7 +492,7 @@ int
 vmt_kvop(void *arg, int op, char *key, char *value, size_t valuelen)
 {
struct vmt_softc *sc = arg;
-   char *buf = NULL, *ptr;
+   char *buf = NULL;
size_t bufsz;
int error = 0;
 
@@ -520,10 +521,9 @@ vmt_kvop(void *arg, int op, char *key, c
goto done;
}
 
-   if (vm_rpc_send_rpci_tx(sc, "%s", buf) != 0) {
-   DPRINTF("%s: error sending command: %s\n", DEVNAME(sc), buf);
+   if ((error = vm_rpc_send_rpci_tx_buf(sc, buf, strlen(buf), value,
+   valuelen)) != 0) {
sc->sc_rpc_error = 1;
-   error = EIO;
goto done;
}
 
@@ -534,11 +534,7 @@ vmt_kvop(void *arg, int op, char *key, c
}
 
/* skip response that was tested in vm_rpci_response_successful() */
-   ptr = sc->sc_rpc_buf + 2;
-
-   /* might truncate, copy anyway but return error */
-   if (strlcpy(value, ptr, valuelen) >= valuelen)
-   error = ENOMEM;
+   bcopy(value + 2, value, valuelen - 2);
 
  done:
free(buf, M_TEMP, bufsz);
@@ -1348,8 +1344,8 @@ vmt_nicinfo_task(void *data)
 
if (nic_info_size != sc->sc_nic_info_size ||
(memcmp(nic_info, sc->sc_nic_info, nic_info_size) != 0)) {
-   if (vm_rpc_send_rpci_tx_buf(sc, nic_info,
-   nic_info_size) != 0) {
+   if (vm_

Re: newsyslog alt compression support?

2022-11-18 Thread Theo de Raadt 
I completely disagree on this, of course.

We do not make base use ports.  

Todd T. Fries  wrote:

> I love xz compression. It really pinches the bytes outa ascii files, which 
> log files
> are of course made of.
> 
> Is there a direction someone can point me in that would permit the 
> functionality this
> diff provides without hardcoding it and perhaps be acceptable for the tree?
> 
> 
> diff --git a/usr.bin/newsyslog/Makefile b/usr.bin/newsyslog/Makefile
> index 1bb0ce36439..03787a6439b 100644
> --- a/usr.bin/newsyslog/Makefile
> +++ b/usr.bin/newsyslog/Makefile
> @@ -6,4 +6,8 @@ BINOWN=   root
>  
>  MAN= newsyslog.8
>  
> +CFLAGS += -DCOMPRESS='"/usr/local/bin/xz"'
> +CFLAGS += -DCOMPRESS_FORCE='"-f9e"'
> +CFLAGS += -DCOMPRESS_POSTFIX='".xz"'
> +
>  .include 
> diff --git a/usr.bin/newsyslog/newsyslog.c b/usr.bin/newsyslog/newsyslog.c
> index 066167151ca..7d3a959ad90 100644
> --- a/usr.bin/newsyslog/newsyslog.c
> +++ b/usr.bin/newsyslog/newsyslog.c
> @@ -73,8 +73,15 @@
>  
>  #define CONF "/etc/newsyslog.conf"
>  #define PIDFILE "/var/run/syslog.pid"
> +#ifndef COMPRESS
>  #define COMPRESS "/usr/bin/gzip"
> +#endif
> +#ifndef COMPRESS_FORCE
> +#define COMPRESS_FORCE "-f"
> +#endif
> +#ifndef COMPRESS_POSTFIX
>  #define COMPRESS_POSTFIX ".gz"
> +#endif
>  #define STATS_DIR "/var/run"
>  #define SENDMAIL "/usr/sbin/sendmail"
>  
> @@ -925,7 +932,7 @@ compress_log(struct conf_entry *ent)
>   if (pid == -1) {
>   err(1, "fork");
>   } else if (pid == 0) {
> - (void)execl(COMPRESS, base, "-f", tmp, (char *)NULL);
> + (void)execl(COMPRESS, base, COMPRESS_FORCE, tmp, (char *)NULL);
>   warn(COMPRESS);
>   _exit(1);
>   }
> -- 
> Todd Fries .. t...@fries.net
> 
>  
> |\  1.636.410.0632 (voice)
> | Free Daemon Consulting, LLC\  1.405.227.9094 (voice)
> | http://FreeDaemonConsulting.com\  1.866.792.3418 (FAX)
> | PO Box 16169, Oklahoma City, OK 73113-2169 \  sip:freedae...@ekiga.net
> | "..in support of free software solutions." \  sip:4052279...@ekiga.net
>  \
>  
>   37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
> http://todd.fries.net/pgp.txt
>

newsyslog alt compression support?

2022-11-18 Thread Todd T. Fries 
I love xz compression. It really pinches the bytes outa ascii files, which log 
files
are of course made of.

Is there a direction someone can point me in that would permit the 
functionality this
diff provides without hardcoding it and perhaps be acceptable for the tree?


diff --git a/usr.bin/newsyslog/Makefile b/usr.bin/newsyslog/Makefile
index 1bb0ce36439..03787a6439b 100644
--- a/usr.bin/newsyslog/Makefile
+++ b/usr.bin/newsyslog/Makefile
@@ -6,4 +6,8 @@ BINOWN= root
 
 MAN=   newsyslog.8
 
+CFLAGS += -DCOMPRESS='"/usr/local/bin/xz"'
+CFLAGS += -DCOMPRESS_FORCE='"-f9e"'
+CFLAGS += -DCOMPRESS_POSTFIX='".xz"'
+
 .include 
diff --git a/usr.bin/newsyslog/newsyslog.c b/usr.bin/newsyslog/newsyslog.c
index 066167151ca..7d3a959ad90 100644
--- a/usr.bin/newsyslog/newsyslog.c
+++ b/usr.bin/newsyslog/newsyslog.c
@@ -73,8 +73,15 @@
 
 #define CONF "/etc/newsyslog.conf"
 #define PIDFILE "/var/run/syslog.pid"
+#ifndef COMPRESS
 #define COMPRESS "/usr/bin/gzip"
+#endif
+#ifndef COMPRESS_FORCE
+#define COMPRESS_FORCE "-f"
+#endif
+#ifndef COMPRESS_POSTFIX
 #define COMPRESS_POSTFIX ".gz"
+#endif
 #define STATS_DIR "/var/run"
 #define SENDMAIL "/usr/sbin/sendmail"
 
@@ -925,7 +932,7 @@ compress_log(struct conf_entry *ent)
if (pid == -1) {
err(1, "fork");
} else if (pid == 0) {
-   (void)execl(COMPRESS, base, "-f", tmp, (char *)NULL);
+   (void)execl(COMPRESS, base, COMPRESS_FORCE, tmp, (char *)NULL);
warn(COMPRESS);
_exit(1);
}
-- 
Todd Fries .. t...@fries.net

 
|\  1.636.410.0632 (voice)
| Free Daemon Consulting, LLC\  1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com\  1.866.792.3418 (FAX)
| PO Box 16169, Oklahoma City, OK 73113-2169 \  sip:freedae...@ekiga.net
| "..in support of free software solutions." \  sip:4052279...@ekiga.net
 \
 
  37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
http://todd.fries.net/pgp.txt

Re: Get rid of UVM_VNODE_CANPERSIST

2022-11-18 Thread Mark Kettenis 
> Date: Thu, 17 Nov 2022 20:23:37 +0100
> From: Mark Kettenis 
> 
> > From: Jeremie Courreges-Anglas 
> > Date: Thu, 17 Nov 2022 18:00:21 +0100
> > 
> > On Tue, Nov 15 2022, Martin Pieuchot  wrote:
> > > UVM vnode objects include a reference count to keep track of the number
> > > of processes that have the corresponding pages mapped in their VM space.
> > >
> > > When the last process referencing a given library or executable dies,
> > > the reaper will munmap this object on its behalf.  When this happens it
> > > doesn't free the associated pages to speed-up possible re-use of the
> > > file.  Instead the pages are placed on the inactive list but stay ready
> > > to be pmap_enter()'d without requiring I/O as soon as a newly process
> > > needs to access them.
> > >
> > > The mechanism to keep pages populated, known as UVM_VNODE_CANPERSIST,
> > > doesn't work well with swapping [0].  For some reason when the page daemon
> > > wants to free pages on the inactive list it tries to flush the pages to
> > > disk and panic(9) because it needs a valid reference to the vnode to do
> > > so.
> > >
> > > This indicates that the mechanism described above, which seems to work
> > > fine for RO mappings, is currently buggy in more complex situations.
> > > Flushing the pages when the last reference of the UVM object is dropped
> > > also doesn't seem to be enough as bluhm@ reported [1].
> > >
> > > The diff below, which has already be committed and reverted, gets rid of
> > > the UVM_VNODE_CANPERSIST logic.  I'd like to commit it again now that
> > > the arm64 caching bug has been found and fixed.
> > >
> > > Getting rid of this logic means more I/O will be generated and pages
> > > might have a faster reuse cycle.  I'm aware this might introduce a small
> > > slowdown,
> > 
> > Numbers for my usual make -j4 in libc,
> > on an Unmatched riscv64 box, now:
> >16m32.65s real21m36.79s user30m53.45s system
> >16m32.37s real21m33.40s user31m17.98s system
> >16m32.63s real21m35.74s user31m12.01s system
> >16m32.13s real21m36.12s user31m06.92s system
> > After:
> >19m14.15s real21m09.39s user36m51.33s system
> >19m19.11s real21m02.61s user36m58.46s system
> >19m21.77s real21m09.23s user37m03.85s system
> >19m09.39s real21m08.96s user36m36.00s system
> > 
> > 4 cores amd64 VM, before (-current plus an other diff):
> >1m54.31s real 2m47.36s user 4m24.70s system
> >1m52.64s real 2m45.68s user 4m23.46s system
> >1m53.47s real 2m43.59s user 4m27.60s system
> > After:
> >2m34.12s real 2m51.15s user 6m20.91s system
> >2m34.30s real 2m48.48s user 6m23.34s system
> >2m37.07s real 2m49.60s user 6m31.53s system
> > 
> > > however I believe we should work towards loading files from the
> > > buffer cache to save I/O cycles instead of having another layer of cache.
> > > Such work isn't trivial and making sure the vnode <-> UVM relation is
> > > simple and well understood is the first step in this direction.
> > >
> > > I'd appreciate if the diff below could be tested on many architectures,
> > > include the offending rpi4.
> > 
> > Mike has already tested a make build on a riscv64 Unmatched.  I have
> > also run regress in sys, lib/libc and lib/libpthread on that arch.  As
> > far as I can see this looks stable on my machine, but what I really care
> > about is the riscv64 bulk build cluster (I'm going to start another
> > bulk build soon).
> > 
> > > Comments?  Oks?
> > 
> > The performance drop in my microbenchmark kinda worries me but it's only
> > a microbenchmark...
> 
> I wouldn't call this a microbenchmark.  I fear this is typical for
> builds of anything on clang architectures.  And I expect it to be
> worse on single-processor machine where *every* time we execute clang
> or lld all the pages are thrown away upon exit and will need to be
> read back from disk again for the next bit of C code we compile.
> 
> Having mmap'ed reads go through the buffer cache should indeed help
> here, but that smells like UBC and even if it isn't, it is something
> we don't have and will be tricky to get right.
> 
> The discussions we had during h2k22 made me understand this thing a
> bit better.  Is there any reason why we can't keep a reference to the
> vnode and have the pagedaemon drop it when it drops the pages?  Is
> there a chance that we run out of vnodes this way?  I vaguely remember
> beck@ saying that we can have tons of vnodes now.

Maybe that isn't the best idea.  So here is what may be an actual fix
for the "macppc panic: vref used where vget required" problem we're
seeing that prompted us to look at UVM_VNODE_CANPERSIST.

If we look back to at the race that bluhm@ posted:

panic: vref used where vget required
Stopped at  db_enter+0x24:  lwz r11,12(r1)
TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
 192060  78628 21 0x2  00  c++

Re: nologin: Style fixes

2022-11-18 Thread Theo de Raadt 
This does not help anything.


Josiah Frentsos  wrote:

> Index: nologin.c
> ===
> RCS file: /cvs/src/sbin/nologin/nologin.c,v
> retrieving revision 1.9
> diff -u -p -r1.9 nologin.c
> --- nologin.c 12 Jul 2021 15:09:19 -  1.9
> +++ nologin.c 18 Nov 2022 16:59:31 -
> @@ -25,7 +25,6 @@
>   * SUCH DAMAGE.
>   */
>  
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -38,7 +37,6 @@
>  
>  #define DEFAULT_MESG "This account is currently not available.\n"
>  
> -/*ARGSUSED*/
>  int
>  main(int argc, char *argv[])
>  {
> @@ -51,15 +49,15 @@ main(int argc, char *argv[])
>   if (pledge("stdio rpath", NULL) == -1)
>   err(1, "pledge");
>  
> - nfd = open(_PATH_NOLOGIN_TXT, O_RDONLY);
> - if (nfd == -1) {
> + if ((nfd = open(_PATH_NOLOGIN_TXT, O_RDONLY)) == -1) {
>   write(STDOUT_FILENO, DEFAULT_MESG, strlen(DEFAULT_MESG));
> - exit (1);
> + exit(1);
>   }
>  
>   while ((nrd = read(nfd, nbuf, sizeof(nbuf))) != -1 && nrd != 0)
>   write(STDOUT_FILENO, nbuf, nrd);
> - close (nfd);
>  
> - exit (1);
> + close(nfd);
> +
> + exit(1);
>  }
>

nologin: Style fixes

2022-11-18 Thread Josiah Frentsos 
Index: nologin.c
===
RCS file: /cvs/src/sbin/nologin/nologin.c,v
retrieving revision 1.9
diff -u -p -r1.9 nologin.c
--- nologin.c   12 Jul 2021 15:09:19 -  1.9
+++ nologin.c   18 Nov 2022 16:59:31 -
@@ -25,7 +25,6 @@
  * SUCH DAMAGE.
  */
 
-#include 
 #include 
 #include 
 #include 
@@ -38,7 +37,6 @@
 
 #define DEFAULT_MESG   "This account is currently not available.\n"
 
-/*ARGSUSED*/
 int
 main(int argc, char *argv[])
 {
@@ -51,15 +49,15 @@ main(int argc, char *argv[])
if (pledge("stdio rpath", NULL) == -1)
err(1, "pledge");
 
-   nfd = open(_PATH_NOLOGIN_TXT, O_RDONLY);
-   if (nfd == -1) {
+   if ((nfd = open(_PATH_NOLOGIN_TXT, O_RDONLY)) == -1) {
write(STDOUT_FILENO, DEFAULT_MESG, strlen(DEFAULT_MESG));
-   exit (1);
+   exit(1);
}
 
while ((nrd = read(nfd, nbuf, sizeof(nbuf))) != -1 && nrd != 0)
write(STDOUT_FILENO, nbuf, nrd);
-   close (nfd);
 
-   exit (1);
+   close(nfd);
+
+   exit(1);
 }

Help testing Apple M1/M2 bootloader update

2022-11-18 Thread Tobias Heider 
Hi all,

we are working on automated bootloader and device-tree updates for Apple
Silicon machines.  This is necessary because both drivers and device trees
are moving targets and without a way to update both we end up in situations
where drivers suddenly stop working.

All of the fw_update(8) infrastructure is already in place, the only thing
missing is installboot(8) automatically copying the new binary to the EFI
system partition.  Before we enable this for everyone we would like to
gather some test feedback to make sure everything works as expected.

For the following you will need a M1/M2 machine running OpenBSD snapshots
with a new enough Asahi bootloader. The easiest way to test that is to check
that you have a M1N1 subdirectory on your EFI system partition. If you don't,
this won't work for you and you will likely need to reinstall at some point
in the future.

To install and test the new bootloader by hand:

1. sysupgrade to the newest snapshot
2. Make sure fw_update downloaded the new bootloader to 
/etc/firmware/apple-boot.bin
3. Install the firmware to your ESP:
  3.1 Mount your EFI system partition (likely your only MSDOS partition)
  `mount /dev/sd0l /mnt` for me
  3.2 Backup /mnt/M1N1/BOOT.BIN to /mnt/M1N1/BOOT.BIN.old
  (if this does not exist, stop here. Your installation is too old)
  3.3 Copy /etc/firmware/apple-boot.bin to /mnt/M1N1/BOOT.BIN
  3.4 umount /mnt
4. Reboot and be greeted with the new bootloader

In the unlikely case that something went wrong, restore /mnt/M1N1/BOOT.BIN from
your backup. In any case, please let us know how it went.

Cheers,
Tobias

unit(1): Sur l’extension de la liste des préfixes du SI

2022-11-18 Thread Florian Obser 
See page 6 of
https://www.bipm.org/documents/20126/77765681/Resolutions-2022.pdf/281f3160-fc56-3e63-dbf7-77b76500990f

OK?

diff --git usr.bin/units/units.lib usr.bin/units/units.lib
index c50011dcbc8..fb61ae63dc4 100644
--- usr.bin/units/units.lib
+++ usr.bin/units/units.lib
@@ -13,6 +13,8 @@ erlang!i!
 K  !j!
 
 / International System of Units (SI) prefixes
+quetta-1e30
+ronna- 1e27
 yotta- 1e24
 zetta- 1e21
 exa-   1e18
@@ -34,8 +36,12 @@ femto-   1e-15
 atto-  1e-18
 zepto- 1e-21
 yocto- 1e-24
+ronto- 1e-27
+quecto-1e-30
 
 / SI symbols
+Q- quetta
+R- ronna
 Y- yotta
 Z- zetta
 E- exa
@@ -55,6 +61,8 @@ f-femto
 a- atto
 z- zepto
 y- yocto
+r- ronto
+q- quecto
 
 / ISO/IEC 8 binary prefixes
 yobi-  1208925819614629174706176

-- 
I'm not entirely sure you are real.

Re: ed: Make use of stderr compliant with POSIX

2022-11-18 Thread Todd C . Miller 
On Sun, 25 Sep 2022 13:12:44 +0200, =?UTF-8?Q?S=C3=B6ren?= Tempel wrote:

> Currently, the OpenBSD ed implementation incorrectly writes information
> to standard error that should be written to standard out (as per POSIX).
>
> For the read and write command the POSIX standard states the following:
>
>   If the command is successful, the number of bytes written shall
>   be written to standard output [...]
>
> However, OpenBSD ed presently writes the number of bytes (for both the
> read and the write command) to standard error. Furthermore, the POSIX
> standard mandates that the infamous "?\n" error string should also be
> written to standard output while OpenBSD ed presently writes the string
> to standard error.

Committed, thanks.

 - todd