Re: services(5): more cleanup
On 5/11/21 9:04 PM, Kurt Mosiejczuk wrote: On Wed, May 12, 2021 at 01:13:55AM +0200, Jeremie Courreges-Anglas wrote: I'd like to drop SWAT, unofficial and dropped by the samba project around the switch to samba4. - moved smtps/465 to the standards section (rfc8314) The new service was named "submissions". I guess we should use both that and the "smtps" alias. https://datatracker.ietf.org/doc/html/rfc8314#section-7.3 ok? A quick question, does this mean that the port in pf.conf will also have to be renamed? I have a few machines which use something to the effect of `pass in on egress proto tcp to port smtps ...`. Will that be broken by this? Similarly smtpd.conf? Or do they do this port-name translation separately? Best, Aisha ok kmos --Kurt Index: services === RCS file: /d/cvs/src/etc/services,v retrieving revision 1.100 diff -u -p -p -u -r1.100 services --- services5 May 2021 11:49:17 - 1.100 +++ services11 May 2021 23:03:12 - @@ -123,7 +123,7 @@ microsoft-ds445/tcp # Microsoft-DS microsoft-ds 445/udp # Microsoft-DS kpasswd 464/tcp # Kerberos 5 password changing kpasswd 464/udp # Kerberos 5 password changing -smtps 465/tcp # mail message submission (TLS) +submissions465/tcp smtps # mail message submission (TLS) photuris 468/tcp # Photuris Key Management photuris 468/udp isakmp500/udp # ISAKMP key management @@ -296,7 +296,6 @@ kerberos_master 751/udp # Kerberos 4 kerberos_master 751/tcp # Kerberos 4 kadmin krb_prop 754/tcp hprop # Kerberos slave propagation krbupdate 760/tcp kreg# BSD Kerberos registration -swat 901/tcp # Samba Web Administration Tool datametrics 1645/udp ekshell2 2106/tcp# Encrypted kshell - UColorado, Boulder webster 2627/tcp# Network dictionary -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: httpd(8): don't try to chunk-encode an empty body
Hi,
I can confirm this patch (from the 6.9 source) makes httpd work with
Android Nextcloud client 3.16, where the unpatched httpd does not work.
Thanks very much!
Cheers,
Steve Williams
On 15/05/2021 9:14 a.m., Florian Obser wrote:
Turns out it's not that difficult to do this correctly since we already
wait until we read all http headers from the fcgi upstream. We just need
to delay writing of the http header until we know if the body is empty
or not.
OK?
diff --git httpd.h httpd.h
index b3a40b3af68..c4adfba232d 100644
--- httpd.h
+++ httpd.h
@@ -300,6 +300,7 @@ struct fcgi_data {
int end;
int status;
int headersdone;
+ int headerssent;
};
struct range {
diff --git server_fcgi.c server_fcgi.c
index 64a0e9d2abb..e1e9704c920 100644
--- server_fcgi.c
+++ server_fcgi.c
@@ -114,6 +114,7 @@ server_fcgi(struct httpd *env, struct client *clt)
clt->clt_fcgi.toread = sizeof(struct fcgi_record_header);
clt->clt_fcgi.status = 200;
clt->clt_fcgi.headersdone = 0;
+ clt->clt_fcgi.headerssent = 0;
if (clt->clt_srvevb != NULL)
evbuffer_free(clt->clt_srvevb);
@@ -544,22 +545,20 @@ server_fcgi_read(struct bufferevent *bev, void *arg)
if (!clt->clt_fcgi.headersdone) {
clt->clt_fcgi.headersdone =
server_fcgi_getheaders(clt);
- if (clt->clt_fcgi.headersdone) {
- if (server_fcgi_header(clt,
- clt->clt_fcgi.status)
- == -1) {
- server_abort_http(clt,
- 500,
- "malformed fcgi "
- "headers");
- return;
- }
- }
if (!EVBUFFER_LENGTH(clt->clt_srvevb))
break;
}
/* FALLTHROUGH */
case FCGI_END_REQUEST:
+ if (clt->clt_fcgi.headersdone &&
+ !clt->clt_fcgi.headerssent) {
+ if (server_fcgi_header(clt,
+ clt->clt_fcgi.status) == -1) {
+ server_abort_http(clt, 500,
+ "malformed fcgi headers");
+ return;
+ }
+ }
if (server_fcgi_writechunk(clt) == -1) {
server_abort_http(clt, 500,
"encoding error");
@@ -600,6 +599,8 @@ server_fcgi_header(struct client *clt, unsigned int code)
char tmbuf[32];
struct kv *kv, *cl, key;
+ clt->clt_fcgi.headerssent = 1;
+
if (desc == NULL || (error = server_httperror_byid(code)) == NULL)
return (-1);
@@ -615,6 +616,12 @@ server_fcgi_header(struct client *clt, unsigned int code)
if (kv_add(&resp->http_headers, "Server", HTTPD_SERVERNAME) == NULL)
return (-1);
+ if (clt->clt_fcgi.type == FCGI_END_REQUEST ||
+ EVBUFFER_LENGTH(clt->clt_srvevb) == 0) {
+ /* Can't chunk encode an empty body. */
+ clt->clt_fcgi.chunked = 0;
+ }
+
/* Set chunked encoding */
if (clt->clt_fcgi.chunked) {
/* XXX Should we keep and handle Content-Length instead? */
[PATCH] make pthread_mutex_t non-opaque
I don't recommend to commit this, but I wanted to resurrect the discussion, perhaps get some early feedback, and to find out if anyone else had been working on this :) This experimental diff merges the two different (futex and non-futex) versions of struct pthread_mutex into one, and makes its members public, so that applications can know its size and control where it's stored. The futex version's 'lock' member is renamed to 'futex', and libc and rthread major versions are bumped. Bootstrap is kind of painful, since changing the size of pthread_mutex breaks ABI in a lot more than just libc and librthread, though. This is preparation for pshared mutexes, and applies on top of tedu@'s unmerged pshared semaphore diff from July 2020, which similarly made semaphores non-opaque. I made some regression test tweaks to that diff, but since the librthread part is unchanged from tedu's, I'm not sending it to the list at this time - you can find it with my modifications in git at https://git.sr.ht/~lotheac/openbsd/log/pthread in case you're interested in replicating my experiments. Because this removes dynamic allocations from pthread_mutex_init, it also allows making a few thing simpler, since pthread_mutex_init can no longer fail. I considered making pthread_mutex struct members hidden by only exposing correct-sized padding members, but that gets tricky due to alignment issues regarding _atomic_lock_t as kettenis@ pointed out in the previous thread back in July. Hiding and/or oversizing the user-visible struct for future expansion while keeping proper alignment might be possible, but not done in this diff - yet. I think hiding at least some of the members will have to be done, since including sys/queue.h in pthread.h (for the TAILQ in pthread_mutex) causes namespace pollution which fails eg. git build from ports. Suggestions welcome though. Since the non-futex version of pthread_mutex uses a tailq, static initialization is a bit tricky -- we can't use TAILQ_HEAD_INITIALIZER in PTHREAD_MUTEX_INITIALIZER, since the former requires the address of the tailq and the latter does not take arguments. So, I added a member called 'needinit' and kept part of the previous initialization logic: when a mutex is being locked, and it has only been statically initialized using PTHREAD_MUTEX_INITIALIZER, pthread_mutex_init will be called to perform the rest of the initialization. (side note: too bad C99 designated initializers can't be used here, since this header could be used with older -std=) I dropped 'volatile' from the pthread_mutex_t typedef with this, because libcxx was failing to convert from 'volatile pthread_mutex *' to 'void *', now that __libcpp_mutex_t is a struct and not just a pointer. I have to admit I don't really understand what the implications of dropping it are, though. After bootstrap, this survived a base build and make regress on amd64. I also lightly tested the non-futex version (rthread_sync.c) by running it through regress/lib/libpthread on amd64, and it seemed to work. I did not build ports or xenocara since this isn't quite finished yet. Thoughts? If this is the way to go, then pthread_cond, pthread_rwlock, and perhaps pthread_*attr should receive similar treatment - I just haven't gotten around to writing those diffs yet. They could (should?) be done as part of the same rthread&libc major bump as this. libc is still using NULL void*s as locks, expecting _MUTEX_LOCK to dynamically allocate them at first use. That still works with this diff, but for future work it might be better to convert those usages to actual pthread_mutex_t's. --- include/pthread.h | 19 +- lib/libc/include/thread_private.h | 17 -- lib/libc/shlib_version | 2 +- lib/libc/thread/rthread_cond.c | 7 +-- lib/libc/thread/rthread_libc.c | 93 +++-- lib/libc/thread/rthread_mutex.c | 93 + lib/libc/thread/rthread_sync.c | 55 + lib/librthread/rthread_barrier.c| 3 +- lib/librthread/rthread_mutex_prio.c | 11 ++-- lib/librthread/shlib_version| 4 +- 10 files changed, 107 insertions(+), 197 deletions(-) diff --git a/include/pthread.h b/include/pthread.h index cfb1356a1d4..9b40c6a07af 100644 --- a/include/pthread.h +++ b/include/pthread.h @@ -40,9 +40,11 @@ /* * Header files. */ +#include #include #include #include +#include #include #include @@ -111,7 +113,7 @@ struct pthread_rwlockattr; */ typedef struct pthread *pthread_t; typedef struct pthread_attr*pthread_attr_t; -typedef volatile struct pthread_mutex *pthread_mutex_t; +typedef struct pthread_mutex pthread_mutex_t; typedef struct pthread_mutex_attr *pthread_mutexattr_t; typedef struct pthread_cond*pthread_cond_t; typedef struct pthread_cond_attr *pthread_condattr_t; @@ -133,8 +135,19 @@ typedef void *pthread_addr_t; typedef void *(*pthread
Re: mandoc: -Tlint: search /usr/local/man as well
Hi Klemens,
Klemens Nanni wrote on Mon, Apr 05, 2021 at 09:33:13PM +0200:
> On Mon, Apr 05, 2021 at 06:47:58PM +0200, Ingo Schwarze wrote:
>> Klemens Nanni wrote on Sun, Apr 04, 2021 at 03:54:43PM +0200:
>>> On Sun, Apr 04, 2021 at 03:42:03PM +0200, Tim van der Molen wrote:
Doesn't mandoc -Tlint -Wstyle do what you want?
>>> I don't think so. Oddly enough, `-Wstyle' does not do what I would
>>> expect: it omits STYLE messages instead of printing them.
>> It does not. It only omits BASE messages, which is the lowest message
>> level and the only one below STYLE. See `man -O tag=base mandoc`
>> what the purpose of BASE is.
[...]
>>> But it would also suppress legitimate messages, e.g. `.Xr' macros with
>>> misspelled manuals in the base MANPATH:
>> Yes, so far, checking of .Xr targets is only done on the BASE level,
>> not on the STYLE level because i regarded the requirement that .Xr targets
>> exist as a requirement of the OpenBSD base system. For portable software
>> outside the OpenBSD base system, in the past, i didn't think checking .Xr
>> targets would be helpful. It appears you now found a use case for that.
> A use case, but not really a requirement, at least not for people
> developing portable software on OpenBSD -- that's where I'm coming from:
> messages telling me installed manuals cannot be found are annoying.
>
> But I guess that turns into a valid use case as soon as mandoc is used
> on and for another system with different manual paths.
>> Your patch is not OK as it stands because mandoc would no longer help
>> developers working on the base system to find .Xr links pointing
>> outside the base system, and we have a policy that we don't want those.
> Agreed.
>> I guess the right thing to do is to leave "-W all" unchanged (including
>> looking in the base system only) but change "-W style" to also do the .Xr
>> target check, but along the user's manpath.
> That makes sense and the diff below enables check_xr() to pick the right
> manual paths.
>
> HOWEVER it currently won't print anything because when `-Wstyle' is used
> mandoc_msg(MANDOCERR_XR_BAD, ...) in check_xr() won't print anything as
> MANDOC_XR_BAD is lower than MANDOCERR_STYLE.
>
> I played swapping those two levels in the `enum mandocerr' but that
> won't quite work (e.g. mandoc_msg() printing the wrong message)...
>
> Ingo, perhaps you have an idea on how to fix that?
Does the following patch work for you?
Here is what it does:
* parse the config file not only in man(1) and apropos(1) mode,
but also in mandoc(1) -T style mode because the full manpath
is now needed for .Xr checking even when the manual page file
to be processed does not need to be searched for but is provided
on the command line
* pass through configuration data to the various checking functions
as far as they now need it;
* move MANDOCERR_XR_BAD from BASE to STYLE both in the enum (mandoc.h)
and in the message catalog (mandoc_msg.c)
* properly document the change
Yours,
Ingo
Index: main.c
===
RCS file: /cvs/src/usr.bin/mandoc/main.c,v
retrieving revision 1.256
diff -u -p -r1.256 main.c
--- main.c 19 Feb 2021 19:49:49 - 1.256
+++ main.c 15 May 2021 20:04:51 -
@@ -1,6 +1,6 @@
/* $OpenBSD: main.c,v 1.256 2021/02/19 19:49:49 kn Exp $ */
/*
- * Copyright (c) 2010-2012, 2014-2020 Ingo Schwarze
+ * Copyright (c) 2010-2012, 2014-2021 Ingo Schwarze
* Copyright (c) 2008-2012 Kristaps Dzonsons
* Copyright (c) 2010 Joerg Sonnenberger
*
@@ -92,7 +92,7 @@ structoutstate {
int mandocdb(int, char *[]);
-static void check_xr(void);
+static void check_xr(struct manpaths *);
static int fs_lookup(const struct manpaths *,
size_t ipath, const char *,
const char *, const char *,
@@ -103,7 +103,7 @@ static int fs_search(const struct man
static void glob_esc(char **, const char *, const char *);
static void outdata_alloc(struct outstate *, struct manoutput *);
static void parse(struct mparse *, int, const char *,
- struct outstate *, struct manoutput *);
+ struct outstate *, struct manconf *);
static void passthrough(int, int);
static void process_onefile(struct mparse *, struct manpage *,
int, struct outstate *, struct manconf *);
@@ -430,7 +430,8 @@ main(int argc, char *argv[])
/* Read the configuration file. */
- if (search.argmode != ARG_FILE)
+ if (search.argmode != ARG_FILE ||
+ mandoc_msg_getmin() == MANDOCERR_STYLE)
manconf_parse(&conf, conf_file, defpaths, auxpaths);
/* man(1): Resolve each name individually. */
@@ -841,7 +842,7 @@ process_onefile(s
Diff for www:OpenBSD/plus69
Hi, Here a diff for www page: OpenBSD/plus69 Isn't it a typo? (I'm not sure) Right? Index: plus69.html === RCS file: /cvs/www/plus69.html,v retrieving revision 1.3 diff -u -r1.3 plus69.html --- plus69.html 5 May 2021 23:58:34 - 1.3 +++ plus69.html 15 May 2021 12:55:06 - @@ -186,7 +186,7 @@ Added a "batch" mode to https://man.openbsd.org/mg.1";>mg(1) via the "-b" command line option which will initialize a pty, run the specified file of mg commands and then exit. Added https://man.openbsd.org/rpki-client.8";>rpki-client(8) -V option to show version. -Removed https://man.openbsd.org/vmd.8";>vwm(8) booting from kernels in raw/qcow2 images. +Removed https://man.openbsd.org/vmd.8";>vmd(8) booting from kernels in raw/qcow2 images. Unlocked https://man.openbsd.org/sendsyslog.2";>sendsyslog(2).
Re: mention apmd(8) on afterboot(8)
On Sat, 15 May 2021, Jason McIntyre wrote: > hi. > > so i'm ok with this. two more points: > > - i'd use a colon after "15%", not a full stop > - i'd remove the " check the man page" line and .Pp because it'd save space > and we already Xr the page. up to you though. Those make sense (diff at the end with corrections). I'll commit it later if nobody objects. Thank you Jason. > > jmc > > On 15 May 2021 17:14:55 BST, Paco Esteban wrote: > >Hi Jason, > > > >On Sat, 15 May 2021, Jason McIntyre wrote: > > > >> On Sat, May 15, 2021 at 12:27:53PM +0200, Paco Esteban wrote: > >> > Hi, > >> > > >> > This adds a mention to apmd(8) on afterboot(8). Original idea is > >from > >> > kmos@, crappy wording is mine (corrections/suggestions welcome). > >> > > >> > ok to commit ? > >> > > >> > >> hi. > >> > >> i guess i don;t object, but i'm not convinced this page needs such a > >> large block of text on power management. there is a "Daemons" section > >> which could just provide a nod to the relevant pages. > > > >I put it there after the Video stuff which is somewhat tailored to > >laptop users. But I don't have a strong opinion on where to put it. > > > >The Daemons section only mentions intro(8) which does not have any > >mention of apmd(8) at all. > > > >As we already make mentions to things like Printers or Video there it > >does not feel weird to me. But yeah, it could be shorter. Maybe > >without the rcctl example lines and just point to the man page. > > > >In any case, mods below with your suggestions. > > > >> > >> one note inline: > >> > >> > diff b8464fd1ac0e783621fb415f793b0d73c4fb /usr/src > >> > blob - 8b4079f857da2aa79783848d450addba1e5831e6 > >> > file + share/man/man8/afterboot.8 > >> > --- share/man/man8/afterboot.8 > >> > +++ share/man/man8/afterboot.8 > >> > @@ -418,6 +418,23 @@ Normal recording can be enabled by adding the > >followin > >> > kern.audio.record=1 > >> > kern.video.record=1 > >> > .Ed > >> > +.Ss Power management > >> > +The > >> > +.Xr apmd 8 > >> > +daemon controls the Advanced Power Management (APM). > >> > +If your device's BIOS supports it, you can configure this daemon > >to act on > >> > +different events and adjust the performance of your device. > >> > >> we tend to avoid 2nd person text like this. so it could be written > >like: > >> > >>If the BIOS supports it, the daemon can be configured to act on > >>different events and adjust device performance. > > > >Right, that reads way better. > >I've included a modified version at the end with that form and a wee > >bit > >shorter. > > > >> > >> jmc > >> > >> > +In the following example > >> > +.Xr apmd 8 > >> > +is configured to start on boot in automatic performance adjustment > >mode and > >> > +suspend the system if no AC is connected and the estimated battery > >life is > >> > +equal or below 15%. > >> > +.Bd -literal -offset indent > >> > +# rcctl set apmd status on > >> > +# rcctl set apmd flags -A -z 15 > >> > +.Ed > >> > +.Pp > >> > +For more information check the man page. > >> > .Ss Mail aliases > >> > Edit > >> > .Pa /etc/mail/aliases > > > >diff aeddc3fc1c2dc619781d7d37222447f40fb248a7 /usr/src > >blob - 8b4079f857da2aa79783848d450addba1e5831e6 > >file + share/man/man8/afterboot.8 > >--- share/man/man8/afterboot.8 > >+++ share/man/man8/afterboot.8 > >@@ -418,6 +418,19 @@ Normal recording can be enabled by adding the > >followin > > kern.audio.record=1 > > kern.video.record=1 > > .Ed > >+.Ss Power management > >+If the BIOS supports it, > >+.Xr apmd 8 > >+can be configured to act on different events and adjust device > >performance. > >+In the following example it is configured to start on boot in > >automatic > >+performance adjustment mode and suspend the system if no AC is > >connected and > >+the estimated battery life is equal or below 15%. > >+.Bd -literal -offset indent > >+# rcctl set apmd status on > >+# rcctl set apmd flags -A -z 15 > >+.Ed > >+.Pp > >+For more information check the man page. > > .Ss Mail aliases > > Edit > > .Pa /etc/mail/aliases > diff refs/heads/master refs/heads/mystuff blob - 8b4079f857da2aa79783848d450addba1e5831e6 blob + 06f70e3860849c899682c2e23d42f1a21fcd9bf4 --- share/man/man8/afterboot.8 +++ share/man/man8/afterboot.8 @@ -418,6 +418,17 @@ Normal recording can be enabled by adding the followin kern.audio.record=1 kern.video.record=1 .Ed +.Ss Power management +If the BIOS supports it, +.Xr apmd 8 +can be configured to act on different events and adjust device performance. +In the following example it is configured to start on boot in automatic +performance adjustment mode and suspend the system if no AC is connected and +the estimated battery life is equal or below 15%: +.Bd -literal -offset indent +# rcctl set apmd status on +# rcctl set apmd flags -A -z 15 +.Ed .Ss Mail aliases Edit .Pa /etc/mail/aliases -- Paco Esteban. 0x5818130B8A6DBC03
Re: mention apmd(8) on afterboot(8)
hi. so i'm ok with this. two more points: - i'd use a colon after "15%", not a full stop - i'd remove the " check the man page" line and .Pp because it'd save space and we already Xr the page. up to you though. jmc On 15 May 2021 17:14:55 BST, Paco Esteban wrote: >Hi Jason, > >On Sat, 15 May 2021, Jason McIntyre wrote: > >> On Sat, May 15, 2021 at 12:27:53PM +0200, Paco Esteban wrote: >> > Hi, >> > >> > This adds a mention to apmd(8) on afterboot(8). Original idea is >from >> > kmos@, crappy wording is mine (corrections/suggestions welcome). >> > >> > ok to commit ? >> > >> >> hi. >> >> i guess i don;t object, but i'm not convinced this page needs such a >> large block of text on power management. there is a "Daemons" section >> which could just provide a nod to the relevant pages. > >I put it there after the Video stuff which is somewhat tailored to >laptop users. But I don't have a strong opinion on where to put it. > >The Daemons section only mentions intro(8) which does not have any >mention of apmd(8) at all. > >As we already make mentions to things like Printers or Video there it >does not feel weird to me. But yeah, it could be shorter. Maybe >without the rcctl example lines and just point to the man page. > >In any case, mods below with your suggestions. > >> >> one note inline: >> >> > diff b8464fd1ac0e783621fb415f793b0d73c4fb /usr/src >> > blob - 8b4079f857da2aa79783848d450addba1e5831e6 >> > file + share/man/man8/afterboot.8 >> > --- share/man/man8/afterboot.8 >> > +++ share/man/man8/afterboot.8 >> > @@ -418,6 +418,23 @@ Normal recording can be enabled by adding the >followin >> > kern.audio.record=1 >> > kern.video.record=1 >> > .Ed >> > +.Ss Power management >> > +The >> > +.Xr apmd 8 >> > +daemon controls the Advanced Power Management (APM). >> > +If your device's BIOS supports it, you can configure this daemon >to act on >> > +different events and adjust the performance of your device. >> >> we tend to avoid 2nd person text like this. so it could be written >like: >> >> If the BIOS supports it, the daemon can be configured to act on >> different events and adjust device performance. > >Right, that reads way better. >I've included a modified version at the end with that form and a wee >bit >shorter. > >> >> jmc >> >> > +In the following example >> > +.Xr apmd 8 >> > +is configured to start on boot in automatic performance adjustment >mode and >> > +suspend the system if no AC is connected and the estimated battery >life is >> > +equal or below 15%. >> > +.Bd -literal -offset indent >> > +# rcctl set apmd status on >> > +# rcctl set apmd flags -A -z 15 >> > +.Ed >> > +.Pp >> > +For more information check the man page. >> > .Ss Mail aliases >> > Edit >> > .Pa /etc/mail/aliases > >diff aeddc3fc1c2dc619781d7d37222447f40fb248a7 /usr/src >blob - 8b4079f857da2aa79783848d450addba1e5831e6 >file + share/man/man8/afterboot.8 >--- share/man/man8/afterboot.8 >+++ share/man/man8/afterboot.8 >@@ -418,6 +418,19 @@ Normal recording can be enabled by adding the >followin > kern.audio.record=1 > kern.video.record=1 > .Ed >+.Ss Power management >+If the BIOS supports it, >+.Xr apmd 8 >+can be configured to act on different events and adjust device >performance. >+In the following example it is configured to start on boot in >automatic >+performance adjustment mode and suspend the system if no AC is >connected and >+the estimated battery life is equal or below 15%. >+.Bd -literal -offset indent >+# rcctl set apmd status on >+# rcctl set apmd flags -A -z 15 >+.Ed >+.Pp >+For more information check the man page. > .Ss Mail aliases > Edit > .Pa /etc/mail/aliases
Re: mention apmd(8) on afterboot(8)
Hi Jason, On Sat, 15 May 2021, Jason McIntyre wrote: > On Sat, May 15, 2021 at 12:27:53PM +0200, Paco Esteban wrote: > > Hi, > > > > This adds a mention to apmd(8) on afterboot(8). Original idea is from > > kmos@, crappy wording is mine (corrections/suggestions welcome). > > > > ok to commit ? > > > > hi. > > i guess i don;t object, but i'm not convinced this page needs such a > large block of text on power management. there is a "Daemons" section > which could just provide a nod to the relevant pages. I put it there after the Video stuff which is somewhat tailored to laptop users. But I don't have a strong opinion on where to put it. The Daemons section only mentions intro(8) which does not have any mention of apmd(8) at all. As we already make mentions to things like Printers or Video there it does not feel weird to me. But yeah, it could be shorter. Maybe without the rcctl example lines and just point to the man page. In any case, mods below with your suggestions. > > one note inline: > > > diff b8464fd1ac0e783621fb415f793b0d73c4fb /usr/src > > blob - 8b4079f857da2aa79783848d450addba1e5831e6 > > file + share/man/man8/afterboot.8 > > --- share/man/man8/afterboot.8 > > +++ share/man/man8/afterboot.8 > > @@ -418,6 +418,23 @@ Normal recording can be enabled by adding the followin > > kern.audio.record=1 > > kern.video.record=1 > > .Ed > > +.Ss Power management > > +The > > +.Xr apmd 8 > > +daemon controls the Advanced Power Management (APM). > > +If your device's BIOS supports it, you can configure this daemon to act on > > +different events and adjust the performance of your device. > > we tend to avoid 2nd person text like this. so it could be written like: > > If the BIOS supports it, the daemon can be configured to act on > different events and adjust device performance. Right, that reads way better. I've included a modified version at the end with that form and a wee bit shorter. > > jmc > > > +In the following example > > +.Xr apmd 8 > > +is configured to start on boot in automatic performance adjustment mode and > > +suspend the system if no AC is connected and the estimated battery life is > > +equal or below 15%. > > +.Bd -literal -offset indent > > +# rcctl set apmd status on > > +# rcctl set apmd flags -A -z 15 > > +.Ed > > +.Pp > > +For more information check the man page. > > .Ss Mail aliases > > Edit > > .Pa /etc/mail/aliases diff aeddc3fc1c2dc619781d7d37222447f40fb248a7 /usr/src blob - 8b4079f857da2aa79783848d450addba1e5831e6 file + share/man/man8/afterboot.8 --- share/man/man8/afterboot.8 +++ share/man/man8/afterboot.8 @@ -418,6 +418,19 @@ Normal recording can be enabled by adding the followin kern.audio.record=1 kern.video.record=1 .Ed +.Ss Power management +If the BIOS supports it, +.Xr apmd 8 +can be configured to act on different events and adjust device performance. +In the following example it is configured to start on boot in automatic +performance adjustment mode and suspend the system if no AC is connected and +the estimated battery life is equal or below 15%. +.Bd -literal -offset indent +# rcctl set apmd status on +# rcctl set apmd flags -A -z 15 +.Ed +.Pp +For more information check the man page. .Ss Mail aliases Edit .Pa /etc/mail/aliases -- Paco Esteban. 0x5818130B8A6DBC03
Re: httpd(8): don't try to chunk-encode an empty body
Turns out it's not that difficult to do this correctly since we already
wait until we read all http headers from the fcgi upstream. We just need
to delay writing of the http header until we know if the body is empty
or not.
OK?
diff --git httpd.h httpd.h
index b3a40b3af68..c4adfba232d 100644
--- httpd.h
+++ httpd.h
@@ -300,6 +300,7 @@ struct fcgi_data {
int end;
int status;
int headersdone;
+ int headerssent;
};
struct range {
diff --git server_fcgi.c server_fcgi.c
index 64a0e9d2abb..e1e9704c920 100644
--- server_fcgi.c
+++ server_fcgi.c
@@ -114,6 +114,7 @@ server_fcgi(struct httpd *env, struct client *clt)
clt->clt_fcgi.toread = sizeof(struct fcgi_record_header);
clt->clt_fcgi.status = 200;
clt->clt_fcgi.headersdone = 0;
+ clt->clt_fcgi.headerssent = 0;
if (clt->clt_srvevb != NULL)
evbuffer_free(clt->clt_srvevb);
@@ -544,22 +545,20 @@ server_fcgi_read(struct bufferevent *bev, void *arg)
if (!clt->clt_fcgi.headersdone) {
clt->clt_fcgi.headersdone =
server_fcgi_getheaders(clt);
- if (clt->clt_fcgi.headersdone) {
- if (server_fcgi_header(clt,
- clt->clt_fcgi.status)
- == -1) {
- server_abort_http(clt,
- 500,
- "malformed fcgi "
- "headers");
- return;
- }
- }
if (!EVBUFFER_LENGTH(clt->clt_srvevb))
break;
}
/* FALLTHROUGH */
case FCGI_END_REQUEST:
+ if (clt->clt_fcgi.headersdone &&
+ !clt->clt_fcgi.headerssent) {
+ if (server_fcgi_header(clt,
+ clt->clt_fcgi.status) == -1) {
+ server_abort_http(clt, 500,
+ "malformed fcgi headers");
+ return;
+ }
+ }
if (server_fcgi_writechunk(clt) == -1) {
server_abort_http(clt, 500,
"encoding error");
@@ -600,6 +599,8 @@ server_fcgi_header(struct client *clt, unsigned int code)
char tmbuf[32];
struct kv *kv, *cl, key;
+ clt->clt_fcgi.headerssent = 1;
+
if (desc == NULL || (error = server_httperror_byid(code)) == NULL)
return (-1);
@@ -615,6 +616,12 @@ server_fcgi_header(struct client *clt, unsigned int code)
if (kv_add(&resp->http_headers, "Server", HTTPD_SERVERNAME) == NULL)
return (-1);
+ if (clt->clt_fcgi.type == FCGI_END_REQUEST ||
+ EVBUFFER_LENGTH(clt->clt_srvevb) == 0) {
+ /* Can't chunk encode an empty body. */
+ clt->clt_fcgi.chunked = 0;
+ }
+
/* Set chunked encoding */
if (clt->clt_fcgi.chunked) {
/* XXX Should we keep and handle Content-Length instead? */
--
I'm not entirely sure you are real.
Re: mention apmd(8) on afterboot(8)
On Sat, May 15, 2021 at 12:27:53PM +0200, Paco Esteban wrote: > Hi, > > This adds a mention to apmd(8) on afterboot(8). Original idea is from > kmos@, crappy wording is mine (corrections/suggestions welcome). > > ok to commit ? > hi. i guess i don;t object, but i'm not convinced this page needs such a large block of text on power management. there is a "Daemons" section which could just provide a nod to the relevant pages. one note inline: > diff b8464fd1ac0e783621fb415f793b0d73c4fb /usr/src > blob - 8b4079f857da2aa79783848d450addba1e5831e6 > file + share/man/man8/afterboot.8 > --- share/man/man8/afterboot.8 > +++ share/man/man8/afterboot.8 > @@ -418,6 +418,23 @@ Normal recording can be enabled by adding the followin > kern.audio.record=1 > kern.video.record=1 > .Ed > +.Ss Power management > +The > +.Xr apmd 8 > +daemon controls the Advanced Power Management (APM). > +If your device's BIOS supports it, you can configure this daemon to act on > +different events and adjust the performance of your device. we tend to avoid 2nd person text like this. so it could be written like: If the BIOS supports it, the daemon can be configured to act on different events and adjust device performance. jmc > +In the following example > +.Xr apmd 8 > +is configured to start on boot in automatic performance adjustment mode and > +suspend the system if no AC is connected and the estimated battery life is > +equal or below 15%. > +.Bd -literal -offset indent > +# rcctl set apmd status on > +# rcctl set apmd flags -A -z 15 > +.Ed > +.Pp > +For more information check the man page. > .Ss Mail aliases > Edit > .Pa /etc/mail/aliases > > -- > Paco Esteban. > 0x5818130B8A6DBC03 >
Re: panic(9): set panicstr atomically
> Date: Sat, 15 May 2021 11:06:39 + > From: Visa Hankala > > On Wed, May 12, 2021 at 07:08:39PM -0500, Scott Cheloha wrote: > > In a separate mail thread, bluhm@ mentioned that panic(9) does not > > cleanly handle multiple CPUs entering it simultaneously: > > > > https://marc.info/?l=openbsd-tech&m=161908805925325&w=2 > > > > I'm unsure which part of panic(9) is causing the problem he mentions, > > but one obvious issue I see is that panicstr is not set atomically, > > so two CPUs entering panic(9) simultaneously may clobber panicbuf. > > > > If we set panicstr atomically only one CPU will write panicbuf. > > I think most of the clobbering is explained by more than one CPU writing > to the console at the same time. The vsnprintf() and setting of panicstr > usually happen quickly, so the kind of garbling occasionally seen with > nearly simultaneous panicking is not likely to arise there. Console I/O, > on the other hand, can be orders of magnitude slower. That, and the fact > that mutexes become no-ops once panicstr is set, create a slow phase > where multiple CPUs can easily be concurrently even if the initial > timings were not so close after all. > > I feel that panic() should let only the first panicker run the panic > code and stop any other CPUs, like NetBSD does. Another option is to > serialize panic() in a more proper way. Or maybe secondary panickers > should just delay a little at the start of panic()... The problem with serializing panics is that you increase the risk that you deadlock and don't see any messages at all...
Re: panic(9): set panicstr atomically
On Wed, May 12, 2021 at 07:08:39PM -0500, Scott Cheloha wrote: > In a separate mail thread, bluhm@ mentioned that panic(9) does not > cleanly handle multiple CPUs entering it simultaneously: > > https://marc.info/?l=openbsd-tech&m=161908805925325&w=2 > > I'm unsure which part of panic(9) is causing the problem he mentions, > but one obvious issue I see is that panicstr is not set atomically, > so two CPUs entering panic(9) simultaneously may clobber panicbuf. > > If we set panicstr atomically only one CPU will write panicbuf. I think most of the clobbering is explained by more than one CPU writing to the console at the same time. The vsnprintf() and setting of panicstr usually happen quickly, so the kind of garbling occasionally seen with nearly simultaneous panicking is not likely to arise there. Console I/O, on the other hand, can be orders of magnitude slower. That, and the fact that mutexes become no-ops once panicstr is set, create a slow phase where multiple CPUs can easily be concurrently even if the initial timings were not so close after all. I feel that panic() should let only the first panicker run the panic code and stop any other CPUs, like NetBSD does. Another option is to serialize panic() in a more proper way. Or maybe secondary panickers should just delay a little at the start of panic()...
mention apmd(8) on afterboot(8)
Hi, This adds a mention to apmd(8) on afterboot(8). Original idea is from kmos@, crappy wording is mine (corrections/suggestions welcome). ok to commit ? diff b8464fd1ac0e783621fb415f793b0d73c4fb /usr/src blob - 8b4079f857da2aa79783848d450addba1e5831e6 file + share/man/man8/afterboot.8 --- share/man/man8/afterboot.8 +++ share/man/man8/afterboot.8 @@ -418,6 +418,23 @@ Normal recording can be enabled by adding the followin kern.audio.record=1 kern.video.record=1 .Ed +.Ss Power management +The +.Xr apmd 8 +daemon controls the Advanced Power Management (APM). +If your device's BIOS supports it, you can configure this daemon to act on +different events and adjust the performance of your device. +In the following example +.Xr apmd 8 +is configured to start on boot in automatic performance adjustment mode and +suspend the system if no AC is connected and the estimated battery life is +equal or below 15%. +.Bd -literal -offset indent +# rcctl set apmd status on +# rcctl set apmd flags -A -z 15 +.Ed +.Pp +For more information check the man page. .Ss Mail aliases Edit .Pa /etc/mail/aliases -- Paco Esteban. 0x5818130B8A6DBC03
umsm(4)/umb(4) supports for Quectel EC25
Hi,
Attached is a diff for umsm(4)/umb(4) which enables support for Quectel EC25.
umsm0 at uhub0 port 2 configuration 1 interface 0 "Android Android" rev
2.00/3.18 addr 2
ucom0 at umsm0
umsm1 at uhub0 port 2 configuration 1 interface 1 "Android Android" rev
2.00/3.18 addr 2
ucom1 at umsm1
umsm2 at uhub0 port 2 configuration 1 interface 2 "Android Android" rev
2.00/3.18 addr 2
ucom2 at umsm2
umsm3 at uhub0 port 2 configuration 1 interface 3 "Android Android" rev
2.00/3.18 addr 2
ucom3 at umsm3
umsm4 at uhub0 port 2 configuration 1 interface 4 "Android Android" rev
2.00/3.18 addr 2
ucom4 at umsm4
The Quectel EC25 is a MBIM compatible chip, you'll need to switch it into MBIM
mode via a specific AT-command (AT+QCFG="usbnet",2) over the serial port cuaU2.
Need additional quirks to get Quectel to work.
umb0 at uhub0 port 2 "Android Android" rev 2.00/3.18 addr 2
Index: share/man/man4/umb.4
===
RCS file: /cvs/src/share/man/man4/umb.4,v
retrieving revision 1.12
diff -u -p -u -p -r1.12 umb.4
--- share/man/man4/umb.428 Mar 2021 12:10:05 - 1.12
+++ share/man/man4/umb.415 May 2021 09:05:33 -
@@ -49,6 +49,7 @@ The following devices should work:
.It Fibocom L831-EAU
.\" .It Huawei ME906s -- attaches but needs more work
.It Medion Mobile S4222 (MediaTek OEM)
+.It Quectel EC25
.It Sierra Wireless EM7345
.It Sierra Wireless EM7455
.It Sierra Wireless EM8805
Index: share/man/man4/umsm.4
===
RCS file: /cvs/src/share/man/man4/umsm.4,v
retrieving revision 1.95
diff -u -p -u -p -r1.95 umsm.4
--- share/man/man4/umsm.4 11 Apr 2018 04:23:10 - 1.95
+++ share/man/man4/umsm.4 15 May 2021 09:05:33 -
@@ -100,6 +100,7 @@ driver:
.It Li "Option iCON 225" Ta "USB"
.It Li "Option iCON 505" Ta "USB"
.It Li "Option GlobeTrotter HSUPA 380E" Ta "PCI Express Mini Card"
+.It Li "Quectel EC25" Ta "PCI Express Mini Card"
.It Li "Sierra Wireless MC8755" Ta "PCI Express Mini Card"
.It Li "Sierra Wireless MC8775" Ta "PCI Express Mini Card"
.It Li "Sierra Wireless MC8790" Ta "PCI Express Mini Card"
Index: sys/dev/usb/if_umb.c
===
RCS file: /cvs/src/sys/dev/usb/if_umb.c,v
retrieving revision 1.44
diff -u -p -u -p -r1.44 if_umb.c
--- sys/dev/usb/if_umb.c22 Apr 2021 14:06:59 - 1.44
+++ sys/dev/usb/if_umb.c15 May 2021 09:05:35 -
@@ -238,6 +238,13 @@ const struct umb_quirk umb_quirks[] = {
UMATCH_VENDOR_PRODUCT
},
+ { { USB_VENDOR_QUECTEL, USB_PRODUCT_QUECTEL_EC25 },
+ 0,
+ 1,
+ UMATCH_VENDOR_PRODUCT
+ },
+
+
{ { USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_ME906S },
UMBFLG_NDP_AT_END,
3,
Index: sys/dev/usb/umsm.c
===
RCS file: /cvs/src/sys/dev/usb/umsm.c,v
retrieving revision 1.118
diff -u -p -u -p -r1.118 umsm.c
--- sys/dev/usb/umsm.c 31 Jul 2020 10:49:33 - 1.118
+++ sys/dev/usb/umsm.c 15 May 2021 09:05:35 -
@@ -173,6 +173,8 @@ static const struct umsm_type umsm_devs[
{{ USB_VENDOR_QUANTA2, USB_PRODUCT_QUANTA2_UMASS }, DEV_UMASS4},
{{ USB_VENDOR_QUANTA2, USB_PRODUCT_QUANTA2_Q101 }, 0},
+ {{ USB_VENDOR_QUECTEL, USB_PRODUCT_QUECTEL_EC25 }, 0},
+
{{ USB_VENDOR_ZTE, USB_PRODUCT_ZTE_AC2746 }, 0},
{{ USB_VENDOR_ZTE, USB_PRODUCT_ZTE_UMASS_INSTALLER }, DEV_UMASS4},
{{ USB_VENDOR_ZTE, USB_PRODUCT_ZTE_UMASS_INSTALLER2 }, DEV_UMASS6},
Index: sys/dev/usb/usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.739
diff -u -p -u -p -r1.739 usbdevs
--- sys/dev/usb/usbdevs 25 Apr 2021 15:58:01 - 1.739
+++ sys/dev/usb/usbdevs 15 May 2021 09:05:35 -
@@ -644,6 +644,7 @@ vendor THINGM 0x27b8 ThingM
vendor ASUSTEK 0x2821 ASUSTeK Computer
vendor PIONEERDJ 0x2b73 Pioneer DJ
vendor PLANEX 0x2c02 Planex Communications
+vendor QUECTEL 0x2c7c Quectel
vendor CLUB3D 0x2d1c Club 3D
vendor CLEVO 0x30da CLEVO
vendor DYNABOOK0x30f3 Dynabook
@@ -3679,6 +3680,9 @@ product QUALCOMM2 MSM_PHONE 0x6000 CDMA
product QUANTA RT3070 0x0304 RT3070
product QUANTA2 UMASS 0x1000 Quanta USB MSM (umass mode)
product QUANTA2 Q101 0xea02 Quanta Q101 HSDPA USB modem
+
+/* Quectel products */
+product QUECTEL EC25 0x0125 EC25 LTE
/* Quickshot products */
product QUICKSHOT STRIKEPAD0x6238 USB StrikePad
