OK. This is fine.

Yea. We only allow pushing to the ssh endpoint

In D48798#1115132, @jhb wrote:

FYI, one hiccup with this plan is that yacc only generates C code. I am working on creating a dedicated C API to sit between parse.y and ctld.c so that the rest of ctld can be C++. Blech.

Any sendmail configs affected?

When the selected delete method isn't supported, and we retry with others, we can make bp go NULL since we requeue the command so it's reprocessed in dastart again. different delete methods have different limitations on size, so we can't just transform it to something else or fail the I/O.

Dropping this for now. I needed it for the read retry rework, but since I'm stepping away from that for now, I'll drop this too.

So this isn't quite right, so I'm going to abandon.

In D47169#1114112, @diizzy wrote:

Submission to bugzilla is required for any policy defined my Porters Handbook to apply. I've asked this question before without getting any answer but do we have some kind of unified agreement that we're to accept PRs at all from GitHub from portmgr or people involved with ports?

Note: There's no good interface for this. I was thinking of having a global tunable kern.cam.da.no_read_retry and a similar per-drive sysctl/tunable.

In D48689#1110732, @mav wrote:

This change require DA_FLAG_PACK_INVALID to be reliable avoid false periph invalidations. I am not sure current asc == 0x3a covers all the cases, I have feeling that 0x28/0x00 Not ready to ready change, medium may have changed is even more widespread case of media change and so pack invalidation.

Clarify comments with mav@'s input.

In D48794#1113055, @jkim wrote:

Gleb added a stopgap in rGe1ebda4458bb but I don't like it because we will have vfs.ffs node in MINIMAL kernel.

In D48763#1112606, @bz wrote:

In D48763#1112273, @imp wrote:

It would be better, imho, *NOT* to pollute the base FreeBSD with this junky API.

+1

Instead, I'd create a wrapper for linux printf that re-writes format to at least convert pV to Vp and implement 'V' as a proper modifier. that would be much safer, less invasive and also allow us to have other, weird things from. Linux if we have to should some other format crazy happen in the future that's more likely to break things.

It's a bit more tricky unfortunately if we want something which works on device_printf() etc. It'll need a "conversion intermediate" for the fmt string for quite a few functions and macros but that's definitively doable, just tedious but can also happen incrementally.

In D48794#1112862, @mckusick wrote:

This will cause libufs to fail to build. Also, ffs_subr.c is supposed to contain all the kernel functionality needed by filesystem utilities. And ffs_oldfscompat_inode_read() is one of those functions.

I propose just doing this change instead

diff --git a/sys/ufs/ffs/ffs_subr.c b/sys/ufs/ffs/ffs_subr.c
index e2b09da86ae5..ef488185e026 100644
--- a/sys/ufs/ffs/ffs_subr.c
+++ b/sys/ufs/ffs/ffs_subr.c
@@ -405,9 +405,12 @@ ffs_oldfscompat_write(struct fs *fs)
  */
 static int prttimechgs = 0;
 #ifdef _KERNEL
+#include "opt_dontuse.h" /* Check to see if FFS is in this kernel */
+#ifdef FFS
 SYSCTL_DECL(_vfs_ffs);
 SYSCTL_INT(_vfs_ffs, OID_AUTO, prttimechgs, CTLFLAG_RWTUN, &prttimechgs, 0,
 	"print UFS1 time changes made to inodes");
+#endif /* FFS */
 #endif /* _KERNEL */
 bool
 ffs_oldfscompat_inode_read(struct fs *fs, union dinodep dp, time_t now)

I'm agnostic on the wrapping... I tend to use a 120ish limit myself, though I know that drives people nuts. Others in the project regularly commit > 80 < 100 lines and have for ~decades. kib is the only one that's still objecting.

In D48751#1112399, @dumbbell wrote:

In D48751#1112293, @imp wrote:

Also, please do *NOT* commit this (or any other) with *WHY* as the subject line of the commit message. each commit should have a single line at the top that describes the whole commit.
This is true for the whole series. Also I think I saw a *HOW* heading, that should be omitted as well and the context should make it clear to match our usual practice.

I’m sorry, I did not notice your message before pushing the patches… I use the revision title as the commit’s first line. When I put why/how headers, there are in the "body" of the commit message.

From now on, I will not include these headers.

Also, please do *NOT* commit this (or any other) with *WHY* as the subject line of the commit message. each commit should have a single line at the top that describes the whole commit.
This is true for the whole series. Also I think I saw a *HOW* heading, that should be omitted as well and the context should make it clear to match our usual practice.

Yea, this is a stupid API that flies in the face of years and years of how printf works. The modifiers never follow the main format specifier.
It would break a driver than wnated to say "Memory used: %pV %pP" to signify Virtual and Physical addresses of something, though it's likely rare.
It would be better, imho, *NOT* to pollute the base FreeBSD with this junky API.
Instead, I'd create a wrapper for linux printf that re-writes format to at least convert pV to Vp and implement 'V' as a proper modifier. that would be much safer, less invasive and also allow us to have other, weird things from. Linux if we have to should some other format crazy happen in the future that's more likely to break things.

Only thing I'm at all nervous about is removing stale bmake.. but it's recoverable if in error, so I'm not that nervous.

Bah! You're right. Punting on this one.

In D48689#1110732, @mav wrote:

This change require DA_FLAG_PACK_INVALID to be reliable avoid false periph invalidations. I am not sure current asc == 0x3a covers all the cases, I have feeling that 0x28/0x00 Not ready to ready change, medium may have changed is even more widespread case of media change and so pack invalidation.