Re: man find -exec -- a little bit more hand-holding
On Fri, Aug 14, 2020 at 04:30:13AM +0100, ropers wrote:
> The find man page might benefit from adding a little bit more
> user-friendly hand-holding here:
>
> Index: find.1
> ===
> RCS file: /cvs/src/usr.bin/find/find.1,v
> retrieving revision 1.98
> diff -u -r1.98 find.1
> --- find.12 Sep 2019 21:18:41 - 1.98
> +++ find.114 Aug 2020 02:59:48 -
> @@ -231,6 +231,10 @@
> .Qq {}
> appears anywhere in the utility name or the
> arguments it is replaced by the pathname of the current file.
> +The semicolon will likely have to be escaped, depending on the shell.
> +See
> +.Sx CAVEATS
> +below.
> .Pp
> If terminated by a plus sign,
> the pathnames for which the
>
>
> EXAMPLE:
>
> $ find ~ -iname ".*" -exec echo {} \;
> works, but
> $ find ~ -iname ".*" -exec echo {} ;
> does not.
>
> (Yes, this is a contrived example. I wouldn't want to make people
> copy things all over the place.)
>
hi.
first off, i do sympathise ;) shell escaping always hurts my head too.
regarding your diff: i don;t think this is the way to go. really, we
would have to add such a text every time we encounter a character that
may need escaping. so the whole point of the text in CAVEATS in to avoid
such a large text addition, and just remind people to watch out
(caveat!) the text in CAVEATS pretty much makes your diff redundant.
the EXAMPLES section additionally shows escaping.
i think there's enough there for people.
havng said that:
- i had hoped we'd have a specific \; example. that format is so
commonly seen that it might make sense. so i'd not be against either
adding such an example (currently EXAMPLES is fairly small) or
altering another.
- i cannot work out what is with the \! examples. i know we try to make
entries work for both csh and sh style shells, but stuff like this
works without escaping:
$ find . ! -type f
jmc
man find -exec -- a little bit more hand-holding
The find man page might benefit from adding a little bit more
user-friendly hand-holding here:
Index: find.1
===
RCS file: /cvs/src/usr.bin/find/find.1,v
retrieving revision 1.98
diff -u -r1.98 find.1
--- find.1 2 Sep 2019 21:18:41 - 1.98
+++ find.1 14 Aug 2020 02:59:48 -
@@ -231,6 +231,10 @@
.Qq {}
appears anywhere in the utility name or the
arguments it is replaced by the pathname of the current file.
+The semicolon will likely have to be escaped, depending on the shell.
+See
+.Sx CAVEATS
+below.
.Pp
If terminated by a plus sign,
the pathnames for which the
EXAMPLE:
$ find ~ -iname ".*" -exec echo {} \;
works, but
$ find ~ -iname ".*" -exec echo {} ;
does not.
(Yes, this is a contrived example. I wouldn't want to make people
copy things all over the place.)
Re: Enable arm64 PAN feature
On Thu, Aug 13, 2020 at 09:17:41PM +0200, Mark Kettenis wrote:
> ARMv8.1 introduced PAN (Priviliged Access Never) which prevents the
> kernel from accessing userland data. This can be bypassed by using
> special instructions which we already use in copyin(9) and friends.
> So we can simply turn this feature on if the CPU supports it.
>
> Tested on an Odroid-C4 which has Cortex-A55 cores that have PAN
> support.
>
> ok?
This should be changing PSTATE.PAN as well. Can you force an
acess of this type to be sure the permission fault occurs?
>From the Arm ARM:
"When the value of PSTATE.PAN is 1, any privileged data access from
EL1, or EL2 when HCR_EL2.E2H is 1, to a virtual memory address that
is accessible at EL0, generates a Permission fault.
When the value of PSTATE.PAN is 0, the translation system is the
same as in Armv8.0.
When ARMv8.1-PAN is implemented, the SPSR_EL1.PAN, SPSR_EL2.PAN, and
SPSR_EL3.PAN bits are used for exception returns, and the DSPSR_EL0
register is used for entry to or exit from Debug state.
When ARMv8.1-PAN is implemented, the SCTLR_EL1.SPAN and SCTLR_EL2.SPAN
bits are used to control whether the PAN bit is set on an exception
to EL1 or EL2."
>
>
> Index: arch/arm64/arm64/cpu.c
> ===
> RCS file: /cvs/src/sys/arch/arm64/arm64/cpu.c,v
> retrieving revision 1.38
> diff -u -p -r1.38 cpu.c
> --- arch/arm64/arm64/cpu.c4 Jun 2020 21:18:16 - 1.38
> +++ arch/arm64/arm64/cpu.c13 Aug 2020 19:12:30 -
> @@ -321,6 +321,7 @@ cpu_attach(struct device *parent, struct
> struct fdt_attach_args *faa = aux;
> struct cpu_info *ci;
> uint64_t mpidr = READ_SPECIALREG(mpidr_el1);
> + uint64_t id_aa64mmfr1, sctlr;
> uint32_t opp;
>
> KASSERT(faa->fa_nreg > 0);
> @@ -393,6 +394,14 @@ cpu_attach(struct device *parent, struct
> cpu_cpuspeed = cpu_clockspeed;
> }
>
> + /* Enable PAN. */
> + id_aa64mmfr1 = READ_SPECIALREG(id_aa64mmfr1_el1);
> + if (ID_AA64MMFR1_PAN(id_aa64mmfr1) != ID_AA64MMFR1_PAN_NONE) {
> + sctlr = READ_SPECIALREG(sctlr_el1);
> + sctlr &= ~SCTLR_SPAN;
> + WRITE_SPECIALREG(sctlr_el1, sctlr);
> + }
> +
> /* Initialize debug registers. */
> WRITE_SPECIALREG(mdscr_el1, DBG_MDSCR_TDCC);
> WRITE_SPECIALREG(oslar_el1, 0);
> @@ -522,6 +531,7 @@ cpu_boot_secondary(struct cpu_info *ci)
> void
> cpu_start_secondary(struct cpu_info *ci)
> {
> + uint64_t id_aa64mmfr1, sctlr;
> uint64_t tcr;
> int s;
>
> @@ -543,6 +553,14 @@ cpu_start_secondary(struct cpu_info *ci)
> tcr |= TCR_T0SZ(64 - USER_SPACE_BITS);
> tcr |= TCR_A1;
> WRITE_SPECIALREG(tcr_el1, tcr);
> +
> + /* Enable PAN. */
> + id_aa64mmfr1 = READ_SPECIALREG(id_aa64mmfr1_el1);
> + if (ID_AA64MMFR1_PAN(id_aa64mmfr1) != ID_AA64MMFR1_PAN_NONE) {
> + sctlr = READ_SPECIALREG(sctlr_el1);
> + sctlr &= ~SCTLR_SPAN;
> + WRITE_SPECIALREG(sctlr_el1, sctlr);
> + }
>
> /* Initialize debug registers. */
> WRITE_SPECIALREG(mdscr_el1, DBG_MDSCR_TDCC);
> Index: arch/arm64/include/armreg.h
> ===
> RCS file: /cvs/src/sys/arch/arm64/include/armreg.h,v
> retrieving revision 1.11
> diff -u -p -r1.11 armreg.h
> --- arch/arm64/include/armreg.h 5 Jun 2020 22:14:25 - 1.11
> +++ arch/arm64/include/armreg.h 13 Aug 2020 19:12:30 -
> @@ -451,6 +451,7 @@
> #define SCTLR_nTWI 0x0001
> #define SCTLR_nTWE 0x0004
> #define SCTLR_WXN 0x0008
> +#define SCTLR_SPAN 0x0080
> #define SCTLR_EOE 0x0100
> #define SCTLR_EE0x0200
> #define SCTLR_UCI 0x0400
> @@ -478,6 +479,7 @@
> #define PSR_D 0x0200
> #define PSR_IL 0x0010
> #define PSR_SS 0x0020
> +#define PSR_PAN 0x0040
> #define PSR_V 0x1000
> #define PSR_C 0x2000
> #define PSR_Z 0x4000
>
>
if_spppsubr.c: zap LOOPALIVECNT
Unused since revision 1.138 date: 2015/09/30 09:45:20; author: sthen; state: Exp; lines: +50 -279; commitid: 0pACTtU Sw4WmBBBr; remove cisco hdlc code from sppp(4), it's no longer used - pppoe(4) only uses ppp framing, and the drivers for sync serial cards have been removed so the sppp code is now only used to support pppoe(4). ok mpi@, kill it chris@ OK? Index: if_spppsubr.c === RCS file: /cvs/src/sys/net/if_spppsubr.c,v retrieving revision 1.184 diff -u -p -r1.184 if_spppsubr.c --- if_spppsubr.c 10 Jul 2020 13:26:42 - 1.184 +++ if_spppsubr.c 13 Aug 2020 21:46:37 - @@ -68,7 +68,6 @@ # define UNTIMEOUT(fun, arg, handle) \ timeout_del(&(handle)) -#define LOOPALIVECNT 3 /* loopback detection tries */ #define MAXALIVECNT3 /* max. missed alive packets */ #defineNORECV_TIME 15 /* before we get worried */
Re: Enable arm64 PAN feature
> Date: Thu, 13 Aug 2020 22:52:57 +0200
> From: Patrick Wildt
>
> On Thu, Aug 13, 2020 at 09:17:41PM +0200, Mark Kettenis wrote:
> > ARMv8.1 introduced PAN (Priviliged Access Never) which prevents the
> > kernel from accessing userland data. This can be bypassed by using
> > special instructions which we already use in copyin(9) and friends.
> > So we can simply turn this feature on if the CPU supports it.
> >
> > Tested on an Odroid-C4 which has Cortex-A55 cores that have PAN
> > support.
> >
> > ok?
> >
>
> So if I read this right, the SPAN bit makes that an exception to
> kernel/hypervisor mode sets the PAN bit in the PSTATE. Exception
> also means "interrupt", or is this only syscall? I think intrs
> are also exceptions...
>
> Essentially, everytime we switch to EL1/EL2 PAN will be enabled?
Yes!
> Sounds good to me, ok patrick@
Thanks. I'll wait a bit to give drahn@ and jsg@ the opportunity to
chime in.
> > Index: arch/arm64/arm64/cpu.c
> > ===
> > RCS file: /cvs/src/sys/arch/arm64/arm64/cpu.c,v
> > retrieving revision 1.38
> > diff -u -p -r1.38 cpu.c
> > --- arch/arm64/arm64/cpu.c 4 Jun 2020 21:18:16 - 1.38
> > +++ arch/arm64/arm64/cpu.c 13 Aug 2020 19:12:30 -
> > @@ -321,6 +321,7 @@ cpu_attach(struct device *parent, struct
> > struct fdt_attach_args *faa = aux;
> > struct cpu_info *ci;
> > uint64_t mpidr = READ_SPECIALREG(mpidr_el1);
> > + uint64_t id_aa64mmfr1, sctlr;
> > uint32_t opp;
> >
> > KASSERT(faa->fa_nreg > 0);
> > @@ -393,6 +394,14 @@ cpu_attach(struct device *parent, struct
> > cpu_cpuspeed = cpu_clockspeed;
> > }
> >
> > + /* Enable PAN. */
> > + id_aa64mmfr1 = READ_SPECIALREG(id_aa64mmfr1_el1);
> > + if (ID_AA64MMFR1_PAN(id_aa64mmfr1) != ID_AA64MMFR1_PAN_NONE) {
> > + sctlr = READ_SPECIALREG(sctlr_el1);
> > + sctlr &= ~SCTLR_SPAN;
> > + WRITE_SPECIALREG(sctlr_el1, sctlr);
> > + }
> > +
> > /* Initialize debug registers. */
> > WRITE_SPECIALREG(mdscr_el1, DBG_MDSCR_TDCC);
> > WRITE_SPECIALREG(oslar_el1, 0);
> > @@ -522,6 +531,7 @@ cpu_boot_secondary(struct cpu_info *ci)
> > void
> > cpu_start_secondary(struct cpu_info *ci)
> > {
> > + uint64_t id_aa64mmfr1, sctlr;
> > uint64_t tcr;
> > int s;
> >
> > @@ -543,6 +553,14 @@ cpu_start_secondary(struct cpu_info *ci)
> > tcr |= TCR_T0SZ(64 - USER_SPACE_BITS);
> > tcr |= TCR_A1;
> > WRITE_SPECIALREG(tcr_el1, tcr);
> > +
> > + /* Enable PAN. */
> > + id_aa64mmfr1 = READ_SPECIALREG(id_aa64mmfr1_el1);
> > + if (ID_AA64MMFR1_PAN(id_aa64mmfr1) != ID_AA64MMFR1_PAN_NONE) {
> > + sctlr = READ_SPECIALREG(sctlr_el1);
> > + sctlr &= ~SCTLR_SPAN;
> > + WRITE_SPECIALREG(sctlr_el1, sctlr);
> > + }
> >
> > /* Initialize debug registers. */
> > WRITE_SPECIALREG(mdscr_el1, DBG_MDSCR_TDCC);
> > Index: arch/arm64/include/armreg.h
> > ===
> > RCS file: /cvs/src/sys/arch/arm64/include/armreg.h,v
> > retrieving revision 1.11
> > diff -u -p -r1.11 armreg.h
> > --- arch/arm64/include/armreg.h 5 Jun 2020 22:14:25 - 1.11
> > +++ arch/arm64/include/armreg.h 13 Aug 2020 19:12:30 -
> > @@ -451,6 +451,7 @@
> > #defineSCTLR_nTWI 0x0001
> > #defineSCTLR_nTWE 0x0004
> > #defineSCTLR_WXN 0x0008
> > +#defineSCTLR_SPAN 0x0080
> > #defineSCTLR_EOE 0x0100
> > #defineSCTLR_EE0x0200
> > #defineSCTLR_UCI 0x0400
> > @@ -478,6 +479,7 @@
> > #definePSR_D 0x0200
> > #definePSR_IL 0x0010
> > #definePSR_SS 0x0020
> > +#definePSR_PAN 0x0040
> > #definePSR_V 0x1000
> > #definePSR_C 0x2000
> > #definePSR_Z 0x4000
> >
>
Re: Enable arm64 PAN feature
On Thu, Aug 13, 2020 at 09:17:41PM +0200, Mark Kettenis wrote:
> ARMv8.1 introduced PAN (Priviliged Access Never) which prevents the
> kernel from accessing userland data. This can be bypassed by using
> special instructions which we already use in copyin(9) and friends.
> So we can simply turn this feature on if the CPU supports it.
>
> Tested on an Odroid-C4 which has Cortex-A55 cores that have PAN
> support.
>
> ok?
>
So if I read this right, the SPAN bit makes that an exception to
kernel/hypervisor mode sets the PAN bit in the PSTATE. Exception
also means "interrupt", or is this only syscall? I think intrs
are also exceptions...
Essentially, everytime we switch to EL1/EL2 PAN will be enabled?
Sounds good to me, ok patrick@
>
> Index: arch/arm64/arm64/cpu.c
> ===
> RCS file: /cvs/src/sys/arch/arm64/arm64/cpu.c,v
> retrieving revision 1.38
> diff -u -p -r1.38 cpu.c
> --- arch/arm64/arm64/cpu.c4 Jun 2020 21:18:16 - 1.38
> +++ arch/arm64/arm64/cpu.c13 Aug 2020 19:12:30 -
> @@ -321,6 +321,7 @@ cpu_attach(struct device *parent, struct
> struct fdt_attach_args *faa = aux;
> struct cpu_info *ci;
> uint64_t mpidr = READ_SPECIALREG(mpidr_el1);
> + uint64_t id_aa64mmfr1, sctlr;
> uint32_t opp;
>
> KASSERT(faa->fa_nreg > 0);
> @@ -393,6 +394,14 @@ cpu_attach(struct device *parent, struct
> cpu_cpuspeed = cpu_clockspeed;
> }
>
> + /* Enable PAN. */
> + id_aa64mmfr1 = READ_SPECIALREG(id_aa64mmfr1_el1);
> + if (ID_AA64MMFR1_PAN(id_aa64mmfr1) != ID_AA64MMFR1_PAN_NONE) {
> + sctlr = READ_SPECIALREG(sctlr_el1);
> + sctlr &= ~SCTLR_SPAN;
> + WRITE_SPECIALREG(sctlr_el1, sctlr);
> + }
> +
> /* Initialize debug registers. */
> WRITE_SPECIALREG(mdscr_el1, DBG_MDSCR_TDCC);
> WRITE_SPECIALREG(oslar_el1, 0);
> @@ -522,6 +531,7 @@ cpu_boot_secondary(struct cpu_info *ci)
> void
> cpu_start_secondary(struct cpu_info *ci)
> {
> + uint64_t id_aa64mmfr1, sctlr;
> uint64_t tcr;
> int s;
>
> @@ -543,6 +553,14 @@ cpu_start_secondary(struct cpu_info *ci)
> tcr |= TCR_T0SZ(64 - USER_SPACE_BITS);
> tcr |= TCR_A1;
> WRITE_SPECIALREG(tcr_el1, tcr);
> +
> + /* Enable PAN. */
> + id_aa64mmfr1 = READ_SPECIALREG(id_aa64mmfr1_el1);
> + if (ID_AA64MMFR1_PAN(id_aa64mmfr1) != ID_AA64MMFR1_PAN_NONE) {
> + sctlr = READ_SPECIALREG(sctlr_el1);
> + sctlr &= ~SCTLR_SPAN;
> + WRITE_SPECIALREG(sctlr_el1, sctlr);
> + }
>
> /* Initialize debug registers. */
> WRITE_SPECIALREG(mdscr_el1, DBG_MDSCR_TDCC);
> Index: arch/arm64/include/armreg.h
> ===
> RCS file: /cvs/src/sys/arch/arm64/include/armreg.h,v
> retrieving revision 1.11
> diff -u -p -r1.11 armreg.h
> --- arch/arm64/include/armreg.h 5 Jun 2020 22:14:25 - 1.11
> +++ arch/arm64/include/armreg.h 13 Aug 2020 19:12:30 -
> @@ -451,6 +451,7 @@
> #define SCTLR_nTWI 0x0001
> #define SCTLR_nTWE 0x0004
> #define SCTLR_WXN 0x0008
> +#define SCTLR_SPAN 0x0080
> #define SCTLR_EOE 0x0100
> #define SCTLR_EE0x0200
> #define SCTLR_UCI 0x0400
> @@ -478,6 +479,7 @@
> #define PSR_D 0x0200
> #define PSR_IL 0x0010
> #define PSR_SS 0x0020
> +#define PSR_PAN 0x0040
> #define PSR_V 0x1000
> #define PSR_C 0x2000
> #define PSR_Z 0x4000
>
Re: [PATCH 2] Add support for Passthrough PCI to VMM
Jordan Hargrave writes: > This patch adds support to VMM to support passthrough PCI. I have tested > this on both Intel/AMD boxes, it requires the DMAR/IOMMU diff patch. FYI: your first patch came through to the list with an interesting From field and got flagged as spam on my end. Had to dig it out. I'd presume you're referring to "Add DMA Remapping support for Intel VT-d and AMD Vi"? > > In order to build this you need to copy the arch/amd64/include/vmmvar.h to > /usr/include/machine and rebuild usr.sbin/vmd and usr.sbin/vmm > Not sure about others, but I can get your patches to apply, things compile, but cannot link a new kernel: ld: error: undefined symbol: _iommu_domain >>> referenced by vmm.c:525 (/usr/src/sys/arch/amd64/amd64/vmm.c:525) >>> vmm.o:(vm_getbar) ld: error: undefined symbol: _iommu_map >>> referenced by vmm.c:537 (/usr/src/sys/arch/amd64/amd64/vmm.c:537) >>> vmm.o:(vm_getbar) ld: error: undefined symbol: acpidmar_sc >>> referenced by acpi.c:2452 (/usr/src/sys/dev/acpi/acpi.c:2452) >>> acpi.o:(acpi_sleep_pm) >>> referenced by acpi.c:2490 (/usr/src/sys/dev/acpi/acpi.c:2490) >>> acpi.o:(acpi_resume_pm) >>> referenced by pci_machdep.c:811 >>> (/usr/src/sys/arch/amd64/pci/pci_machdep.c:811) >>> pci_machdep.o:(pci_probe_device_hook) ld: error: undefined symbol: acpidmar_sw >>> referenced by acpi.c:2453 (/usr/src/sys/dev/acpi/acpi.c:2453) >>> acpi.o:(acpi_sleep_pm) >>> referenced by acpi.c:2491 (/usr/src/sys/dev/acpi/acpi.c:2491) >>> acpi.o:(acpi_resume_pm) ld: error: undefined symbol: acpidmar_pci_hook >>> referenced by pci_machdep.c:812 >>> (/usr/src/sys/arch/amd64/pci/pci_machdep.c:812) >>> pci_machdep.o:(pci_probe_device_hook) Are you sure you've included all your changes in the patchset? -Dave
Enable arm64 PAN feature
ARMv8.1 introduced PAN (Priviliged Access Never) which prevents the
kernel from accessing userland data. This can be bypassed by using
special instructions which we already use in copyin(9) and friends.
So we can simply turn this feature on if the CPU supports it.
Tested on an Odroid-C4 which has Cortex-A55 cores that have PAN
support.
ok?
Index: arch/arm64/arm64/cpu.c
===
RCS file: /cvs/src/sys/arch/arm64/arm64/cpu.c,v
retrieving revision 1.38
diff -u -p -r1.38 cpu.c
--- arch/arm64/arm64/cpu.c 4 Jun 2020 21:18:16 - 1.38
+++ arch/arm64/arm64/cpu.c 13 Aug 2020 19:12:30 -
@@ -321,6 +321,7 @@ cpu_attach(struct device *parent, struct
struct fdt_attach_args *faa = aux;
struct cpu_info *ci;
uint64_t mpidr = READ_SPECIALREG(mpidr_el1);
+ uint64_t id_aa64mmfr1, sctlr;
uint32_t opp;
KASSERT(faa->fa_nreg > 0);
@@ -393,6 +394,14 @@ cpu_attach(struct device *parent, struct
cpu_cpuspeed = cpu_clockspeed;
}
+ /* Enable PAN. */
+ id_aa64mmfr1 = READ_SPECIALREG(id_aa64mmfr1_el1);
+ if (ID_AA64MMFR1_PAN(id_aa64mmfr1) != ID_AA64MMFR1_PAN_NONE) {
+ sctlr = READ_SPECIALREG(sctlr_el1);
+ sctlr &= ~SCTLR_SPAN;
+ WRITE_SPECIALREG(sctlr_el1, sctlr);
+ }
+
/* Initialize debug registers. */
WRITE_SPECIALREG(mdscr_el1, DBG_MDSCR_TDCC);
WRITE_SPECIALREG(oslar_el1, 0);
@@ -522,6 +531,7 @@ cpu_boot_secondary(struct cpu_info *ci)
void
cpu_start_secondary(struct cpu_info *ci)
{
+ uint64_t id_aa64mmfr1, sctlr;
uint64_t tcr;
int s;
@@ -543,6 +553,14 @@ cpu_start_secondary(struct cpu_info *ci)
tcr |= TCR_T0SZ(64 - USER_SPACE_BITS);
tcr |= TCR_A1;
WRITE_SPECIALREG(tcr_el1, tcr);
+
+ /* Enable PAN. */
+ id_aa64mmfr1 = READ_SPECIALREG(id_aa64mmfr1_el1);
+ if (ID_AA64MMFR1_PAN(id_aa64mmfr1) != ID_AA64MMFR1_PAN_NONE) {
+ sctlr = READ_SPECIALREG(sctlr_el1);
+ sctlr &= ~SCTLR_SPAN;
+ WRITE_SPECIALREG(sctlr_el1, sctlr);
+ }
/* Initialize debug registers. */
WRITE_SPECIALREG(mdscr_el1, DBG_MDSCR_TDCC);
Index: arch/arm64/include/armreg.h
===
RCS file: /cvs/src/sys/arch/arm64/include/armreg.h,v
retrieving revision 1.11
diff -u -p -r1.11 armreg.h
--- arch/arm64/include/armreg.h 5 Jun 2020 22:14:25 - 1.11
+++ arch/arm64/include/armreg.h 13 Aug 2020 19:12:30 -
@@ -451,6 +451,7 @@
#defineSCTLR_nTWI 0x0001
#defineSCTLR_nTWE 0x0004
#defineSCTLR_WXN 0x0008
+#defineSCTLR_SPAN 0x0080
#defineSCTLR_EOE 0x0100
#defineSCTLR_EE0x0200
#defineSCTLR_UCI 0x0400
@@ -478,6 +479,7 @@
#definePSR_D 0x0200
#definePSR_IL 0x0010
#definePSR_SS 0x0020
+#definePSR_PAN 0x0040
#definePSR_V 0x1000
#definePSR_C 0x2000
#definePSR_Z 0x4000
Re: TCP congestion control progression
>> On Aug 9, 2020, at 6:29 PM, Chris Cappuccio wrote: > Brian Brombacher [br...@planetunix.net] wrote: >> >> I am wondering what approach the project is planning to use to modernize >> the congestion control algorithms. I'm interested in assisting the project >> with development effort in this area. I've spent time making modifications >> for my own purposes and would prefer to understand the projects goals before >> continuing, if possible. > > Various improvements have been made over the years for dynamic window size, > also further tweaks for higher bandwidth over high latency connections. I'd > recommend sharing your current modifications here to get feedback. > > Chris Hi Chris, The modifications I’ve made are around parameters related to the slow start threshold logic, ENOBUF behavior on interface write, and each Reno congestion control logic segment has also received some changes. The majority of the changes are implementing sysctl tunables to experiment with varying degrees of network behavior I’ve been witnessing on my infrastructure. I’ve been evaluating potential patterns to allow optimal maintenance and addition of future CC algorithms. Cheers, Brian
