Re: svn commit: r368714 - head/lib/libc/string
On Thu, 2020-12-17 at 18:22 +0200, Konstantin Belousov wrote:
> On Thu, Dec 17, 2020 at 01:01:01PM +, Jessica Clarke wrote:
> > On 17 Dec 2020, at 12:53, Konstantin Belousov
> > wrote:
> > >
> > > On Thu, Dec 17, 2020 at 12:41:47PM +, Mateusz Piotrowski
> > > wrote:
> > > > Author: 0mp (doc,ports committer)
> > > > Date: Thu Dec 17 12:41:47 2020
> > > > New Revision: 368714
> > > > URL: https://svnweb.freebsd.org/changeset/base/368714
> > > >
> > > > Log:
> > > > strerror.3: Add an example for perror()
> > > >
> > > > This is a nice and quick reference.
> > > >
> > > > Reviewed by: jilles, yuripv
> > > > MFC after: 2 weeks
> > > > Differential Revision: https://reviews.freebsd.org/D27623
> > > >
> > > > Modified:
> > > > head/lib/libc/string/strerror.3
> > > >
> > > > Modified: head/lib/libc/string/strerror.3
> > > > ===
> > > > ===
> > > > --- head/lib/libc/string/strerror.3 Thu Dec 17 03:42:54
> > > > 2020(r368713)
> > > > +++ head/lib/libc/string/strerror.3 Thu Dec 17 12:41:47
> > > > 2020(r368714)
> > > > @@ -32,7 +32,7 @@
> > > > .\" @(#)strerror.3 8.1 (Berkeley) 6/9/93
> > > > .\" $FreeBSD$
> > > > .\"
> > > > -.Dd December 7, 2020
> > > > +.Dd December 17, 2020
> > > > .Dt STRERROR 3
> > > > .Os
> > > > .Sh NAME
> > > > @@ -170,6 +170,31 @@ The use of these variables is deprecated;
> > > > or
> > > > .Fn strerror_r
> > > > should be used instead.
> > > > +.Sh EXAMPLES
> > > > +The following example shows how to use
> > > > +.Fn perror
> > > > +to report an error.
> > > > +.Bd -literal -offset 2n
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +
> > > > +int
> > > > +main(void)
> > > > +{
> > > > + int fd;
> > > > +
> > > > + if ((fd = open("/nonexistent", O_RDONLY)) == -1) {
> > > > + perror("open()");
> > > > + exit(1);
> > > > + }
> > > > +printf("File descriptor: %d\en", fd);
> > >
> > > This lines is indented with spaces, while other lines have tabs.
> > >
> > > > + return (0);
> > >
> > > return (0) is redundand.
> >
> > It's not required as per the standard, but omitting it is needlessly
> > obfuscating it and bad practice. C lets you do a whole load of things
> > that are a bad idea, and whilst this one is harmless, it is nonetheless
> > confusing to anyone who is not intimately acquainted quirks like this
> > special case in the standard.
>
> Why it is bad practice ?
>
> C is a small language, and while knowing some quirks (like this one)
> seems to be optional, others are not. And worse, that other quirks are
> essential for writing correct code at all. Consequence is that ignoring
> details indicates insufficient knowledge of the fundamentals and lowers
> the trust in the provided suggestion.
I completely disagree. Writing example code where you fail to return a
value and just fall out the bottom of some function that declares it
returns an int is just Bad Code. Using some obscure quirk of the
language as justification for that bad code doesn't help the situation
at all.
How obscure is this quirk? I've been writing C code since 1983,
including having released a freeware compiler (pre-gcc days) and
working on a commercial C compiler. I used to moderate the c_language
conference on BIX (back when that was a thing). I make my living
writing C and C++ code every day. And yet, I had completely forgotten
about this quirk.
Example code shouldn't be used to establish how much more clever you
are than the reader, it should be as easy to understand as possible.
-- Ian
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r368585 - in head: sys/dev/gpio sys/sys tools/test tools/test/gpioevents usr.sbin/gpioctl
Author: ian
Date: Sat Dec 12 18:34:15 2020
New Revision: 368585
URL: https://svnweb.freebsd.org/changeset/base/368585
Log:
Provide userland notification of gpio pin changes ("userland gpio
interrupts").
This is an import of the Google Summer of Code 2018 project completed by
Christian Kramer (and, sadly, ignored by us for two years now). The goals
stated for that project were:
FreeBSD already has support for interrupts implemented in the GPIO
controller drivers of several SoCs, but there are no interfaces to take
advantage of them out of user space yet. The goal of this work is to
implement such an interface by providing descriptors which integrate
with the common I/O system calls and multiplexing mechanisms.
The initial imported code supports the following functionality:
- A kernel driver that provides an interface to the user space; the
existing gpioc(4) driver was enhanced with this functionality.
- Implement support for the most common I/O system calls / multiplexing
mechanisms:
- read() Places the pin number on which the interrupt occurred in the
buffer. Blocking and non-blocking behaviour supported.
-poll()/select()
-kqueue()
-signal driven I/O. Posting SIGIO when the O_ASYNC was set.
- Many-to-many relationship between pins and file descriptors.
- A file descriptor can monitor several GPIO pins.
- A GPIO pin can be monitored by multiple file descriptors.
- Integration with gpioctl and libgpio.
I added some fixes (mostly to locking) and feature enhancements on top of
the original gsoc code. The feature ehancements allow the user to choose
between detailed and summary event reporting. Detailed reporting provides
a record describing each pin change event. Summary reporting provides the
time of the first and last change of each pin, and a count of how many times
it changed state since the last read(2) call. Another enhancement allows
the recording of multiple state change events on multiple pins between each
call to read(2) (the original code would track only a single event at a time).
The phabricator review for these changes timed out without approval, but I
cite it below anyway, because the review contains a series of diffs that
show how I evolved the code from its original state in Christian's github
repo for the gsoc project to what is being commited here. (In effect,
the phab review extends the VC history back to the original code.)
Submitted by: Christian Kramer
Obtained from:https://github.com/ckraemer/freebsd/tree/gsoc2018
Differential Revision:https://reviews.freebsd.org/D27398
Added:
head/tools/test/gpioevents/
head/tools/test/gpioevents/Makefile (contents, props changed)
head/tools/test/gpioevents/gpioevents.c (contents, props changed)
Modified:
head/sys/dev/gpio/gpiobus.c
head/sys/dev/gpio/gpioc.c
head/sys/sys/gpio.h
head/tools/test/README
head/usr.sbin/gpioctl/gpioctl.c
Modified: head/sys/dev/gpio/gpiobus.c
==
--- head/sys/dev/gpio/gpiobus.c Sat Dec 12 17:11:22 2020(r368584)
+++ head/sys/dev/gpio/gpiobus.c Sat Dec 12 18:34:15 2020(r368585)
@@ -143,6 +143,15 @@ gpio_check_flags(uint32_t caps, uint32_t flags)
/* Cannot mix pull-up/pull-down together. */
if (flags & GPIO_PIN_PULLUP && flags & GPIO_PIN_PULLDOWN)
return (EINVAL);
+ /* Cannot mix output and interrupt flags together */
+ if (flags & GPIO_PIN_OUTPUT && flags & GPIO_INTR_MASK)
+ return (EINVAL);
+ /* Only one interrupt flag can be defined at once */
+ if ((flags & GPIO_INTR_MASK) & ((flags & GPIO_INTR_MASK) - 1))
+ return (EINVAL);
+ /* The interrupt attached flag cannot be set */
+ if (flags & GPIO_INTR_ATTACHED)
+ return (EINVAL);
return (0);
}
Modified: head/sys/dev/gpio/gpioc.c
==
--- head/sys/dev/gpio/gpioc.c Sat Dec 12 17:11:22 2020(r368584)
+++ head/sys/dev/gpio/gpioc.c Sat Dec 12 18:34:15 2020(r368585)
@@ -35,8 +35,15 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
+#include
+#include
+#include
#include
#include
+#include
+#include
+#include
#include
#include
@@ -47,30 +54,510 @@ __FBSDID("$FreeBSD$");
#undef GPIOC_DEBUG
#ifdef GPIOC_DEBUG
#define dprintf printf
+#define ddevice_printf device_printf
#else
#define dprintf(x, arg...)
+#define ddevice_printf(dev, x, arg...)
#endif
-static int gpioc_probe(device_t dev);
-static int gpioc_attach(device_t dev);
-static int gpioc_detach(device_t dev);
+struct gpioc_softc {
+ device_tsc_dev; /* gpiocX dev */
+ device_tsc_pdev;/* gpio
Re: svn commit: r368187 - head/sys/dev/nvme
On Mon, 2020-11-30 at 17:56 +0100, Michal Meloun wrote: > > On 30.11.2020 17:02, Ian Lepore wrote: > > On Mon, 2020-11-30 at 14:51 +, Michal Meloun wrote: > > > Author: mmel > > > Date: Mon Nov 30 14:51:48 2020 > > > New Revision: 368187 > > > URL: https://svnweb.freebsd.org/changeset/base/368187 > > > > > > Log: > > >Unbreak r368167 in userland. Decorate unused arguments. > > > > > >Reported by: kp, tuexen, jenkins, and many others > > >MFC with: r368167 > > > > > > Modified: > > >head/sys/dev/nvme/nvme.h > > > > > > Modified: head/sys/dev/nvme/nvme.h > > > = > > > > > > = > > > --- head/sys/dev/nvme/nvme.h Mon Nov 30 14:49:13 2020( > > > r368186) > > > +++ head/sys/dev/nvme/nvme.h Mon Nov 30 14:51:48 2020( > > > r368187) > > > @@ -1728,9 +1728,15 @@ extern int nvme_use_nvd; > > > > > > #endif /* _KERNEL */ > > > > > > +#if _BYTE_ORDER != _LITTLE_ENDIAN > > > +#define MODIF > > > +#else > > > +#define MODIF __unused > > > +#endif > > > + > > > /* Endianess conversion functions for NVMe structs */ > > > static inline > > > -void nvme_completion_swapbytes(struct nvme_completion *s) > > > +void nvme_completion_swapbytes(struct nvme_completion *s > > > MODIF) > > > > IMO, this is pretty ugly, it causes the brain to screech to a halt > > when > > you see it. Why not just add an unconditional __unused to the > > functions? The unused attribute is defined as marking the variable > > as > > "potentially unused" -- there is no penalty for having it there and > > then actually using the variable. > > > > I understand, (and I have significant tendency to agree) but I did > not > find more correct way how to do it. > Are you sure that __unused is defined as *potentially* unused? I > cannot > find nothing about this and you known how are compiler guys creative > with generating of new warnings... > I known that C++17 have 'maybe_unused' attribute, but relationship > to > standard '__unused' looks unclear. > > In any case, I have not single problem to change this to the > proposed > style if we found that this is the optimal way. > > Michal The __unused macro is defined in cdefs.h under #if __GNUC_PREREQ__(2, 7) as attribute((unused)) and the gcc docs for that attribute say "This attribute, attached to a [variable|function], means that the variable is meant to be possibly unused. GCC will not produce a warning for this variable." -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r368187 - head/sys/dev/nvme
On Mon, 2020-11-30 at 14:51 +, Michal Meloun wrote: > Author: mmel > Date: Mon Nov 30 14:51:48 2020 > New Revision: 368187 > URL: https://svnweb.freebsd.org/changeset/base/368187 > > Log: > Unbreak r368167 in userland. Decorate unused arguments. > > Reported by:kp, tuexen, jenkins, and many others > MFC with: r368167 > > Modified: > head/sys/dev/nvme/nvme.h > > Modified: head/sys/dev/nvme/nvme.h > = > = > --- head/sys/dev/nvme/nvme.h Mon Nov 30 14:49:13 2020(r368186) > +++ head/sys/dev/nvme/nvme.h Mon Nov 30 14:51:48 2020(r368187) > @@ -1728,9 +1728,15 @@ extern int nvme_use_nvd; > > #endif /* _KERNEL */ > > +#if _BYTE_ORDER != _LITTLE_ENDIAN > +#define MODIF > +#else > +#define MODIF __unused > +#endif > + > /* Endianess conversion functions for NVMe structs */ > static inline > -void nvme_completion_swapbytes(struct nvme_completion *s) > +void nvme_completion_swapbytes(struct nvme_completion *s MODIF) IMO, this is pretty ugly, it causes the brain to screech to a halt when you see it. Why not just add an unconditional __unused to the functions? The unused attribute is defined as marking the variable as "potentially unused" -- there is no penalty for having it there and then actually using the variable. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r368163 - in head: sbin/ifconfig sys/dev/if_wg sys/dev/if_wg/include sys/dev/if_wg/include/crypto sys/dev/if_wg/include/sys sys/dev/if_wg/include/zinc sys/dev/if_wg/module sys/dev/if_w
On Sun, 2020-11-29 at 19:20 -0500, Shawn Webb wrote: > On Sun, Nov 29, 2020 at 07:38:04PM +, Matt Macy wrote: > > Author: mmacy > > Date: Sun Nov 29 19:38:03 2020 > > New Revision: 368163 > > URL: https://svnweb.freebsd.org/changeset/base/368163 > > > > Log: > > Import kernel WireGuard support > > > > Data path largely shared with the OpenBSD implementation by > > Matt Dunwoodie > > > > Reviewed by: gre...@freebsd.org > > MFC after:1 month > > Sponsored by: Rubicon LLC, (Netgate) > > Differential Revision:https://reviews.freebsd.org/D26137 > > RELNOTES: yes? > > Thanks, > Or maybe an entry in src/RELNOTES, preferably one that (unlike the commit message) has at least some tiny shred of a clue about what Wireguard is. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r368042 - in head: share/doc/legal share/doc/legal/imx sys/arm/freescale/imx sys/contrib/dev/imx
Author: ian
Date: Thu Nov 26 01:40:04 2020
New Revision: 368042
URL: https://svnweb.freebsd.org/changeset/base/368042
Log:
Add the firmware blob required to use the sdma hardware in the imx6
processor, and its associated license text (which is similar to a
bsd-3-clause, but with a prohibition against decompiling). Install a copy
of the license in /usr/share/doc/legal/imx, to comply with the license terms
that requires a copy of the license to be delivered along with the firmware.
Obtained from:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/imx/sdma/sdma-imx6q.bin
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/LICENSE.sdma_firmware
Added:
head/share/doc/legal/Makefile.armv7 (contents, props changed)
head/share/doc/legal/imx/
head/share/doc/legal/imx/Makefile (contents, props changed)
head/sys/contrib/dev/imx/
head/sys/contrib/dev/imx/LICENSE
head/sys/contrib/dev/imx/sdma-imx6q.bin.uu
Modified:
head/share/doc/legal/Makefile
head/sys/arm/freescale/imx/files.imx6
head/sys/arm/freescale/imx/imx6_sdma.c
Modified: head/share/doc/legal/Makefile
==
--- head/share/doc/legal/Makefile Wed Nov 25 23:19:01 2020
(r368041)
+++ head/share/doc/legal/Makefile Thu Nov 26 01:40:04 2020
(r368042)
@@ -8,4 +8,5 @@ SUBDIR= intel_ipw \
SUBDIR_PARALLEL=
+.include
.include
Added: head/share/doc/legal/Makefile.armv7
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/share/doc/legal/Makefile.armv7 Thu Nov 26 01:40:04 2020
(r368042)
@@ -0,0 +1,3 @@
+# $FreeBSD$
+
+SUBDIR += imx
Added: head/share/doc/legal/imx/Makefile
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/share/doc/legal/imx/Makefile Thu Nov 26 01:40:04 2020
(r368042)
@@ -0,0 +1,7 @@
+# $FreeBSD$
+
+FILES= ${SRCTOP}/sys/contrib/dev/imx/LICENSE
+FILESDIR= ${SHAREDIR}/doc/legal
+FILESNAME= sdma-imx6q.LICENSE
+
+.include
Modified: head/sys/arm/freescale/imx/files.imx6
==
--- head/sys/arm/freescale/imx/files.imx6 Wed Nov 25 23:19:01 2020
(r368041)
+++ head/sys/arm/freescale/imx/files.imx6 Thu Nov 26 01:40:04 2020
(r368042)
@@ -20,7 +20,7 @@ arm/freescale/imx/imx_i2c.c optional fsliic
arm/freescale/imx/imx_spi.coptional imx_spi
arm/freescale/imx/imx6_sdma.c optional fslsdma
arm/freescale/imx/imx6_audmux.coptional sound
-arm/freescale/imx/imx6_ssi.c optional sound
+arm/freescale/imx/imx6_ssi.c optional sound fslsdma
arm/freescale/imx/imx6_ahci.c optional ahci
dev/hdmi/dwc_hdmi.coptional hdmi
@@ -47,23 +47,18 @@ arm/freescale/imx/imx6_usbphy.c optional ehci
#
#arm/freescale/imx/imx_console.c standard
-#
-# Not ready yet...
-#
-#arm/freescale/imx/imx51_ipuv3.c optional sc
-
-# SDMA firmware
-sdma_fw.c optional sdma_fw\
- compile-with"${AWK} -f $S/tools/fw_stub.awk
sdma-imx6q-to1.bin:sdma_fw -msdma -c${.TARGET}" \
+# SDMA firmware.
+sdma-imx6q.c optional fslsdma\
+ compile-with"${AWK} -f $S/tools/fw_stub.awk
sdma-imx6q.bin:sdma-imx6q -msdma -c${.TARGET}" \
no-implicit-rule before-depend local\
- clean "sdma_fw.c"
-sdma-imx6q-to1.fwo optional sdma_fw\
- dependency "sdma-imx6q-to1.bin"\
- compile-with"${LD} -m ${LD_EMULATION} -b binary -d -warn-common -r
-d -o ${.TARGET} sdma-imx6q-to1.bin" \
+ clean "sdma-imx6q.c"
+sdma-imx6q.fwo optional fslsdma\
+ dependency "sdma-imx6q.bin"\
+ compile-with"${LD} -m ${LD_EMULATION} -b binary -d -warn-common -r
-d -o ${.TARGET} sdma-imx6q.bin" \
no-implicit-rule\
- clean "sdma-imx6q-to1.fwo"
-sdma-imx6q-to1.bin optional sdma_fw\
- dependency "$S/contrib/dev/imx/sdma-imx6q-to1.bin.uu" \
- compile-with"uudecode < $S/contrib/dev/imx/sdma-imx6q-to1.bin.uu" \
+ clean "sdma-imx6q.fwo"
+sdma-imx6q.bin optional fslsdma\
+ dependency "$S/contrib/dev/imx/sdma-imx6q.bin.uu" \
+ compile-with"uudecode < $S/contrib/dev/imx/sdma-imx6q.bin.uu" \
no-obj no-implicit-rule
svn commit: r368030 - head/sys/arm/freescale/imx
Author: ian
Date: Wed Nov 25 20:05:05 2020
New Revision: 368030
URL: https://svnweb.freebsd.org/changeset/base/368030
Log:
Extend the imx6 gpc->gic interrupt controller fixup of fdt data at runtime
to work with the pmu and tempmon nodes as well as the soc node. This allows
interrupts to work on the pmu and tempmon devices even though we don't have
a driver for the low-power gpc interrupt controller (which is not a problem
because we also don't have support for entering deep power-down modes where
it gets used).
Modified:
head/sys/arm/freescale/imx/imx6_machdep.c
Modified: head/sys/arm/freescale/imx/imx6_machdep.c
==
--- head/sys/arm/freescale/imx/imx6_machdep.c Wed Nov 25 19:10:20 2020
(r368029)
+++ head/sys/arm/freescale/imx/imx6_machdep.c Wed Nov 25 20:05:05 2020
(r368030)
@@ -78,6 +78,10 @@ static platform_cpu_reset_t imx6_cpu_reset;
* node to refer to GIC instead of GPC. This will get us by until we write our
* own GPC driver (or until linux changes its mind and the FDT data again).
*
+ * 2020/11/25: The tempmon and pmu nodes are siblings (not children) of the soc
+ * node, so for them to use interrupts we need to apply the same fix as we do
+ * for the soc node.
+ *
* We validate that we have data that looks like we expect before changing it:
* - SOC node exists and has GPC as its interrupt parent.
* - GPC node exists and has GIC as its interrupt parent.
@@ -95,22 +99,30 @@ static platform_cpu_reset_t imx6_cpu_reset;
* nodes by string matching we now have to search for both flavors of each node
* name involved.
*/
+
static void
+fix_node_iparent(const char* nodepath, phandle_t gpcxref, phandle_t gicxref)
+{
+ static const char *propname = "interrupt-parent";
+ phandle_t node, iparent;
+
+ if ((node = OF_finddevice(nodepath)) == -1)
+ return;
+ if (OF_getencprop(node, propname, &iparent, sizeof(iparent)) <= 0)
+ return;
+ if (iparent != gpcxref)
+ return;
+
+ OF_setprop(node, propname, &gicxref, sizeof(gicxref));
+}
+
+static void
fix_fdt_interrupt_data(void)
{
phandle_t gicipar, gicnode, gicxref;
phandle_t gpcipar, gpcnode, gpcxref;
- phandle_t socipar, socnode;
int result;
- socnode = OF_finddevice("/soc");
- if (socnode == -1)
- return;
- result = OF_getencprop(socnode, "interrupt-parent", &socipar,
- sizeof(socipar));
- if (result <= 0)
- return;
-
/* GIC node may be child of soc node, or appear directly at root. */
gicnode = OF_finddevice("/soc/interrupt-controller@00a01000");
if (gicnode == -1)
@@ -143,11 +155,13 @@ fix_fdt_interrupt_data(void)
return;
gpcxref = OF_xref_from_node(gpcnode);
- if (socipar != gpcxref || gpcipar != gicxref || gicipar != gicxref)
+ if (gpcipar != gicxref || gicipar != gicxref)
return;
gicxref = cpu_to_fdt32(gicxref);
- OF_setprop(socnode, "interrupt-parent", &gicxref, sizeof(gicxref));
+ fix_node_iparent("/soc", gpcxref, gicxref);
+ fix_node_iparent("/pmu", gpcxref, gicxref);
+ fix_node_iparent("/tempmon", gpcxref, gicxref);
}
static void
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r368029 - in head/sys: arm/freescale/imx modules/imx/imx6_snvs
Author: ian
Date: Wed Nov 25 19:10:20 2020
New Revision: 368029
URL: https://svnweb.freebsd.org/changeset/base/368029
Log:
Convert the imx6_snvs RTC driver to access registers via the syscon device.
This is required for it to work correctly in the GENERIC kernel.
Modified:
head/sys/arm/freescale/imx/imx6_snvs.c
head/sys/modules/imx/imx6_snvs/Makefile
Modified: head/sys/arm/freescale/imx/imx6_snvs.c
==
--- head/sys/arm/freescale/imx/imx6_snvs.c Wed Nov 25 19:08:22 2020
(r368028)
+++ head/sys/arm/freescale/imx/imx6_snvs.c Wed Nov 25 19:10:20 2020
(r368029)
@@ -45,6 +45,7 @@ __FBSDID("$FreeBSD$");
#include
#include "clock_if.h"
+#include "syscon_if.h"
#defineSNVS_LPCR 0x38/* Control register */
#define LPCR_LPCALB_VAL_SHIFT 10/* Calibration shift */
@@ -68,13 +69,12 @@ __FBSDID("$FreeBSD$");
struct snvs_softc {
device_tdev;
- struct resource * memres;
+ struct syscon *syscon;
uint32_tlpcr;
};
static struct ofw_compat_data compat_data[] = {
{"fsl,sec-v4.0-mon-rtc-lp", true},
- {"fsl,sec-v4.0-mon", true},
{NULL, false}
};
@@ -82,14 +82,14 @@ static inline uint32_t
RD4(struct snvs_softc *sc, bus_size_t offset)
{
- return (bus_read_4(sc->memres, offset));
+ return (SYSCON_READ_4(sc->syscon, offset));
}
static inline void
WR4(struct snvs_softc *sc, bus_size_t offset, uint32_t value)
{
- bus_write_4(sc->memres, offset, value);
+ SYSCON_WRITE_4(sc->syscon, offset, value);
}
static void
@@ -187,16 +187,12 @@ static int
snvs_attach(device_t dev)
{
struct snvs_softc *sc;
- int rid;
sc = device_get_softc(dev);
sc->dev = dev;
- rid = 0;
- sc->memres = bus_alloc_resource_any(sc->dev, SYS_RES_MEMORY, &rid,
- RF_ACTIVE);
- if (sc->memres == NULL) {
- device_printf(sc->dev, "could not allocate registers\n");
+ if (syscon_get_handle_default(sc->dev, &sc->syscon) != 0) {
+ device_printf(sc->dev, "Cannot get syscon handle\n");
return (ENXIO);
}
@@ -212,7 +208,6 @@ snvs_detach(device_t dev)
sc = device_get_softc(dev);
clock_unregister(sc->dev);
- bus_release_resource(sc->dev, SYS_RES_MEMORY, 0, sc->memres);
return (0);
}
Modified: head/sys/modules/imx/imx6_snvs/Makefile
==
--- head/sys/modules/imx/imx6_snvs/Makefile Wed Nov 25 19:08:22 2020
(r368028)
+++ head/sys/modules/imx/imx6_snvs/Makefile Wed Nov 25 19:10:20 2020
(r368029)
@@ -11,5 +11,6 @@ SRCS+=\
clock_if.h \
device_if.h \
ofw_bus_if.h \
+ syscon_if.h \
.include
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r368028 - head/sys/arm/conf
Author: ian Date: Wed Nov 25 19:08:22 2020 New Revision: 368028 URL: https://svnweb.freebsd.org/changeset/base/368028 Log: Add the standard extres pseudo devices to the IMX6 kernel config. Some imx6 drivers are being converted to use features that weren't available when they were first written (such as accessing shared device registers via the syscon pseudo-device), so imx6 custom kernels that reference those devices will now need this infrastructure in place. Modified: head/sys/arm/conf/IMX6 Modified: head/sys/arm/conf/IMX6 == --- head/sys/arm/conf/IMX6 Wed Nov 25 18:36:38 2020(r368027) +++ head/sys/arm/conf/IMX6 Wed Nov 25 19:08:22 2020(r368028) @@ -117,6 +117,15 @@ optionsFDT # Configure using FDT/DTB data makeoptionsMODULES_EXTRA="dtb/imx6 imx" device fdt_pinctrl # FDT pinmux driver +# EXT_RESOURCES pseudo devices +optionsEXT_RESOURCES +device clk +device phy +device hwreset +device nvmem +device regulator +device syscon + # SoC-specific devices device ffec# Freescale Fast Ethernet Controller device fsliic # Freescale i2c/iic ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r368026 - head/sys/arm/freescale/imx
Author: ian
Date: Wed Nov 25 18:09:01 2020
New Revision: 368026
URL: https://svnweb.freebsd.org/changeset/base/368026
Log:
A couple small fixes for the imx6_sdma driver...
Attach after interrupt controllers, since the attach function tries to
set up an interrupt handler.
Check for the availability of the required firmware early in the attach
code (before allocating resources). If the firmware is not available, set
a static var to remember that, so that if the device is re-probed on later
passes it won't repeatedly try to attach and then complain again about
missing firmware.
Modified:
head/sys/arm/freescale/imx/imx6_sdma.c
Modified: head/sys/arm/freescale/imx/imx6_sdma.c
==
--- head/sys/arm/freescale/imx/imx6_sdma.c Wed Nov 25 17:15:24 2020
(r368025)
+++ head/sys/arm/freescale/imx/imx6_sdma.c Wed Nov 25 18:09:01 2020
(r368026)
@@ -75,6 +75,12 @@ static struct resource_spec sdma_spec[] = {
{ -1, 0 }
};
+/*
+ * This will get set to true if we can't load firmware while attaching, to
+ * prevent multiple attempts to re-attach the device on each bus pass.
+ */
+static bool firmware_unavailable;
+
static void
sdma_intr(void *arg)
{
@@ -117,7 +123,7 @@ static int
sdma_probe(device_t dev)
{
- if (!ofw_bus_status_okay(dev))
+ if (!ofw_bus_status_okay(dev) || firmware_unavailable)
return (ENXIO);
if (!ofw_bus_is_compatible(dev, "fsl,imx6q-sdma"))
@@ -468,6 +474,11 @@ sdma_attach(device_t dev)
sc = device_get_softc(dev);
sc->dev = dev;
+ if (load_firmware(sc) == -1) {
+ firmware_unavailable = true;
+ return (ENXIO);
+ }
+
if (bus_alloc_resources(dev, sdma_spec, sc->res)) {
device_printf(dev, "could not allocate resources\n");
return (ENXIO);
@@ -487,9 +498,6 @@ sdma_attach(device_t dev)
return (ENXIO);
}
- if (load_firmware(sc) == -1)
- return (ENXIO);
-
if (boot_firmware(sc) == -1)
return (ENXIO);
@@ -511,5 +519,6 @@ static driver_t sdma_driver = {
static devclass_t sdma_devclass;
+/* We want to attach after all interrupt controllers, before anything else. */
EARLY_DRIVER_MODULE(sdma, simplebus, sdma_driver, sdma_devclass, 0, 0,
-BUS_PASS_RESOURCE);
+BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LAST);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r368021 - head/sys/arm/ti
Author: ian
Date: Wed Nov 25 15:45:20 2020
New Revision: 368021
URL: https://svnweb.freebsd.org/changeset/base/368021
Log:
Only attach the ti_scm_syscon driver when running on a compatible TI chip.
This prevents attaching on non-TI systems in the GENERIC kernel.
Reviewed by: manu@, mmel@
Modified:
head/sys/arm/ti/ti_scm_syscon.c
Modified: head/sys/arm/ti/ti_scm_syscon.c
==
--- head/sys/arm/ti/ti_scm_syscon.c Wed Nov 25 15:07:22 2020
(r368020)
+++ head/sys/arm/ti/ti_scm_syscon.c Wed Nov 25 15:45:20 2020
(r368021)
@@ -54,6 +54,8 @@ __FBSDID("$FreeBSD$");
#include
#include "clkdev_if.h"
+#include
+
#if 0
#define DPRINTF(dev, msg...) device_printf(dev, msg)
#else
@@ -146,6 +148,9 @@ static int
ti_scm_syscon_probe(device_t dev)
{
if (!ofw_bus_status_okay(dev))
+ return (ENXIO);
+
+ if (!ti_soc_is_supported())
return (ENXIO);
if (ofw_bus_search_compatible(dev, compat_data)->ocd_data == 0)
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r367994 - head/release/arm
On Tue, 2020-11-24 at 20:12 +0100, Emmanuel Vadot wrote: > On Tue, 24 Nov 2020 11:56:53 -0700 > Ian Lepore wrote: > > > On Tue, 2020-11-24 at 17:52 +, Emmanuel Vadot wrote: > > > Author: manu > > > Date: Tue Nov 24 17:52:01 2020 > > > New Revision: 367994 > > > URL: https://svnweb.freebsd.org/changeset/base/367994 > > > > > > Log: > > > Release: arm: Remove config for old boards > > > > > > All those board are impossible to buy nowadays and could boot > > > using > > > the > > > GENERICSD image after putting the correct u-boot on them. > > > > > > > The imx6 boards are most certainly not impossible to buy. But I > > think > > they do work with the generic kernel. > > > > -- Ian > > Wandboard seems to be obtainable from wandboard.org but there is so > many of them, does u-boot-wandboard works with all of them ? > Same question for the hummingboard, I see some hummingboard on > solid-run website but I don't know if u-boot-cubox-hummingboard is > made > for them or not. > And yes they do boot with GENERIC kernel, in fact the release image > have been using GENERIC kernel for a long time. > Afaik, all the wandboard and solidrun variants boot fine if you load the right dtb. -- Ian > > > Reviewed by:imp > > > Relnotes: yes > > > Differential Revision: https://reviews.freebsd.org/D27282 > > > > > > Deleted: > > > head/release/arm/BANANAPI.conf > > > head/release/arm/CUBIEBOARD.conf > > > head/release/arm/CUBIEBOARD2.conf > > > head/release/arm/CUBOX-HUMMINGBOARD.conf > > > head/release/arm/PANDABOARD.conf > > > head/release/arm/WANDBOARD.conf > > ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r367994 - head/release/arm
On Tue, 2020-11-24 at 17:52 +, Emmanuel Vadot wrote: > Author: manu > Date: Tue Nov 24 17:52:01 2020 > New Revision: 367994 > URL: https://svnweb.freebsd.org/changeset/base/367994 > > Log: > Release: arm: Remove config for old boards > > All those board are impossible to buy nowadays and could boot using > the > GENERICSD image after putting the correct u-boot on them. > The imx6 boards are most certainly not impossible to buy. But I think they do work with the generic kernel. -- Ian > Reviewed by:imp > Relnotes: yes > Differential Revision: https://reviews.freebsd.org/D27282 > > Deleted: > head/release/arm/BANANAPI.conf > head/release/arm/CUBIEBOARD.conf > head/release/arm/CUBIEBOARD2.conf > head/release/arm/CUBOX-HUMMINGBOARD.conf > head/release/arm/PANDABOARD.conf > head/release/arm/WANDBOARD.conf ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r367920 - head/tools/tools/netmap
On Sat, 2020-11-21 at 18:20 +, Vincenzo Maffione wrote: > Author: vmaffione > Date: Sat Nov 21 18:20:21 2020 > New Revision: 367920 ... > +.Bd -literal -offset intent > s/intent/indent/ ? -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r367695 - in head/sys: kern sys
On Wed, 2020-11-18 at 15:37 -0800, John Baldwin wrote: > On 11/18/20 2:16 PM, Mateusz Guzik wrote: > > On 11/17/20, John Baldwin wrote: > > > On 11/14/20 11:22 AM, Mateusz Guzik wrote: > > > > Interested parties can check the consumer (also seen in the diff) > > to > > see this is for consistency. I don't think any comments are > > warranted > > in the header. > > I did read the consumer, and there didn't seem tremendous value in > the > extra line there. > > > > These changes would benefit from review. > > > > > > > I don't think it's feasible to ask for review for everything lest > > it > > degardes to rubber stamping and I don't think this change warranted > > it, regardless of the cosmetic issues which can always show up. > > That is not consistent with the direction the project is moving. If > you > check the commit logs of other high-volume committers such as markj@, > kib@, or myself, you will find that a substantial number of those > commits > are reviewed (typically in phabricator) without preventing us from > making useful progress. Also, while the previous core did not > mandate > reviews, we moved closer to it when the Pre-Commit Review chapter was > added to the Committer's Guide: > > https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/pre-commit-review.html > > In the related thread on developers@ we indicated that while weren't > yet > making pre-commit review mandatory, we collectively want to move in > that > direction. > Yeah, the direction the project is moving is to drive away the few remaining prolific contributors with policies that take all the satisfaction out of working on freebsd. There's a reason I've gone from being in the top ten commiters list in 2019 to having around a dozen commits in 2020. (Harrison Bergeron lives, it seems, but the world has so many more Diana Moon Glampers to counter with.) -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r367678 - head/usr.sbin/freebsd-update
On Tue, 2020-11-17 at 14:41 -0800, Rodney W. Grimes wrote: > > On Sat, Nov 14, 2020 at 11:20 AM Mateusz Piotrowski < > > 0...@freebsd.org> wrote: > > > > > > Hello Rodney, > > > > > > On 11/14/20 4:59 PM, Rodney W. Grimes wrote: > > > > > Author: 0mp (doc,ports committer) > > > > > Date: Sat Nov 14 13:07:41 2020 > > > > > New Revision: 367678 > > > > > URL: https://svnweb.freebsd.org/changeset/base/367678 > > > > > > > > > > Log: > > > > >Document the PAGER environment variable > > > > > > > > > >Sometimes users want to use freebsd-update(8) in a non- > > > > > interactive way and > > > > >what they often miss is that they have to set PAGER to > > > > > cat(1) in order to > > > > >avoid interactive prompts from less(1). > > > > > > > > Which was caused by the change of invoking more(1) as less(1) > > > > causing > > > > this regression, as when invoked as more(1) it falls off the > > > > end of > > > > empty input and causes no such interactive prompt. > > > > > > > > Setting PAGER to more(1) also fixes this. > > > > > > Mmm, I'm not sure if that would work. If I run "jot 1000 | more" > > > in my terminal I still get an > > > interactive prompt. Could it be that you are referring to a > > > different more(1) implementation? I'm > > > clearly missing something. > > > > > Part of what your missing is freebsd-update(8) often outputs a 0 > length file which less(1) well want you to respond Quit to before > going to the next file. more(1) does not do that. > > jot 1000 produces 1 x 1000 line file, that is not whats causing > the issues with freebsd-update and less(1), it is more like > 1000 x 1 line files. > > > > > more(1) is more or less like `less -E`, which is a default PAGER I > > had > > advocated for back when it changed. It can be mostly non- > > interactive > > as long as your diffs are small, but it's definitely much less > > painful. > > Yes, that would of been less painful, note that iirc there are a > few other places effected in similiar ways with 0 line output > files sent to less(1) that cause a need to hit a bunch of q's > to get the command completed. > > Since I am an aged more(1) user I just globally fix PAGER. > It would of been far less painful had PAGER simply been > changed to less rather than all the binary invokations > beeing changed, but hind sight is amazing. > You might find some solace in the brave new world by adding to your .cshrc: setenv LESS -m -E -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r366652 - head/sys/dev/iicbus
Author: ian
Date: Mon Oct 12 18:02:51 2020
New Revision: 366652
URL: https://svnweb.freebsd.org/changeset/base/366652
Log:
Bug fixes for the ads111x driver... make configurable gain and sample rate
hints work on per-channel basis as documented, rather than chip-wide. Also,
when configured via hints, return BUS_PROBE_NOWILDCARD on successful hints
match, so that the hints don't bogusly match other types of i2c chips.
Modified:
head/sys/dev/iicbus/ads111x.c
Modified: head/sys/dev/iicbus/ads111x.c
==
--- head/sys/dev/iicbus/ads111x.c Mon Oct 12 17:43:38 2020
(r366651)
+++ head/sys/dev/iicbus/ads111x.c Mon Oct 12 18:02:51 2020
(r366652)
@@ -456,12 +456,15 @@ ads111x_add_channels(struct ads111x_softc *sc)
name = device_get_name(sc->dev);
unit = device_get_unit(sc->dev);
for (chan = 0; chan < sc->chipinfo->numchan; ++chan) {
+ char resname[16];
found = false;
gainidx = DEFAULT_GAINIDX;
rateidx = DEFAULT_RATEIDX;
- if (resource_int_value(name, unit, "gain_index", &gainidx) == 0)
+ snprintf(resname, sizeof(resname), "%d.gain_index", chan);
+ if (resource_int_value(name, unit, resname, &gainidx) == 0)
found = true;
- if (resource_int_value(name, unit, "rate_index", &gainidx) == 0)
+ snprintf(resname, sizeof(resname), "%d.rate_index", chan);
+ if (resource_int_value(name, unit, resname, &rateidx) == 0)
found = true;
if (found) {
ads111x_setup_channel(sc, chan, gainidx, rateidx);
@@ -522,7 +525,11 @@ ads111x_probe(device_t dev)
info = ads111x_find_chipinfo(dev);
if (info != NULL) {
device_set_desc(dev, info->name);
+#ifdef FDT
return (BUS_PROBE_DEFAULT);
+#else
+ return (BUS_PROBE_NOWILDCARD);
+#endif
}
return (ENXIO);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r365643 - head/bin/cp
On Fri, 2020-09-25 at 20:48 +0100, Edward Tomasz Napierała wrote: > > On 25 Sep 2020, at 19:12, Ian Lepore wrote: > > [..] > > > (A question that occurs to me: could it be that the files you've > > seen > > got created at shutdown after devfs was unmounted, rather than at > > startup? I don't know enough about the shutdown sequence to know > > whether that's possible.) > > Thing is, if you unmount /dev, you are revoking > all the device nodes, including your ttys and disk device nodes. You > wouldn’t be able to properly shutdown afterwards. > > I was thinking more of something in the shutdown rc scripts or an errant daemon process unmounting /dev. But it sounds like that's not possible while disks are still mounted. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r365643 - head/bin/cp
On Fri, 2020-09-25 at 10:55 -0700, Rodney W. Grimes wrote: > > I was under the impression from previous reading and kib's response > > that this is a complete non-issue, there's no way you can go > > multi-user without a mounted /dev and we go to somewhat great > > lengths to make sure we're good. > > Though kib can assert that, it does not change the fact that I > frequently find /dev/null FILES on unmounted root file systems. > > But lets not mix the 2 separate things of boot time /dev dependency > and build time /dev dependency. If you look in sys/kern/vfs_mountroot.c you can see that the code to mount /dev is invoked unconditionally as the first step of mounting root, and that all the calls it makes to get devfs mounted have their results checked with KASSERTs. That's pretty strong evidence that devfs is mounted before rc scripts run. That creates a situation where you are making an extraordinary claim, so you need to provide extraordinary evidence to support it. A sequence of actions that allows others to recreate the situation would do the trick. (A question that occurs to me: could it be that the files you've seen got created at shutdown after devfs was unmounted, rather than at startup? I don't know enough about the shutdown sequence to know whether that's possible.) -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r366042 - in head/stand: i386/zfsboot libsa
On Wed, 2020-09-23 at 10:44 +, Bjoern A. Zeeb wrote: > On 23 Sep 2020, at 1:04, Warner Losh wrote: > > >Ideally, we'd keep the cp /dev/null in the > > build as a regression test, > > Well or at least write a test case so that at least CI catches it. > > /bz It might make sense to separately test /dev/null as the source and the destination with cp. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r365643 - head/bin/cp
On Tue, 2020-09-22 at 15:50 -0600, Warner Losh wrote:
> I think it's a great leap sideways, but I've done cp /dev/null foo to
> clear
> it out for 35 years now... It's why it feels like a workaround.
>
> Though it is a legit optimization, no matter the feelings. As for
> clearer,
> I'm less sure since then I have to remember what the : operator does.
>
> Warner
>
For me, :> is idiomatic (but ugly).
On the other hand, the cp /dev/null had a nice dogfooding aspect to
it... when we broke cp by accident, its use in the build system was the
first alarm to go off.
--Ian
> On Tue, Sep 22, 2020 at 3:48 PM Alan Somers
> wrote:
>
> > It doesn't feel like a workaround to me. I think Kyle's version is
> > clearer than the original.
> >
> > On Tue, Sep 22, 2020 at 3:45 PM Warner Losh wrote:
> >
> > >
> > >
> > > On Tue, Sep 22, 2020 at 3:42 PM Kyle Evans
> > > wrote:
> > >
> > > > cp is already fixed, people are still feeling the fallout of
> > > > being
> > > > within those revisions and needing to bootstrap their own cp.
> > > > We can
> > > > reduce the number of components these invocations rely on
> > > > trivially to
> > > > shell built-in mechanics, why not do so?
> > > >
> > >
> > > Fair point. I just bristle at putting workarounds in for valid
> > > /bin/sh
> > > syntax because we opposed for a few days. so long as it's an
> > > unconditional
> > > clearing of the file to be zero length, I'm OK with that.
> > >
> > > Warner
> > >
> > >
> > > > On Tue, Sep 22, 2020 at 4:40 PM Warner Losh
> > > > wrote:
> > > > >
> > > > > So why do we need a workaround at all? cp /dev/null has been
> > > > > fixed,
> > > >
> > > > and that's way more important to get right.
> > > > >
> > > > > I don't want to paper-over issues with this at all, though if
> > > > > we use
> > > >
> > > > the host's (now broken) cp, I suppose that might be OK in the
> > > > short term.
> > > > If that's the case, then maybe this is OK.
> > > > >
> > > > > Otherwise, I'd strongly prefer we fix cp.
> > > > >
> > > > > Warner
> > > > >
> > > > > On Tue, Sep 22, 2020 at 3:31 PM Alan Somers <
> > > > > asom...@freebsd.org>
> > > >
> > > > wrote:
> > > > > >
> > > > > > +1.
> > > > > >
> > > > > > On Tue, Sep 22, 2020 at 3:27 PM Kyle Evans <
> > > > > > kev...@freebsd.org>
> > > >
> > > > wrote:
> > > > > > >
> > > > > > > I'm running a build at the suggestion of mjg to confirm
> > > > > > > there aren't
> > > > > > > any others hiding that can be converted, and I will
> > > > > > > commit after I've
> > > > > > > verified that this is it.
> > > > > > >
> > > > > > > On Tue, Sep 22, 2020 at 4:02 PM Alan Somers <
> > > > > > > asom...@freebsd.org>
> > > >
> > > > wrote:
> > > > > > > >
> > > > > > > > LGTM.
> > > > > > > >
> > > > > > > > On Tue, Sep 22, 2020 at 2:59 PM Kyle Evans <
> > > > > > > > kev...@freebsd.org>
> > > >
> > > > wrote:
> > > > > > > > >
> > > > > > > > > Perhaps:
> > > > > > > > >
> > > > > > > > > diff --git a/stand/i386/zfsboot/Makefile
> > > >
> > > > b/stand/i386/zfsboot/Makefile
> > > > > > > > > index ff315abc0ef..7e362b43a39 100644
> > > > > > > > > --- a/stand/i386/zfsboot/Makefile
> > > > > > > > > +++ b/stand/i386/zfsboot/Makefile
> > > > > > > > > @@ -81,7 +81,7 @@ zfsboot.ld: zfsboot.ldr zfsboot.bin
> > > > > > > > > ${BTXKERN}
> > > > > > > > > -o ${.TARGET} -P 1 zfsboot.bin
> > > > > > > > >
> > > > > > > > > zfsboot.ldr:
> > > > > > > > > - cp /dev/null ${.TARGET}
> > > > > > > > > + :> ${.TARGET}
> > > > > > > > >
> > > > > > > > > zfsboot.bin: zfsboot.out
> > > > > > > > > ${OBJCOPY} -S -O binary zfsboot.out
> > > > > > > > > ${.TARGET}
> > > > > > > > > diff --git a/stand/libsa/Makefile
> > > > > > > > > b/stand/libsa/Makefile
> > > > > > > > > index effece9e01b..63cd46a9c54 100644
> > > > > > > > > --- a/stand/libsa/Makefile
> > > > > > > > > +++ b/stand/libsa/Makefile
> > > > > > > > > @@ -122,7 +122,7 @@ beforedepend:
> > > > > > > > > ln -sf ${SRCTOP}/include/arpa/inet.h
> > > > > > > > > arpa/inet.h; \
> > > > > > > > > ln -sf ${SRCTOP}/include/arpa/t
> > > > > > > > > ftp.h arpa/tftp.h; \
> > > > > > > > > for i in _time.h _strings.h _string.h; do \
> > > > > > > > > - [ -f xlocale/$$i ] || cp /dev/null
> > > > > > > > > xlocale/$$i; \
> > > > > > > > > + [ -f xlocale/$$i ] || :> xlocale/$$i;
> > > > > > > > > \
> > > > > > > > > done; \
> > > > > > > > > for i in ${STAND_H_INC}; do \
> > > > > > > > > ln -sf ${SASRC}/stand.h $$i; \
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Tue, Sep 22, 2020 at 3:58 PM Alan Somers <
> > > > > > > > > asom...@freebsd.org>
> > > >
> > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Looks like two places in stand. Is there any
> > > > > > > > > > reason why
> > > >
> > > > Mateusz's suggestion wouldn't work?
> > > > > > > > > >
> > > > > > > > > > > rg -g Makefile 'cp.*/dev/null'
> > > > > > >
Re: svn commit: r365984 - head/usr.bin/calendar/calendars
On Tue, 2020-09-22 at 17:56 +0200, Steffen Nurpmeso wrote:
> Ian Lepore wrote in
> :
> |On Tue, 2020-09-22 at 16:02 +0200, Steffen Nurpmeso wrote:
> |> Greg Lehey wrote in
> |> <202009212255.08lmtpsp078...@repo.freebsd.org>:
> |>|Author: grog
> |>|Date: Mon Sep 21 22:55:51 2020
> |>|New Revision: 365984
> |>|URL: https://svnweb.freebsd.org/changeset/base/365984
> |>|
> |>|Log:
> |>| Remove claim that Allied Forces created "West Germany" in
> |> 1953. I can
> |>| find no historic substantiation for such a claim. The Federal
> |>| Republic of Germany was created by Germans on 23 May 1949, as
> |> also
> |>| noted in this file.
> |>
> |> I could imagine it was Konrad Adenauer (chancellor at that time)
> |> refusing (let aside western war winners) the Sowjet offer to
> |> reunite Germany shall Germany henceforth exist as a "neutral
> |> state" in the same sense as Switzerland claims to be neutral.
> |> He refused, instead forward looking to rearm the German army.
> |> That is, turning Germany to a part of the Western Alliance
> |> explicitly and willingly. Or was that in 1949? Hm.
> |
> |And this is why I agree with Cy and Conrad that we should not be
> trying
> |to be wikipedia lite.
>
> Not finding anything at all that is to say then?
> On Wikipedia there is lobbyism and even war in big style for sure,
> you can very often see this.
> In fact, _this_ calendar entry is so fine because it mentions
> something that is not talked about in Germany, the last time
> i have heard it in the public was about twenty years ago, wait, it
> was in fact 2003 during the German public law TV show "Greatest
> Germans", and once the brave man said it ("sometimes the truth has
> to be told") it came out how that audience was mounted, because
> a loud LIE! could be heard. And yes, Konrad Adenauer was
> voted the greatest german of all time, a wise and comprehensible
> decision, outperforming those dwarfs like Goethe, Schiller,
> Beethoven, Einstein, Bach, and our wonderful emperor even. I do
> not understand!
>
> The calendar program came into BSD in 1981 and originally only
> looked for per user calendar files.
> I am using this program ever since i started using FreeBSD, now
> also on Linux. Other than that i cannot help it, you know.
> But it is great that just recently someone pimped the codebase in
> order to make it work with other calendar formats also, i think.
> (I cloned that specific repository in addition the second i read
> the announcement. Have not tried it yet though. But will keep
> it.)
>
And now you're arguing about the factual correctness of your comment in
reply to my comment which wasn't about the facts at all.
Thank you for proving my point most elequently about why we should not
be purveyors of trivia or general knowledge.
-- Ian
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r365984 - head/usr.bin/calendar/calendars
On Tue, 2020-09-22 at 16:02 +0200, Steffen Nurpmeso wrote: > Greg Lehey wrote in > <202009212255.08lmtpsp078...@repo.freebsd.org>: > |Author: grog > |Date: Mon Sep 21 22:55:51 2020 > |New Revision: 365984 > |URL: https://svnweb.freebsd.org/changeset/base/365984 > | > |Log: > | Remove claim that Allied Forces created "West Germany" in > 1953. I can > | find no historic substantiation for such a claim. The Federal > | Republic of Germany was created by Germans on 23 May 1949, as > also > | noted in this file. > > I could imagine it was Konrad Adenauer (chancellor at that time) > refusing (let aside western war winners) the Sowjet offer to > reunite Germany shall Germany henceforth exist as a "neutral > state" in the same sense as Switzerland claims to be neutral. > He refused, instead forward looking to rearm the German army. > That is, turning Germany to a part of the Western Alliance > explicitly and willingly. Or was that in 1949? Hm. > > And this is why I agree with Cy and Conrad that we should not be trying to be wikipedia lite. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r365889 - head/share/mk
On Fri, 2020-09-18 at 15:44 -0400, Mark Johnston wrote: > On Fri, Sep 18, 2020 at 01:27:23PM -0600, Ian Lepore wrote: > > On Fri, 2020-09-18 at 19:03 +, Mark Johnston wrote: > > > Author: markj > > > Date: Fri Sep 18 19:03:34 2020 > > > New Revision: 365889 > > > URL: https://svnweb.freebsd.org/changeset/base/365889 > > > > > > Log: > > > Install library symlinks atomically. > > > > > > As we do for shared library binaries, pass -S to install(1) when > > > installing symlinks. Doing so helps avoid transient failures when > > > libraries are being reinstalled, which seems to be the root cause > > > of > > > spurious libgcc_s.so link failures during CI builds. > > > > > > > Actually, I believe this will just paper over the real problem, which > > is the fact that we're building and installing the same library > > multiple times during early build steps. Nobody has yet been able to > > explain why we do that, and I haven't been able to figure out why by > > analyzing any differences in the generated files, but I'm not done > > trying. > > Sorry, this deserved more commentary in the commit log. > > Indeed, we install libgcc_s.so multiple times during buildworld. As far > as I can see, it's intentional insofar as libgcc_s.so is listed in > multiple library targets: it's in both _prereq_libs and _startup_libs in > Makefile.inc1. In particular, from scanning the log from a recent > instance of the failure, libgcc_s gets built once but installed multiple > times. > > Why that's the case, or whether it's still necessary, is not clear to > me. But adding -S seemed like a desirable change in general, so I went > forward with it. Yeah, it has been listed in both prereq and startup list since it was first added by kan@ in 2007 or so. I wonder if he remembers why (added to cc list)? -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r365889 - head/share/mk
On Fri, 2020-09-18 at 19:03 +, Mark Johnston wrote: > Author: markj > Date: Fri Sep 18 19:03:34 2020 > New Revision: 365889 > URL: https://svnweb.freebsd.org/changeset/base/365889 > > Log: > Install library symlinks atomically. > > As we do for shared library binaries, pass -S to install(1) when > installing symlinks. Doing so helps avoid transient failures when > libraries are being reinstalled, which seems to be the root cause > of > spurious libgcc_s.so link failures during CI builds. > Actually, I believe this will just paper over the real problem, which is the fact that we're building and installing the same library multiple times during early build steps. Nobody has yet been able to explain why we do that, and I haven't been able to figure out why by analyzing any differences in the generated files, but I'm not done trying. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r365729 - head/sys/dev/usb
Author: ian Date: Mon Sep 14 17:33:28 2020 New Revision: 365729 URL: https://svnweb.freebsd.org/changeset/base/365729 Log: Add product ID strings for a couple Microchip usb hubs. Also, update the vendor ID string to say just "Microchip Technology" -- the buyout of Standard Microsystems happened in 2012 and the SMC/SMSC names are pretty much retired at this point. PR: 241406 Modified: head/sys/dev/usb/usbdevs Modified: head/sys/dev/usb/usbdevs == --- head/sys/dev/usb/usbdevsMon Sep 14 17:21:52 2020(r365728) +++ head/sys/dev/usb/usbdevsMon Sep 14 17:33:28 2020(r365729) @@ -103,7 +103,7 @@ vendor CREATIVE 0x041e Creative Labs vendor NOKIA 0x0421 Nokia vendor ADI 0x0422 ADI Systems vendor CATC0x0423 Computer Access Technology -vendor SMC20x0424 Microchip (Standard Microsystems) +vendor SMC20x0424 Microchip Technology vendor MOTOROLA_HK 0x0425 Motorola HK vendor GRAVIS 0x0428 Advanced Gravis Computer vendor CIRRUSLOGIC 0x0429 Cirrus Logic @@ -4427,13 +4427,15 @@ product SMART2 G2MEMKEY 0x1700 G2 Memory Key product SMARTBRIDGES SMARTLINK 0x0001 SmartLink USB Ethernet product SMARTBRIDGES SMARTNIC 0x0003 smartNIC 2 PnP Ethernet -/* SMC products */ +/* Microchip Technology (formerly SMC) products */ product SMC 2102USB0x0100 10Mbps Ethernet product SMC 2202USB0x0200 10/100 Ethernet product SMC 2206USB0x0201 EZ Connect USB Ethernet product SMC 2862WG 0xee13 EZ Connect Wireless Adapter product SMC2 2020HUB 0x2020 USB Hub +product SMC2 2513HUB 0x2513 USB Hub product SMC2 2514HUB 0x2514 USB Hub +product SMC2 2517HUB 0x2517 USB Hub product SMC3 2662WUSB 0xa002 2662W-AR Wireless product SMC2 LAN7800_ETH 0x7800 USB/Ethernet product SMC2 LAN7801_ETH 0x7801 USB/Ethernet ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r365366 - in head: contrib/bmake contrib/bmake/lst.lib contrib/bmake/mk contrib/bmake/mk/sys contrib/bmake/unit-tests usr.bin/bmake usr.bin/bmake/unit-tests
On Sat, 2020-09-05 at 19:29 +, Simon J. Gerraty wrote:
> o new debug option -dl: LINT mode, does the equivalent of := for all
> variable assignments so that file and line number are reported for
> variable parse errors.
Doesn't -dl already have a meaning ("loud" builds)?
-- Ian
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r365274 - in head: share/man/man4 sys/dev/iicbus/mux
Author: ian
Date: Wed Sep 2 19:37:47 2020
New Revision: 365274
URL: https://svnweb.freebsd.org/changeset/base/365274
Log:
In ltc430x(4), add the ability to configure control register 2 via FDT or
hints data. Control register 2 holds the settings a user might want to
configure, such as the timeout value for idle busses and whether to enable
the mass-writes feature.
Also add hint support for disconnecting idle busses (which was already
supported using FDT data).
Update the manpage with the new features, and also split the hints section
into separate lists of required and optional hints.
Modified:
head/share/man/man4/ltc430x.4
head/sys/dev/iicbus/mux/ltc430x.c
Modified: head/share/man/man4/ltc430x.4
==
--- head/share/man/man4/ltc430x.4 Wed Sep 2 19:21:37 2020
(r365273)
+++ head/share/man/man4/ltc430x.4 Wed Sep 2 19:37:47 2020
(r365274)
@@ -26,7 +26,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd September 1, 2020
+.Dd September 2, 2020
.Dt LTC430X 4
.Os
.Sh NAME
@@ -85,12 +85,19 @@ ltc,downstream-accelerators-enable
.It
ltc,upstream-accelerators-enable
.El
+.Pp
+In addition, the following additional property is supported:
+.Bl -tag -offset indent -width indent
+.It Va freebsd,ctlreg2
+A value to store into the chip's control register 2 during initialization.
+Consult the chip datasheet for the meaning of the various bits in
+the register.
+.El
.Sh HINTS CONFIGURATION
On a
.Xr device.hints 5
-based system, these values are configurable for
-.Nm :
-.Bl -tag -width indent
+based system, the following hints are required:
+.Bl -tag -offset indent -width indent
.It Va hint.ltc430x..at
The upstream
.Xr iicbus 4
@@ -101,11 +108,33 @@ instance is attached to.
The slave address of the
.Nm
instance on the upstream bus.
+.It Va hint.ltc430x..chip_type
+The type of chip the driver is controlling.
+Valid values are
+.Dq ltc4305
+and
+.Dq ltc4306 .
.El
.Pp
+The following hints are optional:
+.Bl -tag -offset indent -width indent
+.It Va hint.ltc430x..ctlreg2
+A value to store into the chip's control register 2 during initialization.
+Consult the chip datasheet for the meaning of the various bits in
+the register.
+This hint is optional; when missing, the driver does not update control
+register 2.
+.It Va hint.ltc430x..idle_disconnect
+Whether to disconnect all downstream busses from the upstream bus when idle.
+If set to zero, the most recently used downstream bus is left connected to
+the upstream bus after IO completes.
+Any non-zero value causes all downstream busses to be disconnected when idle.
+This hint is optional; when missing, the driver behaves as if it were zero.
+.El
+.Pp
When configured via hints, the driver automatically adds an iicbus
instance for every downstream bus supported by the chip.
-There is currently no way to indicate used versus unused channels.
+There is currently no way to indicate used versus unused downstream channels.
.Sh SEE ALSO
.Xr iicbus 4 ,
.Xr iicmux 4 ,
Modified: head/sys/dev/iicbus/mux/ltc430x.c
==
--- head/sys/dev/iicbus/mux/ltc430x.c Wed Sep 2 19:21:37 2020
(r365273)
+++ head/sys/dev/iicbus/mux/ltc430x.c Wed Sep 2 19:37:47 2020
(r365274)
@@ -79,6 +79,7 @@ struct ltc430x_softc {
#defineLTC430X_CTLREG_00
#defineLTC430X_CTLREG_11
#defineLTC430X_CTLREG_22
+#define LTC430X_CR2_ENABLE_MW (1u << 3) /* Enable mass write
address. */
#defineLTC430X_CTLREG_33
static int
@@ -157,17 +158,39 @@ static int
ltc430x_attach(device_t dev)
{
struct ltc430x_softc *sc __unused;
- int chip, err, numchan;
+ int chip, err, numchan, val;
+ uint8_t busbits, ctlreg2;
sc = device_get_softc(dev);
+ busbits = 0;
+ ctlreg2 = LTC430X_CR2_ENABLE_MW;
+
+ /*
+* Check for the idle-disconnect and ctlreg2 options, first in FDT data,
+* then allow them to be overriden by hints data.
+*/
#ifdef FDT
phandle_t node;
node = ofw_bus_get_node(dev);
sc->idle_disconnect = OF_hasprop(node, "i2c-mux-idle-disconnect");
+
+ if (OF_getprop(macnode, "freebsd,ctlreg2", &val, sizeof(val)) > 0) {
+ ctlreg2 = val;
+ }
#endif
+ if (resource_int_value(device_get_name(dev), device_get_unit(dev),
+ "idle_disconnect", &val) == 0) {
+ sc->idle_disconnect = val;
+ }
+
+ if (resource_int_value(device_get_name(dev), device_get_unit(dev),
+ "ctlreg2", &val) == 0) {
+ ctlreg2 = val;
+ }
+
/* We found the chip type when probing, so now it "can't fail". */
if ((chip = ltc430x_find_chiptype(dev)) == CHIP_NONE) {
device_printf(dev, "impossible: can't identify chip type\n");
@@ -175,8 +198,22 @
svn commit: r365058 - head/share/man/man4
Author: ian Date: Tue Sep 1 19:06:08 2020 New Revision: 365058 URL: https://svnweb.freebsd.org/changeset/base/365058 Log: Document the fact that you must set an i2c slave address as well as the upstream iicbus to configure this device using hints. Modified: head/share/man/man4/ltc430x.4 Modified: head/share/man/man4/ltc430x.4 == --- head/share/man/man4/ltc430x.4 Tue Sep 1 19:02:07 2020 (r365057) +++ head/share/man/man4/ltc430x.4 Tue Sep 1 19:06:08 2020 (r365058) @@ -26,7 +26,7 @@ .\" .\" $FreeBSD$ .\" -.Dd January 1, 2020 +.Dd September 1, 2020 .Dt LTC430X 4 .Os .Sh NAME @@ -97,6 +97,10 @@ The upstream the .Nm instance is attached to. +.It Va hint.ltc430x..addr +The slave address of the +.Nm +instance on the upstream bus. .El .Pp When configured via hints, the driver automatically adds an iicbus ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r365054 - in head/sys: conf dev/sdhci
On Tue, 2020-09-01 at 17:27 +0100, Andrew Turner wrote: > > On 1 Sep 2020, at 17:17, Marcin Wojtas wrote: > > > > Author: mw > > Date: Tue Sep 1 16:17:21 2020 > > New Revision: 365054 > > URL: https://svnweb.freebsd.org/changeset/base/365054 > > > > Log: > > Introduce the SDHCI driver for NXP QorIQ Layerscape SoCs > > > > Implement support for an eSDHC controller found in NXP QorIQ > > Layerscape SoCs. > > > > This driver has been tested with NXP LS1046A and LX2160A > > (Honeycomb board), > > which is incompatible with the existing sdhci_fsl driver (aiming > > at older > > chips from this family). As such, it is not intended as > > replacement for > > the old driver, but rather serves as an improved alternative for > > SoCs that > > support it. > > It comes with support for both PIO and Single DMA modes and > > samples the > > clock from the extres clk API. > > > > Submitted by: Artur Rojek > > Reviewed by: manu, mmel, kibab > > Obtained from: Semihalf > > Sponsored by: Alstom Group > > Differential Revision: https://reviews.freebsd.org/D26153 > > > > Added: > > head/sys/dev/sdhci/sdhci_fsl_fdt.c (contents, props changed) > > Modified: > > head/sys/conf/files > > > > Modified: head/sys/conf/files > > === > > === > > --- head/sys/conf/files Tue Sep 1 16:13:09 2020(r365053) > > +++ head/sys/conf/files Tue Sep 1 16:17:21 2020(r365054) > > @@ -3058,6 +3058,7 @@ dev/scc/scc_dev_z8530.c optiona > > l scc > > dev/sdhci/sdhci.c optional sdhci > > dev/sdhci/sdhci_fdt.c optional sdhci fdt > > dev/sdhci/sdhci_fdt_gpio.c optional sdhci fdt gpio > > +dev/sdhci/sdhci_fsl_fdt.c optional sdhci fdt gpio > > This looks wrong. It should be using an NXP specific option, not > gpio. > > Andrew In addition to gpio, not instead of it (the new driver uses the fdt gpio helper stuff for card detect and write protect). -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364946 - head/sys/kern
On Sat, 2020-08-29 at 05:02 -0600, Warner Losh wrote: > > > > sbuf_cpy() at _gone_in_dev+0x560 > > pc = 0x003c1ff0 lr = 0x003a9078 > > sp = 0x6f21a510 fp = 0x6f21a570 > > > > _gone_in_dev() at sbuf_new_for_sysctl+0x170 > > pc = 0x003a9078 lr = 0x0037c1a8 > > sp = 0x6f21a580 fp = 0x6f21a5a0 > > > > sbuf_new_for_sysctl() at kernel_sysctl+0x36c > > pc = 0x0037c1a8 lr = 0x0037b63c > > sp = 0x6f21a5b0 fp = 0x6f21a630 > > > > This traceback is all kinds of crazy. sbuf_new_for_sysctl doesn't call > _gone_in_dev(), which doesn't do sbuf stuff at all. And neither does it > call sbuf_cpy(). Though I get a crash that looks like: > Tracing pid 66442 tid 101464 td 0xfe02f47b7c00 > kdb_enter() at kdb_enter+0x37/frame 0xfe02f4ae3740 > vpanic() at vpanic+0x19e/frame 0xfe02f4ae3790 > panic() at panic+0x43/frame 0xfe02f4ae37f0 > sbuf_clear() at sbuf_clear+0xac/frame 0xfe02f4ae3800 > sbuf_cpy() at sbuf_cpy+0x5a/frame 0xfe02f4ae3820 > device_sysctl_handler() at device_sysctl_handler+0x133/frame > 0xfe02f4ae38a0 > sysctl_root_handler_locked() at sysctl_root_handler_locked+0x9c/frame > 0xfe02f4ae38f0 > sysctl_root() at sysctl_root+0x20a/frame 0xfe02f4ae3970 > userland_sysctl() at userland_sysctl+0x17d/frame 0xfe02f4ae3a20 > sys___sysctl() at sys___sysctl+0x5f/frame 0xfe02f4ae3ad0 > amd64_syscall() at amd64_syscall+0x140/frame 0xfe02f4ae3bf0 > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe02f4ae3bf0 > --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x80042d50a, rsp = > 0x7fffd458, rbp = 0x7fffd490 --- > > on a sysctl -a which I think makes more sense... I'll see if I can track > it down... I think it's because sbuf_cpy does an unconditional clear, which > triggers this assert, which is likely bogus for this case. sbuf_cat doesn't > seem to have this issue... I'll confirm and commit. > > Warner This kind of crazy happens when the traceback just reports the name of the nearest global symbol it can find because static or other local symbols aren't available to it. The clue that that's what's going on tends to be in things like: sbuf_cpy() at _gone_in_dev+0x560 It's almost certain that _gone_in_dev() isn't a big enough function that an offset of 0x560 is still in that function, so it's really in some static function that got linked nearby but the symbols for statics got stripped. Usually you can use addr2line on kernel.full to get the real names for the pc and lr values. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364822 - in head/crypto/openssl/crypto: aes/asm bn/asm chacha/asm ec/asm modes/asm poly1305/asm sha/asm
On Wed, 2020-08-26 at 19:04 +0200, Mateusz Guzik wrote: > On 8/26/20, Jung-uk Kim wrote: > > Author: jkim > > Date: Wed Aug 26 16:55:28 2020 > > New Revision: 364822 > > URL: https://svnweb.freebsd.org/changeset/base/364822 > > > > Log: > > Fix Clang version detection. > > > > We prepend "FreeBSD" to Clang version string. This broke > > compiler test > > for > > AVX instruction support. > > > > What about other software checking in similar fashion? imo the right > fix is to stop mucking with the way clang reports itself > Maybe it would be better to not modify the start of the string. Instead of FreeBSD clang version 9.0.1 (g...@github.com:llvm/llvm-project.git c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1) maybe clang version 9.0.1 for FreeBSD (g...@github.com:llvm/llvm-project.git c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1) -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r364402 - head/sys/kern
On Wed, 2020-08-19 at 13:54 -0400, Shawn Webb wrote:
> On Wed, Aug 19, 2020 at 11:51:10AM -0600, Warner Losh wrote:
> > On Wed, Aug 19, 2020 at 11:48 AM Shawn Webb <
> > shawn.w...@hardenedbsd.org>
> > wrote:
> >
> > > On Wed, Aug 19, 2020 at 11:44:42AM -0600, Warner Losh wrote:
> > > > On Wed, Aug 19, 2020 at 11:26 AM Shawn Webb <
> > > > shawn.w...@hardenedbsd.org>
> > > > wrote:
> > > >
> > > > > On Wed, Aug 19, 2020 at 05:10:05PM +, Warner Losh wrote:
> > > > > > Author: imp
> > > > > > Date: Wed Aug 19 17:10:04 2020
> > > > > > New Revision: 364402
> > > > > > URL: https://svnweb.freebsd.org/changeset/base/364402
> > > > > >
> > > > > > Log:
> > > > > > Add VFS FS events for mount and unmount to devctl/devd
> > > > > >
> > > > > > Report when a filesystem is mounted, remounted or
> > > > > > unmounted via
> > >
> > > devd,
> > > > > along with
> > > > > > details about the mount point and mount options.
> > > > > >
> > > > > > Discussed with: kib@
> > > > > > Reviewed by: kirk@ (prior version)
> > > > > > Sponsored by: Netflix
> > > > > > Diffential Revision: https://reviews.freebsd.org/D25969
> > > > > >
> > > > > > Modified:
> > > > > > head/sys/kern/vfs_mount.c
> > > > > >
> > > > > > Modified: head/sys/kern/vfs_mount.c
> > > > > >
> > >
> > > =
> > > =
> > > > > > --- head/sys/kern/vfs_mount.c Wed Aug 19 17:09:58 2020
> > >
> > > (r364401)
> > > > > > +++ head/sys/kern/vfs_mount.c Wed Aug 19 17:10:04 2020
> > >
> > > (r364402)
> > > > > > @@ -42,6 +42,7 @@ __FBSDID("$FreeBSD$");
> > > > > > #include
> > > > > > #include
> > > > > > #include
> > > > > > +#include
> > > > > > #include
> > > > > > #include
> > > > > > #include
> > > > > > @@ -101,6 +102,8 @@ MTX_SYSINIT(mountlist, &mountlist_mtx,
> > >
> > > "mountlist",
> > > > > MT
> > > > > > EVENTHANDLER_LIST_DEFINE(vfs_mounted);
> > > > > > EVENTHANDLER_LIST_DEFINE(vfs_unmounted);
> > > > > >
> > > > > > +static void dev_vfs_event(const char *type, struct mount
> > > > > > *mp, bool
> > > > >
> > > > > donew);
> > > > > > +
> > > > > > /*
> > > > > > * Global opts, taken by all filesystems
> > > > > > */
> > > > > > @@ -1020,6 +1023,7 @@ vfs_domount_first(
> > > > > > VOP_UNLOCK(vp);
> > > > > > EVENTHANDLER_DIRECT_INVOKE(vfs_mounted, mp, newdp,
> > > > > > td);
> > > > > > VOP_UNLOCK(newdp);
> > > > > > + dev_vfs_event("MOUNT", mp, false);
> > > > > > mountcheckdirs(vp, newdp);
> > > > > > vn_seqc_write_end(vp);
> > > > > > vn_seqc_write_end(newdp);
> > > > > > @@ -1221,6 +1225,7 @@ vfs_domount_update(
> > > > > > if (error != 0)
> > > > > > goto end;
> > > > > >
> > > > > > + dev_vfs_event("REMOUNT", mp, true);
> > > > > > if (mp->mnt_opt != NULL)
> > > > > > vfs_freeopts(mp->mnt_opt);
> > > > > > mp->mnt_opt = mp->mnt_optnew;
> > > > > > @@ -1839,6 +1844,7 @@ dounmount(struct mount *mp, int
> > > > > > flags, struct
> > > > >
> > > > > thread *
> > > > > > TAILQ_REMOVE(&mountlist, mp, mnt_list);
> > > > > > mtx_unlock(&mountlist_mtx);
> > > > > > EVENTHANDLER_DIRECT_INVOKE(vfs_unmounted, mp, td);
> > > > > > + dev_vfs_event("UNMOUNT", mp, false);
> > > > > > if (coveredvp != NULL) {
> > > > > > coveredvp->v_mountedhere = NULL;
> > > > > > vn_seqc_write_end(coveredvp);
> > > > > > @@ -2425,4 +2431,72 @@ kernel_vmount(int flags, ...)
> > > > > >
> > > > > > error = kernel_mount(ma, flags);
> > > > > > return (error);
> > > > > > +}
> > > > > > +
> > > > > > +/* Map from mount options to printable formats. */
> > > > > > +static struct mntoptnames optnames[] = {
> > > > > > + MNTOPT_NAMES
> > > > > > +};
> > > > > > +
> > > > > > +static void
> > > > > > +dev_vfs_event_mntopt(struct sbuf *sb, const char *what,
> > > > > > struct
> > > > >
> > > > > vfsoptlist *opts)
> > > > > > +{
> > > > > > + struct vfsopt *opt;
> > > > > > +
> > > > > > + if (opts == NULL || TAILQ_EMPTY(opts))
> > > > > > + return;
> > > > > > + sbuf_printf(sb, " %s=\"", what);
> > > > > > + TAILQ_FOREACH(opt, opts, link) {
> > > > > > + if (opt->name[0] == '\0' || (opt->len > 0 &&
> > > > > > *(char
> > > > >
> > > > > *)opt->value == '\0'))
> > > > > > + continue;
> > > > > > + devctl_safe_quote_sb(sb, opt->name);
> > > > > > + if (opt->len > 0) {
> > > > > > + sbuf_putc(sb, '=');
> > > > > > + devctl_safe_quote_sb(sb, opt->value);
> > > > > > + }
> > > > > > + sbuf_putc(sb, ';');
> > > > > > + }
> > > > > > + sbuf_putc(sb, '"');
> > > > > > +}
> > > > > > +
> > > > > > +#define DEVCTL_LEN 1024
> > > > > > +static void
> > > > > > +dev_vfs_event(const char *type, struct mount *mp, bool
> > > > > > donew)
> > > > > > +{
> > >
Re: svn commit: r364166 - head/usr.sbin/crunch/crunchgen
On Wed, 2020-08-12 at 09:24 -0700, Rodney W. Grimes wrote: > > On 12 Aug 2020, at 17:10, Rodney W. Grimes < > > free...@gndrsh.dnsmgr.net> wrote: > > > > > > > Author: arichardson > > > > Date: Wed Aug 12 15:49:06 2020 > > > > New Revision: 364166 > > > > URL: https://svnweb.freebsd.org/changeset/base/364166 > > > > > > > > Log: > > > > Fix crunchgen usage of mkstemp() > > > > > > > > On Glibc systems mkstemp can only be used once with the same > > > > template > > > > string since it will be modified in-place and no longer > > > > contain any 'X' chars. > > > > It is fine to reuse the same file here but we need to be > > > > explicit and use > > > > open() instead of mkstemp() on the second use. > > > > > > > > While touching this file also avoid a hardcoded /bin/pwd since > > > > that may not > > > > work when building on non-FreeBSD systems. > > > > > > This may cause some grief, as now pwd may use a shell builtin > > > and often shell builtin's return a cwd that is not a true > > > full path, ie it may contain symlink compontents in the > > > path. > > > > > > /bin/sh: > > > > > > # cd /tmp/b > > > # /bin/pwd > > > /tmp/a > > > # pwd > > > /tmp/b > > > # ls -lag /tmp/? > > > lrwxr-xr-x 1 root wheel 1 Aug 12 16:06 /tmp/b -> a > > > > > > /tmp/a: > > > total 17 > > > drwxr-xr-x 2 root wheel2 Aug 12 16:06 . > > > drwxrwxrwt 18 root wheel 248 Aug 12 16:06 .. > > > > There's the question of whether that really matters; both values > > are in > > some sense correct. But if you want to restore the old behaviour, I > > believe `env pwd` is the portable way to do so? > > You have cut the context, but the code has a comment that > states it is doing this to remove symbolic links, so this > change infact undoes something that was being done intentionally. > > I do believe also that a "env pwd" would do the right thing > as well. > Or just use "pwd -P" and avoid invoking multiple programs when the shell can do all the work. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r363992 - head/usr.sbin/pwd_mkdb
On Sat, 2020-08-08 at 11:08 +0100, Alexander Richardson wrote:
> On Sat, 8 Aug 2020 at 02:19, Mateusz Guzik wrote:
> >
> > This broke i386 builds:
> >
> > /usr/src/usr.bin/chpass/field.c:175:15: error: incompatible pointer
> > types passing
> > '_bootstrap_time_t *' (aka 'unsigned long long *') to
> > parameter
> > of type 'time_t *'
> > (aka 'int *') [-Werror,-Wincompatible-pointer-types]
> > if (!atot(p, &pw->pw_change))
> > ^~
> > /usr/src/usr.bin/chpass/chpass.h:67:27: note: passing argument to
> > parameter here
> > int atot(char *, time_t *);
> > ^
> > /usr/src/usr.bin/chpass/field.c:185:15: error: incompatible pointer
> > types passing
> > '_bootstrap_time_t *' (aka 'unsigned long long *') to
> > parameter
> > of type 'time_t *'
> > (aka 'int *') [-Werror,-Wincompatible-pointer-types]
> > if (!atot(p, &pw->pw_expire))
> > ^~
> > /usr/src/usr.bin/chpass/chpass.h:67:27: note: passing argument to
> > parameter here
> > int atot(char *, time_t *);
> > ^
>
> Sorry, fixed in r364049.
>
It may be fixed in terms of compiling, but how about at runtime?
_bootstrap_time_t is still typedef'd as 64-bit, but on i386 a time_t is
a 32-bit type.
-- Ian
> > On 8/6/20, Alex Richardson wrote:
> > > Author: arichardson
> > > Date: Thu Aug 6 20:46:13 2020
> > > New Revision: 363992
> > > URL: https://svnweb.freebsd.org/changeset/base/363992
> > >
> > > Log:
> > > Allow bootstrapping pwd_mkdb on Linux/macOS
> > >
> > > We need to provide a struct passwd that is compatible with the
> > > target
> > > system and this is not the case when cross-building from
> > > macOS/Linux.
> > > It should also be a problem when bootstrapping for an i386
> > > target from a
> > > FreeBSD amd64 host since time_t does not match across those
> > > systems.
> > > However, pwd_mkdb always truncates integer values to 32-bit so
> > > this
> > > difference does not result in different databases.
> > >
> > > Reviewed By:brooks
> > > Differential Revision: https://reviews.freebsd.org/D25931
> > >
> > > Added:
> > > head/usr.sbin/pwd_mkdb/pwd.h (contents, props changed)
> > > Modified:
> > > head/usr.sbin/pwd_mkdb/Makefile
> > >
> > > Modified: head/usr.sbin/pwd_mkdb/Makefile
> > > =
> > > =
> > > --- head/usr.sbin/pwd_mkdb/Makefile Thu Aug 6 20:44:40
> > > 2020(r363991)
> > > +++ head/usr.sbin/pwd_mkdb/Makefile Thu Aug 6 20:46:13
> > > 2020(r363992)
> > > @@ -9,5 +9,8 @@ MAN= pwd_mkdb.8
> > > SRCS=pw_scan.c pwd_mkdb.c
> > >
> > > CFLAGS+= -I${SRCTOP}/lib/libc/gen# for pw_scan.h
> > > +.if defined(BOOTSTRAPPING)
> > > +CFLAGS+=-I${.CURDIR}
> > > +.endif
> > >
> > > .include
> > >
> > > Added: head/usr.sbin/pwd_mkdb/pwd.h
> > > =
> > > =
> > > --- /dev/null 00:00:00 1970 (empty, because file is newly
> > > added)
> > > +++ head/usr.sbin/pwd_mkdb/pwd.h Thu Aug 6 20:46:13
> > > 2020(r363992)
> > > @@ -0,0 +1,66 @@
> > > +/*-
> > > + * SPDX-License-Identifier: BSD-2-Clause
> > > + *
> > > + * Copyright 2018-2020 Alex Richardson
> > > + *
> > > + * This software was developed by SRI International and the
> > > University of
> > > + * Cambridge Computer Laboratory (Department of Computer Science
> > > and
> > > + * Technology) under DARPA contract HR0011-18-C-0016 ("ECATS"),
> > > as part of
> > > the
> > > + * DARPA SSITH research programme.
> > > + *
> > > + * This software was developed by SRI International and the
> > > University of
> > > + * Cambridge Computer Laboratory under DARPA/AFRL contract
> > > (FA8750-10-C-0237)
> > > + * ("CTSRD"), as part of the DARPA CRASH research programme.
> > > + *
> > > + * Redistribution and use in source and binary forms, with or
> > > without
> > > + * modification, are permitted provided that the following
> > > conditions
> > > + * are met:
> > > + * 1. Redistributions of source code must retain the above
> > > copyright
> > > + *notice, this list of conditions and the following
> > > disclaimer.
> > > + * 2. Redistributions in binary form must reproduce the above
> > > copyright
> > > + *notice, this list of conditions and the following
> > > disclaimer in the
> > > + *documentation and/or other materials provided with the
> > > distribution.
> > > + *
> > > + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS
> > > IS'' AND
> > > + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
> > > TO, THE
> > > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
> > > PARTICULAR
> > > PURPOSE
> > > + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS
> > > BE LIABLE
> > > + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEM
Re: svn commit: r364010 - head/sbin/iscontrol
On Fri, 2020-08-07 at 17:32 +0200, Emmanuel Vadot wrote:
> On Fri, 7 Aug 2020 08:26:00 -0700 (PDT)
> "Rodney W. Grimes" wrote:
>
> > > Author: manu
> > > Date: Fri Aug 7 12:19:21 2020
> > > New Revision: 364010
> > > URL: https://svnweb.freebsd.org/changeset/base/364010
> > >
> > > Log:
> > > pkgbase: We can't easily have a package with either a - or a _
> >
> > Wow, hopefully this is short term.
>
> Not really.
>
> > I would think a package name can be any valid file name, and to
> > remove - and _ from that set is going
> > to cause lots of POLA.
>
> The package file itself contain '-', they are named
> FreeBSD--{dbg,lib32,dev,}-. it's just that we used -
> and
> _ when building them to get some variable which contain the
> description, nothing that can't be patched by this is clearly not my
> priority.
>
This should be easy to fix. Use sed instead of tr, and translate - to
__ to remove dashes, and then translate __ back to - to restore them,
and you've properly preserved single _ usage in names.
-- Ian
> >
> > >
> > > Rename iscsi_legacy to iscsilegacy, having - or _ in a package
> > > name cause
> > > problems when we process them and generate the ucl.
> > >
> > > Modified:
> > > head/sbin/iscontrol/Makefile
> > >
> > > Modified: head/sbin/iscontrol/Makefile
> > > =
> > > =
> > > --- head/sbin/iscontrol/Makefile Fri Aug 7 10:20:39 2020(
> > > r364009)
> > > +++ head/sbin/iscontrol/Makefile Fri Aug 7 12:19:21 2020(
> > > r364010)
> > > @@ -1,6 +1,6 @@
> > > # $FreeBSD$
> > >
> > > -PACKAGE=iscsi_legacy
> > > +PACKAGE=iscsilegacy
> > > SRCS= iscontrol.c pdu.c fsm.c config.c login.c auth_subr.c
> > > misc.c
> > > PROG= iscontrol
> > > LIBADD= cam md
> > >
> >
> > --
> > Rod Grimes
> > rgri...@freebsd.org
>
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r363576 - head/usr.bin/vmstat
Author: ian Date: Sun Jul 26 18:33:29 2020 New Revision: 363576 URL: https://svnweb.freebsd.org/changeset/base/363576 Log: Describe the value in the 're' column of vmstat(8) in terms of freebsd's vm implementation. The old description was left over from the 4.4 BSD Lite import in 1994, and was a bit misleading (not all arches use simulated reference bits, some implement reference tracking in hardware). Modified: head/usr.bin/vmstat/vmstat.8 Modified: head/usr.bin/vmstat/vmstat.8 == --- head/usr.bin/vmstat/vmstat.8Sun Jul 26 18:33:29 2020 (r363575) +++ head/usr.bin/vmstat/vmstat.8Sun Jul 26 18:33:29 2020 (r363576) @@ -283,7 +283,7 @@ These are given in units per second. .It flt total number of page faults .It re -page reclaims (simulating reference bits) +pages reactivated (found in laundry or inactive queues) .\" .It at .\" pages attached (found in free list) .It pi ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r363569 - head/usr.bin/vmstat
Author: ian Date: Sun Jul 26 17:50:39 2020 New Revision: 363569 URL: https://svnweb.freebsd.org/changeset/base/363569 Log: Remove commented-out lines describing the old never-implemented -t option. In 2018, r338094 removed the commented-out code for supporting the -t command line option which had been present since the BSD 4.4 Lite import, but was never implemented for freebsd. This does the same for the man page. Modified: head/usr.bin/vmstat/vmstat.8 Modified: head/usr.bin/vmstat/vmstat.8 == --- head/usr.bin/vmstat/vmstat.8Sun Jul 26 17:44:03 2020 (r363568) +++ head/usr.bin/vmstat/vmstat.8Sun Jul 26 17:50:39 2020 (r363569) @@ -28,7 +28,7 @@ .\"@(#)vmstat.88.1 (Berkeley) 6/6/93 .\" $FreeBSD$ .\" -.Dd May 26, 2020 +.Dd July 26, 2020 .Dt VMSTAT 8 .Os .Sh NAME @@ -209,9 +209,6 @@ Display the contents of the .Em sum structure, giving the total number of several kinds of paging related events which have occurred since system startup. -.\" .It Fl t -.\" Report on the number of page in and page reclaims since system startup, -.\" and the amount of time required by each. .It Fl w Pause .Ar wait ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r363473 - head/share/man/man8
On Fri, 2020-07-24 at 14:17 +, Mateusz Piotrowski wrote: > Author: 0mp (doc,ports committer) > Date: Fri Jul 24 14:17:37 2020 > New Revision: 363473 > URL: https://svnweb.freebsd.org/changeset/base/363473 > > [...] > @@ -237,8 +237,13 @@ The > .Ar name > argument is the > .Xr basename 1 > -component of the path to the script, usually > -.Pa /etc/rc.d/name . > +component of the path to the script located at > +.Pa /etc/rc.d > +(scripts stored in other locations like grammar: "like" should be "such as" > +.Pa /usr/local/etc/rc.d > +cannot be contolled with typo: controlled -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r363330 - head/sys/dev/iicbus
Author: ian Date: Sun Jul 19 18:53:19 2020 New Revision: 363330 URL: https://svnweb.freebsd.org/changeset/base/363330 Log: The ds3231 RTC chip bitmask values for 12- versus 24-hour mode were reversed, flip them so that times in the 20:00:00 to 23:59:59 range read correctly. Reported by: Dr. Rolf Jansen Pointy hat: ian@ Modified: head/sys/dev/iicbus/ds3231reg.h Modified: head/sys/dev/iicbus/ds3231reg.h == --- head/sys/dev/iicbus/ds3231reg.h Sun Jul 19 17:47:55 2020 (r363329) +++ head/sys/dev/iicbus/ds3231reg.h Sun Jul 19 18:53:19 2020 (r363330) @@ -38,8 +38,8 @@ #defineDS3231_MINS 0x01 #defineDS3231_MINS_MASK0x7f #defineDS3231_HOUR 0x02 -#defineDS3231_HOUR_MASK_12HR 0x3f -#defineDS3231_HOUR_MASK_24HR 0x1f +#defineDS3231_HOUR_MASK_12HR 0x1f +#defineDS3231_HOUR_MASK_24HR 0x3f #defineDS3231_HOUR_IS_PM 0x20 #defineDS3231_HOUR_USE_AMPM0x40 #defineDS3231_WEEKDAY 0x03 ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r362781 - head/sys/compat/linuxkpi/common/include/linux
On Mon, 2020-06-29 at 14:26 -0600, Warner Losh wrote: > On Mon, Jun 29, 2020, 2:15 PM Ravi Pokala > wrote: > > > -Original Message- > > From: on behalf of Hans Petter > > Selasky > > > > Date: 2020-06-29, Monday at 06:08 > > To: , , < > > svn-src-head@freebsd.org> > > Subject: svn commit: r362781 - > > head/sys/compat/linuxkpi/common/include/linux > > > > Author: hselasky > > Date: Mon Jun 29 13:08:40 2020 > > New Revision: 362781 > > URL: https://svnweb.freebsd.org/changeset/base/362781 > > > > Log: > > Implement is_signed(), type_max() and type_min() function > > macros in > > the > > LinuxKPI. > > > > MFC after:1 week > > Sponsored by: Mellanox Technologies > > > > Modified: > > head/sys/compat/linuxkpi/common/include/linux/kernel.h > > > > Modified: > > head/sys/compat/linuxkpi/common/include/linux/kernel.h > > > > === > > === > > --- head/sys/compat/linuxkpi/common/include/linux/kernel.h Mon > > Jun 29 > > 12:59:09 2020(r362780) > > +++ head/sys/compat/linuxkpi/common/include/linux/kernel.h Mon > > Jun 29 > > 13:08:40 2020(r362781) > > @@ -564,4 +564,20 @@ linux_ratelimited(linux_ratelimit_t *rl) > > #define__is_constexpr(x) \ > > __builtin_constant_p(x) > > > > Hi Hans, > > > > +#defineis_signed(x) (((x)-1 / (x)2) == (x)0) > > > > It took me several reads to understand this, until I figured out > > that 'x' > > is not a variable, it's the name of a *type*. > > > > If 'x' is a variable, then '(x)-1' is subtraction, but '(x)2' and > > '(x)0' > > are nonsensical. > > > > If 'x' is a *type*, then '(x)-1' is typecasting '-1', and similarly > > for > > '(x)2' and '(x)0'. > > > > So, perhaps a comment, or a better name for 'x'? > > > > I had similar thoughts. Maybe 't' instead? > Or maybe since there's no one-character restriction on macro variable names, something actually descriptive like 'datatype'. -- Ian > Warner > > Thanks, > > > > Ravi (rpokala@) > > > > +#definetype_max(x) ( > > \ > > + (sizeof(x) >= 8) ? (is_signed(x) ? INT64_MAX : UINT64_MAX) > > : \ > > + (sizeof(x) >= 4) ? (is_signed(x) ? INT32_MAX : UINT32_MAX) > > : \ > > + (sizeof(x) >= 2) ? (is_signed(x) ? INT16_MAX : UINT16_MAX) > > : \ > > +(is_signed(x) ? INT8_MAX : UINT8_MAX) \ > > +) > > + > > +#definetype_min(x) > > ( \ > > + (sizeof(x) >= 8) ? (is_signed(x) ? INT64_MIN : 0) : \ > > + (sizeof(x) >= 4) ? (is_signed(x) ? INT32_MIN : 0) : \ > > + (sizeof(x) >= 2) ? (is_signed(x) ? INT16_MIN : 0) : \ > > +(is_signed(x) ? INT8_MIN : 0) \ > > +) > > + > > #endif /* _LINUX_KERNEL_H_ */ > > > > > > ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r362422 - head/sbin/dump
On Sat, 2020-06-20 at 07:57 -0600, Warner Losh wrote: > On Sat, Jun 20, 2020 at 7:27 AM Hans Petter Selasky wrote: > > > On 2020-06-20 13:10, Rodney W. Grimes wrote: > > > > Author: imp > > > > Date: Sat Jun 20 04:19:17 2020 > > > > New Revision: 362422 > > > > URL:https://svnweb.freebsd.org/changeset/base/362422 > > > > > > > > Log: > > > >Increase the whimsy in this file by famring dump's work out to > > > > minions. Adjust > > > >variables accordingly. Thankfully, we are able to do this without > > > > additional > > > >banana expenditures. > > > > > > This flys in the face of its intent and as a "commit" is more > > > racially biased than the code was! > > > > > > > Hi Warner, > > > > Maybe a stupid question, but is this the correct meaning or description > > of minion? > > > > https://www.google.com/search?q=minions > > > > minion; plural noun: minions > > > > a follower or underling of a powerful person, especially a servile > > or unimportant one. > > "he gets oppressed minions like me to fob them off" > > > > "Minion" is still a person, like "slave" is, so I must say I agree with > > Rodney about this, I don't see how this makes it any better? Can you > > explain? > > > > For me, Minions come from the Despicable Me movies and sequels. They work > for Gru, who pays them for their services. They love Bananas and often do > crazy things for a banana. They work for Gru willingly. They are free to > leave at any time. They are sad at the prospect of Gru having to lay them > off. > > Minions are also, as you point out, employed by the powerful to accomplish > things. Key word here is 'employed'. Servile doesn't mean 'involuntary > servitude' but rather 'an excessive willingness to please.' Underling means > only that them are below them on the org chart. There's no inherent > implication of an abusive relationship, per se, though that happens as in > any power relationship between people. > > And the extensive searching I did before the commit showed no complaints > about the movies, or that this term had some coded, racist history. Or any > other coded history that's problematic. Or any overt history for that > matter. > > SaltStack uses it as their name for agents that carry out tasks, for > example. > > So what am I missing? > Common sense, apparently. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r362217 - head/stand/common
On Tue, 2020-06-16 at 10:30 -0700, Rodney W. Grimes wrote: > > In message < > > 55903c38d363aef2a6f6d0075dd4526b86d51258.ca...@freebsd.org>, > > Ian Le > > pore writes: > > > On Tue, 2020-06-16 at 07:05 +, Toomas Soome wrote: > > > > Author: tsoome > > > > Date: Tue Jun 16 07:05:03 2020 > > > > New Revision: 362217 > > > > URL: https://svnweb.freebsd.org/changeset/base/362217 > > > > > > > > Log: > > > > loader: variable i is unused without MBR/GPT support built in > > > > > > > > Because i is only used as index in for loop, declare it in > > > > for > > > > statement. > > > > > > > > > > As much as I prefer doing it this way, style(9) doesn't allow for > > > variable declarations inside a for() statement (or even inside a > > > local > > > block, which is just too 1980s for me, but it is still our > > > standard). > > Last time I tried to assert that bit of style(9) with respect to > inside a local block I was over ridden, so it is probably time > to atleast revisit that part of style(9). > > > Doesn't this use stack for a shorter period of time or does the > > compiler > > optimize this, making this change moot? > > > > The tradeoff is a few extra bytes of stack for a longer period of > > time vs a > > few extra instructions incrementing and decrementing the stack > > pointer. > > I do not think the reasoning had to do with stack space vs > instuctions, > but more about being able to clearly know about variable reuse and > not > do it as that can create fun bugs. > > Tools have modernized since that part of style was written. I think a modern compiler will likely emit one of those "declaration of foo here shadows declaration in outer scope" type messages. Not that it should; IMO, part of the point of keeping definitions confined to as local a scope as possible is to help ensure you're using the variable you think you are in that local scope and not accidentally perturbing something used elsewhere. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r362217 - head/stand/common
On Tue, 2020-06-16 at 19:34 +0200, Kristof Provost wrote: > On 16 Jun 2020, at 19:11, Ed Maste wrote: > > On Tue, 16 Jun 2020 at 13:01, Ian Lepore wrote: > > > > > > As much as I prefer doing it this way, style(9) doesn't allow for > > > variable declarations inside a for() statement (or even inside a > > > local > > > block, which is just too 1980s for me, but it is still our standard). > > > > Perhaps it's time to update style(9) to at least permit these uses, as > > we've done with the blank line at the beginning of functions with no > > local variables, and with braces around single-line bodies. > > We have 431 instances of `for (int i` in sys alone. It’s not so much a > question of allowing it as acknowledging reality at this point. > > Best regards, > Kristof Hmm, so we do. If you weed out sys/contrib, and device drivers contributed by vendors, the number is a lot smaller, but still big enough that we should just change the rules I think. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r362217 - head/stand/common
On Tue, 2020-06-16 at 07:05 +, Toomas Soome wrote: > Author: tsoome > Date: Tue Jun 16 07:05:03 2020 > New Revision: 362217 > URL: https://svnweb.freebsd.org/changeset/base/362217 > > Log: > loader: variable i is unused without MBR/GPT support built in > > Because i is only used as index in for loop, declare it in for > statement. > As much as I prefer doing it this way, style(9) doesn't allow for variable declarations inside a for() statement (or even inside a local block, which is just too 1980s for me, but it is still our standard). -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r362017 - in head/usr.bin/sed: . tests
On Thu, 2020-06-11 at 16:29 +0200, Steffen Nurpmeso wrote: > Hello. > > Mateusz Piotrowski wrote in > <995726df-cb28-c294-09ca-6cca302b2...@freebsd.org>: > |On 6/11/20 12:06 AM, Steffen Nurpmeso wrote: > |> Yuri Pankov wrote in > |> : > |>|Mateusz Piotrowski wrote: > |>|> Author: 0mp (doc,ports committer) > |>|> Date: Wed Jun 10 19:23:58 2020 > |>|> New Revision: 362017 > |>|> URL: https://svnweb.freebsd.org/changeset/base/362017 > |>|> > |>|> Log: > |>|>Read commands from stdin when -f - is passed to sed(1) > |> .. > |>|Am I reading it wrong, or is it the same test case added 3 times? > |> > |> It also used "Fl f Cm -" instead of "Fl f Ar -". Just saying.. > > |Which is correct. "-" is not a variable here. It is a fixed string hence > |the use of Cm. > > I would rather say no, .Ar is an argument (to the ".Fl"ag f), > whereas .Cm is a command modifier: > >Command Modifiers > The command modifier is identical to the '.Fl' (flag) command with the > exception that the '.Cm' macro does not assert a dash in front of every > argument. Traditionally flags are marked by the preceding dash, however, > some commands or subsets of commands do not use them. Command modifiers > may also be specified in conjunction with interactive commands such as > editor commands. > Yeah, but... The '.Fl' macro without any arguments results in a dash representing stdin/stdout. Note that giving '.Fl' a single dash will result in two dashes. The '.Fl' macro is parsed and is callable. And that seems to argue that "Fl f Fl" is correct. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r361677 - in head/usr.bin/svn: . lib lib/libapr lib/libapr_util lib/libserf lib/libsvn_client lib/libsvn_delta lib/libsvn_diff lib/libsvn_fs lib/libsvn_fs_fs lib/libsvn_fs_util lib/lib
On Sun, 2020-05-31 at 22:04 +, Dimitry Andric wrote: > Author: dim > Date: Sun May 31 22:04:51 2020 > New Revision: 361677 > URL: https://svnweb.freebsd.org/changeset/base/361677 > > Log: > Change Makefiles under usr.bin/svn to make them easier to > incrementally > update. No functional change intended. > > MFC after: 2 weeks > I wish we could get style.Makefile(9) updated to mandate this 1-per- line style when listing sources, dirs, etc, when the number of items is greater than N, where N is something like 3-6 filenames. Otherwise the requirement to sort the names alphabetically pretty much mandates that many lines of the file will change just to insert one or two new files, and that makes it all but impossible to figure out from a diff what actually changed. -- Ian > [...] > -SUBDIR= lib .WAIT \ > - svn svnadmin svnbench svndumpfilter svnfsfs svnlook svnserve \ > - svnsync svnversion svnmucc svnrdump > +SUBDIR= lib \ > + .WAIT \ > + svn \ > + svnadmin \ > + svnbench \ > + svndumpfilter \ > + svnfsfs \ > + svnlook \ > + svnserve \ > + svnsync \ > + svnversion \ > + svnmucc \ > + svnrdump > SUBDIR_PARALLEL= > ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r361275 - in head/sys: conf dev/hyperv/hvsock dev/hyperv/include dev/hyperv/vmbus modules/hyperv modules/hyperv/hvsock sys
On Thu, 2020-05-21 at 01:53 +, Wei Hu wrote: > > -Original Message- > > From: Enji Cooper > > Sent: Wednesday, May 20, 2020 11:58 PM > > To: Shawn Webb > > Cc: Wei Hu ; src-committ...@freebsd.org; svn-src- > > a...@freebsd.org; svn-src-head@freebsd.org > > Subject: Re: svn commit: r361275 - in head/sys: conf dev/hyperv/hvsock > > dev/hyperv/include dev/hyperv/vmbus modules/hyperv > > modules/hyperv/hvsock sys > > > > > > > On May 20, 2020, at 08:54, Enji Cooper wrote: > > > > > > > > On May 20, 2020, at 08:11, Shawn Webb > > > > wrote: > > > > > > > > > > On Wed, May 20, 2020 at 11:03:59AM +, Wei Hu wrote: > > > > > Author: whu > > > > > Date: Wed May 20 11:03:59 2020 > > > > > New Revision: 361275 > > > > > URL: > > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsv > > > > > > > > > nweb.freebsd.org%2Fchangeset%2Fbase%2F361275&data=02%7C01%7C > > weh% > > > > > > > > > 40microsoft.com%7Cd6ff3617bffa43d10a7708d7fcd68470%7C72f988bf86f141 > > a > > > > > > > > > f91ab2d7cd011db47%7C1%7C0%7C637255870581110888&sdata=mzz6R > > ILCVBk > > > > > q06RI1PAfVNKWZO2y7jBO0C1E%2F%2FEJwUY%3D&reserved=0 > > > > > > > > > > Log: > > > > > HyperV socket implementation for FreeBSD > > > > > > > > > > This change adds Hyper-V socket feature in FreeBSD. New socket > > > > > address family AF_HYPERV and its kernel support are added. > > > > > > Hi Wei, > > >Could you please further describe what this feature is/does? > > > > I realize after looking at the review that it contains the content I > > was hoping > > for. It would have been helpful to folks if this context had been included > > in the > > commit message. > > Hi Enji, > > I thought I just keep it simple for the commit log message while people can > refer to the review site for details. Sorry about that. Let me know if there > is > anyway to make up for it. > > Wei > Ten years from now, phabricator may just be a fading memory, but the source code repo lives forever. Usually when I put something in phab for review, the description I enter in phab is exactly the text I intend to use when committing the change. That helps the people doing the review... the description is an overview of what is being changed, and most importantly, why it is being changed (fixes a bug, adds a new feature, better performance, etc). Everything you say there to help reviewers will be equally helpful in the repo history when someone needs to research some day why a change got made. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r361209 - head/sys/netinet
On Mon, 2020-05-18 at 23:01 +0200, Michael Tuexen wrote: > > On 18. May 2020, at 22:48, Ian Lepore wrote: > > > > On Mon, 2020-05-18 at 22:43 +0200, Michael Tuexen wrote: > > > > Sure. You can certainly ignore user reports corresponding to > > > > bogus > > > > flags, though, and encourage use of various flags. > > > > > > I could, but decided to improve the situation for some people, > > > but > > > wasn't realising that I made it worse for others. Sorry about > > > that. > > > > I'm trying to figure out why your original commit was a problem. I > > understand why it was questioned, but once the answer came out, > > it's > > clear that the code you originally committed does what it's > > supposed to > > without any harmful side effects. Sure, freebsd doesn't strictly > > need > > I guess the point Conrad is making, that on FreeBSD the check is not > needed, since the call can not fail. So the FreeBSD code base would > not > be consistent: within the SCTP related code the return code is > checked, > in the other code it is not. > > it, but the code is shared among projects, so what's the harm in > > the > > extra check that helps other projects sharing the code? It's > > certainly > > a lot less confusion and code clutter than any of the "remedies" > > that > > have been discussed. > > Yepp, sharing code between platforms makes things harder. Running the > same > code in kernel land and userland does not make it simpler. Different > groups > have different opinions/styles/... > > I'll revert the commit tomorrow and a variadic macros > SCTP_SNPRINTF(), which > will map on FreeBSD to snprintf() and on the other platforms will do > the check. > > If the build problem comes up on FreeBSD userland (and I have no idea > if that > is the case, since I don't know how Firefox / Chrome are build on > FreeBSD), > I leave it up to the port maintainer of the application to deal with > it. > > Best regards > Michael > > > > -- Ian > > > > Well it seems to me you're being asked to do a lot of extra work that has the final result of making the code LESS clear and MORE complex, because of one person's opinion. I'm actually a bit tempted to complain about the change, because to me it reduces rather than improves code quality. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r361209 - head/sys/netinet
On Mon, 2020-05-18 at 22:43 +0200, Michael Tuexen wrote: > > Sure. You can certainly ignore user reports corresponding to bogus > > flags, though, and encourage use of various flags. > > I could, but decided to improve the situation for some people, but > wasn't realising that I made it worse for others. Sorry about that. I'm trying to figure out why your original commit was a problem. I understand why it was questioned, but once the answer came out, it's clear that the code you originally committed does what it's supposed to without any harmful side effects. Sure, freebsd doesn't strictly need it, but the code is shared among projects, so what's the harm in the extra check that helps other projects sharing the code? It's certainly a lot less confusion and code clutter than any of the "remedies" that have been discussed. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r360033 - head/tests/sys/kqueue/libkqueue
On Fri, 2020-04-17 at 02:22 +, Kyle Evans wrote:
> Author: kevans
> Date: Fri Apr 17 02:22:15 2020
> New Revision: 360033
> URL: https://svnweb.freebsd.org/changeset/base/360033
>
> Log:
> tests: kqueue: use a more precise timer for the NOTE_ABSTIME test
>
> Originally noticed while attempting to run the kqueue tests under
> qemu-user-static, this apparently just happens sometimes when running in a
> jail in general -- the timer will fire off "too early," but it's really just
> the result of imprecise measurements (noted by cem).
>
> Kicking this over to NOTE_USECONDS still tests the correct thing while
> allowing it to work more consistently; a basic sanity test reveals that we
> often end up coming in just less than 200 microseconds after the timer
> fired off.
>
> MFC after: 3 days
>
> Modified:
> head/tests/sys/kqueue/libkqueue/timer.c
>
> Modified: head/tests/sys/kqueue/libkqueue/timer.c
> ==
> --- head/tests/sys/kqueue/libkqueue/timer.c Fri Apr 17 02:21:46 2020
> (r360032)
> +++ head/tests/sys/kqueue/libkqueue/timer.c Fri Apr 17 02:22:15 2020
> (r360033)
> @@ -216,17 +216,17 @@ test_abstime(void)
> {
> const char *test_id = "kevent(EVFILT_TIMER, EV_ONESHOT, NOTE_ABSTIME)";
> struct kevent kev;
> -time_t start;
> -time_t stop;
> -const int timeout = 3;
> +long end, start, stop;
> +const int timeout_sec = 3;
>
> test_begin(test_id);
>
> test_no_kevents();
>
> -start = time(NULL);
> +start = now();
> +end = start + SEC_TO_US(timeout_sec);
> EV_SET(&kev, vnode_fd, EVFILT_TIMER, EV_ADD | EV_ONESHOT,
> - NOTE_ABSTIME | NOTE_SECONDS, start + timeout, NULL);
> + NOTE_ABSTIME | NOTE_USECONDS, end, NULL);
> if (kevent(kqfd, &kev, 1, NULL, 0, NULL) < 0)
> err(1, "%s", test_id);
>
> @@ -235,10 +235,10 @@ test_abstime(void)
> kev.data = 1;
> kev.fflags = 0;
> kevent_cmp(&kev, kevent_get(kqfd));
> -stop = time(NULL);
> -if (stop < start + timeout)
> -err(1, "too early %jd %jd", (intmax_t)stop, (intmax_t)(start +
> timeout));
>
> +stop = now();
> +if (stop < end)
> +err(1, "too early %jd %jd", (intmax_t)stop, (intmax_t)end);
> /* Check if the event occurs again */
> sleep(3);
> test_no_kevents();
Not caused by you, but this change made me notice: using 'long' to
hold the number of microseconds since the unix epoch will only work on
amd64 and arm64. Everything involved with that needs to use uint64_t
to work on all arches.
-- Ian
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r359949 - head/usr.sbin/bhyve
On Wed, 2020-04-15 at 08:30 -0400, Shawn Webb wrote: > On Wed, Apr 15, 2020 at 01:58:51AM +, Conrad Meyer wrote: > > Author: cem > > Date: Wed Apr 15 01:58:51 2020 > > New Revision: 359949 > > URL: https://svnweb.freebsd.org/changeset/base/359949 > > > > Log: > > bhyve(8): Add bootrom allocation abstraction > > > > To allow more general use of the bootrom region, separate initialization > > from > > allocation, and allocation from loading a file. > > > > The bootrom segment is the high 16MB of the low 4GB region. > > > > Each allocation in the segment creates a new mapping with specified > > protection. > > By default, allocation begins at the low end of the range. However, the > > BOOTROM_ALLOC_TOP flag is provided to locate a provided bootrom in the > > high > > region it is expected to be in. > > > > The existing ROM-file loading code is refactored to use the new interface. > > > > Reviewed by: grehan (earlier version) > > Differential Revision:https://reviews.freebsd.org/D24422 > > Hey Conrad, > > Is there any way you'd have a change of heart and support MFC'ing? I'm > sure many people, including myself, would be ever so grateful not to > have to maintain their own MFC's of your work. > > Thanks, > There are multiple people involved in maintaining bhyve, you can ask any of them (or, really, any committer at all) to MFC things. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r359797 - in head/sys: net netinet netinet6
On Sat, 2020-04-11 at 13:02 -0700, Conrad Meyer wrote:
> Hi Alexander,
>
> On Sat, Apr 11, 2020 at 12:37 AM Alexander V. Chernikov
> wrote:
> >
> > Author: melifaro
> > Date: Sat Apr 11 07:37:08 2020
> > New Revision: 359797
> > URL: https://svnweb.freebsd.org/changeset/base/359797
> >
> > Log:
> > Remove per-AF radix_mpath initializtion functions.
> >
> > Split their functionality by moving random seed allocation
> >to SYSINIT and calling (new) generic multipath function from
> >standard IPv4/IPv5 RIB init handlers.
> > ...
> > --- head/sys/net/radix_mpath.c Sat Apr 11 07:31:16
> > 2020(r359796)
> > +++ head/sys/net/radix_mpath.c Sat Apr 11 07:37:08
> > 2020(r359797)
> > @@ -290,38 +290,18 @@ rtalloc_mpath_fib(struct route *ro, uint32_t
> > hash, u_i
> > ...
> > +static void
> > +mpath_init(void)
> > {
> > - struct rib_head *rnh;
> >
> > hashjitter = arc4random();
> > - if (in6_inithead(head, off, fibnum) == 1) {
> > - rnh = (struct rib_head *)*head;
> > - rnh->rnh_multipath = 1;
> > - return 1;
> > - } else
> > - return 0;
> > }
> > +SYSINIT(mpath_init, SI_SUB_PROTO_DOMAIN, SI_ORDER_ANY, mpath_init,
> > NULL);
>
> This is pretty early in boot to be asking for random numbers. We
> don't have interrupts yet, for example. If the system doesn't have a
> saved /boot/entropy loaded (PPC, or installer, or some other embedded
> system perhaps), we will either deadlock boot or get not especially
> random numbers here (depending on availability behavior of arc4random
> — currently we err on the side of low quality random numbers).
>
> If this number is predictable to an attacker, is it easier to DoS the
> system? Do we need the random number before userspace starts? (I
> would imagine networking does not really start chatting with remote
> hosts prior to userspace boot, but this is just a guess.)
>
> Best,
> Conrad
>
I believe the earliest use of networking during boot is for mounting
the rootfs using nfs. So SI_SUB_ROOT_CONF-1 might be good.
-- Ian
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r359685 - in head: . etc lib/libc/gen share/mk share/termcap usr.bin/login usr.bin/vgrind usr.sbin/services_mkdb
On Thu, 2020-04-09 at 16:16 -0700, Rodney W. Grimes wrote: > > Well, how many FreeBSD builds have you run in the last year, Rodney, > > personally to care about 0.1s slowdown that it might have caused? We've run > > at least a 1,000 here, probably 3x more. > > That is a non technical personal attack. > > > So yes, the cost is there, the > > cost is well understood and found negligible versus the benefit of having a > > slightly more extensible build system that is slightly easier to understand > > and integrate into bigger projects. > > I do not see how moving 5 values adds any extensibility or any ease of use, > or intergratability. It added an ease of editing the values to one file, > values that *should not be edited inplace*. > > If these values need overridden it should always be done on the make command > line, especially by projects external to FreeBSD. Your "extensible build > system" > is reaching into internal project build infustructure in a non-supportable way > if it requires this types of change. > You did not look at the changes carefully enough. This doesn't just gather some values into one place, it replaces instances of hard-coded tool names with variables. To do so, those variables need to be defined somewhere. A new src.tools.mk is a good sensible place for that. Now that you have them all in once place, it doesn't make sense to still have duplicate definitions in other places, everything should refer to the one new source. You have focused in on that last sentence and started complaining about it as if it were the entire change. It's just a minor cleanup which is the natural thing to do given the rest of the change. And the rest of the change is useful in exactly the ways Maxim is saying (I say that as someone who also maintains a large proprietary source base that uses the freebsd build infrastructure). -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r359633 - head/share/man/man4
On Sat, 2020-04-04 at 17:10 -0700, Rodney W. Grimes wrote: > > Author: brueffer > > Date: Sat Apr 4 21:38:00 2020 > > New Revision: 359633 > > URL: https://svnweb.freebsd.org/changeset/base/359633 > > > > Log: > >Add a manpage for smbios(4). > > > >Submitted by: Gordon Bergling > > There should be an AUTHORS section entry for him writting the man > page. Is that not optional? I've never added one to any manpage I've ever written, and don't especially want it to be added. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r359574 - in head/sys: arm/xilinx conf
Author: ian
Date: Thu Apr 2 19:06:05 2020
New Revision: 359574
URL: https://svnweb.freebsd.org/changeset/base/359574
Log:
Add the Cadence GEM ethernet driver to NOTES so that it gets built with
LINT kernels. Move the config for it from files. files into the
main config (conf/files), because it works on multiple platforms now.
Modified:
head/sys/arm/xilinx/files.zynq7
head/sys/conf/NOTES
head/sys/conf/files
head/sys/conf/files.riscv
Modified: head/sys/arm/xilinx/files.zynq7
==
--- head/sys/arm/xilinx/files.zynq7 Thu Apr 2 18:37:15 2020
(r359573)
+++ head/sys/arm/xilinx/files.zynq7 Thu Apr 2 19:06:05 2020
(r359574)
@@ -9,7 +9,6 @@ arm/xilinx/zy7_slcr.c standard
arm/xilinx/zy7_devcfg.cstandard
arm/xilinx/zy7_mp.coptional smp
-dev/cadence/if_cgem.c optional cgem
arm/xilinx/zy7_ehci.c optional ehci
arm/xilinx/uart_dev_cdnc.c optional uart
arm/xilinx/zy7_gpio.c optional gpio
Modified: head/sys/conf/NOTES
==
--- head/sys/conf/NOTES Thu Apr 2 18:37:15 2020(r359573)
+++ head/sys/conf/NOTES Thu Apr 2 19:06:05 2020(r359574)
@@ -1786,6 +1786,7 @@ deviceaxphy # Asix Semiconductor AX88x9x
device bmtphy # Broadcom BCM5201/BCM5202 and 3Com 3c905C
device bnxt# Broadcom NetXtreme-C/NetXtreme-E
device brgphy # Broadcom BCM54xx/57xx 1000baseTX
+device cgem# Cadence GEM Gigabit Ethernet
device ciphy # Cicada/Vitesse CS/VSC8xxx
device e1000phy# Marvell 88E1000 1000/100/10-BT
device gentbi # Generic 10-bit 1000BASE-{LX,SX} fiber ifaces
Modified: head/sys/conf/files
==
--- head/sys/conf/files Thu Apr 2 18:37:15 2020(r359573)
+++ head/sys/conf/files Thu Apr 2 19:06:05 2020(r359574)
@@ -1351,6 +1351,7 @@ dev/bwn/if_bwn_phy_g.coptional bwn bhnd
dev/bwn/if_bwn_phy_lp.coptional bwn bhnd
dev/bwn/if_bwn_phy_n.c optional bwn bhnd
dev/bwn/if_bwn_util.c optional bwn bhnd
+dev/cadence/if_cgem.c optional cgem fdt
dev/cardbus/cardbus.c optional cardbus
dev/cardbus/cardbus_cis.c optional cardbus
dev/cardbus/cardbus_device.c optional cardbus
Modified: head/sys/conf/files.riscv
==
--- head/sys/conf/files.riscv Thu Apr 2 18:37:15 2020(r359573)
+++ head/sys/conf/files.riscv Thu Apr 2 19:06:05 2020(r359574)
@@ -4,7 +4,6 @@ cddl/dev/dtrace/riscv/dtrace_subr.c
optional dtrace
cddl/dev/fbt/riscv/fbt_isa.c optional dtrace_fbt |
dtraceall compile-with "${FBT_C}"
crypto/blowfish/bf_enc.c optionalcrypto | ipsec | ipsec_support
crypto/des/des_enc.c optionalcrypto | ipsec | ipsec_support
| netsmb
-dev/cadence/if_cgem.c optionalcgem
dev/ofw/ofw_cpu.c optionalfdt
dev/ofw/ofwpci.c optionalpci fdt
dev/pci/pci_host_generic.c optionalpci
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r359571 - head/sys/dev/cadence
Author: ian
Date: Thu Apr 2 17:57:40 2020
New Revision: 359571
URL: https://svnweb.freebsd.org/changeset/base/359571
Log:
Cadence GEM ethernet driver style clean-up, no functional changes.
This is mostly indentation whitespace, and reflowing a few multiline
comments. This gets a bunch of minor stuff out of the way so that the diffs
for style don't clutter up the diffs for some upcoming functional changes.
Submitted by: Thomas Skibo
Differential Revision:https://reviews.freebsd.org/D24226
Modified:
head/sys/dev/cadence/if_cgem.c
head/sys/dev/cadence/if_cgem_hw.h
Modified: head/sys/dev/cadence/if_cgem.c
==
--- head/sys/dev/cadence/if_cgem.c Thu Apr 2 17:22:16 2020
(r359570)
+++ head/sys/dev/cadence/if_cgem.c Thu Apr 2 17:57:40 2020
(r359571)
@@ -112,8 +112,8 @@ struct cgem_softc {
device_tmiibus;
u_int mii_media_active; /* last active media */
int if_old_flags;
- struct resource *mem_res;
- struct resource *irq_res;
+ struct resource *mem_res;
+ struct resource *irq_res;
void*intrhand;
struct callout tick_ch;
uint32_tnet_ctl_shadow;
@@ -131,7 +131,7 @@ struct cgem_softc {
int rxring_hd_ptr; /* where to put rcv bufs */
int rxring_tl_ptr; /* where to get receives */
int rxring_queued; /* how many rcv bufs queued */
- bus_dmamap_trxring_dma_map;
+ bus_dmamap_trxring_dma_map;
int rxbufs; /* tunable number rcv bufs */
int rxhangwar; /* rx hang work-around */
u_int rxoverruns; /* rx overruns */
@@ -200,16 +200,15 @@ struct cgem_softc {
} stats;
};
-#define RD4(sc, off) (bus_read_4((sc)->mem_res, (off)))
-#define WR4(sc, off, val) (bus_write_4((sc)->mem_res, (off), (val)))
+#define RD4(sc, off) (bus_read_4((sc)->mem_res, (off)))
+#define WR4(sc, off, val) (bus_write_4((sc)->mem_res, (off), (val)))
#define BARRIER(sc, off, len, flags) \
(bus_barrier((sc)->mem_res, (off), (len), (flags))
#define CGEM_LOCK(sc) mtx_lock(&(sc)->sc_mtx)
-#define CGEM_UNLOCK(sc)mtx_unlock(&(sc)->sc_mtx)
-#define CGEM_LOCK_INIT(sc) \
- mtx_init(&(sc)->sc_mtx, device_get_nameunit((sc)->dev), \
-MTX_NETWORK_LOCK, MTX_DEF)
+#define CGEM_UNLOCK(sc)mtx_unlock(&(sc)->sc_mtx)
+#define CGEM_LOCK_INIT(sc) mtx_init(&(sc)->sc_mtx, \
+ device_get_nameunit((sc)->dev), MTX_NETWORK_LOCK, MTX_DEF)
#define CGEM_LOCK_DESTROY(sc) mtx_destroy(&(sc)->sc_mtx)
#define CGEM_ASSERT_LOCKED(sc) mtx_assert(&(sc)->sc_mtx, MA_OWNED)
@@ -259,9 +258,8 @@ cgem_get_mac(struct cgem_softc *sc, u_char eaddr[])
eaddr[5] = rnd & 0xff;
device_printf(sc->dev, "no mac address found, assigning "
- "random: %02x:%02x:%02x:%02x:%02x:%02x\n",
- eaddr[0], eaddr[1], eaddr[2],
- eaddr[3], eaddr[4], eaddr[5]);
+ "random: %02x:%02x:%02x:%02x:%02x:%02x\n", eaddr[0],
+ eaddr[1], eaddr[2], eaddr[3], eaddr[4], eaddr[5]);
}
/* Move address to first slot and zero out the rest. */
@@ -275,11 +273,11 @@ cgem_get_mac(struct cgem_softc *sc, u_char eaddr[])
}
}
-/* cgem_mac_hash(): map 48-bit address to a 6-bit hash.
- * The 6-bit hash corresponds to a bit in a 64-bit hash
- * register. Setting that bit in the hash register enables
- * reception of all frames with a destination address that hashes
- * to that 6-bit value.
+/*
+ * cgem_mac_hash(): map 48-bit address to a 6-bit hash. The 6-bit hash
+ * corresponds to a bit in a 64-bit hash register. Setting that bit in the
hash
+ * register enables reception of all frames with a destination address that
+ * hashes to that 6-bit value.
*
* The hash function is described in sec. 16.2.3 in the Zynq-7000 Tech
* Reference Manual. Bits 0-5 in the hash are the exclusive-or of
@@ -308,15 +306,16 @@ cgem_hash_maddr(void *arg, struct sockaddr_dl *sdl, u_
index = cgem_mac_hash(LLADDR(sdl));
if (index > 31)
- hashes[0] |= (1 << (index - 32));
+ hashes[0] |= (1U << (index - 32));
else
- hashes[1] |= (1 << index);
+ hashes[1] |= (1U << index);
return (1);
}
-/* After any change in rx flags or multi-cast addresses, set up
- * hash registers and net config register bits.
+/*
+ * After any change in rx flags or multi-cast addresses, set up hash registers
+ * and net config register bits.
*/
sta
svn commit: r359423 - head/sys/arm/include
Author: ian Date: Sun Mar 29 17:30:08 2020 New Revision: 359423 URL: https://svnweb.freebsd.org/changeset/base/359423 Log: Add a missing suffix that was causing a whole word to get loaded instead of the proper 8 or 16 bits when the macro was expanded for those sizes. Fixes a hang in the armv7 kernel. Submitted by: Thomas Skibo Pointy hat: ian@ Modified: head/sys/arm/include/atomic-v6.h Modified: head/sys/arm/include/atomic-v6.h == --- head/sys/arm/include/atomic-v6.hSun Mar 29 15:43:00 2020 (r359422) +++ head/sys/arm/include/atomic-v6.hSun Mar 29 17:30:08 2020 (r359423) @@ -196,7 +196,7 @@ ATOMIC_ACQ_REL_LONG(clear) \ __asm __volatile( \ "1: ldrex" SUF " %[tmp], [%[ptr]] \n" \ - " ldr%[ret], [%[oldv]] \n" \ + " ldr" SUF " %[ret], [%[oldv]] \n" \ " teq%[tmp], %[ret]\n" \ " ittee ne\n" \ " str" SUF "ne %[tmp], [%[oldv]] \n" \ ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r359053 - head/sys/kern
On Wed, 2020-03-18 at 22:36 +0200, Konstantin Belousov wrote:
> On Tue, Mar 17, 2020 at 07:25:01PM -0600, Ian Lepore wrote:
> > On Tue, 2020-03-17 at 17:05 -0700, John Baldwin wrote:
> > > On 3/17/20 3:36 PM, Ian Lepore wrote:
> > > > On Tue, 2020-03-17 at 22:27 +, Conrad Meyer wrote:
> > > > > Author: cem
> > > > > Date: Tue Mar 17 22:27:16 2020
> > > > > New Revision: 359053
> > > > > URL: https://svnweb.freebsd.org/changeset/base/359053
> > > > >
> > > > > Log:
> > > > > Implement sysctl kern.boot_id
> > > > >
> > > > > Boot IDs are random, opaque 128-bit identifiers that
> > > > > distinguish distinct
> > > > > system boots. A new ID is generated each time the system
> > > > > boots. Unlike
> > > > > kern.boottime, the value is not modified by NTP
> > > > > adjustments. It remains fixed
> > > > > until the machine is restarted.
> > > > >
> > > > > PR: 244867
> > > > > Reported by:Ricardo Fraile
> > > > > MFC after: I do not intend to, but feel free
> > > > >
> > > > > Modified:
> > > > > head/sys/kern/kern_mib.c
> > > > >
> > > > > Modified: head/sys/kern/kern_mib.c
> > > > > =
> > > > >
> > > > > =
> > > > > --- head/sys/kern/kern_mib.c Tue Mar 17 21:29:03 2020(
> > > > > r359052)
> > > > > +++ head/sys/kern/kern_mib.c Tue Mar 17 22:27:16 2020(
> > > > > r359053)
> > > > > @@ -448,6 +448,32 @@ SYSCTL_PROC(_kern, KERN_HOSTID, hostid,
> > > > > CTLTYPE_ULONG | CTLFLAG_RW | CTLFLAG_PRISON |
> > > > > CTLFLAG_MPSAFE
> > > > > > CTLFLAG_CAPRD,
> > > > >
> > > > > NULL, 0, sysctl_hostid, "LU", "Host ID");
> > > > >
> > > > > +static struct mtx bootid_lk;
> > > > > +MTX_SYSINIT(bootid_lock, &bootid_lk, "bootid generator
> > > > > lock",
> > > > > MTX_DEF);
> > > > > +
> > > > > +static int
> > > > > +sysctl_bootid(SYSCTL_HANDLER_ARGS)
> > > > > +{
> > > > > + static uint8_t boot_id[16];
> > > > > + static bool initialized = false;
> > > > > +
> > > > > + mtx_lock(&bootid_lk);
> > > > > + if (!initialized) {
> > > > > + if (!is_random_seeded()) {
> > > > > + mtx_unlock(&bootid_lk);
> > > > > + return (ENXIO);
> > > > > + }
> > > > > + arc4random_buf(boot_id, sizeof(boot_id));
> > > > > + initialized = true;
> > > > > + }
> > > > > + mtx_unlock(&bootid_lk);
> > > > > +
> > > > > + return (SYSCTL_OUT(req, boot_id, sizeof(boot_id)));
> > > > > +}
> > > > > +SYSCTL_PROC(_kern, OID_AUTO, boot_id,
> > > > > +CTLTYPE_STRUCT | CTLFLAG_RD | CTLFLAG_MPSAFE |
> > > > > CTLFLAG_CAPRD,
> > > > > +NULL, 0, sysctl_bootid, "", "Random boot ID");
> > > > > +
> > > > > /*
> > > > > * The osrelease string is copied from the global (osrelease
> > > > > in
> > > > > vers.c) into
> > > > > * prison0 by a sysinit and is inherited by child jails if
> > > > > notG
> > > > > changed at jail
> > > >
> > > > This seems a bit complex. Why run a sysinit to init a mutex so
> > > > that
> > > > you can safely do a lazy init of boot_id? Seems like it would
> > > > be
> > > > much
> > > > easier to just use a sysinit at SI_SUB_LAST to init boot_id
> > > > before
> > > > sysctl can reference it.
> > >
> > > Presumably you may not have enough entropy by SI_SUB_LAST to
> > > generate
> > > it?
> > >
> >
> > I thought arc4random in the kernel could provide random numbers
> > immediately (and definitely after jitter in device attachment times
> > at
> > the end of kernel init)? This doesn't seem like the kind of thing
> > that
> > needs crypto-strength randomness.
>
> I think that a large simplification can come from the random driver
> initializing the boot_id variable immediately before setting things
> so that is_random_seeded() start returning true.
>
> But even this might be too complex, Why not copy the value from the
> boottime on boot, and not ever touch it after.
On some systems (virtually all mips, arm, and some arm64 systems),
there is no RTC and boottime doesn't get set initially until ntpd or
something else in userland runs to set time.
-- Ian
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r359053 - head/sys/kern
On Tue, 2020-03-17 at 17:05 -0700, John Baldwin wrote:
> On 3/17/20 3:36 PM, Ian Lepore wrote:
> > On Tue, 2020-03-17 at 22:27 +, Conrad Meyer wrote:
> > > Author: cem
> > > Date: Tue Mar 17 22:27:16 2020
> > > New Revision: 359053
> > > URL: https://svnweb.freebsd.org/changeset/base/359053
> > >
> > > Log:
> > > Implement sysctl kern.boot_id
> > >
> > > Boot IDs are random, opaque 128-bit identifiers that
> > > distinguish distinct
> > > system boots. A new ID is generated each time the system
> > > boots. Unlike
> > > kern.boottime, the value is not modified by NTP
> > > adjustments. It remains fixed
> > > until the machine is restarted.
> > >
> > > PR: 244867
> > > Reported by:Ricardo Fraile
> > > MFC after: I do not intend to, but feel free
> > >
> > > Modified:
> > > head/sys/kern/kern_mib.c
> > >
> > > Modified: head/sys/kern/kern_mib.c
> > > =
> > > =
> > > --- head/sys/kern/kern_mib.c Tue Mar 17 21:29:03 2020(
> > > r359052)
> > > +++ head/sys/kern/kern_mib.c Tue Mar 17 22:27:16 2020(
> > > r359053)
> > > @@ -448,6 +448,32 @@ SYSCTL_PROC(_kern, KERN_HOSTID, hostid,
> > > CTLTYPE_ULONG | CTLFLAG_RW | CTLFLAG_PRISON | CTLFLAG_MPSAFE
> > > | CTLFLAG_CAPRD,
> > > NULL, 0, sysctl_hostid, "LU", "Host ID");
> > >
> > > +static struct mtx bootid_lk;
> > > +MTX_SYSINIT(bootid_lock, &bootid_lk, "bootid generator lock",
> > > MTX_DEF);
> > > +
> > > +static int
> > > +sysctl_bootid(SYSCTL_HANDLER_ARGS)
> > > +{
> > > + static uint8_t boot_id[16];
> > > + static bool initialized = false;
> > > +
> > > + mtx_lock(&bootid_lk);
> > > + if (!initialized) {
> > > + if (!is_random_seeded()) {
> > > + mtx_unlock(&bootid_lk);
> > > + return (ENXIO);
> > > + }
> > > + arc4random_buf(boot_id, sizeof(boot_id));
> > > + initialized = true;
> > > + }
> > > + mtx_unlock(&bootid_lk);
> > > +
> > > + return (SYSCTL_OUT(req, boot_id, sizeof(boot_id)));
> > > +}
> > > +SYSCTL_PROC(_kern, OID_AUTO, boot_id,
> > > +CTLTYPE_STRUCT | CTLFLAG_RD | CTLFLAG_MPSAFE |
> > > CTLFLAG_CAPRD,
> > > +NULL, 0, sysctl_bootid, "", "Random boot ID");
> > > +
> > > /*
> > > * The osrelease string is copied from the global (osrelease in
> > > vers.c) into
> > > * prison0 by a sysinit and is inherited by child jails if not
> > > changed at jail
> >
> > This seems a bit complex. Why run a sysinit to init a mutex so
> > that
> > you can safely do a lazy init of boot_id? Seems like it would be
> > much
> > easier to just use a sysinit at SI_SUB_LAST to init boot_id before
> > sysctl can reference it.
>
> Presumably you may not have enough entropy by SI_SUB_LAST to generate
> it?
>
I thought arc4random in the kernel could provide random numbers
immediately (and definitely after jitter in device attachment times at
the end of kernel init)? This doesn't seem like the kind of thing that
needs crypto-strength randomness.
-- Ian
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r359053 - head/sys/kern
On Tue, 2020-03-17 at 22:27 +, Conrad Meyer wrote:
> Author: cem
> Date: Tue Mar 17 22:27:16 2020
> New Revision: 359053
> URL: https://svnweb.freebsd.org/changeset/base/359053
>
> Log:
> Implement sysctl kern.boot_id
>
> Boot IDs are random, opaque 128-bit identifiers that distinguish distinct
> system boots. A new ID is generated each time the system boots. Unlike
> kern.boottime, the value is not modified by NTP adjustments. It remains
> fixed
> until the machine is restarted.
>
> PR: 244867
> Reported by:Ricardo Fraile
> MFC after: I do not intend to, but feel free
>
> Modified:
> head/sys/kern/kern_mib.c
>
> Modified: head/sys/kern/kern_mib.c
> ==
> --- head/sys/kern/kern_mib.c Tue Mar 17 21:29:03 2020(r359052)
> +++ head/sys/kern/kern_mib.c Tue Mar 17 22:27:16 2020(r359053)
> @@ -448,6 +448,32 @@ SYSCTL_PROC(_kern, KERN_HOSTID, hostid,
> CTLTYPE_ULONG | CTLFLAG_RW | CTLFLAG_PRISON | CTLFLAG_MPSAFE |
> CTLFLAG_CAPRD,
> NULL, 0, sysctl_hostid, "LU", "Host ID");
>
> +static struct mtx bootid_lk;
> +MTX_SYSINIT(bootid_lock, &bootid_lk, "bootid generator lock", MTX_DEF);
> +
> +static int
> +sysctl_bootid(SYSCTL_HANDLER_ARGS)
> +{
> + static uint8_t boot_id[16];
> + static bool initialized = false;
> +
> + mtx_lock(&bootid_lk);
> + if (!initialized) {
> + if (!is_random_seeded()) {
> + mtx_unlock(&bootid_lk);
> + return (ENXIO);
> + }
> + arc4random_buf(boot_id, sizeof(boot_id));
> + initialized = true;
> + }
> + mtx_unlock(&bootid_lk);
> +
> + return (SYSCTL_OUT(req, boot_id, sizeof(boot_id)));
> +}
> +SYSCTL_PROC(_kern, OID_AUTO, boot_id,
> +CTLTYPE_STRUCT | CTLFLAG_RD | CTLFLAG_MPSAFE | CTLFLAG_CAPRD,
> +NULL, 0, sysctl_bootid, "", "Random boot ID");
> +
> /*
> * The osrelease string is copied from the global (osrelease in vers.c) into
> * prison0 by a sysinit and is inherited by child jails if not changed at
> jail
This seems a bit complex. Why run a sysinit to init a mutex so that
you can safely do a lazy init of boot_id? Seems like it would be much
easier to just use a sysinit at SI_SUB_LAST to init boot_id before
sysctl can reference it.
-- Ian
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r359005 - head/usr.bin/calendar/calendars
On Sun, 2020-03-15 at 15:12 -0700, Conrad Meyer wrote: [...] > Sarcasm doesn't work on the internet. Do you mean things like... > URL: https://svnweb.freebsd.org/changeset/base/358562 > > Log: > Add extremely useful calendar(1) application to FreeBSD > > It does extremely useful things like execute sendmail and spew dubiously > accurate factoids. > > From the feedback, it seems like it is an essential utility in a modern unix > and not at all a useless bikeshed. How do those Linux people live without > it? > Reverts r358561. Because I have to agree, that sure didn't work for me. Neither do hypocritical holier-than-thou proclamations, or attempts to wrap one's self in the mantle of victimhood after having behaved as a confrontational aggressor. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r358891 - head/share/man/man5
On Wed, 2020-03-11 at 16:37 -0400, Ed Maste wrote: > On Wed, 11 Mar 2020 at 16:27, Ian Lepore wrote: > > > > With, there are 3 extra spaces. "Sy ". > > Right, I mean the extraneous Sy had the side effect of improving (in > my opinion) the rendered table. Anyhow, they're removed now. Well, my point is that it looked better because there were 3 extra spaces, so you can get that spacing by adding 3 extra chars to the column headings in the .Bl line. They don't have be "Sy " at the front, I think just spaces at the end of each heading (inside the quotes) would do it. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r358891 - head/share/man/man5
On Wed, 2020-03-11 at 16:01 -0400, Ed Maste wrote: > On Wed, 11 Mar 2020 at 15:07, Mateusz Piotrowski <0...@freebsd.org> > wrote: > > > > Hi, > > > > On 3/11/20 7:15 PM, Ed Maste wrote: > > > Author: emaste > > > Date: Wed Mar 11 18:15:18 2020 > > > New Revision: 358891 > > > URL: https://svnweb.freebsd.org/changeset/base/358891 > > > > > > Log: > > >elf.5: start documenting ELF note sections > > > > ... > > > Modified: head/share/man/man5/elf.5 > > > = > > > = > > > --- head/share/man/man5/elf.5 Wed Mar 11 15:12:31 > > > 2020(r358890) > > > +++ head/share/man/man5/elf.5 Wed Mar 11 18:15:18 > > > 2020(r358891) > > > @@ -24,7 +24,7 @@ > > > > ... > > > +.Bl -column -offset indent "Sy Field" "Sy Size" "Sy Description" > > > > The "Sy" macros can be dropped from those strings specifying the > > width > > of columns. They are not expanded there anyway. > > Interesting, thanks for the note. I probably copied them from arch.7, > so it might need similar treatment. > > They did have a side-effect of putting more space between columns > though; with extra Sy: > >Field Size Description >namesz 32 bitsSize of name >descsz 32 bitsSize of desc >type32 bitsOS-dependent note type >namenamesz Null-terminated originator name >descdescsz OS-dependent note data > > Without: > >FieldSizeDescription >namesz 32 bits Size of name >descsz 32 bits Size of desc >type 32 bits OS-dependent note type >name namesz Null-terminated originator name >desc descsz OS-dependent note data With, there are 3 extra spaces. "Sy ". -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r358411 - head/contrib/sendmail/src
On Mon, 2020-03-02 at 03:39 +0700, Eugene Grosbein wrote: > 02.03.2020 3:07, Ian Lepore wrote: > > > > You can easily repeat the problem using recent ports tree and > > > recent > > > stable/11 and handbook-recommended way. > > > > > > > And why can't you use the mail/sendmail port with the SSL options > > set > > the same as for other ports? > > That's not about possible work-arounds that are numerous. > That's about our Handbook and fixing what was not broken before. > Oh, so you're not actually looking for a solution, you just want to complain until somebody acknowledges your "pain" in having to change something. I mean... it can't be about inaccuracy in the handbook, because that also is totally within your power to fix. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r358411 - head/contrib/sendmail/src
On Mon, 2020-03-02 at 02:46 +0700, Eugene Grosbein wrote: > 01.03.2020 22:20, Hajimu UMEMOTO wrote: > > > > > > > > On Sun, 1 Mar 2020 21:57:35 +0700 > > > > > > > Eugene Grosbein said: > > > > eugen> One more time: these days it is not possible to upgrade > > 11.2-STABLE system to recent stable/11 > > eugen> with stock sendmail and SSL/SASL support if the system has > > ports that need openssl-1.1.1, > > > > If you wish to use base sendmail with cyrus-sasl2, you must build > > cyrus-sasl2 with base openssl. If you wish to use cyrus-sasl2 with > > port openssl, you should use port sendmail. > > One more time: these days it is not possible. > > Dependency error: This port wants the OpenSSL library from the > FreeBSD > base system. You can't build against it, while a newer > version is installed by a port. > Please deinstall the port, remove DEFAULT_VERSIONS=ssl=base or > undefine WITH_OPENSSL_BASE. > *** Error code 1 > > Meantime, openssl-1.1.1 is needed by multiple other ports and cannod > be deinstalled. > And if I force building cyrus-sasl2 with base openssl using SSL > option that was rolled back, > it STILL does not help. > > You can easily repeat the problem using recent ports tree and recent > stable/11 and handbook-recommended way. > And why can't you use the mail/sendmail port with the SSL options set the same as for other ports? -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r358416 - head/sys/sys
On Fri, 2020-02-28 at 21:16 +, Brooks Davis wrote:
> On Fri, Feb 28, 2020 at 01:02:02AM +, Warner Losh wrote:
> > Author: imp
> > Date: Fri Feb 28 01:02:01 2020
> > New Revision: 358416
> > URL: https://svnweb.freebsd.org/changeset/base/358416
> >
> > Log:
> > Remove duplicated ATA_CHECK_POWER_MODE
> >
> > Modified:
> > head/sys/sys/ata.h
> >
> > Modified: head/sys/sys/ata.h
> > ===
> > ===
> > --- head/sys/sys/ata.h Fri Feb 28 00:42:27 2020(r358415)
> > +++ head/sys/sys/ata.h Fri Feb 28 01:02:01 2020(r358416)
> > @@ -507,7 +507,6 @@ struct ata_params {
> > #define ATA_SF_DIS_SRVIRQ 0xde/* disable service
> > interrupt */
> > #defineATA_SF_LPSAERC 0x62/* Long Phys Sect
> > Align ErrRep*/
> > #defineATA_SF_DSN 0x63/* Device Stats
> > Notification */
> > -#define ATA_CHECK_POWER_MODE 0xe5/* Check
> > Power Mode */
> > #define ATA_SECURITY_SET_PASSWORD 0xf1/* set drive
> > password */
> > #define ATA_SECURITY_UNLOCK 0xf2/* unlock drive
> > using passwd */
> > #define ATA_SECURITY_ERASE_PREPARE 0xf3/* prepare to
> > erase drive */
> >
>
> I know that's not that you were working on, but that's a remarkable
> collection of whitespace decisions in the remaining lines.
>
> -- Brooks
It's not as bad when you open the file in an editor. The indentation
is consistent and sensible, but it contains a mix of spaces and tabs so
it looks pretty bad in an email diff.
-- Ian
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r358262 - head/sys/conf
On Sun, 2020-02-23 at 19:04 +, Warner Losh wrote: > Author: imp > Date: Sun Feb 23 19:04:15 2020 > New Revision: 358262 > URL: https://svnweb.freebsd.org/changeset/base/358262 > > Log: > Use MACHINE_ARCH instead of TARGET_ARCH > > TARGET_ARCH is only for use in Makefile.inc1 contexts. MACHINE_ARCH is the > preferred thing to set. Makefile.inc1 sets MACHINE_ARCH in the cross build > case, and make sets it in the native build case. This will fix anybody > doing a > native build. Add a comment for why we have to do this dance so when/if the > problem with CFLAGS is fixed for the kernel this workaround can be removed. > I suddenly wonder: why does the kernel build need to know about the float ABI if we don't use floating point in the kernel? If it's about whether to include support for the floating point hardware (save/restore context at the userland boundary, etc), then shouldn't that be controlled with a kernel config option or device statement like it is on other arches? If the kernel actually is being compiled with different -march= to generate hardfloat instructions/register usage/etc, then shouldn't there be some compiler-defined macro to indicate that? (A quick search says that __riscv_float_abi_soft may be that macro.) -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r358248 - head/sys/vm
On Sat, 2020-02-22 at 20:01 +0100, Dimitry Andric wrote:
> On 22 Feb 2020, at 17:44, Mateusz Guzik wrote:
> >
> > On 2/22/20, Kyle Evans wrote:
> > > On Sat, Feb 22, 2020 at 10:25 AM Ian Lepore
> > > wrote:
> > > >
> > > > On Sat, 2020-02-22 at 16:20 +, Kyle Evans wrote:
> > > > > Author: kevans
> > > > > Date: Sat Feb 22 16:20:04 2020
> > > > > New Revision: 358248
> > > > > URL: https://svnweb.freebsd.org/changeset/base/358248
> > > > >
> > > > > Log:
> > > > > vm_radix: prefer __builtin_unreachable() to an unreachable
> > > > > panic()
> > > > >
> > > > > This provides the needed hint to GCC and offers an
> > > > > annotation for
> > > > > readers to
> > > > > observe that it's in-fact impossible to hit this point.
> > > > > We'll get hit
> > > > > with a
> > > > > a -Wswitch error if the enum applicable to the switch above
> > > > > were to
> > > > > get
> > > > > expanded without the new value(s) being handled.
> > > > >
> > > > > Modified:
> > > > > head/sys/vm/vm_radix.c
> > > > >
> > > > > Modified: head/sys/vm/vm_radix.c
> > > > > =
> > > > > =
> > > > > --- head/sys/vm/vm_radix.cSat Feb 22 13:23:27
> > > > > 2020(r358247)
> > > > > +++ head/sys/vm/vm_radix.cSat Feb 22 16:20:04
> > > > > 2020(r358248)
> > > > > @@ -208,8 +208,7 @@ vm_radix_node_load(smrnode_t *p, enum
> > > > > vm_radix_access
> > > > > case SMR:
> > > > > return (smr_entered_load(p, vm_radix_smr));
> > > > > }
> > > > > - /* This is unreachable, silence gcc. */
> > > > > - panic("vm_radix_node_get: Unknown access type");
> > > > > + __unreachable();
> > > > > }
> > > > >
> > > > > static __inline void
> > > >
> > > > What does __unreachable() do if the code ever becomes
> > > > reachable? Like
> > > > if a new enum value is added and this switch doesn't get
> > > > updated?
> > > >
> > >
> > > __unreachable doesn't help here, but the compiler will error out
> > > on
> > > the switch() if all enum values aren't addressed and there's no
> > > default: case.
> > >
> > > IMO, compilers could/should become smart enough to error if
> > > there's an
> > > explicit __builtin_unreachable() and they can trivially determine
> > > that
> > > all paths will terminate before this, independent of
> > > -Werror=switch*.
> > > ___
> >
> > I think this is way too iffy, check this program:
> >
> >
> > #include
> >
> > int
> > main(void)
> > {
> >
> > __builtin_unreachable();
> > printf("test\n");
> > }
> >
> > Neither clang nor gcc warn about this and both stop code generation
> > past the statement.
>
> Indeed, that is exactly the intent. See:
>
>
https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005funreachable
>
> "If control flow reaches the point of the __builtin_unreachable, the
> program is undefined. It is useful in situations where the compiler
> cannot deduce the unreachability of the code."
>
> E.g. this is *not* meant as a way to enforce the program to abort at
> runtime, if the supposedly unreachable part is actually reached.
>
> For this purpose, one should use an abort() or panic() function call,
> with such functions being annotated to never return.
>
> -Dimitry
>
The problem is, people will see usages such as what Kyle did, where the
code truly is unreachable (due to -Werror=switch), and not realizing
that's why it's valid there, they'll assume it's a type of assert-
unreachable and copy it/use it in other places as if that's what it was
for.
So, IMO, using it should be exceedingly rare and there should be a
comment nearby about why it's valid in that context, or our
__unreachable cover for it should panic on INVARIANTS, as Kyle proposed
in an earlier reply.
-- Ian
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r358248 - head/sys/vm
On Sat, 2020-02-22 at 16:20 +, Kyle Evans wrote:
> Author: kevans
> Date: Sat Feb 22 16:20:04 2020
> New Revision: 358248
> URL: https://svnweb.freebsd.org/changeset/base/358248
>
> Log:
> vm_radix: prefer __builtin_unreachable() to an unreachable panic()
>
> This provides the needed hint to GCC and offers an annotation for readers to
> observe that it's in-fact impossible to hit this point. We'll get hit with a
> a -Wswitch error if the enum applicable to the switch above were to get
> expanded without the new value(s) being handled.
>
> Modified:
> head/sys/vm/vm_radix.c
>
> Modified: head/sys/vm/vm_radix.c
> ==
> --- head/sys/vm/vm_radix.cSat Feb 22 13:23:27 2020(r358247)
> +++ head/sys/vm/vm_radix.cSat Feb 22 16:20:04 2020(r358248)
> @@ -208,8 +208,7 @@ vm_radix_node_load(smrnode_t *p, enum vm_radix_access
> case SMR:
> return (smr_entered_load(p, vm_radix_smr));
> }
> - /* This is unreachable, silence gcc. */
> - panic("vm_radix_node_get: Unknown access type");
> + __unreachable();
> }
>
> static __inline void
What does __unreachable() do if the code ever becomes reachable? Like
if a new enum value is added and this switch doesn't get updated?
-- Ian
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r357683 - head/lib/libc/string
On Mon, 2020-02-10 at 10:46 -0300, Renato Botelho wrote: > On 08/02/20 18:17, Eitan Adler wrote: > > Author: eadler > > Date: Sat Feb 8 21:17:48 2020 > > New Revision: 357683 > > URL: https://svnweb.freebsd.org/changeset/base/357683 > > > > Log: > >memset.3: better fix previous typo > > > >Upon re-reading the whole sentence this is a better fix. > > > >MFC with: r357681 > > > > Modified: > >head/lib/libc/string/memset.3 > > > > Modified: head/lib/libc/string/memset.3 > > == > > --- head/lib/libc/string/memset.3 Sat Feb 8 21:02:20 2020 > > (r357682) > > +++ head/lib/libc/string/memset.3 Sat Feb 8 21:17:48 2020 > > (r357683) > > @@ -63,8 +63,9 @@ Undefined behaviour from > > .Fn memset , > > resulting from storage overflow, will occur if > > .Fa len > > -is greater than the length of buffer > > -.Fa dest . > > +is greater than the length of the > > +.Fa dest > > +buffer. > > The behaviour is also undefined if > > .Fa dest > > is an invalid pointer. > > .Dd should be bumped to current date > It has always been my understanding for that we don't bump .Dd for things like minor grammar and spelling fixes, only for actual content changes. A few seconds of quick googling finds mailing list messages to that effect going back many many years. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r357709 - head/sys/arm/include
Author: ian
Date: Mon Feb 10 00:05:04 2020
New Revision: 357709
URL: https://svnweb.freebsd.org/changeset/base/357709
Log:
Implement atomic_testandclear_{32,int,long} for 32-bit arm. Also, replace
the existing implementation of atomic_testandset with the same new algorithm,
which uses fewer instructions and fewer registers.
Modified:
head/sys/arm/include/atomic-v6.h
Modified: head/sys/arm/include/atomic-v6.h
==
--- head/sys/arm/include/atomic-v6.hSun Feb 9 22:40:05 2020
(r357708)
+++ head/sys/arm/include/atomic-v6.hMon Feb 10 00:05:04 2020
(r357709)
@@ -858,23 +858,75 @@ atomic_store_rel_long(volatile u_long *p, u_long v)
}
static __inline int
-atomic_testandset_32(volatile uint32_t *p, u_int v)
+atomic_testandclear_32(volatile uint32_t *ptr, u_int bit)
{
- uint32_t tmp, tmp2, res, mask;
+ int newv, oldv, result;
- mask = 1u << (v & 0x1f);
- tmp = tmp2 = 0;
__asm __volatile(
- "1: ldrex %0, [%4]\n"
- " orr %1, %0, %3 \n"
- " strex %2, %1, [%4]\n"
- " cmp %2, #0 \n"
- " it ne \n"
- " bne 1b \n"
- : "=&r" (res), "=&r" (tmp), "=&r" (tmp2)
- : "r" (mask), "r" (p)
- : "cc", "memory");
- return ((res & mask) != 0);
+ " mov ip, #1 \n"
+ " lsl ip, ip, %[bit] \n"
+ /* Done with %[bit] as input, reuse below as output. */
+ "1: \n"
+ " ldrex %[oldv], [%[ptr]] \n"
+ " bic %[newv], %[oldv], ip\n"
+ " strex %[bit], %[newv], [%[ptr]] \n"
+ " teq %[bit], #0 \n"
+ " it ne \n"
+ " bne 1b \n"
+ " ands%[bit], %[oldv], ip \n"
+ " it ne \n"
+ " movne %[bit], #1 \n"
+ : [bit] "=&r" (result),
+ [oldv] "=&r" (oldv),
+ [newv] "=&r" (newv)
+ : [ptr] "r" (ptr),
+"[bit]" (bit)
+ : "cc", "ip", "memory");
+
+ return (result);
+}
+
+static __inline int
+atomic_testandclear_int(volatile u_int *p, u_int v)
+{
+
+ return (atomic_testandclear_32((volatile uint32_t *)p, v));
+}
+
+static __inline int
+atomic_testandclear_long(volatile u_long *p, u_int v)
+{
+
+ return (atomic_testandclear_32((volatile uint32_t *)p, v));
+}
+
+static __inline int
+atomic_testandset_32(volatile uint32_t *ptr, u_int bit)
+{
+ int newv, oldv, result;
+
+ __asm __volatile(
+ " mov ip, #1 \n"
+ " lsl ip, ip, %[bit] \n"
+ /* Done with %[bit] as input, reuse below as output. */
+ "1: \n"
+ " ldrex %[oldv], [%[ptr]] \n"
+ " orr %[newv], %[oldv], ip\n"
+ " strex %[bit], %[newv], [%[ptr]] \n"
+ " teq %[bit], #0 \n"
+ " it ne \n"
+ " bne 1b \n"
+ " ands%[bit], %[oldv], ip \n"
+ " it ne \n"
+ " movne %[bit], #1 \n"
+ : [bit] "=&r" (result),
+ [oldv] "=&r" (oldv),
+ [newv] "=&r" (newv)
+ : [ptr] "r" (ptr),
+"[bit]" (bit)
+ : "cc", "ip", "memory");
+
+ return (result);
}
static __inline int
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r357566 - head
On Wed, 2020-02-05 at 04:43 +, Kyle Evans wrote: > Author: kevans > Date: Wed Feb 5 04:43:58 2020 > New Revision: 357566 > URL: https://svnweb.freebsd.org/changeset/base/357566 > > Log: > Add RELNOTES entry for various daemons pulling in environment variables > > Modified: > head/RELNOTES > > Modified: head/RELNOTES > == > --- head/RELNOTES Wed Feb 5 04:35:54 2020(r357565) > +++ head/RELNOTES Wed Feb 5 04:43:58 2020(r357566) > @@ -10,6 +10,12 @@ newline. Entries should be separated by a newline. > > Changes to this file should not be MFCed. > > +r357560-r357565: > + init(8), service(8), and cron(8) will now adopt user/class environment > + variables (excluding PATH, by default, which will be overwritten) by > + default. Notably, environment variables for all cron jobs and rc > + services can now be set via login.conf(5). > + > Unfortunately, the utility of this cool series of changes is mostly destroyed by the fact that PATH is the variable that could be most usefully set in login.conf for running daemons, specifically because it is set in 3 separate places now. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r357349 - in head/sys: conf modules/tpm
On Fri, 2020-01-31 at 19:36 +, Dimitry Andric wrote: > Author: dim > Date: Fri Jan 31 19:36:14 2020 > New Revision: 357349 > URL: https://svnweb.freebsd.org/changeset/base/357349 > > Log: > Merge r357348 from the clang 10.0.0 import branch: > > Disable new clang 10.0.0 warnings about converting the result of shift > operations to a boolean in tpm(4): > > sys/dev/tpm/tpm_crb.c:301:32: error: converting the result of '<<' to a > boolean; did you mean '(1 << (0)) != 0'? [-Werror,-Wint-in-bool-context] > WR4(sc, TPM_CRB_CTRL_CANCEL, !TPM_CRB_CTRL_CANCEL_CMD); > ^ > sys/dev/tpm/tpm_crb.c:73:34: note: expanded from macro > 'TPM_CRB_CTRL_CANCEL_CMD' > #define TPM_CRB_CTRL_CANCEL_CMD BIT(0) > ^ > sys/dev/tpm/tpm20.h:60:19: note: expanded from macro 'BIT' > #define BIT(x) (1 << (x)) > ^ > > Such warnings can be useful in C++ contexts, but not so much in kernel > drivers, where this type of bit twiddling is commonplace. So disable it > for this case. > I think the point of the compiler warning about shift in a boolean context is the same as warning about assignment in a boolean context. I.e, if (a << 3) might be a typo for if (a < 3) in the same way as "a = 3" might have been intended to be "a == 3". When this type of bit twiddling is used in drivers, it's almost always combined with an & or | operator, which I assume the compiler then won't complain about (or you would have seen thousands of warnings while compiling in dev/*). -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r357349 - in head/sys: conf modules/tpm
On Fri, 2020-01-31 at 23:36 +0100, Dimitry Andric wrote:
> Hmm yes, you are quite right. Other parts of the code also seem to
> use ~TPM_XXX, and the WR4() inline function called takes a
> uint32_t. I'll revert my change and apply the tilde version instead!
>
> -Dimitry
>
So you're going to switch from writing 0 to writing 0xfffe, and
just assume that will work the same? Like, without looking at the
datasheet or TRM for the device? Surely those other 31 bits you're
turning on in a control register can't do anything important, can they?
I haven't looked at the code, but I'll bet the other places that are
using ~SYMBOLNAME are doing so in the context of read-modify-write in a
way that preserves existing bits, which is completely different than
just turning on 31 bits as a side effect of turning one bit off.
-- Ian
> > On 31 Jan 2020, at 22:13, Conrad Meyer wrote:
> >
> > Hi Dimitry,
> >
> > Do you think maybe the intent is to use ~TPM_CRB_CTRL_CANCEL_CMD
> > instead? Plain "0" might also make sense. But I think the
> > compiler
> > is right here and the warning should not be disabled — !BIT(foo)
> > doesn't really make sense for a register. It happens to affect the
> > right bit only because CANCEL_CMD is BIT(0).
> >
> > Thanks,
> > Conrad
> >
> > On Fri, Jan 31, 2020 at 11:36 AM Dimitry Andric
> > wrote:
> > >
> > > Author: dim
> > > Date: Fri Jan 31 19:36:14 2020
> > > New Revision: 357349
> > > URL: https://svnweb.freebsd.org/changeset/base/357349
> > >
> > > Log:
> > > Merge r357348 from the clang 10.0.0 import branch:
> > >
> > > Disable new clang 10.0.0 warnings about converting the result of
> > > shift
> > > operations to a boolean in tpm(4):
> > >
> > > sys/dev/tpm/tpm_crb.c:301:32: error: converting the result of
> > > '<<' to a boolean; did you mean '(1 << (0)) != 0'? [-Werror,-
> > > Wint-in-bool-context]
> > > WR4(sc, TPM_CRB_CTRL_CANCEL, !TPM_CRB_CTRL_CANCEL_CMD);
> > >^
> > > sys/dev/tpm/tpm_crb.c:73:34: note: expanded from macro
> > > 'TPM_CRB_CTRL_CANCEL_CMD'
> > > #define TPM_CRB_CTRL_CANCEL_CMD BIT(0)
> > > ^
> > > sys/dev/tpm/tpm20.h:60:19: note: expanded from macro 'BIT'
> > > #define BIT(x) (1 << (x))
> > >^
> > >
> > > Such warnings can be useful in C++ contexts, but not so much in
> > > kernel
> > > drivers, where this type of bit twiddling is commonplace. So
> > > disable it
> > > for this case.
> > >
> > > MFC after:3 days
> > >
> > > Modified:
> > > head/sys/conf/files.amd64
> > > head/sys/conf/kern.mk
> > > head/sys/modules/tpm/Makefile
> > > Directory Properties:
> > > head/ (props changed)
> > >
> > > Modified: head/sys/conf/files.amd64
> > > =
> > > =
> > > --- head/sys/conf/files.amd64 Fri Jan 31 19:35:21
> > > 2020(r357348)
> > > +++ head/sys/conf/files.amd64 Fri Jan 31 19:36:14
> > > 2020(r357349)
> > > @@ -323,7 +323,8 @@
> > > dev/syscons/scvesactl.c optionalsc vga vesa
> > > dev/syscons/scvgarndr.coptionalsc vga
> > > dev/tpm/tpm.c optionaltpm
> > > dev/tpm/tpm20.coptionaltpm
> > > -dev/tpm/tpm_crb.c optionaltpm acpi
> > > +dev/tpm/tpm_crb.c optionaltpm acpi \
> > > + compile-with "${NORMAL_C} ${NO_WINT_IN_BOOL_CONTEXT}"
> > > dev/tpm/tpm_tis.c optionaltpm acpi
> > > dev/tpm/tpm_acpi.c optionaltpm acpi
> > > dev/tpm/tpm_isa.c optionaltpm isa
> > >
> > > Modified: head/sys/conf/kern.mk
> > > =
> > > =
> > > --- head/sys/conf/kern.mk Fri Jan 31 19:35:21
> > > 2020(r357348)
> > > +++ head/sys/conf/kern.mk Fri Jan 31 19:36:14
> > > 2020(r357349)
> > > @@ -37,6 +37,9 @@ CWARNEXTRA+= -Wno-error-shift-negative-value
> > > .if ${COMPILER_VERSION} >= 4
> > > CWARNEXTRA+= -Wno-address-of-packed-member
> > > .endif
> > > +.if ${COMPILER_VERSION} >= 10
> > > +NO_WINT_IN_BOOL_CONTEXT= -Wno-int-in-bool-context
> > > +.endif
> > > .endif
> > >
> > > .if ${COMPILER_TYPE} == "gcc"
> > >
> > > Modified: head/sys/modules/tpm/Makefile
> > > =
> > > =
> > > --- head/sys/modules/tpm/Makefile Fri Jan 31 19:35:21
> > > 2020(r357348)
> > > +++ head/sys/modules/tpm/Makefile Fri Jan 31 19:36:14
> > > 2020(r357349)
> > > @@ -11,3 +11,5 @@ SRCS+=tpm_isa.c tpm_acpi.c isa_if.h
> > > opt_acpi.h acpi_i
> > > SRCS+= tpm20.c tpm_crb.c tpm_tis.c opt_tpm.h
> > >
> > > .include
> > > +
> > > +CWARNFLAGS.tpm_crb.c+= ${NO_WINT_IN_BOOL_CONTEXT}
>
>
___
svn-src-head@fr
Re: svn commit: r357288 - head/sys/dev/usb/wlan
On Thu, 2020-01-30 at 09:41 +, Hans Petter Selasky wrote: > Author: hselasky > Date: Thu Jan 30 09:41:48 2020 > New Revision: 357288 > URL: https://svnweb.freebsd.org/changeset/base/357288 > > Log: > Widen EPOCH(9) usage in USB WLAN drivers. > > This patch should unbreak the USB WLAN drivers after r357004. > > Pointy hat: glebius@ > Sponsored by: Mellanox Technologies > > Modified: > head/sys/dev/usb/wlan/if_rum.c > head/sys/dev/usb/wlan/if_run.c > head/sys/dev/usb/wlan/if_uath.c > head/sys/dev/usb/wlan/if_upgt.c > head/sys/dev/usb/wlan/if_ural.c > head/sys/dev/usb/wlan/if_urtw.c > head/sys/dev/usb/wlan/if_zyd.c > This is another piece of evidence illustratitng what a bad idea it was to try to handle network interrupts as some sort of special case in the wrong layer of the OS. Network drivers know who they are and can do the right thing. The interrupt dispatching code can only guess at what's going on by using flags that were intended for a whole other purpose. We now how multiple demonstrations of the fact that those flags cannot reliably be used as an indication of whether network packets are going to be handled during the interrupt or not. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r357051 - head/sys/dev/bge
On Thu, 2020-01-23 at 15:05 -0800, Gleb Smirnoff wrote: > On Thu, Jan 23, 2020 at 02:17:33PM -0500, Ryan Stone wrote: > R> What is a driver's responsibility now for entering/leaving the net epoch > now? > > For drivers that are 'special', entering the net epoch is necessary. Special > usually means running if_input outside network interrupt context. > > However, there is plan to generalize entering/exiting epoch for taskqueues > and callouts. > That sounds every bit as horrible and out-of-place as the recent hack (and it does feel very much like a horrible hack) that put network- specific code into the guts of interrupt dispatching. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r356725 - head/usr.bin/diff
On Tue, 2020-01-14 at 08:22 +, Baptiste Daroussin wrote:
> Author: bapt
> Date: Tue Jan 14 08:22:28 2020
> New Revision: 356725
> URL: https://svnweb.freebsd.org/changeset/base/356725
>
> Log:
> When system calls indicate an error they return -1, not some
> arbitrary
> value < 0. errno is only updated in this case.
>
What's the point of these changes, other than almost certainly leading
to worse code generation?
In most instruction sets, you can test for a value < 0 without using
any instructions, you only need to examine the condition flags after
loading the value. To compare equal to -1 typically requires at least
1 extra instruction, and on risc architectures typically at least two
extra (load -1 to a register then compare).
-- Ian
> Obtained from: OpenBSD
> MFC after: 3 days
>
> Modified:
> head/usr.bin/diff/diff.c
> head/usr.bin/diff/diffreg.c
>
> Modified: head/usr.bin/diff/diff.c
> =
> =
> --- head/usr.bin/diff/diff.c Tue Jan 14 08:18:04 2020(r356724)
> +++ head/usr.bin/diff/diff.c Tue Jan 14 08:22:28 2020(r356725)
> @@ -1,4 +1,4 @@
> -/* $OpenBSD: diff.c,v 1.65 2015/12/29 19:04:46 gsoares Exp $ */
> +/* $OpenBSD: diff.c,v 1.67 2019/06/28 13:35:00 deraadt Exp $ */
>
> /*
> * Copyright (c) 2003 Todd C. Miller
> @@ -316,12 +316,12 @@ main(int argc, char **argv)
> } else {
> if (S_ISDIR(stb1.st_mode)) {
> argv[0] = splice(argv[0], argv[1]);
> - if (stat(argv[0], &stb1) < 0)
> + if (stat(argv[0], &stb1) == -1)
> err(2, "%s", argv[0]);
> }
> if (S_ISDIR(stb2.st_mode)) {
> argv[1] = splice(argv[1], argv[0]);
> - if (stat(argv[1], &stb2) < 0)
> + if (stat(argv[1], &stb2) == -1)
> err(2, "%s", argv[1]);
> }
> print_status(diffreg(argv[0], argv[1], dflags, 1),
> argv[0],
>
> Modified: head/usr.bin/diff/diffreg.c
> =
> =
> --- head/usr.bin/diff/diffreg.c Tue Jan 14 08:18:04 2020(r356
> 724)
> +++ head/usr.bin/diff/diffreg.c Tue Jan 14 08:22:28 2020(r356
> 725)
> @@ -1,4 +1,4 @@
> -/* $OpenBSD: diffreg.c,v 1.92 2019/06/28 05:35:34 deraadt Exp $
> */
> +/* $OpenBSD: diffreg.c,v 1.93 2019/06/28 13:35:00 deraadt Exp $
> */
>
> /*-
> * SPDX-License-Identifier: BSD-4-Clause
> @@ -277,7 +277,7 @@ diffreg(char *file1, char *file2, int flags, int
> capsi
> else {
> if (!S_ISREG(stb1.st_mode)) {
> if ((f1 = opentemp(file1)) == NULL ||
> - fstat(fileno(f1), &stb1) < 0) {
> + fstat(fileno(f1), &stb1) == -1) {
> warn("%s", file1);
> status |= 2;
> goto closem;
> @@ -298,7 +298,7 @@ diffreg(char *file1, char *file2, int flags, int
> capsi
> else {
> if (!S_ISREG(stb2.st_mode)) {
> if ((f2 = opentemp(file2)) == NULL ||
> - fstat(fileno(f2), &stb2) < 0) {
> + fstat(fileno(f2), &stb2) == -1) {
> warn("%s", file2);
> status |= 2;
> goto closem;
> @@ -446,7 +446,7 @@ opentemp(const char *f)
>
> if (strcmp(f, "-") == 0)
> ifd = STDIN_FILENO;
> - else if ((ifd = open(f, O_RDONLY, 0644)) < 0)
> + else if ((ifd = open(f, O_RDONLY, 0644)) == -1)
> return (NULL);
>
> (void)strlcpy(tempfile, _PATH_TMP "/diff.",
> sizeof(tempfile));
> @@ -942,7 +942,7 @@ preadline(int fd, size_t rlen, off_t off)
> ssize_t nr;
>
> line = xmalloc(rlen + 1);
> - if ((nr = pread(fd, line, rlen, off)) < 0)
> + if ((nr = pread(fd, line, rlen, off)) == -1)
> err(2, "preadline");
> if (nr > 0 && line[nr-1] == '\n')
> nr--;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r356693 - in head/stand: efi/libefi i386/libi386 libofw uboot/lib
On Mon, 2020-01-13 at 20:43 +0200, Toomas Soome wrote: > > On 13. Jan 2020, at 20:31, Ian Lepore wrote: > > > > On Mon, 2020-01-13 at 18:22 +, Toomas Soome wrote: > > > Author: tsoome > > > Date: Mon Jan 13 18:22:54 2020 > > > New Revision: 356693 > > > URL: https://svnweb.freebsd.org/changeset/base/356693 > > > > > > Log: > > > loader: allocate properly aligned buffer for network packet > > > > > > Use memalign(4, size) to ensure we have properly aligned buffer. > > > > > > MFC after: 2 weeks > > > > > > Modified: > > > head/stand/efi/libefi/efinet.c > > > head/stand/i386/libi386/pxe.c > > > head/stand/libofw/ofw_net.c > > > head/stand/uboot/lib/net.c > > > > > > > The malloc implementation in libstand already g'tees minimum > > alignment > > of 16 bytes on most arches, 64 bytes on arches that use u-boot (see > > libsa/zalloc_defs.h). So how does this change anything? > > > > Hi! > > Well, given the amount of knobs etc, it does not hurt to be explicit, > does it? > > rgds, > toomas I think it does hurt, because now it misleads you into thinking it's 4- byte aligned when it's actually 16 or 64. (That's what made me reply at all, my first gut reaction to reading the commit message was "but 4 is not at all the right alignment on many platforms"). -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r356693 - in head/stand: efi/libefi i386/libi386 libofw uboot/lib
On Mon, 2020-01-13 at 18:22 +, Toomas Soome wrote: > Author: tsoome > Date: Mon Jan 13 18:22:54 2020 > New Revision: 356693 > URL: https://svnweb.freebsd.org/changeset/base/356693 > > Log: > loader: allocate properly aligned buffer for network packet > > Use memalign(4, size) to ensure we have properly aligned buffer. > > MFC after: 2 weeks > > Modified: > head/stand/efi/libefi/efinet.c > head/stand/i386/libi386/pxe.c > head/stand/libofw/ofw_net.c > head/stand/uboot/lib/net.c > The malloc implementation in libstand already g'tees minimum alignment of 16 bytes on most arches, 64 bytes on arches that use u-boot (see libsa/zalloc_defs.h). So how does this change anything? -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r356574 - head/sys/cddl/dev/dtrace/arm
Author: ian
Date: Thu Jan 9 22:51:37 2020
New Revision: 356574
URL: https://svnweb.freebsd.org/changeset/base/356574
Log:
Remove scary-looking printf output that happens when you kldload dtrace on
arm. Replace it with a comment block explaining why the function is empty
on 32-bit arm.
Modified:
head/sys/cddl/dev/dtrace/arm/dtrace_subr.c
Modified: head/sys/cddl/dev/dtrace/arm/dtrace_subr.c
==
--- head/sys/cddl/dev/dtrace/arm/dtrace_subr.c Thu Jan 9 21:50:15 2020
(r356573)
+++ head/sys/cddl/dev/dtrace/arm/dtrace_subr.c Thu Jan 9 22:51:37 2020
(r356574)
@@ -123,7 +123,18 @@ dtrace_invop_remove(int (*func)(uintptr_t, struct trap
void
dtrace_toxic_ranges(void (*func)(uintptr_t base, uintptr_t limit))
{
- printf("IMPLEMENT ME: dtrace_toxic_ranges\n");
+
+ /*
+* There are no ranges to exclude that are common to all 32-bit arm
+* platforms. This function only needs to exclude ranges "... in
+* which it is impossible to recover from such a load after it has been
+* attempted." -- i.e., accessing within the range causes some sort
+* fault in the system which is not handled by the normal arm
+* exception-handling mechanisms. If systems exist where that is the
+* case, a method to handle this functionality would have to be added to
+* the platform_if interface so that those systems could provide their
+* specific toxic range(s).
+*/
}
void
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r356526 - head/sys/dev/iicbus/mux
Author: ian Date: Wed Jan 8 23:06:13 2020 New Revision: 356526 URL: https://svnweb.freebsd.org/changeset/base/356526 Log: Remove some trailing whitespace; no functional changes. Modified: head/sys/dev/iicbus/mux/iicmux.c Modified: head/sys/dev/iicbus/mux/iicmux.c == --- head/sys/dev/iicbus/mux/iicmux.cWed Jan 8 23:03:47 2020 (r356525) +++ head/sys/dev/iicbus/mux/iicmux.cWed Jan 8 23:06:13 2020 (r356526) @@ -153,7 +153,7 @@ iicmux_intr(device_t dev, int event, char *buf) /* XXX iicbus_intr() in iiconf.c should return status. */ iicbus_intr(sc->busdev, event, buf); - return (0); + return (0); } static int @@ -213,7 +213,7 @@ iicmux_write(device_t dev, const char *buf, int len, i } /*-- - * iicmux helper functions, called by hardware-specific drivers. + * iicmux helper functions, called by hardware-specific drivers. * All these functions return a standard errno value. **/ @@ -324,7 +324,7 @@ iicmux_attach(device_t dev, device_t busdev, int numbu if ((err = iicmux_attach_children(sc)) != 0) return (err); - SYSCTL_ADD_UINT(device_get_sysctl_ctx(sc->dev), + SYSCTL_ADD_UINT(device_get_sysctl_ctx(sc->dev), SYSCTL_CHILDREN(device_get_sysctl_tree(sc->dev)), OID_AUTO, "debugmux", CTLFLAG_RWTUN, &sc->debugmux, 0, "debug mux operations"); ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r356525 - head/sys/dev/iicbus/mux
Author: ian
Date: Wed Jan 8 23:03:47 2020
New Revision: 356525
URL: https://svnweb.freebsd.org/changeset/base/356525
Log:
Split the code to find and add iicbus children out to its own function.
Move the decision to take an early exit from that function after adding
children based on FDT data into the #ifdef FDT block, so that it doesn't
offend coverity's notion of how the code should be written. (What's the
point of compilers optimizing away dead code if static analyzers won't
let you use the feature in conjuction with an #ifdef block?)
Reported by: coverity via vangyzen@
Modified:
head/sys/dev/iicbus/mux/iicmux.c
Modified: head/sys/dev/iicbus/mux/iicmux.c
==
--- head/sys/dev/iicbus/mux/iicmux.cWed Jan 8 22:59:31 2020
(r356524)
+++ head/sys/dev/iicbus/mux/iicmux.cWed Jan 8 23:03:47 2020
(r356525)
@@ -240,36 +240,13 @@ iicmux_add_child(device_t dev, device_t child, int bus
return (0);
}
-int
-iicmux_attach(device_t dev, device_t busdev, int numbuses)
+static int
+iicmux_attach_children(struct iicmux_softc *sc)
{
- struct iicmux_softc *sc = device_get_softc(dev);
- int i, numadded;
-
- if (numbuses >= IICMUX_MAX_BUSES) {
- device_printf(dev, "iicmux_attach: numbuses %d > max %d\n",
- numbuses, IICMUX_MAX_BUSES);
- return (EINVAL);
- }
-
- sc->dev = dev;
- sc->busdev = busdev;
- sc->maxbus = -1;
- sc->numbuses = numbuses;
-
- SYSCTL_ADD_UINT(device_get_sysctl_ctx(sc->dev),
- SYSCTL_CHILDREN(device_get_sysctl_tree(sc->dev)), OID_AUTO,
- "debugmux", CTLFLAG_RWTUN, &sc->debugmux, 0, "debug mux
operations");
-
-/*
- * Add children...
- */
- numadded = 0;
-
+ int i;
#ifdef FDT
phandle_t child, node, parent;
- pcell_t reg;
- int idx;
+ pcell_t idx;
/*
* Find our FDT node. Child nodes within our node will become our
@@ -292,14 +269,13 @@ iicmux_attach(device_t dev, device_t busdev, int numbu
* Attach the children represented in the device tree.
*/
for (child = OF_child(parent); child != 0; child = OF_peer(child)) {
- if (OF_getencprop(child, "reg", ®, sizeof(reg)) == -1) {
- device_printf(dev,
+ if (OF_getencprop(child, "reg", &idx, sizeof(idx)) == -1) {
+ device_printf(sc->dev,
"child bus missing required 'reg' property\n");
continue;
}
- idx = (int)reg;
if (idx >= sc->numbuses) {
- device_printf(dev,
+ device_printf(sc->dev,
"child bus 'reg' property %d exceeds the number "
"of buses supported by the device (%d)\n",
idx, sc->numbuses);
@@ -309,21 +285,48 @@ iicmux_attach(device_t dev, device_t busdev, int numbu
sc->childnodes[idx] = child;
if (sc->maxbus < idx)
sc->maxbus = idx;
- ++numadded;
}
+
+ /* If we configured anything using FDT data, we're done. */
+ if (sc->maxbus >= 0)
+ return (0);
#endif /* FDT */
/*
-* If we configured anything using FDT data, we're done. Otherwise add
-* an iicbus child for every downstream bus supported by the mux chip.
+* If we make it to here, we didn't add any children based on FDT data.
+* Add an iicbus child for every downstream bus supported by the mux.
*/
- if (numadded > 0)
- return (0);
-
for (i = 0; i < sc->numbuses; ++i) {
sc->childdevs[i] = device_add_child(sc->dev, "iicbus", -1);
+ sc->maxbus = i;
}
- sc->maxbus = sc->numbuses - 1;
+
+ return (0);
+}
+
+int
+iicmux_attach(device_t dev, device_t busdev, int numbuses)
+{
+ struct iicmux_softc *sc = device_get_softc(dev);
+ int err;
+
+ if (numbuses >= IICMUX_MAX_BUSES) {
+ device_printf(dev, "iicmux_attach: numbuses %d > max %d\n",
+ numbuses, IICMUX_MAX_BUSES);
+ return (EINVAL);
+ }
+
+ sc->dev = dev;
+ sc->busdev = busdev;
+ sc->maxbus = -1;
+ sc->numbuses = numbuses;
+
+ if ((err = iicmux_attach_children(sc)) != 0)
+ return (err);
+
+ SYSCTL_ADD_UINT(device_get_sysctl_ctx(sc->dev),
+ SYSCTL_CHILDREN(device_get_sysctl_tree(sc->dev)), OID_AUTO,
+ "debugmux", CTLFLAG_RWTUN, &sc->debugmux, 0, "debug mux
operations");
return (0);
}
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe,
svn commit: r356522 - head/sys/dev/iicbus/mux
Author: ian
Date: Wed Jan 8 22:48:14 2020
New Revision: 356522
URL: https://svnweb.freebsd.org/changeset/base/356522
Log:
Change some KASSERT to device_printf + return EINVAL. There's no need to
bring the whole kernel down due to a configuration error detected when a
module is loaded, it suffices to just not attach the device.
Modified:
head/sys/dev/iicbus/mux/iicmux.c
Modified: head/sys/dev/iicbus/mux/iicmux.c
==
--- head/sys/dev/iicbus/mux/iicmux.cWed Jan 8 22:45:32 2020
(r356521)
+++ head/sys/dev/iicbus/mux/iicmux.cWed Jan 8 22:48:14 2020
(r356522)
@@ -222,10 +222,16 @@ iicmux_add_child(device_t dev, device_t child, int bus
{
struct iicmux_softc *sc = device_get_softc(dev);
- KASSERT(busidx < sc->numbuses,
- ("iicmux_add_child: bus idx %d too big", busidx));
- KASSERT(sc->childdevs[busidx] == NULL,
- ("iicmux_add_child: bus idx %d already added", busidx));
+ if (busidx >= sc->numbuses) {
+ device_printf(dev,
+ "iicmux_add_child: bus idx %d too big", busidx);
+ return (EINVAL);
+ }
+ if (sc->childdevs[busidx] != NULL) {
+ device_printf(dev, "iicmux_add_child: bus idx %d already added",
+ busidx);
+ return (EINVAL);
+ }
sc->childdevs[busidx] = child;
if (sc->maxbus < busidx)
@@ -240,12 +246,11 @@ iicmux_attach(device_t dev, device_t busdev, int numbu
struct iicmux_softc *sc = device_get_softc(dev);
int i, numadded;
-/*
- * Init the softc...
- */
- KASSERT(numbuses <= IICMUX_MAX_BUSES,
- ("iicmux_attach: numbuses %d exceeds max %d\n",
- numbuses, IICMUX_MAX_BUSES));
+ if (numbuses >= IICMUX_MAX_BUSES) {
+ device_printf(dev, "iicmux_attach: numbuses %d > max %d\n",
+ numbuses, IICMUX_MAX_BUSES);
+ return (EINVAL);
+ }
sc->dev = dev;
sc->busdev = busdev;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r356521 - head/sys/dev/iicbus/mux
Author: ian
Date: Wed Jan 8 22:45:32 2020
New Revision: 356521
URL: https://svnweb.freebsd.org/changeset/base/356521
Log:
Init sc->maxbus to -1, not 0. It represents the highest array index that
has a non-NULL child bus stored in it, so the "none" value can't be zero
since that's a valid array index. Also, when adding all possible buses
because there is no specific per-bus config, there's no need to reset
sc->maxbus on each loop iteration, it can be set once after the loop.
Modified:
head/sys/dev/iicbus/mux/iicmux.c
Modified: head/sys/dev/iicbus/mux/iicmux.c
==
--- head/sys/dev/iicbus/mux/iicmux.cWed Jan 8 22:16:26 2020
(r356520)
+++ head/sys/dev/iicbus/mux/iicmux.cWed Jan 8 22:45:32 2020
(r356521)
@@ -249,6 +249,7 @@ iicmux_attach(device_t dev, device_t busdev, int numbu
sc->dev = dev;
sc->busdev = busdev;
+ sc->maxbus = -1;
sc->numbuses = numbuses;
SYSCTL_ADD_UINT(device_get_sysctl_ctx(sc->dev),
@@ -262,7 +263,8 @@ iicmux_attach(device_t dev, device_t busdev, int numbu
#ifdef FDT
phandle_t child, node, parent;
- pcell_t idx;
+ pcell_t reg;
+ int idx;
/*
* Find our FDT node. Child nodes within our node will become our
@@ -285,11 +287,12 @@ iicmux_attach(device_t dev, device_t busdev, int numbu
* Attach the children represented in the device tree.
*/
for (child = OF_child(parent); child != 0; child = OF_peer(child)) {
- if (OF_getencprop(child, "reg", &idx, sizeof(idx)) == -1) {
+ if (OF_getencprop(child, "reg", ®, sizeof(reg)) == -1) {
device_printf(dev,
"child bus missing required 'reg' property\n");
continue;
}
+ idx = (int)reg;
if (idx >= sc->numbuses) {
device_printf(dev,
"child bus 'reg' property %d exceeds the number "
@@ -314,9 +317,8 @@ iicmux_attach(device_t dev, device_t busdev, int numbu
for (i = 0; i < sc->numbuses; ++i) {
sc->childdevs[i] = device_add_child(sc->dev, "iicbus", -1);
- if (sc->maxbus < i)
- sc->maxbus = i;
}
+ sc->maxbus = sc->numbuses - 1;
return (0);
}
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r356519 - head/sys/dev/iicbus/mux
Author: ian
Date: Wed Jan 8 22:06:31 2020
New Revision: 356519
URL: https://svnweb.freebsd.org/changeset/base/356519
Log:
Ensure any reserved gpio pins get released if an early exit is taken
from the attach function.
Modified:
head/sys/dev/iicbus/mux/iic_gpiomux.c
Modified: head/sys/dev/iicbus/mux/iic_gpiomux.c
==
--- head/sys/dev/iicbus/mux/iic_gpiomux.c Wed Jan 8 21:22:44 2020
(r356518)
+++ head/sys/dev/iicbus/mux/iic_gpiomux.c Wed Jan 8 22:06:31 2020
(r356519)
@@ -119,6 +119,15 @@ gpiomux_probe(device_t dev)
return (rv);
}
+static void
+gpiomux_release_pins(struct gpiomux_softc *sc)
+{
+ int i;
+
+ for (i = 0; i < sc->numpins; ++i)
+ gpio_pin_release(sc->pins[i]);
+}
+
static int
gpiomux_attach(device_t dev)
{
@@ -145,13 +154,16 @@ gpiomux_attach(device_t dev)
sc->numpins = i;
if (sc->numpins == 0) {
device_printf(dev, "cannot acquire pins listed in mux-gpios\n");
- return ((err == 0) ? ENXIO : err);
+ if (err == 0)
+ err = ENXIO;
+ goto errexit;
}
numchannels = 1u << sc->numpins;
if (numchannels > IICMUX_MAX_BUSES) {
device_printf(dev, "too many mux-gpios pins for max %d buses\n",
IICMUX_MAX_BUSES);
- return (EINVAL);
+ err = EINVAL;
+ goto errexit;
}
/*
@@ -163,13 +175,15 @@ gpiomux_attach(device_t dev)
len = OF_getencprop(node, "i2c-parent", &propval, sizeof(propval));
if (len != sizeof(propval)) {
device_printf(dev, "cannot obtain i2c-parent property\n");
- return (ENXIO);
+ err = ENXIO;
+ goto errexit;
}
busdev = OF_device_from_xref((phandle_t)propval);
if (busdev == NULL) {
device_printf(dev,
"cannot find device referenced by i2c-parent property\n");
- return (ENXIO);
+ err = ENXIO;
+ goto errexit;
}
device_printf(dev, "upstream bus is %s\n", device_get_nameunit(busdev));
@@ -202,6 +216,11 @@ gpiomux_attach(device_t dev)
if ((err = iicmux_attach(dev, busdev, numchannels)) == 0)
bus_generic_attach(dev);
+errexit:
+
+ if (err != 0)
+ gpiomux_release_pins(sc);
+
return (err);
}
@@ -209,13 +228,12 @@ static int
gpiomux_detach(device_t dev)
{
struct gpiomux_softc *sc = device_get_softc(dev);
- int err, i;
+ int err;
if ((err = iicmux_detach(dev)) != 0)
return (err);
- for (i = 0; i < sc->numpins; ++i)
- gpio_pin_release(sc->pins[i]);
+ gpiomux_release_pins(sc);
return (0);
}
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r356472 - head/sys/arm/arm
Author: ian
Date: Tue Jan 7 21:13:34 2020
New Revision: 356472
URL: https://svnweb.freebsd.org/changeset/base/356472
Log:
Add #ifdef option-test wrappers around another call to an arm/unwind.c
function which is only compiled-in with certain options.
Why is it always the most trivial part of a big commit that takes 3 tries
to get right?
Modified:
head/sys/arm/arm/elf_machdep.c
Modified: head/sys/arm/arm/elf_machdep.c
==
--- head/sys/arm/arm/elf_machdep.c Tue Jan 7 20:35:43 2020
(r356471)
+++ head/sys/arm/arm/elf_machdep.c Tue Jan 7 21:13:34 2020
(r356472)
@@ -337,7 +337,9 @@ int
elf_cpu_unload_file(linker_file_t lf)
{
+#if defined(DDB) || defined(KDTRACE_HOOKS) || defined(STACK)
/* Inform the stack(9) code that this module is gone. */
unwind_module_unloaded(lf);
+#endif
return (0);
}
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r356379 - head/share/mk
On Sun, 2020-01-05 at 13:17 -0500, Ed Maste wrote: > On Sun, 5 Jan 2020 at 12:53, Yasuhiro KIMURA > wrote: > > > > Just out of curiosity, is there any retirement plan for binutils in > > base system at the moment? > > There's no specific plan, but it is an ongoing goal. Only three > binutils tools are used (for bootstrapping and in the installed > system): as, ld, and objdump. > > BINUTILS_BOOTSTRAP is enabled on x86, 32-bit arm, and powerpc. At > least both x86 archs still use GNU as for a few files; there's work > in > progress to migrate to Clang's IAS for all assembly files. I am not > sure if bootstrap as actually gets used on arm or powerpc. objdump is > also built, but not used on any arch. ld is built on powerpc and > still > being used there; it's not built on x86 or 32-bit arm. > I just set WITHOUT_BINUTILS_BOOTSTRAP in src.conf and did an arm32 crossbuild from amd64 after an rm -rf in $objdir, and both kernel and world built successfully. -- Ian > Making further progress depends on lld maturing (for powerpc) and > addressing the assembler issue. There's no commitment to removing > binutils for 13.0 but there is a reasonable probability we'll be able > to do so. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r356295 - in head/sys: arm/conf arm64/conf
Author: ian Date: Thu Jan 2 22:26:54 2020 New Revision: 356295 URL: https://svnweb.freebsd.org/changeset/base/356295 Log: Add the xdma framework and pl330 dma drivers to arm and arm64 lint builds. Modified: head/sys/arm/conf/NOTES head/sys/arm64/conf/NOTES Modified: head/sys/arm/conf/NOTES == --- head/sys/arm/conf/NOTES Thu Jan 2 22:14:44 2020(r356294) +++ head/sys/arm/conf/NOTES Thu Jan 2 22:26:54 2020(r356295) @@ -28,3 +28,7 @@ nodevice mps # Add devices which are specific to various arm platforms... device twsi# i2c controller on Marvel and Allwinner + +device pl330 # ARM PL330 dma controller +device xdma# xDMA framework for SoC on-chip dma controllers + Modified: head/sys/arm64/conf/NOTES == --- head/sys/arm64/conf/NOTES Thu Jan 2 22:14:44 2020(r356294) +++ head/sys/arm64/conf/NOTES Thu Jan 2 22:26:54 2020(r356295) @@ -189,6 +189,10 @@ device regulator device syscon device aw_syscon +# Misc devices. +device pl330 # ARM PL330 dma controller +device xdma# xDMA framework for SoC on-chip dma controllers + # Chip-specific errata optionsTHUNDERX_PASS_1_1_ERRATA ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r356294 - head/sys/dev/flash
Author: ian
Date: Thu Jan 2 22:14:44 2020
New Revision: 356294
URL: https://svnweb.freebsd.org/changeset/base/356294
Log:
Explicitly include sys/rman.h instead of relying on getting it via some
other header.
Modified:
head/sys/dev/flash/cqspi.c
Modified: head/sys/dev/flash/cqspi.c
==
--- head/sys/dev/flash/cqspi.c Thu Jan 2 22:13:59 2020(r356293)
+++ head/sys/dev/flash/cqspi.c Thu Jan 2 22:14:44 2020(r356294)
@@ -50,6 +50,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
#include
#include
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r356278 - in head: share/man/man4 sys/conf sys/dev/iicbus sys/dev/iicbus/mux sys/modules/i2c sys/modules/i2c/mux sys/modules/i2c/mux/iic_gpiomux sys/modules/i2c/mux/iicmux sys/modules/
On Thu, 2020-01-02 at 17:51 +, Ian Lepore wrote: > Author: ian > Date: Thu Jan 2 17:51:49 2020 > New Revision: 356278 > URL: https://svnweb.freebsd.org/changeset/base/356278 > > Log: > Add support for i2c bus mux hardware. > As usual, forgot to add: Differential Revision:https://reviews.freebsd.org/D22891 -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r356278 - in head: share/man/man4 sys/conf sys/dev/iicbus sys/dev/iicbus/mux sys/modules/i2c sys/modules/i2c/mux sys/modules/i2c/mux/iic_gpiomux sys/modules/i2c/mux/iicmux sys/modules/i...
iicsmb.4 \
iir.4 \
${_imcsmb.4} \
@@ -258,6 +260,7 @@ MAN=aac.4 \
lp.4 \
lpbb.4 \
lpt.4 \
+ ltc430x.4 \
mac.4 \
mac_biba.4 \
mac_bsdextended.4 \
Added: head/share/man/man4/iic_gpiomux.4
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/share/man/man4/iic_gpiomux.4 Thu Jan 2 17:51:49 2020
(r356278)
@@ -0,0 +1,88 @@
+.\"-
+.\" SPDX-License-Identifier: BSD-2-Clause
+.\"
+.\" Copyright (c) 2019 Ian Lepore
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"notice, this list of conditions and the following disclaimer in the
+.\"documentation and/or other materials provided with the distribution.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\" $FreeBSD$
+.\"
+.Dd January 1, 2020
+.Dt IIC_GPIOMUX 4
+.Os
+.Sh NAME
+.Nm iic_gpiomux
+.Nd driver for I2C mux hardware controlled via GPIO
+.Sh SYNOPSIS
+To compile this driver into the kernel,
+place the following line in your
+kernel configuration file:
+.Bd -ragged -offset indent
+.Cd "device iic_gpiomux"
+.Ed
+.Pp
+Alternatively, to load the driver as a
+module at boot time, place the following line in
+.Xr loader.conf 5 :
+.Bd -literal -offset indent
+iic_gpiomux_load="YES"
+.Ed
+.Sh DESCRIPTION
+The
+.Nm
+driver supports any type of I2C bus multiplexer (mux) hardware that
+is controlled by manipulating the state of one or more GPIO pins.
+It automatically connects an upstream I2C bus to one of the downstream
+buses as needed when slave devices on the downstream buses initiate I/O.
+More information on the automatic switching behavior is available in
+.Xr iicmux 4 .
+.Pp
+.Sh FDT CONFIGURATION
+On an
+.Xr fdt 4
+based system, an
+.Nm
+device node may be defined as a child node of any arbitrary bus
+in the FDT data.
+The
+.Va i2c-parent
+property indicates the connection to the upstream I2C bus.
+The children of the
+.Nm
+node are additional i2c buses, which will have their own i2c slave
+devices described in their child nodes.
+.Pp
+The
+.Nm
+driver conforms to the standard
+.Bk -words
+.Li i2c/i2c-mux-gpio.txt
+.Ek
+bindings document.
+.Sh SEE ALSO
+.Xr iicbus 4 ,
+.Xr iicmux 4 ,
+.Sh HISTORY
+The
+.Nm
+driver first appeared in
+.Fx 13.0 .
Added: head/share/man/man4/iicmux.4
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/share/man/man4/iicmux.4Thu Jan 2 17:51:49 2020
(r356278)
@@ -0,0 +1,148 @@
+.\"-
+.\" SPDX-License-Identifier: BSD-2-Clause
+.\"
+.\" Copyright (c) 2019 Ian Lepore
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"notice, this list of conditions and the following disclaimer in the
+.\"documentation and/or other materials provided with the distribution.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\"
svn commit: r356273 - head/sys/arm/arm
Author: ian
Date: Thu Jan 2 15:38:17 2020
New Revision: 356273
URL: https://svnweb.freebsd.org/changeset/base/356273
Log:
Since arm/unwind.c s conditionally compiled, only call functions in it
when one of those conditions is true. Fixes build failure on kernel
configs with no debugging options active.
Modified:
head/sys/arm/arm/elf_machdep.c
Modified: head/sys/arm/arm/elf_machdep.c
==
--- head/sys/arm/arm/elf_machdep.c Thu Jan 2 14:39:37 2020
(r356272)
+++ head/sys/arm/arm/elf_machdep.c Thu Jan 2 15:38:17 2020
(r356273)
@@ -52,6 +52,10 @@ __FBSDID("$FreeBSD$");
#include
#endif
+#include "opt_ddb.h"/* for OPT_DDB */
+#include "opt_global.h" /* for OPT_KDTRACE_HOOKS */
+#include "opt_stack.h" /* for OPT_STACK */
+
static boolean_t elf32_arm_abi_supported(struct image_params *);
u_long elf_hwcap;
@@ -311,11 +315,13 @@ elf_cpu_load_file(linker_file_t lf)
cpu_icache_sync_range((vm_offset_t)lf->address, (vm_size_t)lf->size);
#endif
+#if defined(DDB) || defined(KDTRACE_HOOKS) || defined(STACK)
/*
* Inform the stack(9) code of the new module, so it can acquire its
* per-module unwind data.
*/
unwind_module_loaded(lf);
+#endif
return (0);
}
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r356211 - in head/sys: arm/arm conf
Author: ian
Date: Mon Dec 30 23:20:46 2019
New Revision: 356211
URL: https://svnweb.freebsd.org/changeset/base/356211
Log:
Set a "kernbase" symbol in 32-bit arm locore.S and use it with ldscript.arm.
This brings arm into line with how every other arch does it. For some
reason, only arm lacked a definition of a symbol named kernbase in its
locore.S file(s) for use in its ldscript.arm file. Needlessly different
means harder to maintain.
Using a common symbol name also eases work in progress on a script to help
generate arm and arm64 kernels packaged in various ways (like with a header
blob needed for a bootloader prepended to the kernel file).
Modified:
head/sys/arm/arm/locore-v4.S
head/sys/arm/arm/locore-v6.S
head/sys/conf/Makefile.arm
Modified: head/sys/arm/arm/locore-v4.S
==
--- head/sys/arm/arm/locore-v4.SMon Dec 30 22:39:29 2019
(r356210)
+++ head/sys/arm/arm/locore-v4.SMon Dec 30 23:20:46 2019
(r356211)
@@ -62,9 +62,11 @@ __FBSDID("$FreeBSD$");
*/
.text
.align 2
+
+ .globl kernbase
+ .set kernbase,KERNVIRTADDR
+
#ifdef PHYSADDR
-.globl kernbase
-.set kernbase,KERNBASE
.globl physaddr
.set physaddr,PHYSADDR
#endif
Modified: head/sys/arm/arm/locore-v6.S
==
--- head/sys/arm/arm/locore-v6.SMon Dec 30 22:39:29 2019
(r356210)
+++ head/sys/arm/arm/locore-v6.SMon Dec 30 23:20:46 2019
(r356211)
@@ -59,6 +59,9 @@ __FBSDID("$FreeBSD$");
.text
.align 2
+ .globl kernbase
+ .set kernbase,KERNVIRTADDR
+
#if __ARM_ARCH >= 7
#defineHANDLE_HYP
\
/* Leave HYP mode */;\
Modified: head/sys/conf/Makefile.arm
==
--- head/sys/conf/Makefile.arm Mon Dec 30 22:39:29 2019(r356210)
+++ head/sys/conf/Makefile.arm Mon Dec 30 23:20:46 2019(r356211)
@@ -61,7 +61,7 @@ KERNVIRTADDR= 0xc000
# "ELF for the ARM architecture" for more info on the mapping symbols.
SYSTEM_LD= \
${SYSTEM_LD_BASECMD} \
- --defsym='text_start=${KERNVIRTADDR} + SIZEOF_HEADERS' \
+ --defsym='text_start=kernbase + SIZEOF_HEADERS' \
-o ${.TARGET} ${SYSTEM_OBJS} vers.o; \
$(OBJCOPY) \
--wildcard \
@@ -77,7 +77,7 @@ KERNEL_EXTRA_INSTALL+= ${KERNEL_KO}.bin
${KERNEL_KO}.bin: ${SYSTEM_DEP} vers.o
@echo "linking ${.TARGET}"
@${SYSTEM_LD_BASECMD} \
- --defsym='text_start=${KERNVIRTADDR}' \
+ --defsym='text_start=kernbase' \
-o ${.TARGET} ${SYSTEM_OBJS} vers.o
${SIZE} ${.TARGET}
@${OBJCOPY} \
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r356180 - head/sys/conf
On Sun, 2019-12-29 at 18:17 +, Ian Lepore wrote: > Author: ian > Date: Sun Dec 29 18:17:12 2019 > New Revision: 356180 > URL: https://svnweb.freebsd.org/changeset/base/356180 > > Log: > Eliminate the generated ldscript for arm and arm64, and strip $a/$d marker > symbols from the linked kernel. > > The main thrust of this change is to generate a kernel that has the arm > "marker" symbols stripped. Marker symbols start with $a, $d, $t or $x, and > are emitted by the compiler to tell other toolchain components about the > locations of data embedded in the instruction stream (literal-pool > stuff). They are used for generating mixed-endian binaries (which we don't > support). The linked kernel has approximately 21,000 such symbols in it, > wasting space (500K in kernel.full, 190K in the final linked kernel), and > sometimes obscuring function names in stack tracebacks. > > This change also simplifies the way the kernel is linked. Instead of using > sed to generate two different ldscript files to generate both an elf kernel > and a binary (elf headers stripped) kernel, we now use a single ldscript > that refers to a "text_start" symbol, and we provide the value for that > symbol using --defsym on the linker command line. > Doh! Differential Revision:https://reviews.freebsd.org/D22922 -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r356180 - head/sys/conf
Author: ian
Date: Sun Dec 29 18:17:12 2019
New Revision: 356180
URL: https://svnweb.freebsd.org/changeset/base/356180
Log:
Eliminate the generated ldscript for arm and arm64, and strip $a/$d marker
symbols from the linked kernel.
The main thrust of this change is to generate a kernel that has the arm
"marker" symbols stripped. Marker symbols start with $a, $d, $t or $x, and
are emitted by the compiler to tell other toolchain components about the
locations of data embedded in the instruction stream (literal-pool
stuff). They are used for generating mixed-endian binaries (which we don't
support). The linked kernel has approximately 21,000 such symbols in it,
wasting space (500K in kernel.full, 190K in the final linked kernel), and
sometimes obscuring function names in stack tracebacks.
This change also simplifies the way the kernel is linked. Instead of using
sed to generate two different ldscript files to generate both an elf kernel
and a binary (elf headers stripped) kernel, we now use a single ldscript
that refers to a "text_start" symbol, and we provide the value for that
symbol using --defsym on the linker command line.
Modified:
head/sys/conf/Makefile.arm
head/sys/conf/Makefile.arm64
head/sys/conf/ldscript.arm
head/sys/conf/ldscript.arm64
Modified: head/sys/conf/Makefile.arm
==
--- head/sys/conf/Makefile.arm Sun Dec 29 17:19:57 2019(r356179)
+++ head/sys/conf/Makefile.arm Sun Dec 29 18:17:12 2019(r356180)
@@ -32,9 +32,6 @@ S=../../..
INCLUDES+= -I$S/contrib/libfdt -I$S/gnu/dts/include
-SYSTEM_LD:= ${SYSTEM_LD:$S/conf/ldscript.$M=ldscript.$M}
-SYSTEM_DEP:= ${SYSTEM_DEP:$S/conf/ldscript.$M=ldscript.$M}
-
.if !defined(DEBUG) && !defined(PROFLEVEL)
STRIP_FLAGS = -S
.endif
@@ -58,20 +55,41 @@ CFLAGS += -mllvm -arm-enable-ehabi
KERNVIRTADDR= 0xc000
.endif
+# Use a custom SYSTEM_LD command to generate the elf kernel, so we can
+# set the text segment start address, and also strip the "arm mapping
+# symbols" which have names like $a.0 and $d.2; see the document
+# "ELF for the ARM architecture" for more info on the mapping symbols.
+SYSTEM_LD= \
+ ${SYSTEM_LD_BASECMD} \
+ --defsym='text_start=${KERNVIRTADDR} + SIZEOF_HEADERS' \
+ -o ${.TARGET} ${SYSTEM_OBJS} vers.o; \
+ $(OBJCOPY) \
+ --wildcard \
+ --strip-symbol='$$[adt]*' \
+ ${.TARGET}
+
+# Generate the .bin (no elf headers) kernel as an extra build output.
+# We must relink to generate the .bin kernel, because without headers the
+# location of everything changes. We also strip the ARM marker symbols.
+KERNEL_EXTRA+= ${KERNEL_KO}.bin
+KERNEL_EXTRA_INSTALL+= ${KERNEL_KO}.bin
+
+${KERNEL_KO}.bin: ${SYSTEM_DEP} vers.o
+ @echo "linking ${.TARGET}"
+ @${SYSTEM_LD_BASECMD} \
+ --defsym='text_start=${KERNVIRTADDR}' \
+ -o ${.TARGET} ${SYSTEM_OBJS} vers.o
+ ${SIZE} ${.TARGET}
+ @${OBJCOPY} \
+ --wildcard \
+ --strip-symbol='$$[adt]*' \
+ --output-target=binary \
+ ${.TARGET}
+ @chmod 755 ${.TARGET}
+
# hack because genassym.c includes sys/bus.h which includes these.
genassym.o: bus_if.h device_if.h
-SYSTEM_LD_ = ${LD} -m ${LD_EMULATION} -Bdynamic -T ldscript.$M.noheader \
- ${_LDFLAGS} --no-warn-mismatch --warn-common --export-dynamic \
- --dynamic-linker /red/herring \
- -o ${FULLKERNEL}.noheader -X ${SYSTEM_OBJS} vers.o
-SYSTEM_LD_TAIL +=;sed s/" + SIZEOF_HEADERS"// ldscript.$M \
- >ldscript.$M.noheader; \
- ${SYSTEM_LD_}; \
- ${OBJCOPY} -S -O binary ${FULLKERNEL}.noheader \
- ${KERNEL_KO}.bin; \
- rm ${FULLKERNEL}.noheader
-
%BEFORE_DEPEND
%OBJS
@@ -84,10 +102,7 @@ SYSTEM_LD_TAIL +=;sed s/" + SIZEOF_HEADERS"// ldscript
%CLEAN
-CLEAN+=ldscript.$M ${KERNEL_KO}.bin ldscript.$M.noheader
-
-ldscript.$M: $S/conf/ldscript.$M
- sed s/KERNVIRTADDR/${KERNVIRTADDR}/g > ldscript.$M < $S/conf/ldscript.$M
+CLEAN+=${KERNEL_KO}.bin
%RULES
Modified: head/sys/conf/Makefile.arm64
==
--- head/sys/conf/Makefile.arm64Sun Dec 29 17:19:57 2019
(r356179)
+++ head/sys/conf/Makefile.arm64Sun Dec 29 18:17:12 2019
(r356180)
@@ -27,24 +27,42 @@ S= ../../..
INCLUDES+= -I$S/contrib/libfdt
-#SYSTEM_LD:= ${SYSTEM_LD:$S/conf/ldscript.$M=ldscript.$M}
-#SYSTEM_DEP:= ${SYSTEM_DEP:$S/conf/ldscript.$M=ldscript.$M}
+# Use a custom SYSTEM_LD command to generate the elf kernel, so we can
+# set the text segment start address, and also strip the "arm mapping
+# symbols" which have names like $a.0 and $d.2; see the document
+# "ELF for the ARM architecture" for more info on the mapping symbols.
+SYSTEM_LD= \
+ ${SYSTEM_LD_BASECMD} \
+
svn commit: r356086 - head/sys/conf
Author: ian Date: Thu Dec 26 02:22:38 2019 New Revision: 356086 URL: https://svnweb.freebsd.org/changeset/base/356086 Log: Add comments to a couple i2c device lines. Modified: head/sys/conf/NOTES Modified: head/sys/conf/NOTES == --- head/sys/conf/NOTES Wed Dec 25 22:33:47 2019(r356085) +++ head/sys/conf/NOTES Thu Dec 26 02:22:38 2019(r356086) @@ -2322,10 +2322,10 @@ device jedec_dimm # iicbbgeneric I2C bit-banging code (needed by lpbb, bktr) # device iicbus # Bus support, required for ic/iic/iicsmb below. -device iicbb +device iicbb # bitbang driver; implements i2c on a pair of gpio pins device ic -device iic +device iic # userland access to i2c slave devices via ioctl(8) device iicsmb # smb over i2c bridge device iicoc # OpenCores I2C controller support ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r356085 - head/sys/conf
Author: ian
Date: Wed Dec 25 22:33:47 2019
New Revision: 356085
URL: https://svnweb.freebsd.org/changeset/base/356085
Log:
In kern.pre.mk, split SYSTEM_LD into two variables to avoid duplication in
other files.
Arm and mips systems need to replace the SYSTEM_LD variable because they
need to create intermediate files which are post-processed with objcopy to
create the final .TARGET file. Previously they did so by pasting the full
expansion of SYSTEM_LD with the output filename replaced. This means
changing SYSTEM_LD in kern.pre.mk means you need to chase down anything that
replaces it and figure out how it differs so you can paste your changes in
there too.
Now there is a SYSTEM_LD_BASECMD variable that holds the entire basic kernel
linker command without the input and output files. This will allow arm and
mips makefiles to create their custom versions by refering to
SYSTEM_LD_BASECMD, which then becomes the one place where you have to make
changes to the basic linker command args.
Differential Revision:https://reviews.freebsd.org/D22921
Modified:
head/sys/conf/kern.pre.mk
Modified: head/sys/conf/kern.pre.mk
==
--- head/sys/conf/kern.pre.mk Wed Dec 25 22:25:30 2019(r356084)
+++ head/sys/conf/kern.pre.mk Wed Dec 25 22:33:47 2019(r356085)
@@ -266,10 +266,11 @@ MD_ROOT_SIZE_CONFIGURED!= grep MD_ROOT_SIZE opt_md.h |
SYSTEM_OBJS+= embedfs_${MFS_IMAGE:T:R}.o
.endif
.endif
-SYSTEM_LD= @${LD} -m ${LD_EMULATION} -Bdynamic -T ${LDSCRIPT} ${_LDFLAGS} \
+SYSTEM_LD_BASECMD= \
+ ${LD} -m ${LD_EMULATION} -Bdynamic -T ${LDSCRIPT} ${_LDFLAGS} \
--no-warn-mismatch --warn-common --export-dynamic \
- --dynamic-linker /red/herring \
- -o ${.TARGET} -X ${SYSTEM_OBJS} vers.o
+ --dynamic-linker /red/herring -X
+SYSTEM_LD= @${SYSTEM_LD_BASECMD} -o ${.TARGET} ${SYSTEM_OBJS} vers.o
SYSTEM_LD_TAIL= @${OBJCOPY} --strip-symbol gcc2_compiled. ${.TARGET} ; \
${SIZE} ${.TARGET} ; chmod 755 ${.TARGET}
SYSTEM_DEP+= ${LDSCRIPT}
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r356078 - head/sys/conf
On Wed, 2019-12-25 at 19:52 +0100, Kristof Provost wrote: > > On 25 Dec 2019, at 19:24, Ian Lepore wrote: > > > > Author: ian > > Date: Wed Dec 25 18:24:38 2019 > > New Revision: 356078 > > URL: https://svnweb.freebsd.org/changeset/base/356078 > > > > Log: > > Revert r356077, apparently the change doesn't work after all > > (failed to > > build in CI). > > I built with (an external) LLVM, so that might be the difference. > > Regards, > Kristof > And I apparently can't build it at all, because when I try to follow the instructions and install the package it tells me to, I get a package with freebsd12.0 in the name, then at runtime it's looking for something with 13.0 in the name. And if I try to update my system to something later, my video card turns into a pumpkin (and it's not an old or obsolete card, although it is almost certainly a lower-end card than any self-respecting video card driver writer owns). -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r356078 - head/sys/conf
Author: ian
Date: Wed Dec 25 18:24:38 2019
New Revision: 356078
URL: https://svnweb.freebsd.org/changeset/base/356078
Log:
Revert r356077, apparently the change doesn't work after all (failed to
build in CI).
Modified:
head/sys/conf/Makefile.riscv
Modified: head/sys/conf/Makefile.riscv
==
--- head/sys/conf/Makefile.riscvWed Dec 25 17:26:51 2019
(r356077)
+++ head/sys/conf/Makefile.riscvWed Dec 25 18:24:38 2019
(r356078)
@@ -28,10 +28,10 @@ S= ../../..
INCLUDES+= -I$S/contrib/libfdt
-# XXX Make text segments writable. This has historically been set for
-# riscv, but some preliminary testing shows it may not be needed; this
-# can likely be removed after some more testing.
-LDFLAGS+= -N
+SYSTEM_LD= @${LD} -N -m ${LD_EMULATION} -Bdynamic -T ${LDSCRIPT} ${_LDFLAGS} \
+ --no-warn-mismatch --warn-common --export-dynamic \
+ --dynamic-linker /red/herring \
+ -o ${.TARGET} -X ${SYSTEM_OBJS} vers.o
.if !empty(DDB_ENABLED)
CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
