Remove hardcoded ${HOSTCC} calls in games?
Hi tech@,
When trying the GCC 11 static analyzer on games, I noticed that some of
them (adventure, boggle, fortune, hack, monop, phantasia) have hardcoded
calls to ${HOSTCC}. They would obviously not compile when passed the GCC's
"-fanalyzer" flag through CFLAGS as it is not recognized by Clang.
Most of those calls were added in 1996 by the following commit:
https://github.com/openbsd/src/commit/da34e3c3d40263be91967714eaa1a2c4390ea117
And the remaining ones in early 1997:
https://github.com/openbsd/src/commit/bdcd13e0503c5cfa23706bc22449229ca71dddaf
https://github.com/openbsd/src/commit/06f1ba87d9fbb136e239d3f8fa0b8a7c8c825687
Unless I'm mistaken, I don't see any reason why we need to keep them.
The following diff removes them.
Comments? OK?
Index: games/adventure/Makefile
===
RCS file: /cvs/src/games/adventure/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- games/adventure/Makefile23 May 2002 18:42:59 - 1.5
+++ games/adventure/Makefile12 Oct 2023 07:39:02 -
@@ -9,6 +9,6 @@ data.c: glorkz setup
./setup ${.CURDIR}/glorkz > data.c
setup: setup.c hdr.h
- ${HOSTCC} -o setup ${.CURDIR}/setup.c
+ ${CC} -o setup ${.CURDIR}/setup.c
.include
Index: games/boggle/mkdict/Makefile
===
RCS file: /cvs/src/games/boggle/mkdict/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- games/boggle/mkdict/Makefile7 Jan 2016 16:00:31 - 1.4
+++ games/boggle/mkdict/Makefile12 Oct 2023 07:39:02 -
@@ -5,7 +5,6 @@
PROG= mkdict
CFLAGS+=-I${.CURDIR}/../boggle
NOMAN=noman
-CC=${HOSTCC}
install:
Index: games/boggle/mkindex/Makefile
===
RCS file: /cvs/src/games/boggle/mkindex/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- games/boggle/mkindex/Makefile 7 Jan 2016 16:00:31 - 1.4
+++ games/boggle/mkindex/Makefile 12 Oct 2023 07:39:02 -
@@ -5,7 +5,6 @@
PROG= mkindex
CFLAGS+=-I${.CURDIR}/../boggle
NOMAN=noman
-CC=${HOSTCC}
install:
Index: games/fortune/strfile/Makefile
===
RCS file: /cvs/src/games/fortune/strfile/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- games/fortune/strfile/Makefile 9 Feb 1997 13:52:40 - 1.4
+++ games/fortune/strfile/Makefile 12 Oct 2023 07:39:02 -
@@ -4,6 +4,5 @@
PROG= strfile
MAN= strfile.8
-CC=${HOSTCC}
.include
Index: games/hack/Makefile
===
RCS file: /cvs/src/games/hack/Makefile,v
retrieving revision 1.17
diff -u -p -r1.17 Makefile
--- games/hack/Makefile 5 Apr 2019 09:02:27 - 1.17
+++ games/hack/Makefile 12 Oct 2023 07:39:02 -
@@ -24,7 +24,7 @@ hack.onames.h: makedefs def.objects.h
${.OBJDIR}/makedefs ${.CURDIR}/def.objects.h > hack.onames.h
makedefs: makedefs.c
- ${HOSTCC} ${CFLAGS} ${LDFLAGS} ${LDSTATIC} -o ${.TARGET}
${.CURDIR}/${.PREFIX}.c ${LDADD}
+ ${CC} ${CFLAGS} ${LDFLAGS} ${LDSTATIC} -o ${.TARGET}
${.CURDIR}/${.PREFIX}.c ${LDADD}
beforeinstall:
${INSTALL} ${INSTALL_COPY} -o ${BINOWN} -g ${BINGRP} -m 444
${.CURDIR}/help \
Index: games/monop/Makefile
===
RCS file: /cvs/src/games/monop/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- games/monop/Makefile23 May 2002 18:43:00 - 1.7
+++ games/monop/Makefile12 Oct 2023 07:39:02 -
@@ -12,7 +12,7 @@ cards.pck: initdeck
${.OBJDIR}/initdeck ${.CURDIR}/cards.inp
initdeck: initdeck.c
- ${HOSTCC} ${CFLAGS} ${LDFLAGS} ${LDSTATIC} -o ${.TARGET}
${.CURDIR}/initdeck.c ${LDADD}
+ ${CC} ${CFLAGS} ${LDFLAGS} ${LDSTATIC} -o ${.TARGET}
${.CURDIR}/initdeck.c ${LDADD}
beforeinstall:
${INSTALL} ${INSTALL_COPY} -o ${BINOWN} -g ${BINGRP} -m 444 cards.pck \
Index: games/phantasia/Makefile
===
RCS file: /cvs/src/games/phantasia/Makefile,v
retrieving revision 1.19
diff -u -p -r1.19 Makefile
--- games/phantasia/Makefile11 Jul 2022 03:11:49 - 1.19
+++ games/phantasia/Makefile12 Oct 2023 07:39:02 -
@@ -11,13 +11,13 @@ CLEANFILES+=map setup setup.o phantglobs
all: setup phantasia
setup.o: setup.c
- ${HOSTCC} -c ${CFLAGS} -o ${.TARGET} ${.CURDIR}/setup.c
+ ${CC} -c ${CFLAGS} -o ${.TARGET} ${.CURDIR}/setup.c
phantglobs.o.bld: phantglobs.c
- ${HOSTCC} -c ${CFLAGS} -o ${.TARGET} ${.CURDIR}/phantglobs.c
+ ${CC} -c ${CFLAGS} -o ${.TARGET} ${.CURDIR}/phantglobs.c
setup: phantglobs.o.bld setup.o monsters.asc ${DPADD}
- ${HOSTCC} ${CFLAGS} ${LDFLAGS} ${LDSTATIC} -o ${.TARGET} \
+ ${CC} ${CFLAGS} ${LDFLAGS} ${LDSTATIC} -o ${.TARGET}
fdisk: Add partition type GUIDs for NetBSD
Hi tech@,
Here is a diff to add partition type GUIDs for NetBSD in fdisk.
The values come from NetBSD's sys/sys/disklabel_gpt.h header.
Before the change:
Disk: sd1 Usable LBA: 34 to 937703054 [937703088 Sectors]
#: type [ start: size ]
0: EFI Sys [2048: 262144 ]
1: 49f48d5a-b10e-11dc-b99b-0019d1879648 [ 264192:874608640 ]
2: 49f48d32-b10e-11dc-b99b-0019d1879648 [ 874872832: 62830223 ]
After the change:
Disk: sd1 Usable LBA: 34 to 937703054 [937703088 Sectors]
#: type [ start: size ]
0: EFI Sys [2048: 262144 ]
1: NetBSD FFS [ 264192:874608640 ]
2: NetBSD swap [ 874872832: 62830223 ]
Please note that NetBSD used the FreeBSD GUIDs before their own GUIDs
were created, so I annotated the old value accordingly as legacy. We
could also remove the old entry, I have no strong feeling about this.
Comments? OK?
Index: sbin/fdisk/part.c
===
RCS file: /cvs/src/sbin/fdisk/part.c,v
retrieving revision 1.131
diff -u -p -r1.131 part.c
--- sbin/fdisk/part.c 29 Aug 2022 07:19:14 - 1.131
+++ sbin/fdisk/part.c 11 Feb 2023 11:23:14 -
@@ -191,7 +191,19 @@ const struct gpt_type gpt_types[] = {
{ 0xA8, 0, "MacOS X",
"55465300--11aa-aa11-00306543ecac" },
{ 0xA9, 0, "NetBSD",
- "516e7cb4-6ecf-11d6-8ff8-00022d09712b" },
+ "516e7cb4-6ecf-11d6-8ff8-00022d09712b" }, /* Legacy */
+ { 0xA9, 0, "NetBSD swap",
+ "49f48d32-b10e-11dc-b99b-0019d1879648" },
+ { 0xA9, 0, "NetBSD FFS",
+ "49f48d5a-b10e-11dc-b99b-0019d1879648" },
+ { 0xA9, 0, "NetBSD LFS",
+ "49f48d82-b10e-11dc-b99b-0019d1879648" },
+ { 0xA9, 0, "NetBSD RAID",
+ "49f48daa-b10e-11dc-b99b-0019d1879648" },
+ { 0xA9, 0, "NetBSD CCD",
+ "2db519c4-b10f-11dc-b99b-0019d1879648" },
+ { 0xA9, 0, "NetBSD CGD",
+ "2db519ec-b10f-11dc-b99b-0019d1879648" },
{ 0xAB, 0, "MacOS X boot",
"426f6f74--11aa-aa11-00306543ecac" },
{ 0xAF, 0, "MacOS X HFS+",
Re: Build llvm-cov in base
On Sat, Jul 30, 2022 at 12:19:54AM +0200, Frederic Cambus wrote: > Now that we have llvm-profdata in base, I would like to propose adding > llvm-cov as well. Just like llvm-profdata, it is fast to build and > only takes a few seconds on my amd64 machine. > > Having it in base would allow producing reports from coverage data > processed with llvm-profdata without having to install the devel/llvm > port. Ping. Any feedback on this? I haven't received any comments, neither publicly nor privately. Comments? OK? Any objection?
Build llvm-cov in base
Hi tech@,
Now that we have llvm-profdata in base, I would like to propose adding
llvm-cov as well. Just like llvm-profdata, it is fast to build and
only takes a few seconds on my amd64 machine.
Having it in base would allow producing reports from coverage data
processed with llvm-profdata without having to install the devel/llvm
port.
Comments? OK?
Index: gnu/usr.bin/clang/Makefile
===
RCS file: /cvs/src/gnu/usr.bin/clang/Makefile,v
retrieving revision 1.25
diff -u -p -r1.25 Makefile
--- gnu/usr.bin/clang/Makefile 26 Jul 2022 15:37:34 - 1.25
+++ gnu/usr.bin/clang/Makefile 29 Jul 2022 20:21:18 -
@@ -108,6 +108,7 @@ SUBDIR+=include/llvm-readobj
SUBDIR+=llvm-readobj
SUBDIR+=llvm-profdata
+SUBDIR+=llvm-cov
.if ${AR_VERSION:L} == "llvm" || make(obj)
SUBDIR+=libLLVMDlltoolDriver
Index: gnu/usr.bin/clang/llvm-cov/Makefile
===
RCS file: gnu/usr.bin/clang/llvm-cov/Makefile
diff -N gnu/usr.bin/clang/llvm-cov/Makefile
--- /dev/null 1 Jan 1970 00:00:00 -
+++ gnu/usr.bin/clang/llvm-cov/Makefile 29 Jul 2022 20:21:18 -
@@ -0,0 +1,29 @@
+# $OpenBSD$
+
+.include
+
+PROG= llvm-cov
+BINDIR=/usr/bin
+
+SRCS= llvm-cov.cpp \
+ gcov.cpp \
+ CodeCoverage.cpp \
+ CoverageExporterJson.cpp \
+ CoverageExporterLcov.cpp \
+ CoverageFilters.cpp \
+ CoverageReport.cpp \
+ CoverageSummaryInfo.cpp \
+ SourceCoverageView.cpp \
+ SourceCoverageViewHTML.cpp \
+ SourceCoverageViewText.cpp \
+ TestingSupport.cpp \
+
+MAN+= llvm-cov.1
+
+.PATH: ${.CURDIR}/../../../llvm/llvm/tools/llvm-cov
+
+LLVM_LIBDEPS= LLVM
+
+LDADD+= -L ${.OBJDIR}/../libLLVM -lLLVM
+
+.include
Index: gnu/usr.bin/clang/llvm-cov/llvm-cov.1
===
RCS file: gnu/usr.bin/clang/llvm-cov/llvm-cov.1
diff -N gnu/usr.bin/clang/llvm-cov/llvm-cov.1
--- /dev/null 1 Jan 1970 00:00:00 -
+++ gnu/usr.bin/clang/llvm-cov/llvm-cov.1 29 Jul 2022 20:21:18 -
@@ -0,0 +1,528 @@
+.\" Man page generated from reStructuredText.
+.
+.
+.nr rst2man-indent-level 0
+.
+.de1 rstReportMargin
+\\$1 \\n[an-margin]
+level \\n[rst2man-indent-level]
+level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
+-
+\\n[rst2man-indent0]
+\\n[rst2man-indent1]
+\\n[rst2man-indent2]
+..
+.de1 INDENT
+.\" .rstReportMargin pre:
+. RS \\$1
+. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
+. nr rst2man-indent-level +1
+.\" .rstReportMargin post:
+..
+.de UNINDENT
+. RE
+.\" indent \\n[an-margin]
+.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.nr rst2man-indent-level -1
+.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
+..
+.TH "LLVM-COV" "1" "2022-05-23" "13" "LLVM"
+.SH NAME
+llvm-cov \- emit coverage information
+.SH SYNOPSIS
+.sp
+\fBllvm\-cov\fP \fIcommand\fP [\fIargs...\fP]
+.SH DESCRIPTION
+.sp
+The \fBllvm\-cov\fP tool shows code coverage information for
+programs that are instrumented to emit profile data. It can be used to
+work with \fBgcov\fP\-style coverage or with \fBclang\fP\(aqs instrumentation
+based profiling.
+.sp
+If the program is invoked with a base name of \fBgcov\fP, it will behave as if
+the \fBllvm\-cov gcov\fP command were called. Otherwise, a command should
+be provided.
+.SH COMMANDS
+.INDENT 0.0
+.IP \(bu 2
+\fI\%gcov\fP
+.IP \(bu 2
+\fI\%show\fP
+.IP \(bu 2
+\fI\%report\fP
+.IP \(bu 2
+\fI\%export\fP
+.UNINDENT
+.SH GCOV COMMAND
+.SS SYNOPSIS
+.sp
+\fBllvm\-cov gcov\fP [\fIoptions\fP] \fISOURCEFILE\fP
+.SS DESCRIPTION
+.sp
+The \fBllvm\-cov gcov\fP tool reads code coverage data files and displays
+the coverage information for a specified source file. It is compatible with the
+\fBgcov\fP tool from version 4.2 of \fBGCC\fP and may also be compatible with
some
+later versions of \fBgcov\fP\&.
+.sp
+To use \fBllvm\-cov gcov\fP, you must first build an instrumented version
+of your application that collects coverage data as it runs. Compile with the
+\fB\-fprofile\-arcs\fP and \fB\-ftest\-coverage\fP options to add the
+instrumentation. (Alternatively, you can use the \fB\-\-coverage\fP option,
which
+includes both of those other options.)
+.sp
+At the time you compile the instrumented code, a \fB\&.gcno\fP data file will
be
+generated for each object file. These \fB\&.gcno\fP files contain half of the
+coverage data. The other half of the data comes from \fB\&.gcda\fP files that
are
+generated when you run the instrumented program, with a separate \fB\&.gcda\fP
+file for each object file. Each time you run the program, the execution counts
+are summed into any existing \fB\&.gcda\fP files, so be sure to remove any old
+files if you do not want their contents to be included.
+.sp
+By default, the \fB\&.gcda\fP files are written into the same directory as the
+object files, but you can override that by s
Re: clang-local.1: document support for source-based code coverage
On Wed, May 04, 2022 at 09:50:47AM -0600, Theo de Raadt wrote: > > > Isn't the purpose of the clang-local(1) to document local changes to the > > > system compiler, -fsanitize-minimal-runtime feels like a special case as > > > we do not have the complete sanitizer runtime. > > > > What do you suggest as a good location where people will > > find that information easily ? > > Who knows, but probably not in clang-local.1 > > I actually find it a bit offensive when a base document has to mention > something not in base. While here, let me make a comment on the This is a valid objection, and there were other concerns about clang-local.1 not being an adequate place to mention this, so I'm withdrawing this diff. > proposal's use of the token "devel/llvm" -- that is so completely obtuse > and out of touch with the potential user base. The average person will > not understand that at all. It is hugely presumptious that anyone > searching for this compiler tooling will be familiar with the "ports" > tree-heiracry; the reality is NOONE uses ports, instead they use > packages with has a completely different namespace, and thus > "devel/llvm" is completely meaningless to a person who uses packages. That's a nice slogan idea for a future ports hackathon t-shirt: "the reality is NOONE uses ports". On a more serious note though, building from ports was the only way to have -stable packages before we started to offer -stable binary packages with OpenBSD 6.5, and it is still the only way for users of architectures for which those packages are not provided. It's thus reasonable to assume most of our users are familiar with the ports tree hierarchy terminology.
Re: pcidevs update for AMD Sensor Fusion Hub
On Thu, May 05, 2022 at 08:04:16PM +1000, Jonathan Gray wrote: > On Thu, May 05, 2022 at 11:26:23AM +0200, Frederic Cambus wrote: > > Hi tech@, > > > > Here is a diff to add ID for the AMD Sensor Fusion Hub found on my > > Ryzen-based ZBOX CA621. Full dmesg below. > > > > Comments? OK? > > Can the string instead be "17h/1xh SFH"? Sure thing, new diff below. Index: sys/dev/pci/pcidevs === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.1992 diff -u -p -r1.1992 pcidevs --- sys/dev/pci/pcidevs 4 May 2022 08:10:43 - 1.1992 +++ sys/dev/pci/pcidevs 5 May 2022 10:28:50 - @@ -818,6 +818,7 @@ product AMD 17_1X_XHCI_10x15e0 17h/1xh product AMD 17_1X_XHCI_2 0x15e1 17h/1xh xHCI product AMD 17_1X_ACP 0x15e2 17h/1xh I2S Audio product AMD 17_1X_HDA 0x15e3 17h/1xh HD Audio +product AMD 17_1X_SFH 0x15e6 17h/1xh SFH product AMD 17_1X_DF_0 0x15e8 17h/1xh Data Fabric product AMD 17_1X_DF_1 0x15e9 17h/1xh Data Fabric product AMD 17_1X_DF_2 0x15ea 17h/1xh Data Fabric
pcidevs update for AMD Sensor Fusion Hub
Hi tech@, Here is a diff to add ID for the AMD Sensor Fusion Hub found on my Ryzen-based ZBOX CA621. Full dmesg below. Comments? OK? Index: sys/dev/pci/pcidevs === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.1988 diff -u -p -r1.1988 pcidevs --- sys/dev/pci/pcidevs 11 Mar 2022 08:28:40 - 1.1988 +++ sys/dev/pci/pcidevs 4 May 2022 09:04:34 - @@ -818,6 +818,7 @@ product AMD 17_1X_XHCI_10x15e0 17h/1xh product AMD 17_1X_XHCI_2 0x15e1 17h/1xh xHCI product AMD 17_1X_ACP 0x15e2 17h/1xh I2S Audio product AMD 17_1X_HDA 0x15e3 17h/1xh HD Audio +product AMD 17_1X_SFH 0x15e6 17h/1xh Sensor Fusion Hub product AMD 17_1X_DF_0 0x15e8 17h/1xh Data Fabric product AMD 17_1X_DF_1 0x15e9 17h/1xh Data Fabric product AMD 17_1X_DF_2 0x15ea 17h/1xh Data Fabric OpenBSD 7.1-current (GENERIC.MP) #1: Wed May 4 13:09:09 CEST 2022 fcam...@amd64.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 32125165568 (30636MB) avail mem = 31134224384 (29691MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xeacc0 (44 entries) bios0: vendor American Megatrends Inc. version "B410P112" date 09/08/2021 bios0: ZOTAC B410 acpi0 at bios0: ACPI 6.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT SSDT MCFG HPET UEFI TPM2 SSDT CRAT CDIT SSDT SSDT SSDT WSMT SSDT acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP2(S4) GPP3(S4) GPP4(S4) GPP5(S4) GPP6(S4) GP17(S4) XHC0(S4) XHC1(S4) GP18(S4) SIO1(S3) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx, 2595.56 MHz, 17-18-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx, 2595.10 MHz, 17-18-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx, 2595.10 MHz, 17-18-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu2: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx, 2595.10 MHz, 17-18-01 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu3: 64KB 64b/line 4-way I-cache,
clang-local.1: document support for source-based code coverage
Hi tech@, The base system includes the compiler-rt profile library for source-based code coverage. So here is a diff to document support in clang-local.1, the same way we document support for the ubsan_minimal sanitizer runtime which is also part of compiler-rt. Comments? OK? Index: share/man/man1/clang-local.1 === RCS file: /cvs/src/share/man/man1/clang-local.1,v retrieving revision 1.23 diff -u -p -r1.23 clang-local.1 --- share/man/man1/clang-local.118 Feb 2022 00:39:18 - 1.23 +++ share/man/man1/clang-local.14 May 2022 11:03:11 - @@ -99,6 +99,15 @@ See the documentation for the .Fl fsanitize-minimal-runtime flag. .It +The base system includes the compiler-rt profile library for +source-based code coverage. See the documentation for the +.Fl fprofile-instr-generate +and +.Fl fcoverage-mapping +flags. +Note that llvm-profdata and llvm-cov tools from devel/llvm are +required to process coverage data and produce reports. +.It The .Xr malloc 3 , .Xr calloc 3 ,
Re: Stop mentioning ld(1) warning messages in mktemp.3 and tmpnam.3
On Mon, Oct 25, 2021 at 07:41:51AM -0600, Todd C. Miller wrote: > On Mon, 25 Oct 2021 12:48:01 +1100, Jonathan Gray wrote: > > > Shouldn't lld instead be changed to show warnings? > > That was my thinking as well. After discussing the matter with other developers during h2k21, this is indeed the consensus. I'm building myself a small tool [1] to display .gnu.warning.* sections names in ELF objects along with their content, and will check which other projects use those sections. So far, aside from us, FreeBSD, NetBSD, and DragonFly all use these sections in their libc, and glibc does as well. There is an issue [2] in the LLVM bugtracker about adding support in LLD to generate linker warnings when encountering these sections, I will see what can be done on that topic. [1] https://github.com/fcambus/gwcheck [2] https://bugs.llvm.org/show_bug.cgi?id=42008
Re: Enable Spleen 16x32 and 32x64 on riscv64
On Fri, Oct 29, 2021 at 06:20:07PM -0400, Brad Smith wrote: > > Therefore, here is a diff to enable spleen16x32 and spleen32x64 on riscv64 > > for GENERIC kernels, like we do on amd64, arm64, armv7, and i386. > > > > Comments? OK? > > Sounds like this should be enabled on powerpc64 too? I got an OK for the riscv64 part so I committed it. Looking at the GENERIC kernel conf file for powerpc64, it indeed appears that it has radeondrm(4) support, and that it would be useful to enable the fonts on this platform as well. The following diff does that. Thanks for pointing this out, Brad. Comments? OK? Index: sys/dev/wsfont/wsfont.c === RCS file: /cvs/src/sys/dev/wsfont/wsfont.c,v retrieving revision 1.60 diff -u -p -r1.60 wsfont.c --- sys/dev/wsfont/wsfont.c 1 Nov 2021 18:43:04 - 1.60 +++ sys/dev/wsfont/wsfont.c 2 Nov 2021 13:51:52 - @@ -102,7 +102,8 @@ #endif #if !defined(SMALL_KERNEL) && (defined(__amd64__) || defined(__i386__) || \ -defined(__arm64__) || defined(__armv7__) || defined(__riscv64__)) +defined(__arm64__) || defined(__armv7__) || defined(__riscv64__) || \ +defined(__powerpc64__)) #define FONT_SPLEEN16x32 #define FONT_SPLEEN32x64 #endif
Enable Spleen 16x32 and 32x64 on riscv64
Hi tech@, It has come to my attention that OpenBSD/riscv64 has support for at least radeondrm(4), and can drive a 4k monitor. Therefore, here is a diff to enable spleen16x32 and spleen32x64 on riscv64 for GENERIC kernels, like we do on amd64, arm64, armv7, and i386. Comments? OK? Index: sys/dev/wsfont/wsfont.c === RCS file: /cvs/src/sys/dev/wsfont/wsfont.c,v retrieving revision 1.59 diff -u -p -r1.59 wsfont.c --- sys/dev/wsfont/wsfont.c 1 May 2021 16:11:16 - 1.59 +++ sys/dev/wsfont/wsfont.c 29 Oct 2021 21:58:23 - @@ -102,7 +102,7 @@ #endif #if !defined(SMALL_KERNEL) && (defined(__amd64__) || defined(__i386__) || \ -defined(__arm64__) || defined(__armv7__)) +defined(__arm64__) || defined(__armv7__) || defined(__riscv64__)) #define FONT_SPLEEN16x32 #define FONT_SPLEEN32x64 #endif
libc: Wrap __warn_references occurences in #if defined(APIWARN)
Hi tech@, Most (but not all) __warn_references occurences in libc are wrapped in #if defined(APIWARN) blocks. This diff wraps the remaining occurences, so building libc without the APIWARN definition does not produce any strain .gnu.warning.* sections. Comments? OK? Index: lib/libc/compat-43/getwd.c === RCS file: /cvs/src/lib/libc/compat-43/getwd.c,v retrieving revision 1.12 diff -u -p -r1.12 getwd.c --- lib/libc/compat-43/getwd.c 28 Nov 2017 06:55:49 - 1.12 +++ lib/libc/compat-43/getwd.c 24 Oct 2021 22:07:40 - @@ -45,5 +45,7 @@ getwd(char *buf) return(NULL); } +#if defined(APIWARN) __warn_references(getwd, "getwd() possibly used unsafely; consider using getcwd()"); +#endif Index: lib/libc/stdio/mktemp.c === RCS file: /cvs/src/lib/libc/stdio/mktemp.c,v retrieving revision 1.39 diff -u -p -r1.39 mktemp.c --- lib/libc/stdio/mktemp.c 28 Nov 2017 06:55:49 - 1.39 +++ lib/libc/stdio/mktemp.c 24 Oct 2021 22:07:41 - @@ -118,8 +118,10 @@ _mktemp(char *path) return(path); } +#if defined(APIWARN) __warn_references(mktemp, "mktemp() possibly used unsafely; consider using mkstemp()"); +#endif char * mktemp(char *path) Index: lib/libc/stdio/tempnam.c === RCS file: /cvs/src/lib/libc/stdio/tempnam.c,v retrieving revision 1.20 diff -u -p -r1.20 tempnam.c --- lib/libc/stdio/tempnam.c28 Nov 2017 06:55:49 - 1.20 +++ lib/libc/stdio/tempnam.c24 Oct 2021 22:07:41 - @@ -36,8 +36,10 @@ #include #include +#if defined(APIWARN) __warn_references(tempnam, "tempnam() possibly used unsafely; consider using mkstemp()"); +#endif char * tempnam(const char *dir, const char *pfx) Index: lib/libc/stdio/tmpnam.c === RCS file: /cvs/src/lib/libc/stdio/tmpnam.c,v retrieving revision 1.12 diff -u -p -r1.12 tmpnam.c --- lib/libc/stdio/tmpnam.c 28 Nov 2017 06:55:49 - 1.12 +++ lib/libc/stdio/tmpnam.c 24 Oct 2021 22:07:41 - @@ -36,8 +36,10 @@ #include #include +#if defined(APIWARN) __warn_references(tmpnam, "tmpnam() possibly used unsafely; consider using mkstemp()"); +#endif char * tmpnam(char *s)
Stop mentioning ld(1) warning messages in mktemp.3 and tmpnam.3
Hi tech@, This diff removes mentions of ld warning messages for mktemp(3), tmpnam(3), and tempnam(3). LLD doesn't emit warnings when encountering .gnu.warning.* sections, so those warnings are not emitted anymore for a majority of users since we switched to LLD as the default linker on most architectures. Manual pages for other libc functions for which we have .gnu.warning.* sections did not mention ld warnings. For the record, those functions are: getwd(3), rand(3), rand_r(3), random(3), sprintf(3), stpcpy(3), strcat(3), strcpy(3), vsprintf(3), wcscat(3), and wcscpy(3). Comments? OK? Index: lib/libc/stdio/mktemp.3 === RCS file: /cvs/src/lib/libc/stdio/mktemp.3,v retrieving revision 1.54 diff -u -p -r1.54 mktemp.3 --- lib/libc/stdio/mktemp.3 26 Oct 2014 12:54:18 - 1.54 +++ lib/libc/stdio/mktemp.3 24 Oct 2021 10:38:29 - @@ -408,8 +408,3 @@ Whenever it is possible, or .Fn mkdtemp should be used instead. -.Pp -For this reason, -.Xr ld 1 -will output a warning message whenever it links code that uses -.Fn mktemp . Index: lib/libc/stdio/tmpnam.3 === RCS file: /cvs/src/lib/libc/stdio/tmpnam.3,v retrieving revision 1.23 diff -u -p -r1.23 tmpnam.3 --- lib/libc/stdio/tmpnam.3 30 Aug 2019 23:33:45 - 1.23 +++ lib/libc/stdio/tmpnam.3 24 Oct 2021 10:38:29 - @@ -219,10 +219,3 @@ temporary files are created. .Pp This implementation does not have these flaws, but portable software cannot depend on that. -.Pp -For these reasons, -.Xr ld 1 -will output a warning message whenever it links code that uses the functions -.Fn tmpnam -or -.Fn tempnam .
Re: Larger kernel fonts in RAMDISK_CD?
On Sun, Jun 06, 2021 at 10:42:59PM +0200, Frederic Cambus wrote: > On Wed, Jun 02, 2021 at 07:56:07PM -0600, Theo de Raadt wrote: > > I am satisfied. > > > > That is one architecture. I suggest checking which others can use > > the same treatment. > > I was going to build i386 releases, but then realized we don't have > efifb on this platform, so we don't need the fonts on RAMDISKs. > > This leaves us with armv7 and arm64. Unfortunately I currently do not > have access to hardware to build releases on, so I would need help on > this front. Anyone willing to try building either version 1) or 2) of > the diffs below (depending if we decide to add only the 16x32 font or > both the 12x24 and 16x32)? Thanks in advance. Here is an update on this, I've been kindly given access (thanks!) to an arm64 system and successfully built a release with the diff below adding both the 12x24 and 16x32 versions. Result of running df -h on the mounted miniroot image produced: /dev/vnd0a18.9M 16.7M2.3M88%/mnt Let's skip armv7 for now, very few of the armv7 hardware we support even has video output anyway. So I'm now asking for OKs for the following diff taking care of amd64 and arm64: Index: sys/arch/amd64/conf/RAMDISK_CD === RCS file: /cvs/src/sys/arch/amd64/conf/RAMDISK_CD,v retrieving revision 1.190 diff -u -p -r1.190 RAMDISK_CD --- sys/arch/amd64/conf/RAMDISK_CD 27 Dec 2020 23:05:37 - 1.190 +++ sys/arch/amd64/conf/RAMDISK_CD 5 Jun 2021 21:45:58 - @@ -20,6 +20,10 @@ option MSDOSFS option INET6 option CRYPTO +option FONT_SPLEEN8x16 +option FONT_SPLEEN12x24 +option FONT_SPLEEN16x32 + option RAMDISK_HOOKS option MINIROOTSIZE=7360 Index: sys/arch/arm64/conf/RAMDISK === RCS file: /cvs/src/sys/arch/arm64/conf/RAMDISK,v retrieving revision 1.153 diff -u -p -r1.153 RAMDISK --- sys/arch/arm64/conf/RAMDISK 29 May 2021 08:50:07 - 1.153 +++ sys/arch/arm64/conf/RAMDISK 5 Jun 2021 21:45:58 - @@ -9,6 +9,10 @@ option SMALL_KERNEL option NO_PROPOLICE option BOOT_CONFIG +option FONT_SPLEEN8x16 +option FONT_SPLEEN12x24 +option FONT_SPLEEN16x32 + option RAMDISK_HOOKS option MINIROOTSIZE=24576 Comments? OK?
Re: Larger kernel fonts in RAMDISK_CD?
On Wed, Jun 02, 2021 at 07:56:07PM -0600, Theo de Raadt wrote: > I am satisfied. > > That is one architecture. I suggest checking which others can use > the same treatment. I was going to build i386 releases, but then realized we don't have efifb on this platform, so we don't need the fonts on RAMDISKs. This leaves us with armv7 and arm64. Unfortunately I currently do not have access to hardware to build releases on, so I would need help on this front. Anyone willing to try building either version 1) or 2) of the diffs below (depending if we decide to add only the 16x32 font or both the 12x24 and 16x32)? Thanks in advance. 1) Diff for adding only Spleen 16x32: Index: sys/arch/amd64/conf/RAMDISK_CD === RCS file: /cvs/src/sys/arch/amd64/conf/RAMDISK_CD,v retrieving revision 1.190 diff -u -p -r1.190 RAMDISK_CD --- sys/arch/amd64/conf/RAMDISK_CD 27 Dec 2020 23:05:37 - 1.190 +++ sys/arch/amd64/conf/RAMDISK_CD 5 Jun 2021 21:43:06 - @@ -20,6 +20,9 @@ optionMSDOSFS option INET6 option CRYPTO +option FONT_SPLEEN8x16 +option FONT_SPLEEN16x32 + option RAMDISK_HOOKS option MINIROOTSIZE=7360 Index: sys/arch/arm64/conf/RAMDISK === RCS file: /cvs/src/sys/arch/arm64/conf/RAMDISK,v retrieving revision 1.153 diff -u -p -r1.153 RAMDISK --- sys/arch/arm64/conf/RAMDISK 29 May 2021 08:50:07 - 1.153 +++ sys/arch/arm64/conf/RAMDISK 5 Jun 2021 21:43:06 - @@ -9,6 +9,9 @@ option SMALL_KERNEL option NO_PROPOLICE option BOOT_CONFIG +option FONT_SPLEEN8x16 +option FONT_SPLEEN16x32 + option RAMDISK_HOOKS option MINIROOTSIZE=24576 Index: sys/arch/armv7/conf/RAMDISK === RCS file: /cvs/src/sys/arch/armv7/conf/RAMDISK,v retrieving revision 1.125 diff -u -p -r1.125 RAMDISK --- sys/arch/armv7/conf/RAMDISK 28 May 2021 15:52:11 - 1.125 +++ sys/arch/armv7/conf/RAMDISK 5 Jun 2021 21:43:06 - @@ -11,6 +11,9 @@ optionSMALL_KERNEL option NO_PROPOLICE option BOOT_CONFIG +option FONT_SPLEEN8x16 +option FONT_SPLEEN16x32 + option MINIROOTSIZE=18560 option RAMDISK_HOOKS 2) Diff for adding both Spleen 12x24 and 16x32: Index: sys/arch/amd64/conf/RAMDISK_CD === RCS file: /cvs/src/sys/arch/amd64/conf/RAMDISK_CD,v retrieving revision 1.190 diff -u -p -r1.190 RAMDISK_CD --- sys/arch/amd64/conf/RAMDISK_CD 27 Dec 2020 23:05:37 - 1.190 +++ sys/arch/amd64/conf/RAMDISK_CD 5 Jun 2021 21:45:58 - @@ -20,6 +20,10 @@ option MSDOSFS option INET6 option CRYPTO +option FONT_SPLEEN8x16 +option FONT_SPLEEN12x24 +option FONT_SPLEEN16x32 + option RAMDISK_HOOKS option MINIROOTSIZE=7360 Index: sys/arch/arm64/conf/RAMDISK === RCS file: /cvs/src/sys/arch/arm64/conf/RAMDISK,v retrieving revision 1.153 diff -u -p -r1.153 RAMDISK --- sys/arch/arm64/conf/RAMDISK 29 May 2021 08:50:07 - 1.153 +++ sys/arch/arm64/conf/RAMDISK 5 Jun 2021 21:45:58 - @@ -9,6 +9,10 @@ option SMALL_KERNEL option NO_PROPOLICE option BOOT_CONFIG +option FONT_SPLEEN8x16 +option FONT_SPLEEN12x24 +option FONT_SPLEEN16x32 + option RAMDISK_HOOKS option MINIROOTSIZE=24576 Index: sys/arch/armv7/conf/RAMDISK === RCS file: /cvs/src/sys/arch/armv7/conf/RAMDISK,v retrieving revision 1.125 diff -u -p -r1.125 RAMDISK --- sys/arch/armv7/conf/RAMDISK 28 May 2021 15:52:11 - 1.125 +++ sys/arch/armv7/conf/RAMDISK 5 Jun 2021 21:45:58 - @@ -11,6 +11,10 @@ option SMALL_KERNEL option NO_PROPOLICE option BOOT_CONFIG +option FONT_SPLEEN8x16 +option FONT_SPLEEN12x24 +option FONT_SPLEEN16x32 + option MINIROOTSIZE=18560 option RAMDISK_HOOKS
Re: Larger kernel fonts in RAMDISK_CD?
On Mon, May 31, 2021 at 12:57:47PM +0200, Mark Kettenis wrote: > > +option FONT_SPLEEN8x16 > > +option FONT_SPLEEN12x24 > > +option FONT_SPLEEN16x32 > > +option FONT_SPLEEN32x64 > > + > > option RAMDISK_HOOKS > > option MINIROOTSIZE=7360 > > > > Does this look reasonable? > > I would skip some sizes. 8x16 is readable on any screen size where > 12x24 would be picked. And maybe 16x32 is good enough for 4K screens > as well? Right, the 16x32 variant is small but readable on my 27" 4k monitor, so it sounds reasonable to skip the 32x64 version for now. For the 12x24 version I agree that it's not stricly necessary, just more comfortable. > > > If it does and if we want to go this way, I can try to build a release > > and check if MINIROOTSIZE must be bumped on RAMDISK_CD. Then we could do > > the same for i386, armv7 and arm64. > > I'm all for it, but last time this came up Theo didn't like it and > suggested adding code to scale up the fonts instead. I really don't > think you want to upscale the 8x16 font to 32x64. But if we add the > 16x32 font, upscaling that to 32x64 for the really big screens might > be an option and a reasonable compromise? Indeed, if we want to go this way, I believe upscaling the 16x32 version to 32x64 would give good enough results on 4k screens. > But figuring out how much things grow by adding the 16x32 font would > be a good start. So I built three miniroot images using the same source tree, and results are below. There was no need to bump MINIROOTSIZE. Result of running df -h on mounted vnode disks: /dev/vnd0a 4.3M4.1M146K97%/mnt0 /dev/vnd1a 4.3M4.1M146K97%/mnt1 /dev/vnd2a 4.3M4.1M146K97%/mnt2 Sizes (in bytes) of compressed kernels extracted from miniroot images: -r-xr-xr-x 1 root wheel 4215406 Jun 1 14:47 bsd (baseline) -r-xr-xr-x 1 root wheel 4217267 Jun 1 15:33 bsd (+Spleen 16x32) -r-xr-xr-x 1 root wheel 4218986 Jun 1 20:26 bsd (+Spleen 12x24 and 16x32) Size difference from baseline: With Spleen 16x32: +1861 bytes With Spleen 12x24 and 16x32: +3580 bytes I would be fine with adding only the 16x32 version, but still provided numbers for the 12x24 in case we decide the size difference is small enough for its addition to be worthwhile.
Larger kernel fonts in RAMDISK_CD?
Hi tech@, The size of kernel fonts in RAMDISKs has long been a problem on systems with large screen resolutions booting via EFI, as currently only the 8x16 font is built into RAMDISKs. As those systems are becoming more common, I would like to revisit the topic. Currently, we decide which font is built into which kernel in wsfont(9), which will only add the 8x16 one when SMALL_KERNEL is defined, and larger fonts for selected architectures for !SMALL_KERNEL. There is no way to distinguish between RAMDISK and RAMDISK_CD kernels using #ifdef trickery, so with the current way we cannot add larger fonts only on RAMDISK_CD. As a reminder, we cannot add them to RAMDISK because there is no space left on the floppies, and there is no support for EFI systems on the floppies anyway. However, unless I overlooked something, this could be solved by adding option directives directly in the RAMDISK_CD kernel configuration file. This is how it would look like for amd64: Index: sys/arch/amd64/conf/RAMDISK_CD === RCS file: /cvs/src/sys/arch/amd64/conf/RAMDISK_CD,v retrieving revision 1.190 diff -u -p -r1.190 RAMDISK_CD --- sys/arch/amd64/conf/RAMDISK_CD 27 Dec 2020 23:05:37 - 1.190 +++ sys/arch/amd64/conf/RAMDISK_CD 31 May 2021 09:39:24 - @@ -20,6 +20,11 @@ option MSDOSFS option INET6 option CRYPTO +option FONT_SPLEEN8x16 +option FONT_SPLEEN12x24 +option FONT_SPLEEN16x32 +option FONT_SPLEEN32x64 + option RAMDISK_HOOKS option MINIROOTSIZE=7360 Does this look reasonable? If it does and if we want to go this way, I can try to build a release and check if MINIROOTSIZE must be bumped on RAMDISK_CD. Then we could do the same for i386, armv7 and arm64.
Re: rasops1
On Thu, Dec 24, 2020 at 12:25:40AM +0100, Patrick Wildt wrote:
> > On Fri, Dec 18, 2020 at 10:33:52PM +0100, Mark Kettenis wrote:
> >
> > > The diff below disables the optimized functions on little-endian
> > > architectures such that we always use rasops1_putchar(). This makes
> > > ssdfb(4) work with the default 8x16 font on arm64.
> >
> > I noticed it was committed already, but it seems the following
> > directives:
> >
> > #if defined(RASOPS_SMALL) && BYTE_ORDER == BIG_ENDIAN
> >
> > Should have been:
> >
> > #if !defined(RASOPS_SMALL) && BYTE_ORDER == BIG_ENDIAN
> >
> > We want to include the optimized putchar functions only if RASOPS_SMALL
> > is not defined.
> >
>
> True that. In one #endif comment he actually kept the !, but the actual
> ifs lost it.
Here is a diff to fix the issue, which includes the optimized putchar
functions only if RASOPS_SMALL is not defined.
Comments? OK?
Index: sys/dev/rasops/rasops1.c
===
RCS file: /cvs/src/sys/dev/rasops/rasops1.c,v
retrieving revision 1.11
diff -u -p -r1.11 rasops1.c
--- sys/dev/rasops/rasops1.c21 Dec 2020 12:58:42 - 1.11
+++ sys/dev/rasops/rasops1.c7 Jan 2021 11:08:55 -
@@ -44,7 +44,7 @@ int rasops1_copycols(void *, int, int, i
intrasops1_erasecols(void *, int, int, int, uint32_t);
intrasops1_do_cursor(struct rasops_info *);
intrasops1_putchar(void *, int, int col, u_int, uint32_t);
-#if defined(RASOPS_SMALL) && BYTE_ORDER == BIG_ENDIAN
+#if !defined(RASOPS_SMALL) && BYTE_ORDER == BIG_ENDIAN
intrasops1_putchar8(void *, int, int col, u_int, uint32_t);
intrasops1_putchar16(void *, int, int col, u_int, uint32_t);
#endif
@@ -58,7 +58,7 @@ rasops1_init(struct rasops_info *ri)
rasops_masks_init();
switch (ri->ri_font->fontwidth) {
-#if defined(RASOPS_SMALL) && BYTE_ORDER == BIG_ENDIAN
+#if !defined(RASOPS_SMALL) && BYTE_ORDER == BIG_ENDIAN
case 8:
ri->ri_ops.putchar = rasops1_putchar8;
break;
@@ -223,7 +223,7 @@ rasops1_putchar(void *cookie, int row, i
return 0;
}
-#if defined(RASOPS_SMALL) && BYTE_ORDER == BIG_ENDIAN
+#if !defined(RASOPS_SMALL) && BYTE_ORDER == BIG_ENDIAN
/*
* Paint a single character. This is for 8-pixel wide fonts.
*/
Re: rasops1
Hi Mark, On Fri, Dec 18, 2020 at 10:33:52PM +0100, Mark Kettenis wrote: > The diff below disables the optimized functions on little-endian > architectures such that we always use rasops1_putchar(). This makes > ssdfb(4) work with the default 8x16 font on arm64. I noticed it was committed already, but it seems the following directives: #if defined(RASOPS_SMALL) && BYTE_ORDER == BIG_ENDIAN Should have been: #if !defined(RASOPS_SMALL) && BYTE_ORDER == BIG_ENDIAN We want to include the optimized putchar functions only if RASOPS_SMALL is not defined.
Document the WSDISPLAYIO_GETSCREENTYPE ioctl in wsdisplay.4
Hi tech@,
Here is a diff to document the WSDISPLAYIO_GETSCREENTYPE ioctl in
wsdisplay.4.
The wsdisplay_screentype structure definition can be found in
.
Comments? OK?
Index: wsdisplay.4
===
RCS file: /cvs/src/share/man/man4/wsdisplay.4,v
retrieving revision 1.54
diff -u -p -r1.54 wsdisplay.4
--- wsdisplay.4 25 May 2019 11:02:19 - 1.54
+++ wsdisplay.4 14 Sep 2020 09:56:03 -
@@ -174,6 +174,38 @@ indicates the number of color map entrie
and
.Dv WSDISPLAYIO_PUTCMAP .
This call is likely to be unavailable on text-only displays.
+.It Dv WSDISPLAYIO_GETSCREENTYPE Fa "struct wsdisplay_screentype"
+Retrieve basic information about a screen.
+The returned structure is as follows:
+.Bd -literal -offset indent
+struct wsdisplay_screentype {
+int idx;
+int nidx;
+char name[WSSCREEN_NAME_SIZE];
+int ncols, nrows;
+int fontwidth, fontheight;
+};
+.Ed
+.Pp
+The
+.Va idx
+field indicates the index of the screen.
+The
+.Va nidx
+field indicates the number of screens.
+The
+.Va name
+field contains a human readable string used to identify the screen.
+The
+.Va ncols
+and
+.Va nrows
+fields indicate the available number of columns and rows.
+The
+.Va fontwidth
+and
+.Va fontheight
+fields indicate the dimensions of a character cell and are counted in pixels.
.It Dv WSDISPLAYIO_GETCMAP Fa "struct wsdisplay_cmap"
Retrieve the current color map from the display.
This call needs the
Reflect recent wsfontload(8) changes in the man page
Hi tech@, We are now getting the default values for font height and width using the WSDISPLAYIO_GETSCREENTYPE ioctl, so they always match the currently loaded font metrics. The following diff reflects that in the man page. As text-mode VGA compatible displays are increasingly uncommon, I took the liberty to switch the order and to mention raster displays first. Comments? OK? Index: usr.sbin/wsfontload/wsfontload.8 === RCS file: /cvs/src/usr.sbin/wsfontload/wsfontload.8,v retrieving revision 1.20 diff -u -p -r1.20 wsfontload.8 --- usr.sbin/wsfontload/wsfontload.83 Apr 2017 18:43:41 - 1.20 +++ usr.sbin/wsfontload/wsfontload.87 Aug 2020 13:40:26 - @@ -85,8 +85,8 @@ Default is .Pa /dev/ttyCcfg . .It Fl h Ar height Sets the height of a font character in pixels. -Default is 16 for text-mode VGA compatible displays, -and 22 for raster displays. +Default is to match the currently loaded font height for raster displays, +and 16 for text-mode VGA compatible displays. .It Fl l Specifies to print out a list of loaded fonts, no other arguments should be specified. @@ -97,8 +97,8 @@ If none is given, the name is used to create one. .It Fl w Ar width Sets the width of a font character in pixels. -Default is 8 for text-mode VGA compatible displays, -and 12 for raster displays. +Default is to match the currently loaded font width for raster displays, +and 8 for text-mode VGA compatible displays. .El .Pp .\" Typically, the
Re: wsfontload(8): restore working default height/width values
On Tue, Jul 21, 2020 at 12:44:57PM +0200, Frederic Cambus wrote:
> Currently, wsfontload(8) hardcodes the default height and width values
> for the font to be loaded as 12x22 when using framebuffer consoles, and
> as 8x16 when in text mode. The 12x22 value wasn't correct in case we
> felt back to the smaller 8x16 font for screen widths smaller than 960px,
> and isn't valid anymore since we replaced Gallant 12x22 by Spleen 12x24
> on all architectures but sparc64.
>
> Here is a diff to get the default values for font height and width using
> the WSDISPLAYIO_GETSCREENTYPE ioctl. This ensures that they always match
> the currently loaded font metrics.
>
> Tested on a system with a text mode console only, on efifb(4) and
> inteldrm(4) framebuffer consoles, and on Loongson with smfb(4).
>
> Please note that this needs the diff I sent to tech@ yesterday to allow
> the WSDISPLAYIO_GETSCREENTYPE ioctl on tty*cfg.
>
> Comments? OK?
>
> Index: usr.sbin/wsfontload/wsfontload.c
> ===
> RCS file: /cvs/src/usr.sbin/wsfontload/wsfontload.c,v
> retrieving revision 1.22
> diff -u -p -r1.22 wsfontload.c
> --- usr.sbin/wsfontload/wsfontload.c 20 Jul 2020 14:09:24 - 1.22
> +++ usr.sbin/wsfontload/wsfontload.c 21 Jul 2020 10:41:56 -
> @@ -76,6 +76,7 @@ main(int argc, char *argv[])
> {
> char *wsdev, *infile, *p;
> struct wsdisplay_font f;
> + struct wsdisplay_screentype screens;
> int c, res, wsfd, ffd, type, list, i;
> int defwidth, defheight;
> struct stat stat;
> @@ -178,23 +179,16 @@ main(int argc, char *argv[])
> ffd = STDIN_FILENO;
> }
>
> - res = ioctl(wsfd, WSDISPLAYIO_GTYPE, &type);
> - if (res != 0)
> - type = WSDISPLAY_TYPE_UNKNOWN;
> -
> - switch (type) {
> - /* text-mode VGA */
> - case WSDISPLAY_TYPE_ISAVGA:
> - case WSDISPLAY_TYPE_PCIVGA:
> + memset(&screens, 0, sizeof(screens));
> + res = ioctl(wsfd, WSDISPLAYIO_GETSCREENTYPE, &screens);
> + if (res == 0) {
> + /* raster frame buffers */
> + defwidth = screens.fontwidth;
> + defheight = screens.fontheight;
> + } else {
> + /* text-mode VGA */
> defwidth = 8;
> defheight = 16;
> - break;
> - /* raster frame buffers */
> - default:
> - /* XXX ought to be computed from the frame buffer resolution */
> - defwidth = 12;
> - defheight = 22;
> - break;
> }
>
> f.index = -1;
Ping. Anyone willing to look at this? Thanks!
Re: Allow the WSDISPLAYIO_GETSCREENTYPE ioctl on tty*cfg
On Mon, Jul 20, 2020 at 04:36:46PM +0200, Frederic Cambus wrote:
> Here is a diff to allow the WSDISPLAYIO_GETSCREENTYPE ioctl on the
> tty*cfg device, passing it back to tty*0.
>
> I need this to restore working defaults in wsfontload(8).
>
> Comments? OK?
>
> Index: sys/dev/wscons/wsdisplay.c
> ===
> RCS file: /cvs/src/sys/dev/wscons/wsdisplay.c,v
> retrieving revision 1.141
> diff -u -p -r1.141 wsdisplay.c
> --- sys/dev/wscons/wsdisplay.c25 May 2020 09:55:49 - 1.141
> +++ sys/dev/wscons/wsdisplay.c20 Jul 2020 14:28:42 -
> @@ -1046,10 +1046,15 @@ wsdisplayioctl(dev_t dev, u_long cmd, ca
> #endif
>
> if (ISWSDISPLAYCTL(dev)) {
> - if (cmd != WSDISPLAYIO_GTYPE)
> + switch (cmd) {
> + case WSDISPLAYIO_GTYPE:
> + case WSDISPLAYIO_GETSCREENTYPE:
> + /* pass to the first screen */
> + dev = makedev(major(dev), WSDISPLAYMINOR(unit, 0));
> + break;
> + default:
> return (wsdisplay_cfg_ioctl(sc, cmd, data, flag, p));
> - /* pass WSDISPLAYIO_GTYPE to the first screen */
> - dev = makedev(major(dev), WSDISPLAYMINOR(unit, 0));
> + }
> }
>
> if (WSDISPLAYSCREEN(dev) >= WSDISPLAY_MAXSCREEN)
Ping. Anyone willing to look at this? Thanks!
wsfontload(8): restore working default height/width values
Hi tech@,
Currently, wsfontload(8) hardcodes the default height and width values
for the font to be loaded as 12x22 when using framebuffer consoles, and
as 8x16 when in text mode. The 12x22 value wasn't correct in case we
felt back to the smaller 8x16 font for screen widths smaller than 960px,
and isn't valid anymore since we replaced Gallant 12x22 by Spleen 12x24
on all architectures but sparc64.
Here is a diff to get the default values for font height and width using
the WSDISPLAYIO_GETSCREENTYPE ioctl. This ensures that they always match
the currently loaded font metrics.
Tested on a system with a text mode console only, on efifb(4) and
inteldrm(4) framebuffer consoles, and on Loongson with smfb(4).
Please note that this needs the diff I sent to tech@ yesterday to allow
the WSDISPLAYIO_GETSCREENTYPE ioctl on tty*cfg.
Comments? OK?
Index: usr.sbin/wsfontload/wsfontload.c
===
RCS file: /cvs/src/usr.sbin/wsfontload/wsfontload.c,v
retrieving revision 1.22
diff -u -p -r1.22 wsfontload.c
--- usr.sbin/wsfontload/wsfontload.c20 Jul 2020 14:09:24 - 1.22
+++ usr.sbin/wsfontload/wsfontload.c21 Jul 2020 10:41:56 -
@@ -76,6 +76,7 @@ main(int argc, char *argv[])
{
char *wsdev, *infile, *p;
struct wsdisplay_font f;
+ struct wsdisplay_screentype screens;
int c, res, wsfd, ffd, type, list, i;
int defwidth, defheight;
struct stat stat;
@@ -178,23 +179,16 @@ main(int argc, char *argv[])
ffd = STDIN_FILENO;
}
- res = ioctl(wsfd, WSDISPLAYIO_GTYPE, &type);
- if (res != 0)
- type = WSDISPLAY_TYPE_UNKNOWN;
-
- switch (type) {
- /* text-mode VGA */
- case WSDISPLAY_TYPE_ISAVGA:
- case WSDISPLAY_TYPE_PCIVGA:
+ memset(&screens, 0, sizeof(screens));
+ res = ioctl(wsfd, WSDISPLAYIO_GETSCREENTYPE, &screens);
+ if (res == 0) {
+ /* raster frame buffers */
+ defwidth = screens.fontwidth;
+ defheight = screens.fontheight;
+ } else {
+ /* text-mode VGA */
defwidth = 8;
defheight = 16;
- break;
- /* raster frame buffers */
- default:
- /* XXX ought to be computed from the frame buffer resolution */
- defwidth = 12;
- defheight = 22;
- break;
}
f.index = -1;
Re: Use VGA text mode palette RGB values in rasops(9)
On Wed, Jul 15, 2020 at 10:26:12AM -0600, Theo de Raadt wrote:
> > So here is a new iteration taking feedback into account, using the
> > #if WS_DEFAULT_BG == WSCOL_WHITE check for clarity, and also switching
> > the foreground color of printed kernel messages to light cyan to improve
> > contrast and readability.
>
> I really dislike how two issues are being mixed into one diff.
Right. This was to allow easier testing by having only one diff to
apply, and that's why I wasn't explicitely asking for OKs.
So let's move forward with this, here is a diff addressing only the
color palette changes.
OK?
Index: sys/dev/rasops/rasops.c
===
RCS file: /cvs/src/sys/dev/rasops/rasops.c,v
retrieving revision 1.63
diff -u -p -r1.63 rasops.c
--- sys/dev/rasops/rasops.c 11 Jul 2020 15:02:52 - 1.63
+++ sys/dev/rasops/rasops.c 15 Jul 2020 14:55:45 -
@@ -47,7 +47,8 @@
/* ANSI colormap (R,G,B) */
-#defineNORMAL_BLACK0x00
+#if WS_DEFAULT_BG == WSCOL_WHITE
+#defineNORMAL_BLACK0x00/* Rasops palette */
#defineNORMAL_RED 0x7f
#defineNORMAL_GREEN0x007f00
#defineNORMAL_BROWN0x7f7f00
@@ -64,6 +65,25 @@
#defineHILITE_MAGENTA 0xff00ff
#defineHILITE_CYAN 0x00
#defineHILITE_WHITE0xff
+#else
+#defineNORMAL_BLACK0x00/* VGA text mode palette */
+#defineNORMAL_RED 0xaa
+#defineNORMAL_GREEN0x00aa00
+#defineNORMAL_BROWN0xaa5500
+#defineNORMAL_BLUE 0xaa
+#defineNORMAL_MAGENTA 0xaa00aa
+#defineNORMAL_CYAN 0x00
+#defineNORMAL_WHITE0xaa
+
+#defineHILITE_BLACK0x55
+#defineHILITE_RED 0xff
+#defineHILITE_GREEN0x55ff55
+#defineHILITE_BROWN0x55
+#defineHILITE_BLUE 0xff
+#defineHILITE_MAGENTA 0xff55ff
+#defineHILITE_CYAN 0x55
+#defineHILITE_WHITE0xff
+#endif
const u_char rasops_cmap[256 * 3] = {
#define_C(x) ((x) & 0xff) >> 16, ((x) & 0x00ff00) >> 8, ((x) &
0xff)
Allow the WSDISPLAYIO_GETSCREENTYPE ioctl on tty*cfg
Hi tech@,
Here is a diff to allow the WSDISPLAYIO_GETSCREENTYPE ioctl on the
tty*cfg device, passing it back to tty*0.
I need this to restore working defaults in wsfontload(8).
Comments? OK?
Index: sys/dev/wscons/wsdisplay.c
===
RCS file: /cvs/src/sys/dev/wscons/wsdisplay.c,v
retrieving revision 1.141
diff -u -p -r1.141 wsdisplay.c
--- sys/dev/wscons/wsdisplay.c 25 May 2020 09:55:49 - 1.141
+++ sys/dev/wscons/wsdisplay.c 20 Jul 2020 14:28:42 -
@@ -1046,10 +1046,15 @@ wsdisplayioctl(dev_t dev, u_long cmd, ca
#endif
if (ISWSDISPLAYCTL(dev)) {
- if (cmd != WSDISPLAYIO_GTYPE)
+ switch (cmd) {
+ case WSDISPLAYIO_GTYPE:
+ case WSDISPLAYIO_GETSCREENTYPE:
+ /* pass to the first screen */
+ dev = makedev(major(dev), WSDISPLAYMINOR(unit, 0));
+ break;
+ default:
return (wsdisplay_cfg_ioctl(sc, cmd, data, flag, p));
- /* pass WSDISPLAYIO_GTYPE to the first screen */
- dev = makedev(major(dev), WSDISPLAYMINOR(unit, 0));
+ }
}
if (WSDISPLAYSCREEN(dev) >= WSDISPLAY_MAXSCREEN)
Re: wsfontload(8): display number of characters in a loaded font
On Fri, Jul 17, 2020 at 11:04:07AM +0100, Stuart Henderson wrote:
> Seems useful. While it's not especially likely anyone is parsing the output
> of this, just in case they are it's usually more admin-friendly to add a new
> column at the end unless there's a good reason not to.
Good point, here is a revised diff adding the new column at the end,
and the new output as follow:
# Name Encoding W HChars
0 Boldface ibm 8 16 254
1 Spleen 6x12 iso 6 12 96
2 Spleen 8x16 iso 8 16 224
3 Spleen 12x24 iso 12 24 224
4 Spleen 16x32 iso 16 32 224
5 Spleen 32x64 iso 32 64 224
Comments? OK?
Index: usr.sbin/wsfontload/wsfontload.c
===
RCS file: /cvs/src/usr.sbin/wsfontload/wsfontload.c,v
retrieving revision 1.21
diff -u -p -r1.21 wsfontload.c
--- usr.sbin/wsfontload/wsfontload.c28 Jun 2019 13:32:51 - 1.21
+++ usr.sbin/wsfontload/wsfontload.c20 Jul 2020 11:41:32 -
@@ -141,7 +141,8 @@ main(int argc, char *argv[])
if (list) {
i = 0;
- p = " # Name Encoding W H";
+ p = " # Name Encoding" \
+ " W HChars";
do {
f.index = i;
res = ioctl(wsfd, WSDISPLAYIO_LSFONT, &f);
@@ -151,10 +152,11 @@ main(int argc, char *argv[])
puts(p);
p = NULL;
}
- printf("%2d %-32s %8s %2d %2d\n",
+ printf("%2d %-32s %8s %2d %2d %8d\n",
f.index, f.name,
encodings[f.encoding].name,
- f.fontwidth, f.fontheight);
+ f.fontwidth, f.fontheight,
+ f.numchars);
}
}
i++;
wsfontload(8): display number of characters in a loaded font
Hi tech@,
Here is a diff to add a new column to wsfontload -l output, which
reports the number of characters contained in a loaded font.
It's especially useful with user loaded fonts as they can contain more
than 256 characters.
Below is the current output of wsfontload -l, without the diff:
# Name Encoding W H
0 Boldface ibm 8 16
1 Spleen 6x12 iso 6 12
2 Spleen 8x16 iso 8 16
3 Spleen 12x24 iso 12 24
4 Spleen 16x32 iso 16 32
5 Spleen 32x64 iso 32 64
And now with the diff:
# Name EncodingChars W H
0 Boldface ibm 254 8 16
1 Spleen 6x12 iso 96 6 12
2 Spleen 8x16 iso 224 8 16
3 Spleen 12x24 iso 224 12 24
4 Spleen 16x32 iso 224 16 32
5 Spleen 32x64 iso 224 32 64
Comments? OK?
Index: usr.sbin/wsfontload/wsfontload.c
===
RCS file: /cvs/src/usr.sbin/wsfontload/wsfontload.c,v
retrieving revision 1.21
diff -u -p -r1.21 wsfontload.c
--- usr.sbin/wsfontload/wsfontload.c28 Jun 2019 13:32:51 - 1.21
+++ usr.sbin/wsfontload/wsfontload.c16 Jul 2020 16:11:18 -
@@ -141,7 +141,8 @@ main(int argc, char *argv[])
if (list) {
i = 0;
- p = " # Name Encoding W H";
+ p = " # Name Encoding" \
+ "Chars W H";
do {
f.index = i;
res = ioctl(wsfd, WSDISPLAYIO_LSFONT, &f);
@@ -151,10 +152,11 @@ main(int argc, char *argv[])
puts(p);
p = NULL;
}
- printf("%2d %-32s %8s %2d %2d\n",
+ printf("%2d %-32s %8s %8d %2d %2d\n",
f.index, f.name,
encodings[f.encoding].name,
- f.fontwidth, f.fontheight);
+ f.numchars, f.fontwidth,
+ f.fontheight);
}
}
i++;
Merge if blocks in rasops_mapchar()
Hi tech@,
Here is a diff to merge the two if blocks checking if the font in use
contains a given character in rasops_mapchar().
Comments? OK?
Index: sys/dev/rasops/rasops.c
===
RCS file: /cvs/src/sys/dev/rasops/rasops.c,v
retrieving revision 1.63
diff -u -p -r1.63 rasops.c
--- sys/dev/rasops/rasops.c 11 Jul 2020 15:02:52 - 1.63
+++ sys/dev/rasops/rasops.c 16 Jul 2020 14:18:58 -
@@ -532,13 +532,8 @@ rasops_mapchar(void *cookie, int c, u_in
}
}
-
- if (c < ri->ri_font->firstchar) {
- *cp = '?';
- return (0);
- }
-
- if (c - ri->ri_font->firstchar >= ri->ri_font->numchars) {
+ if (c < ri->ri_font->firstchar ||
+ c - ri->ri_font->firstchar >= ri->ri_font->numchars) {
*cp = '?';
return (0);
}
Re: Use VGA text mode palette RGB values in rasops(9)
On Wed, Jul 08, 2020 at 12:37:11PM +1000, Jonathan Gray wrote:
> Thanks for the explanation. The proposal makes more sense from the
> point of view of the existing colours being darker for openboot black
> on white.
>
> #if WS_DEFAULT_BG == WSCOL_WHITE
>
> old
>
> #else
>
> new
>
> #endif
>
> would have made that a bit more readable.
Yes, this is indeed better, thanks for the suggestion.
> It is interesting that the choice of blue comes up as being problematic
> in xterm as well when reading XTerm-col.ad
>
> For us though it really comes down to white on black (!sparc64), black
> on white (sparc64) and white on blue for the kernel.
I understand the concern is about the contrast for printed kernel
messages.
Currently, output originating from the kernel is displayed using
WSCOL_WHITE on WSCOL_BLUE, which translates to NORMAL_WHITE on
NORMAL_BLUE, and I agree that 0xaa as foreground on a blue
background is not optimal, I think I raised the issue a few years
ago as it's what we currently get when booting in BIOS mode. But
it doesn't have to be this way, it could be changed.
> I agree with the sentiment that people should be using X and leave
> rasops/wscons as simple as possible.
I understand some developers share this position, however we do have
supported platforms (loongson being one, for example), on which X is
not realistically usable.
So here is a new iteration taking feedback into account, using the
#if WS_DEFAULT_BG == WSCOL_WHITE check for clarity, and also switching
the foreground color of printed kernel messages to light cyan to improve
contrast and readability.
Does this proposal look reasonable?
Index: sys/dev/rasops/rasops.c
===
RCS file: /cvs/src/sys/dev/rasops/rasops.c,v
retrieving revision 1.63
diff -u -p -r1.63 rasops.c
--- sys/dev/rasops/rasops.c 11 Jul 2020 15:02:52 - 1.63
+++ sys/dev/rasops/rasops.c 15 Jul 2020 14:55:45 -
@@ -47,7 +47,8 @@
/* ANSI colormap (R,G,B) */
-#defineNORMAL_BLACK0x00
+#if WS_DEFAULT_BG == WSCOL_WHITE
+#defineNORMAL_BLACK0x00/* Rasops palette */
#defineNORMAL_RED 0x7f
#defineNORMAL_GREEN0x007f00
#defineNORMAL_BROWN0x7f7f00
@@ -64,6 +65,25 @@
#defineHILITE_MAGENTA 0xff00ff
#defineHILITE_CYAN 0x00
#defineHILITE_WHITE0xff
+#else
+#defineNORMAL_BLACK0x00/* VGA text mode palette */
+#defineNORMAL_RED 0xaa
+#defineNORMAL_GREEN0x00aa00
+#defineNORMAL_BROWN0xaa5500
+#defineNORMAL_BLUE 0xaa
+#defineNORMAL_MAGENTA 0xaa00aa
+#defineNORMAL_CYAN 0x00
+#defineNORMAL_WHITE0xaa
+
+#defineHILITE_BLACK0x55
+#defineHILITE_RED 0xff
+#defineHILITE_GREEN0x55ff55
+#defineHILITE_BROWN0x55
+#defineHILITE_BLUE 0xff
+#defineHILITE_MAGENTA 0xff55ff
+#defineHILITE_CYAN 0x55
+#defineHILITE_WHITE0xff
+#endif
const u_char rasops_cmap[256 * 3] = {
#define_C(x) ((x) & 0xff) >> 16, ((x) & 0x00ff00) >> 8, ((x) &
0xff)
Index: sys/dev/wscons/wsemul_vt100.c
===
RCS file: /cvs/src/sys/dev/wscons/wsemul_vt100.c,v
retrieving revision 1.39
diff -u -p -r1.39 wsemul_vt100.c
--- sys/dev/wscons/wsemul_vt100.c 25 May 2020 09:55:49 - 1.39
+++ sys/dev/wscons/wsemul_vt100.c 15 Jul 2020 14:55:45 -
@@ -165,13 +165,13 @@ wsemul_vt100_cnattach(const struct wsscr
edp->cbcookie = NULL;
#ifndef WS_KERNEL_FG
-#define WS_KERNEL_FG WSCOL_WHITE
+#define WS_KERNEL_FG WSCOL_CYAN
#endif
#ifndef WS_KERNEL_BG
#define WS_KERNEL_BG WSCOL_BLUE
#endif
#ifndef WS_KERNEL_COLATTR
-#define WS_KERNEL_COLATTR 0
+#define WS_KERNEL_COLATTR WSATTR_HILIT
#endif
#ifndef WS_KERNEL_MONOATTR
#define WS_KERNEL_MONOATTR 0
Re: [PATCH} Optimized rasops32 putchar
On Tue, Jul 14, 2020 at 12:15:37PM +0200, Frederic Cambus wrote: > The diff makes sense to me, I will commit it this week with some minor > style(9) fixes for the switch statement (don't indent the case), unless > I hear objections. Committed, thanks again!
Re: [PATCH} Optimized rasops32 putchar
On Sun, Jul 12, 2020 at 07:16:13PM +0200, Frederic Cambus wrote: > On Fri, Jun 26, 2020 at 07:42:50AM -0700, jo...@armadilloaerospace.com wrote: > > Optimized 32 bit character rendering with unrolled rows and pairwise > > foreground / background pixel rendering. > > > > If it weren't for the 5x8 font, I would have just assumed everything > > was an even width and made the fallback path also pairwise. > > > > In isolation, the 16x32 character case got 2x faster, but that wasn't > > a huge real world speedup where the space rendering that was already > > at memory bandwidth limits accounted for most of the character > > rendering time. However, in combination with the previous fast > > conditional console scrolling that removes most of the space rendering, > > it becomes significant. > > On my Ryzen desktop with radeondrm, I don't see any improvements, the > rasops_vcons_copyrows() optimizations seems to have made character > plotting fast enough so that it's not a bottleneck anymore, which is > definitely great. > > cpu0: AMD Ryzen 7 2700 Eight-Core Processor, 3394.18 MHz, 17-08-02 > radeondrm0 at pci8 dev 0 function 0 "ATI Radeon HD 6450" rev 0x00 > radeondrm0: 1920x1080, 32bpp > > On my T450 however, this diff makes cat'ing my usual test file [1] up > to 20% faster with the default 12x24 font on the built-in 1600x900 > screen, which I think is significant enough for the diff to go in. > > cpu0: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.47 MHz, 06-3d-04 > inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 5500" rev 0x09 > drm0 at inteldrm0 > inteldrm0: 1600x900, 32bpp > > On my Cubieboard2 (armv7) I didn't notice any meaningful difference, > which I assume is to be expected on a 32-bit platform. I suppose it's > also reasonable to assume other 32-bit platforms (i386, hppa, macppc) > will not see any regression beyond noise level? > > Anyone willing to OK this diff? > > [1] https://norvig.com/big.txt So I tested on the other 32-bit machine I have, and didn't notice any regression on my i386 machine with inteldrm, it is actually up to 1.5% faster. It seems we can remove the 'q' variable and drop this assignement, as it is not used: q = u.q[0]; The diff makes sense to me, I will commit it this week with some minor style(9) fixes for the switch statement (don't indent the case), unless I hear objections.
Use CPU_IS_PRIMARY macro on alpha and mips64
Hi tech@,
Here is a diff to use the CPU_IS_PRIMARY macro on alpha and mips64.
Comments? OK?
Index: sys/arch/alpha/alpha/cpu.c
===
RCS file: /cvs/src/sys/arch/alpha/alpha/cpu.c,v
retrieving revision 1.43
diff -u -p -r1.43 cpu.c
--- sys/arch/alpha/alpha/cpu.c 29 May 2020 04:42:23 - 1.43
+++ sys/arch/alpha/alpha/cpu.c 13 Jul 2020 15:39:02 -
@@ -426,7 +426,7 @@ cpu_boot_secondary_processors(void)
ci = cpu_info[i];
if (ci == NULL || ci->ci_idle_pcb == NULL)
continue;
- if (ci->ci_flags & CPUF_PRIMARY)
+ if (CPU_IS_PRIMARY(ci))
continue;
if ((cpus_booted & (1UL << i)) == 0)
continue;
Index: sys/arch/mips64/mips64/cpu.c
===
RCS file: /cvs/src/sys/arch/mips64/mips64/cpu.c,v
retrieving revision 1.75
diff -u -p -r1.75 cpu.c
--- sys/arch/mips64/mips64/cpu.c11 Jul 2020 15:18:08 - 1.75
+++ sys/arch/mips64/mips64/cpu.c13 Jul 2020 15:39:02 -
@@ -514,7 +514,7 @@ cpu_boot_secondary_processors(void)
CPU_INFO_FOREACH(cii, ci) {
if ((ci->ci_flags & CPUF_PRESENT) == 0)
continue;
- if (ci->ci_flags & CPUF_PRIMARY)
+ if (CPU_IS_PRIMARY(ci))
continue;
ci->ci_randseed = (arc4random() & 0x7fff) + 1;
Use CPU_IS_PRIMARY macro in identifycpu() on i386
Hi tech@,
Here is a diff to use the CPU_IS_PRIMARY macro in identifycpu() on i386.
Comments? OK?
Index: sys/arch/i386/i386/machdep.c
===
RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
retrieving revision 1.636
diff -u -p -r1.636 machdep.c
--- sys/arch/i386/i386/machdep.c31 May 2020 06:23:57 - 1.636
+++ sys/arch/i386/i386/machdep.c13 Jul 2020 10:17:07 -
@@ -2106,7 +2106,7 @@ identifycpu(struct cpu_info *ci)
cpu_device);
}
- if (ci->ci_flags & CPUF_PRIMARY) {
+ if (CPU_IS_PRIMARY(ci)) {
if (cpu_ecxfeature & CPUIDECX_RDRAND)
has_rdrand = 1;
if (ci->ci_feature_sefflags_ebx & SEFF0EBX_RDSEED)
Re: [PATCH} Optimized rasops32 putchar
On Fri, Jun 26, 2020 at 07:42:50AM -0700, jo...@armadilloaerospace.com wrote: > Optimized 32 bit character rendering with unrolled rows and pairwise > foreground / background pixel rendering. > > If it weren't for the 5x8 font, I would have just assumed everything > was an even width and made the fallback path also pairwise. > > In isolation, the 16x32 character case got 2x faster, but that wasn't > a huge real world speedup where the space rendering that was already > at memory bandwidth limits accounted for most of the character > rendering time. However, in combination with the previous fast > conditional console scrolling that removes most of the space rendering, > it becomes significant. On my Ryzen desktop with radeondrm, I don't see any improvements, the rasops_vcons_copyrows() optimizations seems to have made character plotting fast enough so that it's not a bottleneck anymore, which is definitely great. cpu0: AMD Ryzen 7 2700 Eight-Core Processor, 3394.18 MHz, 17-08-02 radeondrm0 at pci8 dev 0 function 0 "ATI Radeon HD 6450" rev 0x00 radeondrm0: 1920x1080, 32bpp On my T450 however, this diff makes cat'ing my usual test file [1] up to 20% faster with the default 12x24 font on the built-in 1600x900 screen, which I think is significant enough for the diff to go in. cpu0: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.47 MHz, 06-3d-04 inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 5500" rev 0x09 drm0 at inteldrm0 inteldrm0: 1600x900, 32bpp On my Cubieboard2 (armv7) I didn't notice any meaningful difference, which I assume is to be expected on a 32-bit platform. I suppose it's also reasonable to assume other 32-bit platforms (i386, hppa, macppc) will not see any regression beyond noise level? Anyone willing to OK this diff? [1] https://norvig.com/big.txt
Re: [PATCH] fast conditional console scrolling
On Fri, Jul 10, 2020 at 03:26:16PM +0200, Frederic Cambus wrote: > On Fri, Jun 26, 2020 at 07:49:55AM -0700, jo...@armadilloaerospace.com wrote: > > I should have been more rigorous -- I had two different changes running > > on my system, as well as forcing it to use the 12x24 font for a 160x45 > > console. > > > > If you apply the "Optimized rasops32 putchar" patch I just posted, you > > should see another significant speedup. > > Leaving aside rasops32_putchar() optimizations for now, I tried this > on radeondrm and simplefb (on armv7) with a 1920x1080 monitor and on > top of what John and Paul are reporting, I'm also seeing improvements > when cat'ing the text file [1] I usually use for rasops performance > testing. It's up to 30% faster on both devices, which is significant. > > The diff makes sense to me, and I think this should go in. > > Anyone willing to OK this diff or to commit with my OK? Committed with some minor style(9) formatting fixes pointed out by jcs@ offlist. Thanks!
Re: [PATCH] fast conditional console scrolling
On Fri, Jun 26, 2020 at 07:49:55AM -0700, jo...@armadilloaerospace.com wrote: > I should have been more rigorous -- I had two different changes running > on my system, as well as forcing it to use the 12x24 font for a 160x45 > console. > > If you apply the "Optimized rasops32 putchar" patch I just posted, you > should see another significant speedup. Leaving aside rasops32_putchar() optimizations for now, I tried this on radeondrm and simplefb (on armv7) with a 1920x1080 monitor and on top of what John and Paul are reporting, I'm also seeing improvements when cat'ing the text file [1] I usually use for rasops performance testing. It's up to 30% faster on both devices, which is significant. The diff makes sense to me, and I think this should go in. Anyone willing to OK this diff or to commit with my OK? [1] https://norvig.com/big.txt
Enable Spleen 16x32 and 32x64 on armv7
Hi tech@, Here is a diff to enable spleen16x32 and spleen32x64 on armv7 for GENERIC kernels, like on arm64. I'm using the 16x32 version on my Cubieboard2. I'm not sure if any armv7 devices we support is actually capable of driving a 4K screen, so the 32x64 version might not be useful. If this is a concern, I can send a revised diff to include only the 16x32 version. Comments? OK? Index: sys/dev/wsfont/wsfont.c === RCS file: /cvs/src/sys/dev/wsfont/wsfont.c,v retrieving revision 1.56 diff -u -p -r1.56 wsfont.c --- sys/dev/wsfont/wsfont.c 11 Jul 2019 18:07:54 - 1.56 +++ sys/dev/wsfont/wsfont.c 7 Jul 2020 13:54:56 - @@ -97,7 +97,7 @@ #endif #if !defined(SMALL_KERNEL) && (defined(__amd64__) || defined(__i386__) || \ -defined(__arm64__)) +defined(__arm64__) || defined(__armv7__)) #define FONT_SPLEEN16x32 #define FONT_SPLEEN32x64 #endif
Add "Spleen 6x12" font to wsfont
Hi tech@,
I created a new size for Spleen, to bridge the gap between the 5x8 and
the 8x16 versions. The idea is to have something more readable than the
5x8 version while still being small enough to be usable on OLED displays.
Similar to "Spleen 5x8" it only contains the printable ASCII characters
(96 glyphes).
In order to enable and test the font, this option should be added to the
kernel configuration file: option FONT_SPLEEN6x12
Comments? OK?
Index: sys/dev/wsfont/wsfont.c
===
RCS file: /cvs/src/sys/dev/wsfont/wsfont.c,v
retrieving revision 1.56
diff -u -p -r1.56 wsfont.c
--- sys/dev/wsfont/wsfont.c 11 Jul 2019 18:07:54 - 1.56
+++ sys/dev/wsfont/wsfont.c 8 Jul 2020 10:16:31 -
@@ -48,6 +48,11 @@
#include
#endif
+#ifdef FONT_SPLEEN6x12
+#define HAVE_FONT 1
+#include
+#endif
+
#ifdef FONT_SPLEEN8x16
#define HAVE_FONT 1
#endif
@@ -150,17 +155,20 @@ static struct font builtin_fonts[] = {
#ifdef FONT_SPLEEN5x8
BUILTIN_FONT(spleen5x8, 4),
#endif
+#ifdef FONT_SPLEEN6x12
+ BUILTIN_FONT(spleen6x12, 5),
+#endif
#ifdef FONT_SPLEEN8x16
- BUILTIN_FONT(spleen8x16, 5),
+ BUILTIN_FONT(spleen8x16, 6),
#endif
#ifdef FONT_SPLEEN12x24
- BUILTIN_FONT(spleen12x24, 6),
+ BUILTIN_FONT(spleen12x24, 7),
#endif
#ifdef FONT_SPLEEN16x32
- BUILTIN_FONT(spleen16x32, 7),
+ BUILTIN_FONT(spleen16x32, 8),
#endif
#ifdef FONT_SPLEEN32x64
- BUILTIN_FONT(spleen32x64, 8),
+ BUILTIN_FONT(spleen32x64, 9),
#endif
#undef BUILTIN_FONT
};
Index: sys/dev/wsfont/spleen6x12.h
===
RCS file: sys/dev/wsfont/spleen6x12.h
diff -N sys/dev/wsfont/spleen6x12.h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sys/dev/wsfont/spleen6x12.h 8 Jul 2020 10:16:31 -
@@ -0,0 +1,1294 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2018-2020 Frederic Cambus
+ * All rights reserved.
+ *
+ * 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.
+ */
+
+static u_char spleen6x12_data[];
+
+struct wsdisplay_font spleen6x12 = {
+ .name = "Spleen 6x12",
+ .index = 0,
+ .firstchar = ' ',
+ .numchars = 128 - ' ',
+ .encoding = WSDISPLAY_FONTENC_ISO,
+ .fontwidth = 6,
+ .fontheight = 12,
+ .stride = 1,
+ .bitorder = WSDISPLAY_FONTORDER_L2R,
+ .byteorder = WSDISPLAY_FONTORDER_L2R,
+ .cookie = NULL,
+ .data = spleen6x12_data
+};
+
+static u_char spleen6x12_data[] = {
+ 0x00, /* */
+ 0x00, /* */
+ 0x00, /* */
+ 0x00, /* */
+ 0x00, /* */
+ 0x00, /* */
+ 0x00, /* */
+ 0x00, /* */
+ 0x00, /* */
+ 0x00, /* */
+ 0x00, /* */
+ 0x00, /* */
+
+ 0x00, /* */
+ 0x20, /* ..*. */
+ 0x20, /* ..*. */
+ 0x20, /* ..*. */
+ 0x20, /* ..*. */
+ 0x20, /* ..*. */
+ 0x20, /* ..*. */
+ 0x00, /* */
+ 0x20, /* ..*. */
+ 0x00, /* */
+ 0x00, /* */
+ 0x00, /* */
+
+ 0x00, /* */
+ 0x50, /* .*.* */
+ 0x50, /* .*.* */
+ 0x50, /* .*.* */
+ 0x00, /* */
+ 0x00, /* */
+ 0x00, /* */
+ 0x00, /* */
+ 0x00, /* */
+ 0x00, /* .
Re: Use VGA text mode palette RGB values in rasops(9)
On Wed, Jul 08, 2020 at 12:06:27AM +1000, Jonathan Gray wrote: > On Tue, Jul 07, 2020 at 03:16:33PM +0200, Frederic Cambus wrote: > > Hi tech@, > > > > The recent spike of interest around framebuffer consoles has prompted > > me to revisit a proposal I sent back in early 2017 [1]. > > > > Aesthetics considerations aside, kettenis@ raised the concern that colors > > from the original rasops palette carefully matched what OpenFirmware > > uses for the console on sparc64. > > > > Therefore, I propose to default on using the proper VGA text mode palette > > RGB values, and to keep the original rasops color palette on sparc64. > > > > The differences between the two palettes can be seen here [2]. > > > > Comments? OK? > > Why is it important to match VGA colours? > We don't try to match video modes or fonts. In case it wasn't obvious by comparing the two palettes, the main problem with the rasops palette it that the NORMAL_RED, NORMAL_GREEN, NORMAL_BLUE, NORMAL_MAGENTA and NORMAL_CYAN colors are too dark. NORMAL_BLUE is especially problematic as it's very difficult to read on a black background. It is used as the default color for comments in vim. It's also (I know I'm not going to make any friends here) the color used to "highlight" (ahem) directories in colorls. One can test in frame buffer consoles by doing: export TERM=wsvt25 And run either vim or colorls -G.
Use VGA text mode palette RGB values in rasops(9)
Hi tech@,
The recent spike of interest around framebuffer consoles has prompted
me to revisit a proposal I sent back in early 2017 [1].
Aesthetics considerations aside, kettenis@ raised the concern that colors
from the original rasops palette carefully matched what OpenFirmware
uses for the console on sparc64.
Therefore, I propose to default on using the proper VGA text mode palette
RGB values, and to keep the original rasops color palette on sparc64.
The differences between the two palettes can be seen here [2].
Comments? OK?
[1] https://marc.info/?l=openbsd-tech&m=148374502927423&w=2
[2]
https://www.cambus.net/openbsd-framebuffer-console-and-custom-color-palettes/
Index: sys/dev/rasops/rasops.c
===
RCS file: /cvs/src/sys/dev/rasops/rasops.c,v
retrieving revision 1.62
diff -u -p -r1.62 rasops.c
--- sys/dev/rasops/rasops.c 16 Jun 2020 21:49:30 - 1.62
+++ sys/dev/rasops/rasops.c 7 Jul 2020 09:10:08 -
@@ -47,7 +47,26 @@
/* ANSI colormap (R,G,B) */
-#defineNORMAL_BLACK0x00
+#ifndef __sparc64__
+#defineNORMAL_BLACK0x00/* VGA text mode palette */
+#defineNORMAL_RED 0xaa
+#defineNORMAL_GREEN0x00aa00
+#defineNORMAL_BROWN0xaa5500
+#defineNORMAL_BLUE 0xaa
+#defineNORMAL_MAGENTA 0xaa00aa
+#defineNORMAL_CYAN 0x00
+#defineNORMAL_WHITE0xaa
+
+#defineHILITE_BLACK0x55
+#defineHILITE_RED 0xff
+#defineHILITE_GREEN0x55ff55
+#defineHILITE_BROWN0x55
+#defineHILITE_BLUE 0xff
+#defineHILITE_MAGENTA 0xff55ff
+#defineHILITE_CYAN 0x55
+#defineHILITE_WHITE0xff
+#else
+#defineNORMAL_BLACK0x00/* Rasops palette */
#defineNORMAL_RED 0x7f
#defineNORMAL_GREEN0x007f00
#defineNORMAL_BROWN0x7f7f00
@@ -64,6 +83,7 @@
#defineHILITE_MAGENTA 0xff00ff
#defineHILITE_CYAN 0x00
#defineHILITE_WHITE0xff
+#endif
const u_char rasops_cmap[256 * 3] = {
#define_C(x) ((x) & 0xff) >> 16, ((x) & 0x00ff00) >> 8, ((x) &
0xff)
Use CPU_IS_PRIMARY macro in identifycpu() on amd64
Hi tech@,
While having a glance at identcpu.c to see how CPU flags were printed
for each CPU, I noticed we have the following macro in cpu.h:
#define CPU_IS_PRIMARY(ci) ((ci)->ci_flags & CPUF_PRIMARY)
Here is a diff to use it in identifycpu() on amd64.
Comments? OK?
Index: sys/arch/amd64/amd64/identcpu.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/identcpu.c,v
retrieving revision 1.115
diff -u -p -r1.115 identcpu.c
--- sys/arch/amd64/amd64/identcpu.c 27 May 2020 05:08:53 - 1.115
+++ sys/arch/amd64/amd64/identcpu.c 6 Jul 2020 21:04:13 -
@@ -480,7 +480,7 @@ identifycpu(struct cpu_info *ci)
ci->ci_efeature_ecx, ci->ci_feature_eflags);
/* Other bits may clash */
ci->ci_feature_flags |= (ci->ci_feature_eflags & CPUID_NXE);
- if (ci->ci_flags & CPUF_PRIMARY)
+ if (CPU_IS_PRIMARY(ci))
ecpu_ecxfeature = ci->ci_efeature_ecx;
/* Let cpu_feature be the common bits */
cpu_feature &= ci->ci_feature_flags;
@@ -515,7 +515,7 @@ identifycpu(struct cpu_info *ci)
sizeof(mycpu_model));
/* If primary cpu, fill in the global cpu_model used by sysctl */
- if (ci->ci_flags & CPUF_PRIMARY)
+ if (CPU_IS_PRIMARY(ci))
strlcpy(cpu_model, mycpu_model, sizeof(cpu_model));
ci->ci_family = (ci->ci_signature >> 8) & 0x0f;
@@ -561,7 +561,7 @@ identifycpu(struct cpu_info *ci)
printf(", %llu.%02llu MHz", (freq + 4999) / 100,
((freq + 4999) / 1) % 100);
- if (ci->ci_flags & CPUF_PRIMARY) {
+ if (CPU_IS_PRIMARY(ci)) {
cpuspeed = (freq + 4999) / 100;
cpu_cpuspeed = cpu_amd64speed;
}
@@ -689,7 +689,7 @@ identifycpu(struct cpu_info *ci)
ci->ci_dev->dv_xname);
}
- if (ci->ci_flags & CPUF_PRIMARY) {
+ if (CPU_IS_PRIMARY(ci)) {
#ifndef SMALL_KERNEL
if (!strcmp(cpu_vendor, "AuthenticAMD") &&
ci->ci_pnfeatset >= 0x8007) {
@@ -737,7 +737,7 @@ identifycpu(struct cpu_info *ci)
#endif
#ifdef CRYPTO
- if (ci->ci_flags & CPUF_PRIMARY) {
+ if (CPU_IS_PRIMARY(ci)) {
if (cpu_ecxfeature & CPUIDECX_PCLMUL)
amd64_has_pclmul = 1;
C99 initializers in wsdisplay_font struct definitions
Hi tech@,
Here is a diff to use C99 initializers in wsdisplay_font struct
definitions for Spleen kernel fonts.
Comments? OK?
Index: sys/dev/wsfont/spleen12x24.h
===
RCS file: /cvs/src/sys/dev/wsfont/spleen12x24.h,v
retrieving revision 1.6
diff -u -p -r1.6 spleen12x24.h
--- sys/dev/wsfont/spleen12x24.h21 Jun 2020 19:03:29 - 1.6
+++ sys/dev/wsfont/spleen12x24.h22 Jun 2020 09:44:40 -
@@ -29,18 +29,18 @@
static u_char spleen12x24_data[];
struct wsdisplay_font spleen12x24 = {
- "Spleen 12x24", /* typeface name */
- 0, /* index */
- ' ',/* firstchar */
- 256 - ' ', /* numchars */
- WSDISPLAY_FONTENC_ISO, /* encoding */
- 12, /* width */
- 24, /* height */
- 2, /* stride */
- WSDISPLAY_FONTORDER_L2R,/* bit order */
- WSDISPLAY_FONTORDER_L2R,/* byte order */
- NULL, /* cookie */
- spleen12x24_data/* data */
+ .name = "Spleen 12x24",
+ .index = 0,
+ .firstchar = ' ',
+ .numchars = 256 - ' ',
+ .encoding = WSDISPLAY_FONTENC_ISO,
+ .fontwidth = 12,
+ .fontheight = 24,
+ .stride = 2,
+ .bitorder = WSDISPLAY_FONTORDER_L2R,
+ .byteorder = WSDISPLAY_FONTORDER_L2R,
+ .cookie = NULL,
+ .data = spleen12x24_data
};
static u_char spleen12x24_data[] = {
Index: sys/dev/wsfont/spleen16x32.h
===
RCS file: /cvs/src/sys/dev/wsfont/spleen16x32.h,v
retrieving revision 1.5
diff -u -p -r1.5 spleen16x32.h
--- sys/dev/wsfont/spleen16x32.h21 Jun 2020 19:03:29 - 1.5
+++ sys/dev/wsfont/spleen16x32.h22 Jun 2020 09:44:40 -
@@ -29,18 +29,18 @@
static u_char spleen16x32_data[];
struct wsdisplay_font spleen16x32 = {
- "Spleen 16x32", /* typeface name */
- 0, /* index */
- ' ',/* firstchar */
- 256 - ' ', /* numchars */
- WSDISPLAY_FONTENC_ISO, /* encoding */
- 16, /* width */
- 32, /* height */
- 2, /* stride */
- WSDISPLAY_FONTORDER_L2R,/* bit order */
- WSDISPLAY_FONTORDER_L2R,/* byte order */
- NULL, /* cookie */
- spleen16x32_data/* data */
+ .name = "Spleen 16x32",
+ .index = 0,
+ .firstchar = ' ',
+ .numchars = 256 - ' ',
+ .encoding = WSDISPLAY_FONTENC_ISO,
+ .fontwidth = 16,
+ .fontheight = 32,
+ .stride = 2,
+ .bitorder = WSDISPLAY_FONTORDER_L2R,
+ .byteorder = WSDISPLAY_FONTORDER_L2R,
+ .cookie = NULL,
+ .data = spleen16x32_data
};
static u_char spleen16x32_data[] = {
Index: sys/dev/wsfont/spleen32x64.h
===
RCS file: /cvs/src/sys/dev/wsfont/spleen32x64.h,v
retrieving revision 1.6
diff -u -p -r1.6 spleen32x64.h
--- sys/dev/wsfont/spleen32x64.h21 Jun 2020 19:03:29 - 1.6
+++ sys/dev/wsfont/spleen32x64.h22 Jun 2020 09:44:41 -
@@ -29,18 +29,18 @@
static u_char spleen32x64_data[];
struct wsdisplay_font spleen32x64 = {
- "Spleen 32x64", /* typeface name */
- 0, /* index */
- ' ',/* firstchar */
- 256 - ' ', /* numchars */
- WSDISPLAY_FONTENC_ISO, /* encoding */
- 32, /* width */
- 64, /* height */
- 4, /* stride */
- WSDISPLAY_FONTORDER_L2R,/* bit order */
- WSDISPLAY_FONTORDER_L2R,/* byte order */
- NULL, /* cookie */
- spleen32x64_data/* data */
+ .name = "Spleen 32x64",
+ .index = 0,
+ .firstchar = ' ',
+ .numchars = 256 - ' ',
+ .encoding = WSDISPLAY_FONTENC_ISO,
+ .fontwidth = 32,
+ .fontheight = 64,
+ .stride = 4,
+ .bitorder = WSDISPLAY_FONTORDER_L2R,
+ .byteorder = WSDISPLAY_FONTORDER_L2R,
+ .cookie = NULL,
+ .data = spleen32x64_data
};
static u_char spleen32x64_data[] = {
Index: sys/dev/wsfont/spleen5x8.h
Enable virtual consoles on armv7
Hi tech@, Here is a diff to enable virtual consoles on armv7, the same way it is done on arm64. Also see the diff I sent earlier to sync fbtab. Tested on a Cubieboard2. Comments? OK? Index: etc/etc.armv7/ttys === RCS file: /cvs/src/etc/etc.armv7/ttys,v retrieving revision 1.1 diff -u -p -r1.1 ttys --- etc/etc.armv7/ttys 4 Sep 2013 16:53:40 - 1.1 +++ etc/etc.armv7/ttys 18 Jun 2020 13:28:18 - @@ -4,6 +4,18 @@ # name getty typestatus comments # console"/usr/libexec/getty std.115200" vt220 on secure +ttyC0 "/usr/libexec/getty std.9600" vt220 off secure +ttyC1 "/usr/libexec/getty std.9600" vt220 on secure +ttyC2 "/usr/libexec/getty std.9600" vt220 on secure +ttyC3 "/usr/libexec/getty std.9600" vt220 on secure +ttyC4 "/usr/libexec/getty std.9600" vt220 off secure +ttyC5 "/usr/libexec/getty std.9600" vt220 on secure +ttyC6 "/usr/libexec/getty std.9600" vt220 off secure +ttyC7 "/usr/libexec/getty std.9600" vt220 off secure +ttyC8 "/usr/libexec/getty std.9600" vt220 off secure +ttyC9 "/usr/libexec/getty std.9600" vt220 off secure +ttyCa "/usr/libexec/getty std.9600" vt220 off secure +ttyCb "/usr/libexec/getty std.9600" vt220 off secure tty00 "/usr/libexec/getty std.115200" unknown off secure tty01 "/usr/libexec/getty std.9600" unknown off secure tty02 "/usr/libexec/getty std.9600" unknown off Index: sys/arch/armv7/conf/GENERIC === RCS file: /cvs/src/sys/arch/armv7/conf/GENERIC,v retrieving revision 1.131 diff -u -p -r1.131 GENERIC --- sys/arch/armv7/conf/GENERIC 29 Apr 2020 19:30:58 - 1.131 +++ sys/arch/armv7/conf/GENERIC 18 Jun 2020 13:28:18 - @@ -17,9 +17,9 @@ makeoptions KERNEL_BASE_VIRT="0xc030 maxusers 32 # estimated number of users option CPU_ARMv7 # Support the ARMv7 -#option WSDISPLAY_COMPAT_USL # VT handling +option WSDISPLAY_COMPAT_USL# VT handling option WSDISPLAY_COMPAT_RAWKBD # can get raw scancodes -option WSDISPLAY_DEFAULTSCREENS=1 +option WSDISPLAY_DEFAULTSCREENS=6 # initial number of text consoles option CONF_HAVE_GPIO option PCIVERBOSE
Sync armv7 fbtab with arm64 fbtab
Hi tech@, Here is a diff to sync armv7 fbtab with arm64 fbtab. I left out drm devices as there aren't any on this platform. Comments? OK? Index: etc/etc.armv7/fbtab === RCS file: /cvs/src/etc/etc.armv7/fbtab,v retrieving revision 1.1 diff -u -p -r1.1 fbtab --- etc/etc.armv7/fbtab 4 Sep 2013 16:53:40 - 1.1 +++ etc/etc.armv7/fbtab 17 Jun 2020 21:07:00 - @@ -1 +1,2 @@ /dev/tty00 0600/dev/console +/dev/ttyC0 0600 /dev/console:/dev/wskbd:/dev/wskbd0:/dev/wsmouse:/dev/wsmouse0:/dev/ttyCcfg:/dev/ttyC4
Add entry for wsfont_init.9 in man9 Makefile
Hi tech@, I commited wsfont_init.9 last year to document the wsfont module of wscons, but apparently forgot to add an entry in the man9 Makefile. The following diff does exactly that. Comments? OK? Index: share/man/man9/Makefile === RCS file: /cvs/src/share/man/man9/Makefile,v retrieving revision 1.302 diff -u -p -r1.302 Makefile --- share/man/man9/Makefile 17 Jun 2020 00:28:28 - 1.302 +++ share/man/man9/Makefile 17 Jun 2020 16:30:37 - @@ -49,6 +49,6 @@ MAN= aml_evalnode.9 atomic_add_int.9 ato vfs_cache.9 vaccess.9 vclean.9 vcount.9 vdevgone.9 vfinddev.9 vflush.9 \ vflushbuf.9 vget.9 vgone.9 vhold.9 vinvalbuf.9 vnode.9 vnsubr.9 \ VOP_LOOKUP.9 vput.9 vrecycle.9 vref.9 vrele.9 \ - vwaitforio.9 vwakeup.9 wdog_register.9 + vwaitforio.9 vwakeup.9 wdog_register.9 wsfont_init.9 .include
Enable bwfm(4) on armv7 RAMDISK for SD/MMC and USB devices
Hi tech@, Here is a diff to enable bwfm(4) on armv7 RAMDISK for SD/MMC and USB devices. Discussed with patrick@. Tested on a Cubieboard2 by building a RAMDISK kernel, which shows my USB Wi-Fi dongle attaching when booting it. I checked the miniroot images and they all have several megabytes of free space: Filesystem SizeUsed Avail Capacity Mounted on /dev/vnd0a14.9M 12.0M3.0M80%/mnt Comments? OK? Index: arch/armv7/conf/RAMDISK === RCS file: /cvs/src/sys/arch/armv7/conf/RAMDISK,v retrieving revision 1.118 diff -u -p -r1.118 RAMDISK --- arch/armv7/conf/RAMDISK 29 Apr 2020 19:30:58 - 1.118 +++ arch/armv7/conf/RAMDISK 17 Jun 2020 10:05:23 - @@ -126,6 +126,7 @@ pci*at pciecam? sdhc* at fdt? sdmmc* at sdhc? +bwfm* at sdmmc? # Broadcom FullMAC psci* at fdt? early 1 syscon*at fdt? early 1 @@ -272,6 +273,7 @@ rsu*at uhub?# Realtek RTL8188SU/RTL8 uath* at uhub?# Atheros AR5005UG/AR5005UX otus* at uhub?# Atheros AR9001U athn* at uhub?# Atheros AR9002U +bwfm* at uhub?# Broadcom FullMAC atphy* at mii? # Attansic F1 PHYs rgephy*at mii? # Realtek 8169S/8110S PHY
Re: Enable building wsmoused on arm64 and armv7
On Thu, May 28, 2020 at 10:52:44AM -0600, Theo de Raadt wrote: > -MANSUBDIR= i386 amd64 alpha > +MANSUBDIR= i386 amd64 arm64 armv7 alpha > > Actually, I suggest making this a MI man page. Delete that line, and see > where the files land. I'll adjust sets. Yes, makes sense. Just commited the change, MANSUBDIR is now gone. The man page ends up in /usr/share/man/man8 as expected.
Enable building wsmoused on arm64 and armv7
Hi tech@,
Here is a diff to enable building wsmoused on arm64 and armv7.
Builds and works correctly on my CubieBoard2.
Comments? OK?
Index: usr.sbin/wsmoused/Makefile
===
RCS file: /cvs/src/usr.sbin/wsmoused/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- usr.sbin/wsmoused/Makefile 16 Jul 2014 20:07:03 - 1.7
+++ usr.sbin/wsmoused/Makefile 28 May 2020 16:35:14 -
@@ -1,6 +1,7 @@
# $OpenBSD: Makefile,v 1.7 2014/07/16 20:07:03 okan Exp $
-.if ${MACHINE} == "i386" || ${MACHINE} == "amd64" ||\
+.if ${MACHINE} == "i386" || ${MACHINE} == "amd64" || \
+${MACHINE} == "arm64" || ${MACHINE} == "armv7" || \
${MACHINE} == "alpha"
PROG= wsmoused
@@ -13,6 +14,6 @@ NOPROG=yes
.endif
MAN= wsmoused.8
-MANSUBDIR= i386 amd64 alpha
+MANSUBDIR= i386 amd64 arm64 armv7 alpha
.include
Enable building wsfontload on arm64 and armv7
Hi tech@,
Here is a diff to enable building wsfontload on arm64 and armv7.
Builds and works correctly on my CubieBoard2.
Comments? OK?
Index: usr.sbin/wsfontload/Makefile
===
RCS file: /cvs/src/usr.sbin/wsfontload/Makefile,v
retrieving revision 1.16
diff -u -p -r1.16 Makefile
--- usr.sbin/wsfontload/Makefile19 Jan 2017 08:06:27 - 1.16
+++ usr.sbin/wsfontload/Makefile28 May 2020 16:34:58 -
@@ -2,6 +2,7 @@
.if ${MACHINE} == "i386" || ${MACHINE} == "amd64" || \
${MACHINE} == "alpha" || ${MACHINE} == "hppa" || \
+${MACHINE} == "arm64" || ${MACHINE} == "armv7" || \
${MACHINE} == "loongson"
PROG= wsfontload
Enable scrollback in simplefb(4)
Hi tech@, Here is a diff to enable scrollback in simplefb(4). Tested on OpenBSD/armv7 on my CubieBoard2. The only arm64 device I own is headless so I cannot test on this platform. Comments? OK? Index: sys/dev/fdt/simplefb.c === RCS file: /cvs/src/sys/dev/fdt/simplefb.c,v retrieving revision 1.10 diff -u -p -r1.10 simplefb.c --- sys/dev/fdt/simplefb.c 25 May 2020 09:55:48 - 1.10 +++ sys/dev/fdt/simplefb.c 28 May 2020 10:52:42 - @@ -103,6 +103,7 @@ struct wsdisplay_accessops simplefb_acce .getchar = rasops_getchar, .load_font = rasops_load_font, .list_font = rasops_list_font, + .scrollback = rasops_scrollback }; int
Re: clear margins when remapping efifb
On Wed, May 27, 2020 at 12:25:00PM +0200, Mark Kettenis wrote:
> > Date: Wed, 27 May 2020 19:39:07 +1000
> > From: Jonathan Gray
> >
> > When testing the row and column increase for efifb on a 1920x1080
> > display I noticed the top part of the screen continues to contain part
> > of a white on blue line from earlier in the dmesg even after the machine
> > has finished booting.
> >
> > RI_CENTER changes the ri_bits offset, doing RI_CLEARMARGINS in cnremap
> > clears the fragment of a line caused by using RI_CENTER.
>
> ok kettenis@
I had a different fix for this issue, which prevents the margins to
appear in the first place.
This is why the margins appear:
In rasops(9), if 'ri_emuwidth' is larger than 'ri_width', it is set to
'ri_width', and similarly for 'ri_emuheight' relative to 'ri_height'.
In efifb_cnattach_common(), we call rasops_init() with EFIFB_HEIGHT
and EFIFB_WIDTH as parameters, so on smaller screens or with larger
fonts, or when increasing the EFIFB_HEIGHT and EFIFB_WIDTH values,
'ri_emu{width,height}' becomes equals to 'ri_{width,height}' and no
centering happens.
Then in efifb_cnremap() and efifb_attach(), efifb_std_descr.nrows and
efifb_std_descr.ncols are used instead, and in this case 'ri_emuwidth'
and 'ri_emuheight' can now be a few pixels smaller than 'ri_width' and
'ri_height' and the text area is centered where it previously wasn't,
causing the content previously displayed in what are now margins to
remain there.
Here is a rebased version of the diff:
Index: sys/arch/amd64/amd64/efifb.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/efifb.c,v
retrieving revision 1.31
diff -u -p -r1.31 efifb.c
--- sys/arch/amd64/amd64/efifb.c27 May 2020 07:48:02 - 1.31
+++ sys/arch/amd64/amd64/efifb.c28 May 2020 07:17:49 -
@@ -222,7 +222,7 @@ efifb_attach(struct device *parent, stru
ri->ri_flg &= ~RI_CLEAR;
ri->ri_flg |= RI_VCONS | RI_WRONLY;
- rasops_init(ri, efifb_std_descr.nrows, efifb_std_descr.ncols);
+ rasops_init(ri, EFIFB_HEIGHT, EFIFB_WIDTH);
ri->ri_ops.pack_attr(ri->ri_active, 0, 0, 0, &defattr);
wsdisplay_cnattach(&efifb_std_descr, ri->ri_active, ccol, crow,
@@ -480,7 +480,7 @@ efifb_cnremap(void)
ri->ri_flg &= ~RI_CLEAR;
ri->ri_flg |= RI_CENTER | RI_WRONLY;
- rasops_init(ri, efifb_std_descr.nrows, efifb_std_descr.ncols);
+ rasops_init(ri, EFIFB_HEIGHT, EFIFB_WIDTH);
efifb_early_cleanup();
}
Because the efifb resolution doesn't change, this ensures 'ri_emuwidth'
and 'ri_emuheight' will always get the same value when we remap and
later when we attach, so the text area is always displayed at the same
position.
I verified it still works, and it solves the issue for me on a 1920x1080
screen.
It was commited [1] and reverted [2] at the time we tried to increase
EFIFB_HEIGHT / EFIFB_WIDTH. I reverted it to be on the safe side as we
were nearing a release and it wasn't useful on its own after reverting
the other changes.
[1]
https://cvsweb.openbsd.org/src/sys/arch/amd64/amd64/efifb.c?rev=1.20&content-type=text/x-cvsweb-markup
[2]
https://cvsweb.openbsd.org/src/sys/arch/amd64/amd64/efifb.c?rev=1.23&content-type=text/x-cvsweb-markup
Add sizes for free() in clct(4)
Hi tech@,
Here is a diff to add sizes for free() in clct(4).
Similar diff to the ones previously sent for other audio drivers.
Comments? OK?
Index: sys/dev/pci/cs4281.c
===
RCS file: /cvs/src/sys/dev/pci/cs4281.c,v
retrieving revision 1.36
diff -u -p -r1.36 cs4281.c
--- sys/dev/pci/cs4281.c19 Sep 2016 06:46:44 - 1.36
+++ sys/dev/pci/cs4281.c20 Dec 2019 15:56:40 -
@@ -1187,7 +1187,7 @@ cs4281_malloc(void *addr, int direction,
error = cs4281_allocmem(sc, size, pool, flags, p);
if (error) {
- free(p, pool, 0);
+ free(p, pool, sizeof(*p));
return (0);
}
@@ -1212,7 +1212,7 @@ cs4281_free(void *addr, void *ptr, int p
bus_dmamem_unmap(sc->sc_dmatag, p->addr, p->size);
bus_dmamem_free(sc->sc_dmatag, p->segs, p->nsegs);
*pp = p->next;
- free(p, pool, 0);
+ free(p, pool, sizeof(*p));
return;
}
}
Add sizes for free() in vio(4)
Hi tech@,
Here is a diff to add sizes for free() in vio(4).
There is an existing allocsize variable tracking size of allocations,
turns out we can pass it to free() in the error path.
Comments? OK?
Index: sys/dev/pv/if_vio.c
===
RCS file: /cvs/src/sys/dev/pv/if_vio.c,v
retrieving revision 1.14
diff -u -p -r1.14 if_vio.c
--- sys/dev/pv/if_vio.c 25 Oct 2019 07:13:54 - 1.14
+++ sys/dev/pv/if_vio.c 18 Dec 2019 14:13:45 -
@@ -482,7 +482,7 @@ err_reqs:
bus_dmamap_destroy(vsc->sc_dmat, sc->sc_rx_dmamaps[i]);
}
if (sc->sc_arrays) {
- free(sc->sc_arrays, M_DEVBUF, 0);
+ free(sc->sc_arrays, M_DEVBUF, allocsize);
sc->sc_arrays = 0;
}
err_hdr:
Add sizes for free() in eso(4)
Hi tech@,
Here is a diff to add sizes for free() in eso(4).
Similar diff to the ones previously sent for other audio drivers.
Comments? OK?
Index: sys/dev/pci/eso.c
===
RCS file: /cvs/src/sys/dev/pci/eso.c,v
retrieving revision 1.44
diff -u -p -r1.44 eso.c
--- sys/dev/pci/eso.c 11 Apr 2018 04:37:19 - 1.44
+++ sys/dev/pci/eso.c 13 Dec 2019 10:02:04 -
@@ -1519,7 +1519,7 @@ eso_allocm(void *hdl, int direction, siz
error = eso_allocmem(sc, size, 32, boundary, flags, direction, ed);
if (error) {
- free(ed, type, 0);
+ free(ed, type, sizeof(*ed));
return (NULL);
}
ed->ed_next = sc->sc_dmas;
@@ -1538,7 +1538,7 @@ eso_freem(void *hdl, void *addr, int typ
if (KVADDR(p) == addr) {
eso_freemem(p);
*pp = p->ed_next;
- free(p, type, 0);
+ free(p, type, sizeof(*p));
return;
}
}
Add sizes for free() in eap(4)
Hi tech@,
Here is a diff to add sizes for free() in eap(4).
Similar diff to the ones previously sent for other audio drivers.
Comments? OK?
Index: sys/dev/pci/eap.c
===
RCS file: /cvs/src/sys/dev/pci/eap.c,v
retrieving revision 1.56
diff -u -p -r1.56 eap.c
--- sys/dev/pci/eap.c 14 Sep 2018 08:37:34 - 1.56
+++ sys/dev/pci/eap.c 13 Dec 2019 09:36:24 -
@@ -1471,7 +1471,7 @@ eap_malloc(void *addr, int direction, si
return (0);
error = eap_allocmem(sc, size, 16, p);
if (error) {
- free(p, pool, 0);
+ free(p, pool, sizeof(*p));
return (0);
}
p->next = sc->sc_dmas;
@@ -1489,7 +1489,7 @@ eap_free(void *addr, void *ptr, int pool
if (KERNADDR(p) == ptr) {
eap_freemem(sc, p);
*pp = p->next;
- free(p, pool, 0);
+ free(p, pool, sizeof(*p));
return;
}
}
Add sizes for free() in auixp(4)
Hi tech@,
Here is a diff to add sizes for free() in auixp(4).
Similar diff to the ones previously sent for other audio drivers.
Comments? OK?
Index: sys/dev/pci/auixp.c
===
RCS file: /cvs/src/sys/dev/pci/auixp.c,v
retrieving revision 1.40
diff -u -p -r1.40 auixp.c
--- sys/dev/pci/auixp.c 3 Sep 2018 05:37:32 - 1.40
+++ sys/dev/pci/auixp.c 13 Dec 2019 09:46:27 -
@@ -382,7 +382,7 @@ auixp_malloc(void *hdl, int direction, s
/* get us a dma buffer itself */
error = auixp_allocmem(sc, size, 16, dma);
if (error) {
- free(dma, pool, 0);
+ free(dma, pool, sizeof(*dma));
printf("%s: auixp_malloc: not enough memory\n",
sc->sc_dev.dv_xname);
return NULL;
@@ -415,7 +415,7 @@ auixp_free(void *hdl, void *addr, int po
SLIST_REMOVE(&sc->sc_dma_list, dma, auixp_dma,
dma_chain);
auixp_freemem(sc, dma);
- free(dma, pool, 0);
+ free(dma, pool, sizeof(*dma));
return;
}
}
@@ -537,7 +537,7 @@ auixp_allocate_dma_chain(struct auixp_so
if (error) {
printf("%s: can't malloc dma descriptor chain\n",
sc->sc_dev.dv_xname);
- free(dma, M_DEVBUF, 0);
+ free(dma, M_DEVBUF, sizeof(*dma));
return ENOMEM;
}
Add sizes for free() in auglx(4)
Hi tech@,
Here is a diff to add sizes for free() in auglx(4).
Similar diff to the ones commited for auvia(4) and autri(4).
Comments? OK?
Index: sys/dev/pci/auglx.c
===
RCS file: /cvs/src/sys/dev/pci/auglx.c,v
retrieving revision 1.16
diff -u -p -r1.16 auglx.c
--- sys/dev/pci/auglx.c 20 Dec 2016 15:45:29 - 1.16
+++ sys/dev/pci/auglx.c 12 Dec 2019 21:38:51 -
@@ -587,7 +587,7 @@ auglx_allocm(void *v, int direction, siz
error = auglx_allocmem(sc, size, PAGE_SIZE, p);
if (error) {
- free(p, pool, 0);
+ free(p, pool, sizeof(*p));
return NULL;
}
@@ -608,7 +608,7 @@ auglx_freem(void *v, void *ptr, int pool
if (p->addr == ptr) {
auglx_freemem(sc, p);
*pp = p->next;
- free(p, pool, 0);
+ free(p, pool, sizeof(*p));
return;
}
}
Add sizes for free() in auacer(4)
Hi tech@,
Here is a diff to add sizes for free() in auacer(4).
Similar diff to the ones commited for auvia(4) and autri(4).
Comments? OK?
Index: sys/dev/pci/auacer.c
===
RCS file: /cvs/src/sys/dev/pci/auacer.c,v
retrieving revision 1.21
diff -u -p -r1.21 auacer.c
--- sys/dev/pci/auacer.c12 Dec 2016 06:43:01 - 1.21
+++ sys/dev/pci/auacer.c12 Dec 2019 21:38:59 -
@@ -603,7 +603,7 @@ auacer_allocm(void *v, int direction, si
error = auacer_allocmem(sc, size, PAGE_SIZE, p);
if (error) {
- free(p, pool, 0);
+ free(p, pool, sizeof(*p));
return (NULL);
}
@@ -623,7 +623,7 @@ auacer_freem(void *v, void *ptr, int poo
if (KERNADDR(p) == ptr) {
auacer_freemem(sc, p);
*pp = p->next;
- free(p, pool, 0);
+ free(p, pool, sizeof(*p));
return;
}
}
Add sizes for free() in autri(4)
Hi tech@,
Here is a diff to add sizes for free() in autri(4).
Similar diff to the one commited for auvia(4).
Comments? OK?
Index: sys/dev/pci/autri.c
===
RCS file: /cvs/src/sys/dev/pci/autri.c,v
retrieving revision 1.42
diff -u -p -r1.42 autri.c
--- sys/dev/pci/autri.c 20 Dec 2016 15:45:29 - 1.42
+++ sys/dev/pci/autri.c 3 Dec 2019 12:45:19 -
@@ -995,7 +995,7 @@ autri_malloc(void *addr, int direction,
#endif
error = autri_allocmem(sc, size, 0x1, p);
if (error) {
- free(p, pool, 0);
+ free(p, pool, sizeof(*p));
return NULL;
}
@@ -1014,7 +1014,7 @@ autri_free(void *addr, void *ptr, int po
if (KERNADDR(p) == ptr) {
autri_freemem(sc, p);
*pp = p->next;
- free(p, pool, 0);
+ free(p, pool, sizeof(*p));
return;
}
}
Add sizes for free() in auvia(4)
Hi tech@, Here is a diff to add sizes for free() in auvia(4). Comments? OK? Index: sys/dev/pci/auvia.c === RCS file: /cvs/src/sys/dev/pci/auvia.c,v retrieving revision 1.59 diff -u -p -r1.59 auvia.c --- sys/dev/pci/auvia.c 14 Sep 2018 08:37:34 - 1.59 +++ sys/dev/pci/auvia.c 30 Nov 2019 22:03:32 - @@ -763,7 +763,7 @@ fail_create: fail_map: bus_dmamem_free(sc->sc_dmat, &p->seg, 1); fail_alloc: - free(p, pool, 0); + free(p, pool, sizeof(*p)); return 0; } @@ -782,7 +782,7 @@ auvia_free(void *addr, void *ptr, int po bus_dmamem_free(sc->sc_dmat, &p->seg, 1); *pp = p->next; - free(p, pool, 0); + free(p, pool, sizeof(*p)); return; }
tsleep_nsec(9) for wsdisplay(4)
Hi tech@,
Here is a diff to convert all tsleep(9) calls in wsdisplay(4)
to tsleep_nsec(9).
Comments? OK?
Index: sys/dev/wscons/wsdisplay.c
===
RCS file: /cvs/src/sys/dev/wscons/wsdisplay.c,v
retrieving revision 1.133
diff -u -p -r1.133 wsdisplay.c
--- sys/dev/wscons/wsdisplay.c 1 Jul 2019 19:38:40 - 1.133
+++ sys/dev/wscons/wsdisplay.c 8 Oct 2019 14:40:56 -
@@ -1830,7 +1830,8 @@ wsdisplay_switch(struct device *dev, int
s = spltty();
while (sc->sc_resumescreen != WSDISPLAY_NULLSCREEN && res == 0)
- res = tsleep(&sc->sc_resumescreen, PCATCH, "wsrestore", 0);
+ res = tsleep_nsec(&sc->sc_resumescreen, PCATCH, "wsrestore",
+ INFSLP);
if (res) {
splx(s);
return (res);
@@ -1980,7 +1981,7 @@ wsscreen_switchwait(struct wsdisplay_sof
if (no == WSDISPLAY_NULLSCREEN) {
s = spltty();
while (sc->sc_focus && res == 0) {
- res = tsleep(sc, PCATCH, "wswait", 0);
+ res = tsleep_nsec(sc, PCATCH, "wswait", INFSLP);
}
splx(s);
return (res);
@@ -1995,7 +1996,7 @@ wsscreen_switchwait(struct wsdisplay_sof
s = spltty();
if (scr != sc->sc_focus) {
scr->scr_flags |= SCR_WAITACTIVE;
- res = tsleep(scr, PCATCH, "wswait2", 0);
+ res = tsleep_nsec(scr, PCATCH, "wswait2", INFSLP);
if (scr != sc->sc_scr[no])
res = ENXIO; /* disappeared in the meantime */
else
Spleen kernel fonts improvements
/* .*** */
- 0x0f, 0x0f, 0xe0, 0xf0, /* ***. */
- 0x0f, 0x1f, 0xc0, 0xf0, /* ...***.. */
- 0x0f, 0x3f, 0x80, 0xf0, /* ..***... */
- 0x0f, 0x7f, 0x00, 0xf0, /* .*** */
- 0x0f, 0xfe, 0x00, 0xf0, /* ***. */
+ 0x0f, 0x00, 0x7e, 0xf0, /* .**. */
+ 0x0f, 0x00, 0xfc, 0xf0, /* **.. */
+ 0x0f, 0x01, 0xf8, 0xf0, /* ...**... */
+ 0x0f, 0x03, 0xf0, 0xf0, /* ..** */
+ 0x0f, 0x07, 0xe0, 0xf0, /* .**. */
+ 0x0f, 0x0f, 0xc0, 0xf0, /* **.. */
+ 0x0f, 0x1f, 0x80, 0xf0, /* ...**... */
+ 0x0f, 0x3f, 0x00, 0xf0, /* ..** */
+ 0x0f, 0x7e, 0x00, 0xf0, /* .**. */
0x0f, 0xfc, 0x00, 0xf0, /* **.. */
0x0f, 0xf8, 0x00, 0xf0, /* *... */
0x0f, 0xf0, 0x00, 0xf0, /* */
0x0f, 0xe0, 0x00, 0xf0, /* ***. */
0x0f, 0xc0, 0x00, 0xf0, /* **.. */
0x0f, 0x80, 0x00, 0xf0, /* *... */
+ 0x0f, 0x00, 0x00, 0xf0, /* */
0x0f, 0x00, 0x00, 0xf0, /* */
0x0f, 0x00, 0x00, 0xf0, /* */
0x0f, 0x00, 0x00, 0xf0, /* */
Index: sys/dev/wsfont/spleen5x8.h
===
RCS file: /cvs/src/sys/dev/wsfont/spleen5x8.h,v
retrieving revision 1.3
diff -u -p -r1.3 spleen5x8.h
--- sys/dev/wsfont/spleen5x8.h 8 Jun 2019 07:44:07 - 1.3
+++ sys/dev/wsfont/spleen5x8.h 2 Oct 2019 20:54:25 -
@@ -1,7 +1,7 @@
/* $OpenBSD: spleen5x8.h,v 1.3 2019/06/08 07:44:07 fcambus Exp $ */
/*
- * Copyright (c) 2018 Frederic Cambus
+ * Copyright (c) 2018-2019 Frederic Cambus
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -254,7 +254,7 @@ static u_char spleen5x8_data[] = {
0x00, /* */
0xf0, /* */
0x90, /* *..* */
- 0x20, /* ..*. */
+ 0x10, /* ...* */
0x20, /* ..*. */
0x40, /* .*.. */
0x40, /* .*.. */
Spleen kernel fonts improvements
Hi tech@,
Here is a diff to sync kernel fonts with the latest released Spleen
version, bringing the following improvements:
- Character at position CB is 'E' with diaeresis, not with tilde (12x24 version)
- Character at position D6 is 'O' with diaeresis, not with tilde (12x24 version)
- Character at position DC is 'U' with diaeresis, not with tilde (12x24 version)
- Fix middle bar thickness in the upper case 'eth' character (12x24 version)
- Fix ring alignment for the 'A' and 'a' characters (16x32 and 32x64 versions)
- Fix tilde alignment in the 'o' with tilde character (32x64 version)
- Remove strain pixel on the '3' and 'k' characters (32x64 version)
Comments? OK?
Index: sys/dev/wsfont/spleen12x24.h
===
RCS file: /cvs/src/sys/dev/wsfont/spleen12x24.h,v
retrieving revision 1.3
diff -u -p -r1.3 spleen12x24.h
--- sys/dev/wsfont/spleen12x24.h8 Jun 2019 07:44:07 - 1.3
+++ sys/dev/wsfont/spleen12x24.h3 Sep 2019 20:22:08 -
@@ -4319,9 +4319,9 @@ static u_char spleen12x24_data[] = {
0x00, 0x00, /* */
0x00, 0x00, /* */
- 0x1c, 0x60, /* ...***...**. */
- 0x3f, 0xc0, /* .... */
- 0x63, 0x80, /* .**...***... */
+ 0x00, 0x00, /* */
+ 0x30, 0xc0, /* ..****.. */
+ 0x30, 0xc0, /* ..****.. */
0x00, 0x00, /* */
0x1f, 0xe0, /* .... */
0x30, 0x00, /* ..** */
@@ -4419,9 +4419,9 @@ static u_char spleen12x24_data[] = {
0x00, 0x00, /* */
0x00, 0x00, /* */
- 0x1c, 0x60, /* ...***...**. */
- 0x3f, 0xc0, /* .... */
- 0x63, 0x80, /* .**...***... */
+ 0x00, 0x00, /* */
+ 0x30, 0xc0, /* ..****.. */
+ 0x30, 0xc0, /* ..****.. */
0x00, 0x00, /* */
0x3f, 0xc0, /* .... */
0x06, 0x00, /* .**. */
@@ -4456,7 +4456,7 @@ static u_char spleen12x24_data[] = {
0x60, 0x60, /* .**..**. */
0x60, 0x60, /* .**..**. */
0xfc, 0x60, /* **...**. */
- 0xfc, 0x60, /* **...**. */
+ 0x60, 0x60, /* .**..**. */
0x60, 0x60, /* .**..**. */
0x60, 0x60, /* .**..**. */
0x60, 0x60, /* .**..**. */
@@ -4744,9 +4744,9 @@ static u_char spleen12x24_data[] = {
0x00, 0x00, /* */
0x00, 0x00, /* */
- 0x1c, 0x60, /* ...***...**. */
- 0x3f, 0xc0, /* .... */
- 0x63, 0x80, /* .**...***... */
+ 0x00, 0x00, /* */
+ 0x30, 0xc0, /* ..****.. */
+ 0x30, 0xc0, /* ..****.. */
0x00, 0x00, /* */
0x60, 0x60, /* .**..**. */
0x60, 0x60, /* .**..**. */
Index: sys/dev/wsfont/spleen16x32.h
===
RCS file: /cvs/src/sys/dev/wsfont/spleen16x32.h,v
retrieving revision 1.3
diff -u -p -r1.3 spleen16x32.h
--- sys/dev/wsfont/spleen16x32.h8 Jun 2019 07:44:07 - 1.3
+++ sys/dev/wsfont/spleen16x32.h3 Sep 2019 20:22:09 -
@@ -5489,12 +5489,12 @@ static u_char spleen16x32_data[] = {
0x00, 0x00, /* */
0x00, 0x00, /* */
- 0x00, 0x00, /* */
0x01, 0x80, /* ...**... */
0x03, 0xc0, /* .... */
0x06, 0x60, /* .**..**. */
0x06, 0x60, /* .**..**. */
0x03, 0xc0, /* .... */
+ 0x01, 0x80, /* ...**... */
0x0f, 0xf0, /* */
0x1f, 0xf8, /* ...**... */
0x38, 0x1c, /* ..***..***.. */
@@ -6548,7 +6548,6 @@ static u_char spleen16x32_data[] = {
0x00, 0x00, /* */
0x00, 0x00, /* */
0x00, 0x00, /* */
- 0x00, 0x00, /* */
0x01, 0xc0, /* ...***.. */
0x03, 0xe0, /* ..*. */
0x06, 0x30, /* .**...** */
@@ -6556,6 +6555,7 @@ static u_char spleen16x32_data[] = {
0x06, 0x30, /* .**...** */
0x03, 0xe0, /* ..*. */
0x01, 0xc0, /* ...***.. */
+ 0x00, 0x00, /* */
0x00, 0x00, /* */
0x1f, 0xf0, /* ...* */
0x1f, 0xf8, /* ...**... */
Index: sys/dev/wsfont/spleen32x64.h
==
Fix a segmentation fault in awk
Hi tech@,
Here is a diff to fix a segmentation fault in awk, from upstream
version 20121220 [1]. Upstream fix didn't check for strdup return value
so I added the check.
I've been seeing some awk.core files in my home directory for a while
now, and finally decided to try investigating why it happened. It turns
out misc/mc calls awk to process file information when navigating through
ZIP files, and it sometimes causes awk to segfault.
[1] http://distcache.FreeBSD.org/ports-distfiles/nawk-20121220/awk.tar.gz
Comments? OK?
Index: usr.bin/awk/run.c
===
RCS file: /cvs/src/usr.bin/awk/run.c,v
retrieving revision 1.42
diff -u -p -r1.42 run.c
--- usr.bin/awk/run.c 9 Oct 2017 14:51:31 - 1.42
+++ usr.bin/awk/run.c 12 Aug 2019 18:01:14 -
@@ -1217,13 +1217,15 @@ Cell *dopa2(Node **a, int n)/* a[0], a[
Cell *split(Node **a, int nnn) /* split(a[0], a[1], a[2]); a[3] is type */
{
Cell *x = 0, *y, *ap;
- char *s;
+ char *s, *origs;
int sep;
char *t, temp, num[50], *fs = 0;
int n, tempstat, arg3type;
y = execute(a[0]); /* source string */
- s = getsval(y);
+ origs = s = strdup(getsval(y));
+ if (s == NULL)
+ FATAL("out of space in split");
arg3type = ptoi(a[3]);
if (a[2] == 0) /* fs string */
fs = *FS;
@@ -1343,6 +1345,7 @@ Cell *split(Node **a, int nnn)/* split(
}
tempfree(ap);
tempfree(y);
+ free(origs);
if (a[2] != 0 && arg3type == STRING) {
tempfree(x);
}
Spleen kernel fonts improvements
Hi tech@,
Here is a diff to sync kernel fonts with the latest released Spleen
version, bringing the following improvements:
- Shift the middle bar of the upper case 'G' one pixel down in the 12x24
version
- Shift lower case 'k' character right, for better alignment in the 12x24,
16x32, and 32x64 versions
- Make upper case 'X' thicker in the 16x32 and 32x64 versions
- Make upper case 'V' thicker in the 32x64 version
- Make lower case 'g' character smoother in the 16x32 and 32x64 versions
- Add some artefacts on each side of the lower case 'i' characters
Comments? OK?
Index: sys/dev/wsfont/spleen12x24.h
===
RCS file: /cvs/src/sys/dev/wsfont/spleen12x24.h,v
retrieving revision 1.2
diff -u -p -r1.2 spleen12x24.h
--- sys/dev/wsfont/spleen12x24.h8 Mar 2019 10:53:59 - 1.2
+++ sys/dev/wsfont/spleen12x24.h5 Jun 2019 10:15:21 -
@@ -1029,13 +1029,13 @@ static u_char spleen12x24_data[] = {
0x60, 0x00, /* .**. */
0x60, 0x00, /* .**. */
0x60, 0x00, /* .**. */
+ 0x60, 0x00, /* .**. */
0x63, 0xe0, /* .**...*. */
0x60, 0x60, /* .**..**. */
0x60, 0x60, /* .**..**. */
0x60, 0x60, /* .**..**. */
0x60, 0x60, /* .**..**. */
0x60, 0x60, /* .**..**. */
- 0x60, 0x60, /* .**..**. */
0x30, 0x60, /* ..**.**. */
0x1f, 0xe0, /* .... */
0x00, 0x00, /* */
@@ -1877,6 +1877,7 @@ static u_char spleen12x24_data[] = {
0x06, 0x00, /* .**. */
0x00, 0x00, /* */
0x00, 0x00, /* */
+ 0x1e, 0x00, /* .... */
0x06, 0x00, /* .**. */
0x06, 0x00, /* .**. */
0x06, 0x00, /* .**. */
@@ -1886,8 +1887,7 @@ static u_char spleen12x24_data[] = {
0x06, 0x00, /* .**. */
0x06, 0x00, /* .**. */
0x06, 0x00, /* .**. */
- 0x06, 0x00, /* .**. */
- 0x06, 0x00, /* .**. */
+ 0x07, 0x80, /* .... */
0x00, 0x00, /* */
0x00, 0x00, /* */
0x00, 0x00, /* */
@@ -1923,21 +1923,21 @@ static u_char spleen12x24_data[] = {
0x00, 0x00, /* */
0x00, 0x00, /* */
0x00, 0x00, /* */
- 0x60, 0x00, /* .**. */
- 0x60, 0x00, /* .**. */
- 0x60, 0x00, /* .**. */
- 0x60, 0x00, /* .**. */
- 0x61, 0x80, /* .****... */
- 0x61, 0x80, /* .****... */
- 0x63, 0x00, /* .**...** */
- 0x66, 0x00, /* .**..**. */
- 0x7c, 0x00, /* .*.. */
- 0x6c, 0x00, /* .**.**.. */
- 0x66, 0x00, /* .**..**. */
- 0x63, 0x00, /* .**...** */
- 0x61, 0x80, /* .****... */
- 0x60, 0xc0, /* .**.**.. */
- 0x60, 0xc0, /* .**.**.. */
+ 0x30, 0x00, /* ..** */
+ 0x30, 0x00, /* ..** */
+ 0x30, 0x00, /* ..** */
+ 0x30, 0x00, /* ..** */
+ 0x30, 0xc0, /* ..****.. */
+ 0x30, 0xc0, /* ..****.. */
+ 0x31, 0x80, /* ..**...**... */
+ 0x33, 0x00, /* ..**..** */
+ 0x3e, 0x00, /* ..*. */
+ 0x36, 0x00, /* ..**.**. */
+ 0x33, 0x00, /* ..**..** */
+ 0x31, 0x80, /* ..**...**... */
+ 0x30, 0xc0, /* ..****.. */
+ 0x30, 0x60, /* ..**.**. */
+ 0x30, 0x60, /* ..**.**. */
0x00, 0x00, /* */
0x00, 0x00, /* */
0x00, 0x00, /* */
@@ -5152,6 +5152,7 @@ static u_char spleen12x24_data[] = {
0x03, 0x00, /* ..** */
0x00, 0x00, /* */
0x00, 0x00, /* */
+ 0x1e, 0x00, /* .... */
0x06, 0x00, /* .**. */
0x06, 0x00, /* .**. */
0x06, 0x00, /* .**. */
@@ -5161,8 +5162,7 @@ static u_char spleen12x24_data[] = {
0x06, 0x00, /* .**. */
0x06, 0x00, /* .**. */
0x06, 0x00, /* .**. */
- 0x06, 0x00, /* .**. */
- 0x06, 0x00, /* .**. */
+ 0x07, 0x80, /* ....
Re: sbin/wsconsctl: show more data
On Mon, Mar 18, 2019 at 08:02:09PM +0200, Artturi Alm wrote: > > Revised diff below iterating on what Artturi previously sent, and > > a snippet of wsconsctl output with the diff applied: > > > > display.width=1600 > > display.height=900 > > display.depth=32 > > +display.fontwidth=12 > > +display.fontheight=24 > > display.emulations=vt100 > > display.screentypes=std > > display.focus=4 > > > > [1] https://undeadly.org/cgi?action=article&sid=20131023125815 > > > > Comments? OK? > > > > While my opinion is irrelevant, it does look good to me, thanks :] Ping. Anyone willing to OK the revised diff? Would be useful to have this in 6.5.
Re: sbin/wsconsctl: show more data
On Mon, Jan 07, 2019 at 04:27:46PM -0700, Theo de Raadt wrote:
> Ted Unangst wrote:
>
> > Artturi Alm wrote:
> > > display.width=1920
> > > display.height=1200
> > > display.depth=32
> > > display.emulations=vt100
> > > display.col_x_row=120x37
> > > display.font_wxh=16x32
> >
> > now that we've all had a chance to weigh in on the font, why are you adding
> > this weird x format? speaking of ugly... it should print columns and rows
> > just
> > like width and height.
>
> it is a waste of kernel and userland code since another mechanism already
> exists
>
> use stty -a
While I agree it doesn't make sense to add variables for showing
the number of columns and rows, as the information can be obtained
using ssty -a, displaying fontwidth and fontheight values would be
useful. This allows users to know the size of the currently loaded
font.
Thinking forward, this would also allow to easily get those values
in shell scripts, which can be leveraged if we wanted to only embed
7-bit ASCII characters in the kernel and load the full font later on,
or if someone wanted to continue the UTF-8 work [1] started by miod@.
Revised diff below iterating on what Artturi previously sent, and
a snippet of wsconsctl output with the diff applied:
display.width=1600
display.height=900
display.depth=32
+display.fontwidth=12
+display.fontheight=24
display.emulations=vt100
display.screentypes=std
display.focus=4
[1] https://undeadly.org/cgi?action=article&sid=20131023125815
Comments? OK?
Index: sbin/wsconsctl/display.c
===
RCS file: /cvs/src/sbin/wsconsctl/display.c,v
retrieving revision 1.20
diff -u -p -r1.20 display.c
--- sbin/wsconsctl/display.c8 May 2015 19:12:51 - 1.20
+++ sbin/wsconsctl/display.c18 Mar 2019 17:11:59 -
@@ -41,7 +41,7 @@
#include "wsconsctl.h"
u_int dpytype;
-u_int width, height, depth;
+u_int width, height, depth, fontwidth, fontheight;
int focus;
struct field_pc brightness, contrast, backlight;
int burnon, burnoff, vblank, kbdact, msact, outact;
@@ -54,6 +54,8 @@ struct field display_field_tab[] = {
{ "width", &width, FMT_UINT, FLG_RDONLY },
{ "height",&height,FMT_UINT, FLG_RDONLY },
{ "depth", &depth, FMT_UINT, FLG_RDONLY },
+{ "fontwidth", &fontwidth, FMT_UINT, FLG_RDONLY },
+{ "fontheight",&fontheight,FMT_UINT, FLG_RDONLY },
{ "emulations",&emuls, FMT_EMUL, FLG_RDONLY },
{ "screentypes", &screens, FMT_SCREEN, FLG_RDONLY },
{ "focus", &focus, FMT_INT,FLG_NORDBACK },
@@ -84,7 +86,7 @@ display_get_values(int fd)
const char *cmd_str;
void *ptr;
unsigned long cmd;
- int bon = 0, fbon = 0;
+ int bon = 0, fbon = 0, son = 0;
focus = gscr.idx = -1;
for (pf = display_field_tab; pf->name; pf++) {
@@ -102,6 +104,10 @@ display_get_values(int fd)
} else if (ptr == &emuls) {
fillioctl(WSDISPLAYIO_GETEMULTYPE);
emuls.idx=0;
+ } else if (ptr == &fontwidth || ptr == &fontheight) {
+ fillioctl(WSDISPLAYIO_GETSCREENTYPE);
+ ptr = &screens;
+ screens.idx = 0;
} else if (ptr == &screens) {
fillioctl(WSDISPLAYIO_GETSCREENTYPE);
screens.idx=0;
@@ -168,6 +174,11 @@ display_get_values(int fd)
emuls.idx=fd;
} else if (ptr == &screens) {
screens.idx=fd;
+ if (!son) {
+ fontwidth = screens.fontwidth;
+ fontheight = screens.fontheight;
+ }
+ son++;
} else if (ptr == ¶m) {
struct field_pc *pc = pf->valp;
rasops(9): revert changes in rasops32_putchar()?
Hi tech@,
Now that efifb(4) supports remapping the framebuffer in write combining
mode, it's on par with inteldrm regarding display performance as for as
rasops(9) is concerned.
Therefore, I'm proposing reverting changes which were introduced in
rasops32_putchar() in revision 1.8 [1] as they are now also slowing
things down on efifb(4).
I used a 6.3M text file for testing display performance:
ftp https://norvig.com/big.txt
The inteldrm and efifb tests were done on the same machine, the
radeondrm ones were done on another (faster) machine.
Screen size: 1920x1080
Font size: 16x32
Here are the results (3 runs each) of running: time cat big.txt
inteldrm:
2m39.52s real 0m00.00s user 2m39.52s system
2m39.74s real 0m00.00s user 2m39.84s system
2m39.74s real 0m00.00s user 2m39.77s system
inteldrm (with revert diff applied):
1m37m76s real 0m00.00s user 1m37m60s system
1m37m80s real 0m00.00s user 1m37m56s system
1m37m43s real 0m00.00s user 1m37m47s system
efifb:
2m40.46s real 0m00.00s user 2m39.43s system
2m39.49s real 0m00.00s user 2m39.52s system
2m39.45s real 0m00.00s user 2m39.48s system
efifb (with revert diff applied):
1m37m66s real 0m00.00s user 1m37m19s system
1m37m17s real 0m00.00s user 1m37m22s system
1m37m15s real 0m00.00s user 1m37m20s system
radeondrm:
4m40.75s real 0m00.00s user 4m39m75s system
4m39.84s real 0m00.00s user 4m39m85s system
4m39.68s real 0m00.00s user 4m39m71s system
radeondrm (with revert diff applied):
0m21.08s real 0m00.00s user 0m21.08s system
0m21.15s real 0m00.00s user 0m21.05s system
0m21.10s real 0m00.00s user 0m21.06s system
[1]
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/rasops/rasops32.c.diff?r1=1.7&r2=1.8
Comments? OK?
Index: sys/dev/rasops/rasops32.c
===
RCS file: /cvs/src/sys/dev/rasops/rasops32.c,v
retrieving revision 1.8
diff -u -p -r1.8 rasops32.c
--- sys/dev/rasops/rasops32.c 20 Feb 2017 15:35:05 - 1.8
+++ sys/dev/rasops/rasops32.c 18 Mar 2019 08:15:18 -
@@ -69,7 +69,6 @@ rasops32_putchar(void *cookie, int row,
struct rasops_info *ri;
int32_t *dp, *rp;
u_char *fr;
- uint32_t buffer[64];
ri = (struct rasops_info *)cookie;
@@ -91,13 +90,12 @@ rasops32_putchar(void *cookie, int row,
clr[1] = ri->ri_devcmap[(attr >> 24) & 0xf];
if (uc == ' ') {
- for (cnt = 0; cnt < width; cnt++)
- buffer[cnt] = clr[0];
while (height--) {
dp = rp;
DELTA(rp, ri->ri_stride, int32_t *);
- memcpy(dp, buffer, width << 2);
+ for (cnt = width; cnt; cnt--)
+ *dp++ = clr[0];
}
} else {
uc -= ri->ri_font->firstchar;
@@ -111,11 +109,10 @@ rasops32_putchar(void *cookie, int row,
fr += fs;
DELTA(rp, ri->ri_stride, int32_t *);
- for (cnt = 0; cnt < width; cnt++) {
- buffer[cnt] = clr[(fb >> 31) & 1];
+ for (cnt = width; cnt; cnt--) {
+ *dp++ = clr[(fb >> 31) & 1];
fb <<= 1;
}
- memcpy(dp, buffer, width << 2);
}
}
rasops(9): remove filtering in rasops_list_font_cb()
Hi tech@,
Here is a diff to modify rasops_list_font_cb() to not filter out fonts
with different sizes than the currently used one. This allows getting a
list of all loaded fonts when using the WSDISPLAYIO_LSFONT ioctl.
Currently, the output of wsfontload -l on my machine is:
# Name Encoding W H
0 Spleen 12x24 iso 12 24
With the diff applied:
# Name Encoding W H
0 Spleen 8x16 iso 8 16
1 Spleen 12x24 iso 12 24
2 Spleen 16x32 iso 16 32
3 Spleen 32x64 iso 32 64
On top of allowing to see all fonts which are currently loaded, it
removes the confusion as to why we reach the WSDISPLAY_MAXFONTCOUNT
limit faster than expected when loading more fonts.
It is also a first step towards allowing loading and enabling fonts
of different sizes.
Comments? OK?
Index: sys/dev/rasops/rasops.c
===
RCS file: /cvs/src/sys/dev/rasops/rasops.c,v
retrieving revision 1.58
diff -u -p -r1.58 rasops.c
--- sys/dev/rasops/rasops.c 9 Jan 2019 11:23:32 - 1.58
+++ sys/dev/rasops/rasops.c 15 Mar 2019 22:57:43 -
@@ -1899,10 +1899,6 @@ rasops_list_font_cb(void *cbarg, struct
{
struct rasops_list_font_ctx *ctx = cbarg;
- if (font->fontheight != ctx->ri->ri_font->fontheight ||
- font->fontwidth != ctx->ri->ri_font->fontwidth)
- return 0;
-
if (ctx->cnt-- == 0) {
ctx->font = font;
return 1;
efifb(4): raise maximum size to match inteldrm and radeondrm?
Hi tech@,
Currently, we set the maximum size for the EFI framebuffer console to
100 columns and 31 rows.
Now that efifb(4) supports remapping the framebuffer in write combining
mode, it's now fast enough to consider increasing those values to 160
columns and 160 rows, to match the values in inteldrm and radeondrm.
Comments? OK?
Index: sys/arch/amd64/amd64/efifb.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/efifb.c,v
retrieving revision 1.20
diff -u -p -r1.20 efifb.c
--- sys/arch/amd64/amd64/efifb.c15 Mar 2019 10:38:14 - 1.20
+++ sys/arch/amd64/amd64/efifb.c15 Mar 2019 14:52:11 -
@@ -114,8 +114,8 @@ const struct cfattach efifb_ca = {
sizeof(struct efifb_softc), efifb_match, efifb_attach, NULL
};
-#defineEFIFB_WIDTH 100
-#defineEFIFB_HEIGHT31
+#defineEFIFB_WIDTH 160
+#defineEFIFB_HEIGHT160
struct wsscreen_descr efifb_std_descr = { "std" };
Update openchrome to 0.6.182 in Xenocara
Hi tech@, Here is a diff to update openchrome to 0.6.182 in Xenocara. Tested on my VX900 system. Comments? OK? Index: driver/xf86-video-openchrome/Makefile.in === RCS file: /cvs/xenocara/driver/xf86-video-openchrome/Makefile.in,v retrieving revision 1.10 diff -u -p -r1.10 Makefile.in --- driver/xf86-video-openchrome/Makefile.in9 Dec 2018 21:07:33 - 1.10 +++ driver/xf86-video-openchrome/Makefile.in11 Mar 2019 22:46:14 - @@ -73,7 +73,7 @@ subdir = . DIST_COMMON = README $(am__configure_deps) $(srcdir)/Makefile.am \ $(srcdir)/Makefile.in $(srcdir)/config.h.in \ $(top_srcdir)/configure COPYING ChangeLog NEWS config.guess \ - config.sub install-sh ltmain.sh missing + config.sub depcomp install-sh ltmain.sh missing ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 am__aclocal_m4_deps = $(top_srcdir)/acinclude.m4 \ $(top_srcdir)/configure.ac Index: driver/xf86-video-openchrome/aclocal.m4 === RCS file: /cvs/xenocara/driver/xf86-video-openchrome/aclocal.m4,v retrieving revision 1.9 diff -u -p -r1.9 aclocal.m4 --- driver/xf86-video-openchrome/aclocal.m4 9 Dec 2018 21:07:33 - 1.9 +++ driver/xf86-video-openchrome/aclocal.m4 11 Mar 2019 22:46:14 - @@ -8606,32 +8606,63 @@ m4_ifndef([_LT_PROG_F77], [AC_DEFUN([_L m4_ifndef([_LT_PROG_FC], [AC_DEFUN([_LT_PROG_FC])]) m4_ifndef([_LT_PROG_CXX], [AC_DEFUN([_LT_PROG_CXX])]) -# pkg.m4 - Macros to locate and utilise pkg-config.-*- Autoconf -*- -# serial 1 (pkg-config-0.24) -# -# Copyright © 2004 Scott James Remnant . -# -# This program is free software; you can redistribute it and/or modify -# it under the terms of the GNU General Public License as published by -# the Free Software Foundation; either version 2 of the License, or -# (at your option) any later version. -# -# This program is distributed in the hope that it will be useful, but -# WITHOUT ANY WARRANTY; without even the implied warranty of -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -# General Public License for more details. -# -# You should have received a copy of the GNU General Public License -# along with this program; if not, write to the Free Software -# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. -# -# As a special exception to the GNU General Public License, if you -# distribute this file as part of a program that contains a -# configuration script generated by Autoconf, you may include it under -# the same distribution terms that you use for the rest of that program. - -# PKG_PROG_PKG_CONFIG([MIN-VERSION]) -# -- +dnl pkg.m4 - Macros to locate and utilise pkg-config. -*- Autoconf -*- +dnl serial 11 (pkg-config-0.29.1) +dnl +dnl Copyright © 2004 Scott James Remnant . +dnl Copyright © 2012-2015 Dan Nicholson +dnl +dnl This program is free software; you can redistribute it and/or modify +dnl it under the terms of the GNU General Public License as published by +dnl the Free Software Foundation; either version 2 of the License, or +dnl (at your option) any later version. +dnl +dnl This program is distributed in the hope that it will be useful, but +dnl WITHOUT ANY WARRANTY; without even the implied warranty of +dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +dnl General Public License for more details. +dnl +dnl You should have received a copy of the GNU General Public License +dnl along with this program; if not, write to the Free Software +dnl Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA +dnl 02111-1307, USA. +dnl +dnl As a special exception to the GNU General Public License, if you +dnl distribute this file as part of a program that contains a +dnl configuration script generated by Autoconf, you may include it under +dnl the same distribution terms that you use for the rest of that +dnl program. + +dnl PKG_PREREQ(MIN-VERSION) +dnl --- +dnl Since: 0.29 +dnl +dnl Verify that the version of the pkg-config macros are at least +dnl MIN-VERSION. Unlike PKG_PROG_PKG_CONFIG, which checks the user's +dnl installed version of pkg-config, this checks the developer's version +dnl of pkg.m4 when generating configure. +dnl +dnl To ensure that this macro is defined, also add: +dnl m4_ifndef([PKG_PREREQ], +dnl [m4_fatal([must install pkg-config 0.29 or later before running autoconf/autogen])]) +dnl +dnl See the "Since" comment for each macro you use to see what version +dnl of the macros you require. +m4_defun([PKG_PREREQ], +[m4_define([PKG_MACROS_VERSION], [0.29.1]) +m4_if(m4_version_compare(PKG_MACROS_VERSION, [$1]), -1, +[m4_fatal([pkg.m4 version $1 or higher is required but ]PKG_MACROS_VERSION[ found])]) +])dnl PKG_PREREQ + +dnl PKG_PROG_PKG_CONFIG([MIN-VERSION]) +dnl -- +dnl Since:
Spleen kernel fonts improvements
Hi tech@,
Here is a diff to sync kernel fonts with the latest released Spleen
version, bringing the following improvements:
- Remove strain pixels on the inner upper part of parentheses for the
16x32 version
- Harmonize the 'v' and 'V' characters across all sizes
- Remove artefacts from the 'c' in the copyright sign across all sizes
- Make the upper left corner of the 'R' sharp in the registered sign
for the 16x32 and 32x64 versions
Comments? OK?
Index: sys/dev/wsfont/spleen12x24.h
===
RCS file: /cvs/src/sys/dev/wsfont/spleen12x24.h,v
retrieving revision 1.1
diff -u -p -r1.1 spleen12x24.h
--- sys/dev/wsfont/spleen12x24.h2 Dec 2018 14:44:33 - 1.1
+++ sys/dev/wsfont/spleen12x24.h7 Mar 2019 14:13:19 -
@@ -1,7 +1,7 @@
/* $OpenBSD: spleen12x24.h,v 1.1 2018/12/02 14:44:33 fcambus Exp $ */
/*
- * Copyright (c) 2018 Frederic Cambus
+ * Copyright (c) 2018-2019 Frederic Cambus
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -1408,10 +1408,10 @@ static u_char spleen12x24_data[] = {
0x60, 0x60, /* .**..**. */
0x60, 0x60, /* .**..**. */
0x60, 0x60, /* .**..**. */
- 0x30, 0xe0, /* ..*****. */
+ 0x30, 0xc0, /* ..****.. */
0x30, 0xc0, /* ..****.. */
0x19, 0x80, /* ...**..**... */
- 0x0f, 0x80, /* *... */
+ 0x0f, 0x00, /* */
0x06, 0x00, /* .**. */
0x00, 0x00, /* */
0x00, 0x00, /* */
@@ -2208,7 +2208,7 @@ static u_char spleen12x24_data[] = {
0x60, 0x60, /* .**..**. */
0x60, 0x60, /* .**..**. */
0x60, 0x60, /* .**..**. */
- 0x30, 0xe0, /* ..*****. */
+ 0x30, 0xc0, /* ..****.. */
0x30, 0xc0, /* ..****.. */
0x19, 0x80, /* ...**..**... */
0x0f, 0x00, /* */
@@ -3480,7 +3480,7 @@ static u_char spleen12x24_data[] = {
0x30, 0xc0, /* ..****.. */
0x60, 0x60, /* .**..**. */
0x67, 0x60, /* .**..***.**. */
- 0x6d, 0x60, /* .**.**.*.**. */
+ 0x6c, 0x60, /* .**.**...**. */
0x6c, 0x60, /* .**.**...**. */
0x6c, 0x60, /* .**.**...**. */
0x6c, 0x60, /* .**.**...**. */
Index: sys/dev/wsfont/spleen16x32.h
===
RCS file: /cvs/src/sys/dev/wsfont/spleen16x32.h,v
retrieving revision 1.1
diff -u -p -r1.1 spleen16x32.h
--- sys/dev/wsfont/spleen16x32.h2 Dec 2018 14:44:33 - 1.1
+++ sys/dev/wsfont/spleen16x32.h7 Mar 2019 14:13:19 -
@@ -1,7 +1,7 @@
/* $OpenBSD: spleen16x32.h,v 1.1 2018/12/02 14:44:33 fcambus Exp $ */
/*
- * Copyright (c) 2018 Frederic Cambus
+ * Copyright (c) 2018-2019 Frederic Cambus
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -316,7 +316,7 @@ static u_char spleen16x32_data[] = {
0x01, 0xe0, /* .... */
0x03, 0x80, /* ..***... */
0x07, 0x00, /* .*** */
- 0x07, 0x00, /* .*** */
+ 0x06, 0x00, /* .**. */
0x0e, 0x00, /* ***. */
0x0c, 0x00, /* **.. */
0x1c, 0x00, /* ...***.. */
@@ -349,7 +349,7 @@ static u_char spleen16x32_data[] = {
0x07, 0x80, /* .... */
0x01, 0xc0, /* ...***.. */
0x00, 0xe0, /* ***. */
- 0x00, 0xe0, /* ***. */
+ 0x00, 0x60, /* .**. */
0x00, 0x70, /* .*** */
0x00, 0x30, /* ..** */
0x00, 0x38, /* ..***... */
@@ -1846,7 +1846,7 @@ static u_char spleen16x32_data[] = {
0x30, 0x0c, /* ..****.. */
0x30, 0x0c, /* ..****.. */
0x30, 0x0c, /* ..****.. */
- 0x18, 0x18, /* ...**..**... */
+ 0x38, 0x1c, /* ..***..***.. */
0x1c, 0x38, /* ...******... */
0x0e, 0x70, /* ***..*** */
0x07, 0xe0, /* .**. */
@@ -4581,7 +4581,7 @@ static u_char spleen16x32_data[] = {
0x30, 0x0c, /* ..****.. */
0x33, 0xec, /* ..**..*.**.. */
0x37, 0xec, /* ..**.**.**.. */
- 0x36, 0x6c, /* ..**.**..**.**.. */
+ 0x36, 0x0c, /* ..**.**.**.. */
0x36, 0x0c, /* ..**.**.**.. */
0x36, 0x0c, /* ..**.**.**.. */
0x36, 0x0c, /* ..**.**.**.
Re: bktr(4): remove useless assignment
On Sat, Nov 17, 2018 at 04:36:49PM -0700, Theo de Raadt wrote: > Why not delete the 2nd line? > > I mean isn't it obvious? I'd expect some archeology to figure > out how this bug got introduced, rather than a diff which you > obviously don't know the result of. Fair enough, I realize it indeed looks that way if I don't mention anything. Before sending the diff I found out that both assignements are in our tree since the driver got imported from FreeBSD in 2001 and remained untouched since r1.1. I then checked the actual state of yuvpack_prog() in FreeBSD and only the second assignment remains. The second assignment in its current form got introduced in FreeBSD in 1997 with r29233 [1], when syncinc the driver. The first assignment got removed in 2017 with r314147 [2]. [1]: https://svnweb.freebsd.org/base?view=revision&revision=29233 [2]: https://svnweb.freebsd.org/base?view=revision&revision=314147
bktr(4): remove useless assignment
Hi tech@, Remove useless assignment, value is overwritten right after being set. Coverity CID 1453008. Comments? OK? Index: dev/pci/bktr/bktr_core.c === RCS file: /cvs/src/sys/dev/pci/bktr/bktr_core.c,v retrieving revision 1.39 diff -u -p -r1.39 bktr_core.c --- dev/pci/bktr/bktr_core.c28 Apr 2018 15:44:59 - 1.39 +++ dev/pci/bktr/bktr_core.c17 Nov 2018 21:24:29 - @@ -2864,7 +2864,6 @@ yuvpack_prog( bktr_ptr_t bktr, char i_fl OUTB(bktr, BKTR_COLOR_CTL, INB(bktr, BKTR_COLOR_CTL) | BT848_COLOR_CTL_RGB_DED | BT848_COLOR_CTL_GAMMA); OUTB(bktr, BKTR_ADC, SYNC_LEVEL); - bktr->capcontrol = 1 << 6 | 1 << 4 | 1 << 2 | 3; bktr->capcontrol = 3 << 2 | 3; dma_prog = (u_int *) bktr->dma_prog;
Add wsfont.9, documenting the wsfont subsystem
Hi tech@,
Here is a diff to add wsfont.9, documenting the wsfont subsystem.
This is wsfont.9 revision 1.18 from NetBSD with the following changes:
- Add $Mdocdate$ marker
- Remove documentation for wsfont_matches() which we don't have
- Remove wsfont_find() arguments which we don't have
- Add missing arguments for wsfont_lock() which NetBSD doesn't have
- Modify wsfont_enum() signature to match our implementation
- Modify the wsdisplay_font structure to add the index and cookie members
which NetBSD doesn't have
- Removed some macros for font encoding we do not support anymore
- Removed and corrected stuff which doesn't apply to us because
the codebases have diverged
Comments? OK?
Index: share/man/man9/wsfont.9
===
RCS file: share/man/man9/wsfont.9
diff -N share/man/man9/wsfont.9
--- /dev/null 1 Jan 1970 00:00:00 -
+++ share/man/man9/wsfont.9 13 Nov 2018 21:57:35 -
@@ -0,0 +1,191 @@
+.\"$OpenBSD$
+.\" $NetBSD: wsfont.9,v 1.18 2012/01/13 23:09:51 wiz Exp $
+.\"
+.\" Copyright (c) 2001 The NetBSD Foundation, Inc.
+.\" All rights reserved.
+.\"
+.\" This code is derived from software contributed to The NetBSD Foundation
+.\" by Gregory McGarry.
+.\"
+.\" 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 NETBSD FOUNDATION, INC. 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 FOUNDATION 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.
+.\"
+.Dd $Mdocdate$
+.Dt WSFONT 9
+.Os
+.Sh NAME
+.Nm wsfont ,
+.Nm wsfont_init ,
+.Nm wsfont_find ,
+.Nm wsfont_add ,
+.Nm wsfont_remove ,
+.Nm wsfont_enum ,
+.Nm wsfont_lock ,
+.Nm wsfont_unlock ,
+.Nm wsfont_map_unichar
+.Nd wscons font support
+.Sh SYNOPSIS
+.In dev/wscons/wsconsio.h
+.In dev/wsfont/wsfont.h
+.Ft void
+.Fn wsfont_init "void"
+.Ft int
+.Fn wsfont_find "const char *name" "int width" "int height" "int stride"
+.Ft int
+.Fn wsfont_add "struct wsdisplay_font *font" "int copy"
+.Ft int
+.Fn wsfont_remove "int cookie"
+.Ft void
+.Fn wsfont_enum "int (*cb)(void *, struct wsdisplay_font *)" "void *cbarg"
+.Ft int
+.Fn wsfont_lock "int cookie" "struct wsdisplay_font **ptr" "int bitorder" \
+"int byteorder"
+.Ft int
+.Fn wsfont_unlock "int cookie"
+.Ft int
+.Fn wsfont_map_unichar "struct wsdisplay_font *font" "int c"
+.Sh DESCRIPTION
+The
+.Nm
+module is a component of the wscons
+.\" .Xr wscons 9
+framework to provide access to display fonts.
+Fonts may be loaded dynamically into the kernel or included statically
+in the kernel at compile time.
+Display drivers which emulate a glass-tty console on a bit-mapped
+display can add, remove and find fonts for use by device-dependent
+blitter operations.
+.Pp
+The primary data type for manipulating fonts is the
+.Em wsdisplay_font
+structure in
+.Pa dev/wscons/wsconsio.h :
+.Bd -literal
+struct wsdisplay_font {
+ char name[WSFONT_NAME_SIZE];/* font name */
+ int index;
+ int firstchar;
+ int numchars; /* size of font table */
+ int encoding; /* font encoding */
+ u_int fontwidth;/* character width */
+ u_int fontheight; /* character height */
+ u_int stride;
+ int bitorder;
+ int byteorder;
+ void *cookie;
+ void *data; /* pointer to font table */
+};
+.Ed
+.Pp
+The maximum font table size is
+.Em WSDISPLAY_MAXFONTSZ .
+.Pp
+The
+.Nm
+framework supports fonts with the following encodings:
+.Bl -tag -width compact
+.It Dv WSDISPLAY_FONTENC_ISO
+ISO-encoded fonts.
+.It Dv WSDISPLAY_FONTENC_IBM
+IBM-encoded fonts commonly available for IBM CGA, EGA and VGA display
+adapters.
+.El
+.Sh FUNCTIONS
+.Bl -tag -width compact
+.It Fn wsfont_init "void"
+Initialise the font list with the built-in fonts.
+.It Fn wsfont_find "name" "width" "height" "st
Re: pcidevs update for VIA HD Audio device
On Sun, Nov 11, 2018 at 07:54:12PM +0100, Frederic Cambus wrote: > > Add ID for a VIA HD Audio device found on my HP t5570 Thin Client. > > > > While there, update URL for the vendor ID search engine. > > > > Comments? OK? > > Anyone willing to OK this? Thanks! Please disregard previous mail. It was already OK'ed, daniel@ was kind enough to point me to the mail I missed. Sorry for the noise.
Re: pcidevs update for VIA HD Audio device
On Thu, Nov 01, 2018 at 11:07:20PM +0100, Frederic Cambus wrote: > Add ID for a VIA HD Audio device found on my HP t5570 Thin Client. > > While there, update URL for the vendor ID search engine. > > Comments? OK? Anyone willing to OK this? Thanks!
pcidevs update for VIA HD Audio device
Hi tech@, Add ID for a VIA HD Audio device found on my HP t5570 Thin Client. While there, update URL for the vendor ID search engine. Comments? OK? Index: sys/dev/pci/pcidevs === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.1865 diff -u -p -r1.1865 pcidevs --- sys/dev/pci/pcidevs 26 Oct 2018 05:53:58 - 1.1865 +++ sys/dev/pci/pcidevs 31 Oct 2018 17:43:06 - @@ -39,7 +39,7 @@ $OpenBSD: pcidevs,v 1.1865 2018/10/26 05 * * There is a Vendor ID search engine available at: * - * http://www.pcisig.com/membership/vid_search/ + * https://pcisig.com/membership/member-companies */ /* @@ -7623,7 +7623,7 @@ product VIATECH PM800_DRAM0x3259 PM800 product VIATECH KT880_30x3269 KT880 Host product VIATECH K8HTB_30x3282 K8HTB Host product VIATECH VT8251_ISA 0x3287 VT8251 ISA -product VIATECH HDA0x3288 HD Audio +product VIATECH HDA_0 0x3288 HD Audio product VIATECH CX700_40x3324 CX700 Host product VIATECH P4M890_3 0x3327 P4M890 Host product VIATECH K8M890_3 0x3336 K8M890 Host @@ -7706,6 +7706,7 @@ product VIATECH VT82C598AGP 0x8598 VT82C product VIATECH VT82C601 0x8601 VT82C601 AGP product VIATECH VT8605_AGP 0x8605 VT8605 AGP product VIATECH VX900_IDE 0x9001 VX900 IDE +product VIATECH HDA_1 0x9170 HD Audio product VIATECH VX800_SDMMC0x9530 VX800 SD/MMC product VIATECH VX800_SDIO 0x95d0 VX800 SDIO product VIATECH K8T890_PPB_A 0xa238 K8T890
wdc(4): remove unnecessary if/else block
Hi tech@,
Remove unnecessary if/else block, both branches are identical. We can
in fact use the ATA_DELAY macro directly.
Coverity CID 1453008.
Comments? OK?
Index: dev/ata/ata_wdc.c
===
RCS file: /cvs/src/sys/dev/ata/ata_wdc.c,v
retrieving revision 1.51
diff -u -p -r1.51 ata_wdc.c
--- dev/ata/ata_wdc.c 30 Dec 2017 20:46:59 - 1.51
+++ dev/ata/ata_wdc.c 1 Nov 2018 12:34:17 -
@@ -240,7 +240,6 @@ _wdc_ata_bio_start(struct channel_softc
u_int16_t cyl;
u_int8_t head, sect, cmd = 0;
int nblks;
- int ata_delay;
int error, dma_flags = 0;
WDCDEBUG_PRINT(("_wdc_ata_bio_start %s:%d:%d\n",
@@ -283,10 +282,6 @@ _wdc_ata_bio_start(struct channel_softc
if (ata_bio->flags & ATA_LBA48)
dma_flags |= WDC_DMA_LBA48;
}
- if (ata_bio->flags & ATA_SINGLE)
- ata_delay = ATA_DELAY;
- else
- ata_delay = ATA_DELAY;
again:
/*
*
@@ -345,7 +340,7 @@ again:
}
/* Initiate command */
wdc_set_drive(chp, xfer->drive);
- if (wait_for_ready(chp, ata_delay) < 0)
+ if (wait_for_ready(chp, ATA_DELAY) < 0)
goto timeout;
/* start the DMA channel (before) */
@@ -391,7 +386,7 @@ again:
}
/* Initiate command! */
wdc_set_drive(chp, xfer->drive);
- if (wait_for_ready(chp, ata_delay) < 0)
+ if (wait_for_ready(chp, ATA_DELAY) < 0)
goto timeout;
if (ata_bio->flags & ATA_LBA48) {
wdccommandext(chp, xfer->drive, cmd,
@@ -410,7 +405,7 @@ again:
}
/* If this was a write and not using DMA, push the data. */
if ((ata_bio->flags & ATA_READ) == 0) {
- if (wait_for_drq(chp, ata_delay) != 0) {
+ if (wait_for_drq(chp, ATA_DELAY) != 0) {
printf("%s:%d:%d: timeout waiting for DRQ, "
"st=0x%b, err=0x%02x\n",
chp->wdc->sc_dev.dv_xname, chp->channel,
Add "Spleen 5x8" font to wsfont
Hi tech@,
Here is a diff to add "Spleen 5x8" to wsfont, a font targetted at small
OLED displays to be used with devices handled by ssdfb(4). It contains
all printable ASCII characters (96 glyphes).
The font is 2-Clause BSD licensed and is my original creation.
In order to enable and test the font, this option should be added to the
kernel configuration file: option FONT_SPLEEN5x8
Screenshot: https://www.cambus.net/files/openbsd/dmesg-spleen5x8.png
Comments? OK?
Index: sys/dev/wsfont/wsfont.c
===
RCS file: /cvs/src/sys/dev/wsfont/wsfont.c,v
retrieving revision 1.52
diff -u -p -r1.52 wsfont.c
--- sys/dev/wsfont/wsfont.c 8 Sep 2017 05:36:53 - 1.52
+++ sys/dev/wsfont/wsfont.c 20 Sep 2018 18:52:29 -
@@ -43,6 +43,11 @@
#undef HAVE_FONT
+#ifdef FONT_SPLEEN5x8
+#define HAVE_FONT 1
+#include
+#endif
+
#ifdef FONT_BOLD8x16
#define HAVE_FONT 1
#include
@@ -105,6 +110,9 @@ static struct font builtin_fonts[] = {
#endif
#ifdef FONT_GALLANT12x22
BUILTIN_FONT(gallant12x22, 3),
+#endif
+#ifdef FONT_SPLEEN5x8
+ BUILTIN_FONT(spleen5x8, 4),
#endif
#undef BUILTIN_FONT
};
Index: sys/dev/wsfont/spleen5x8.h
===
RCS file: sys/dev/wsfont/spleen5x8.h
diff -N sys/dev/wsfont/spleen5x8.h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sys/dev/wsfont/spleen5x8.h 20 Sep 2018 18:52:29 -
@@ -0,0 +1,910 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2018 Frederic Cambus
+ * All rights reserved.
+ *
+ * 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.
+ */
+
+static u_char spleen5x8_data[];
+
+struct wsdisplay_font spleen5x8 = {
+ "Spleen 5x8", /* typeface name */
+ 0, /* index */
+ ' ',/* firstchar */
+ 128 - ' ', /* numchars */
+ WSDISPLAY_FONTENC_ISO, /* encoding */
+ 5, /* width */
+ 8, /* height */
+ 1, /* stride */
+ WSDISPLAY_FONTORDER_L2R,/* bit order */
+ WSDISPLAY_FONTORDER_L2R,/* byte order */
+ NULL, /* cookie */
+ spleen5x8_data /* data */
+};
+
+static u_char spleen5x8_data[] = {
+ 0x00, /* */
+ 0x00, /* */
+ 0x00, /* */
+ 0x00, /* */
+ 0x00, /* */
+ 0x00, /* */
+ 0x00, /* */
+ 0x00, /* */
+
+ 0x20, /* ..*. */
+ 0x20, /* ..*. */
+ 0x20, /* ..*. */
+ 0x20, /* ..*. */
+ 0x20, /* ..*. */
+ 0x00, /* */
+ 0x20, /* ..*. */
+ 0x00, /* */
+
+ 0x50, /* .*.* */
+ 0x50, /* .*.* */
+ 0x50, /* .*.* */
+ 0x00, /* */
+ 0x00, /* */
+ 0x00, /* */
+ 0x00, /* */
+ 0x00, /* */
+
+ 0x00, /* */
+ 0x50, /* .*.* */
+ 0xf8, /* *... */
+ 0x50, /* .*.* */
+ 0x50, /* .*.* */
+ 0xf8, /* *... */
+ 0x50, /* .*.* */
+ 0x00, /* */
+
+ 0x20, /* ..*. */
+ 0x70, /* .*** */
+ 0xa0, /* *.*. */
+ 0x60, /* .**. */
+ 0x30, /* ..** */
+ 0x30, /* ..** */
+ 0xe0, /* ***. */
+ 0x20, /* ..*. */
+
+ 0x10, /* ...*.
Re: Harmonize spacing after ellipses in install.sub
On Tue, Aug 14, 2018 at 11:31:30AM +0200, Frederic Cambus wrote:
> We are using spacing after ellipses in displayed messages in an
> inconsistant way.
Here is an improved diff which takes into account the cursor position
while we are waiting for the task to complete, as pointed out by
deraadt@.
In this version the cursor is always positioned after the last dot, and
the space is added when displaying completion confirmation.
This also fixes the extra leading space in dhclient messages.
Comments? OK?
Index: distrib/miniroot/install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.1100
diff -u -p -r1.1100 install.sub
--- distrib/miniroot/install.sub19 Aug 2018 20:35:51 - 1.1100
+++ distrib/miniroot/install.sub21 Aug 2018 14:27:17 -
@@ -2517,10 +2517,10 @@ check_fs() {
((_passno > 0)) || continue
echo -n "fsck -${_f}p $_dev..."
if ! fsck -${_f}p $_dev >/dev/null 2>&1; then
- echo "FAILED. You must fsck $_dev manually."
+ echo " FAILED. You must fsck $_dev manually."
_fail=y
else
- echo "OK."
+ echo " OK."
fi
done /dev/null 2>&1 && echo "done." || echo "failed."
+ ) >/dev/null 2>&1 && echo " done." || echo " failed."
fi
# Ensure that sysmerge in batch mode is run on reboot.
@@ -2791,8 +2791,8 @@ set -A _KERNV -- \$(sysctl -n kern.versi
sed 's/^OpenBSD \([0-9]\.[0-9]\)\([^ ]*\).*/\1 \2/;q')
if ((\${#_KERNV[*]} == 1)) && [[ -s /etc/installurl ]] &&
_CKPATCH=\$(mktemp /tmp/_ckpatch.XX); then
- echo -n "Checking for available binary patches... "
- syspatch -c > \$_CKPATCH && echo -n "done."
+ echo -n "Checking for available binary patches..."
+ syspatch -c > \$_CKPATCH && echo -n " done."
echo
if [[ -s \$_CKPATCH ]]; then
echo "Run syspatch(8) to install:"
@@ -3070,7 +3070,7 @@ do_install() {
[[ -f $_f && -s $_f ]] && mv $_f /mnt/etc/.
done)
- echo "done."
+ echo " done."
# Apply configuration settings based on information from questions().
apply
@@ -3124,11 +3124,11 @@ do_upgrade() {
echo -n "Checking root filesystem (fsck -fp /dev/$ROOTDEV)..."
fsck -fp /dev/$ROOTDEV >/dev/null 2>&1 || { echo "FAILED."; exit; }
- echo "OK."
+ echo " OK."
echo -n "Mounting root filesystem (mount -o ro /dev/$ROOTDEV /mnt)..."
mount -o ro /dev/$ROOTDEV /mnt || { echo "FAILED."; exit; }
- echo "OK."
+ echo " OK."
# The fstab and myname files are required.
for _f in /mnt/etc/{fstab,myname}; do
Index: sys/kern/vfs_subr.c
===
RCS file: /cvs/src/sys/kern/vfs_subr.c,v
retrieving revision 1.277
diff -u -p -r1.277 vfs_subr.c
--- sys/kern/vfs_subr.c 13 Jul 2018 09:25:23 - 1.277
+++ sys/kern/vfs_subr.c 21 Aug 2018 14:27:20 -
@@ -1691,7 +1691,7 @@ vfs_shutdown(struct proc *p)
acct_shutdown();
#endif
- printf("syncing disks... ");
+ printf("syncing disks...");
if (panicstr == 0) {
/* Sync before unmount, in case we hang on something. */
@@ -1704,9 +1704,9 @@ vfs_shutdown(struct proc *p)
#endif
if (vfs_syncwait(p, 1))
- printf("giving up\n");
+ printf(" giving up\n");
else
- printf("done\n");
+ printf(" done\n");
}
/*
Index: sbin/dhclient/dhclient.c
===
RCS file: /cvs/src/sbin/dhclient/dhclient.c,v
retrieving revision 1.576
diff -u -p -r1.576 dhclient.c
--- sbin/dhclient/dhclient.c13 Aug 2018 14:10:26 - 1.576
+++ sbin/dhclient/dhclient.c21 Aug 2018 14:27:21 -
@@ -2771,7 +2771,7 @@ tick_msg(const char *preamble, int succe
return;
if (preamble_sent == 0) {
- fprintf(stderr, "%s: no %s ...", log_procname, preamble);
+ fprintf(stderr, "%s: no %s...", log_procname, preamble);
fflush(stderr);
preamble_sent = 1;
}
Re: rasops(9) cursor drawing code
On Tue, Aug 21, 2018 at 08:07:03PM +0200, Mark Kettenis wrote: > > Date: Mon, 20 Aug 2018 20:55:16 +0200 (CEST) > > From: Mark Kettenis > > > > > Date: Mon, 20 Aug 2018 15:46:57 +0200 > > > From: Frederic Cambus > > > > > > There is an issue when moving the cursor backwards with the left arrow > > > key, characters disappear and only reappear when moving back forward > > > with the right arrow key. > > > > > > I also noticed some similar artefacts when using interactive programs > > > with wsmoused enabled. > > > > Ah, I didn't take the scrollback offset into account. Here is a > > better diff. > > As fcambus@ noticed, I attached the old diff again. Here is the right > one. This version fixes the issues I was seeing. OK fcambus@
Re: rasops(9) cursor drawing code
On Mon, Aug 20, 2018 at 02:05:15PM +0200, Mark Kettenis wrote: > So even when you set the RI_WRONLY or RI_VCONS flag, the rasops code > still does framebuffer reads when it draws the cursor. This causes > problems on a particular (somewhat broken) machine I have. But since > we know that framebuffer reads are quite expensive on other machines, > I think it makes sense to fix this. > > The existing code would xor the cursor position with 0x. This > implementation instead redraws the character at the cursor position > with foreground and background color reversed. That isn't the same > thing, but I think it is a sensible approach and for most cases you > wouldn't be able to tell the difference. There is an issue when moving the cursor backwards with the left arrow key, characters disappear and only reappear when moving back forward with the right arrow key. I also noticed some similar artefacts when using interactive programs with wsmoused enabled.
Add /usr/include/c++ to hier.7
Hi tech@, Here is a diff to add /usr/include/c++ in hier.7. Comments? OK? Index: share/man/man7/hier.7 === RCS file: /cvs/src/share/man/man7/hier.7,v retrieving revision 1.160 diff -u -p -r1.160 hier.7 --- share/man/man7/hier.7 11 Jul 2018 18:45:45 - 1.160 +++ share/man/man7/hier.7 14 Aug 2018 11:27:16 - @@ -210,6 +210,8 @@ Standard C include files. .Bl -tag -width "libmilter/" -compact .It arpa/ C include files for Internet service protocols. +.It c++/ +Include files for the Clang C++ compiler. .It crypto/ C include files for the cryptographic libraries. .It ddb/
Harmonize spacing after ellipses in install.sub
Hi tech@,
We are using spacing after ellipses in displayed messages in an
inconsistant way.
A few examples:
- openssl: generating isakmpd/iked RSA keys... done.
- syncing disks... done
- iwm0: no link . got link
- iwm0: no lease .. got lease
Another example, from syspatch:
- Relinking to create unique kernel... done.
In install.sub though, we find the same message for kernel relinking,
without a space this time:
- Relinking to create unique kernel...done.
And most messages with ellipses in install.sub are displayed without a
space, except for:
- Checking for available binary patches... done.
I propose to standardize on using "... " everywhere, and the following
diff enforces this for the installer.
Comments? OK?
Index: distrib/miniroot/install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.1098
diff -u -p -r1.1098 install.sub
--- distrib/miniroot/install.sub10 Jul 2018 14:22:36 - 1.1098
+++ distrib/miniroot/install.sub14 Aug 2018 09:06:28 -
@@ -2515,7 +2515,7 @@ check_fs() {
# Make sure device exists before fsck'ing it.
make_dev "$_dn" || continue
((_passno > 0)) || continue
- echo -n "fsck -${_f}p $_dev..."
+ echo -n "fsck -${_f}p $_dev... "
if ! fsck -${_f}p $_dev >/dev/null 2>&1; then
echo "FAILED. You must fsck $_dev manually."
_fail=y
@@ -2716,7 +2716,7 @@ finish_up() {
echo "$INSTALL_URL" >/mnt/etc/installurl
fi
- echo -n "Making all device nodes..."
+ echo -n "Making all device nodes... "
(cd /mnt/dev; sh MAKEDEV all
# Make sure any devices we found during probe are created in the
# installed system.
@@ -2760,7 +2760,7 @@ finish_up() {
sha256 /mnt/bsd | (umask 077; sed 's,/mnt,,' >/mnt/var/db/kernel.SHA256)
if [[ -f $_kernel_dir.tgz ]]; then
- echo -n "Relinking to create unique kernel..."
+ echo -n "Relinking to create unique kernel... "
(
set -e
rm -rf $_kernel_dir
@@ -3029,7 +3029,7 @@ do_install() {
/mnt/etc/ttys >/tmp/i/ttys
mv /tmp/i/ttys /mnt/etc/ttys
- echo -n "Saving configuration files..."
+ echo -n "Saving configuration files... "
# Save any leases obtained during install.
(cd /var/db; for _f in dhclient.leases.*; do
@@ -3122,11 +3122,11 @@ do_upgrade() {
# Get $ROOTDISK and $ROOTDEV
get_rootinfo
- echo -n "Checking root filesystem (fsck -fp /dev/$ROOTDEV)..."
+ echo -n "Checking root filesystem (fsck -fp /dev/$ROOTDEV)... "
fsck -fp /dev/$ROOTDEV >/dev/null 2>&1 || { echo "FAILED."; exit; }
echo "OK."
- echo -n "Mounting root filesystem (mount -o ro /dev/$ROOTDEV /mnt)..."
+ echo -n "Mounting root filesystem (mount -o ro /dev/$ROOTDEV /mnt)... "
mount -o ro /dev/$ROOTDEV /mnt || { echo "FAILED."; exit; }
echo "OK."
Remove dead assignment in login(1)
Hi tech@, Since rev 1.36, the instance variable is never read again so we can simply drop the else clause with the assignment. Comments? OK? Index: usr.bin/login/login.c === RCS file: /cvs/src/usr.bin/login/login.c,v retrieving revision 1.69 diff -u -p -r1.69 login.c --- usr.bin/login/login.c 8 Dec 2017 17:04:15 - 1.69 +++ usr.bin/login/login.c 7 Aug 2018 13:47:00 - @@ -406,8 +406,7 @@ main(int argc, char *argv[]) if (strncmp(instance + 1, "root", 4) == 0) rootlogin = 1; *instance++ = '\0'; - } else - instance = ""; + } if (strlen(username) > UT_NAMESIZE) username[UT_NAMESIZE] = '\0';
simplefb(4): display color depth when attaching
Hi tech@,
Here is a diff to display color depth alongside resolution when
attaching simplefb(4).
Compile tested only, the only arm64 device I own is headless.
Comments? OK?
Index: sys/dev/fdt/simplefb.c
===
RCS file: /cvs/src/sys/dev/fdt/simplefb.c,v
retrieving revision 1.3
diff -u -p -r1.3 simplefb.c
--- sys/dev/fdt/simplefb.c 18 Dec 2017 10:13:45 - 1.3
+++ sys/dev/fdt/simplefb.c 29 Jul 2018 21:15:13 -
@@ -154,7 +154,7 @@ simplefb_attach(struct device *parent, s
ri->ri_flg &= ~RI_CLEAR;
}
- printf(": %dx%d\n", ri->ri_width, ri->ri_height);
+ printf(": %dx%d, %dbpp\n", ri->ri_width, ri->ri_height, ri->ri_depth);
ri->ri_flg |= RI_VCONS;
rasops_init(ri, SIMPLEFB_HEIGHT, SIMPLEFB_WIDTH);
Re: rasops(9): Remove rasops4 functions?
On Tue, Jul 24, 2018 at 05:42:32PM +0200, Mark Kettenis wrote: > > Date: Sun, 22 Jul 2018 15:12:09 +0200 > > From: Frederic Cambus > > > > Hi tech@, > > > > Nothing uses the rasops4 (4-bit color depth) functions anymore. > > > > It seems unlikely that any future new platform will ever need them. > > > > Should we remove them? > > > > Comments? OK? > > Hmm, apparently 4-bit is quite common for e-ink displays. So maybe it > makes sense to keep this... In light of this, I think it indeed makes sense to keep them. Thanks for pointing this out.
rasops(9): Remove rasops4 functions?
Hi tech@,
Nothing uses the rasops4 (4-bit color depth) functions anymore.
It seems unlikely that any future new platform will ever need them.
Should we remove them?
Comments? OK?
Index: sys/conf/files
===
RCS file: /cvs/src/sys/conf/files,v
retrieving revision 1.664
diff -u -p -r1.664 files
--- sys/conf/files 13 Jul 2018 09:25:22 - 1.664
+++ sys/conf/files 22 Jul 2018 10:29:36 -
@@ -41,7 +41,6 @@ attachmidi at midibus
# raster operations attributes
define rasops1
-define rasops4
define rasops8
define rasops15
define rasops16
Index: sys/dev/rasops/files.rasops
===
RCS file: /cvs/src/sys/dev/rasops/files.rasops,v
retrieving revision 1.7
diff -u -p -r1.7 files.rasops
--- sys/dev/rasops/files.rasops 15 Dec 2016 19:18:41 - 1.7
+++ sys/dev/rasops/files.rasops 22 Jul 2018 10:29:36 -
@@ -3,14 +3,13 @@
# Note: `rasops_glue' is only here to force the header file's name
# hence it must be mentioned first (shudder...)
-file dev/rasops/rasops.c ((rasops_glue | rasops1 | rasops4 | rasops8 |
+file dev/rasops/rasops.c ((rasops_glue | rasops1 | rasops8 |
rasops15 | rasops16 | rasops24 | rasops32 |
rasops_bswap | rasops_rotation) &
wsdisplay) needs-flag
-file dev/rasops/rasops_masks.c wsdisplay & (rasops1 | rasops4)
+file dev/rasops/rasops_masks.c wsdisplay & rasops1
file dev/rasops/rasops1.cwsdisplay & rasops1
-file dev/rasops/rasops4.cwsdisplay & rasops4
file dev/rasops/rasops8.cwsdisplay & rasops8
file dev/rasops/rasops15.c wsdisplay & (rasops15 | rasops16)
file dev/rasops/rasops24.c wsdisplay & rasops24
Index: sys/dev/rasops/rasops.c
===
RCS file: /cvs/src/sys/dev/rasops/rasops.c,v
retrieving revision 1.54
diff -u -p -r1.54 rasops.c
--- sys/dev/rasops/rasops.c 3 May 2018 10:05:47 - 1.54
+++ sys/dev/rasops/rasops.c 22 Jul 2018 10:29:37 -
@@ -428,11 +428,6 @@ rasops_reconfig(struct rasops_info *ri,
rasops1_init(ri);
break;
#endif
-#if NRASOPS4 > 0
- case 4:
- rasops4_init(ri);
- break;
-#endif
#if NRASOPS8 > 0
case 8:
rasops8_init(ri);
@@ -785,8 +780,6 @@ rasops_init_devcmap(struct rasops_info *
int i;
#if NRASOPS15 > 0 || NRASOPS16 > 0 || NRASOPS24 > 0 || NRASOPS32 > 0
const u_char *p;
-#endif
-#if NRASOPS4 > 0 || NRASOPS15 > 0 || NRASOPS16 > 0 || NRASOPS24 > 0 ||
NRASOPS32 > 0
int c;
#endif
@@ -798,14 +791,6 @@ rasops_init_devcmap(struct rasops_info *
}
switch (ri->ri_depth) {
-#if NRASOPS4 > 0
- case 4:
- for (i = 0; i < 16; i++) {
- c = i | (i << 4);
- ri->ri_devcmap[i] = c | (c<<8) | (c<<16) | (c<<24);
- }
- return;
-#endif
#if NRASOPS8 > 0
case 8:
for (i = 0; i < 16; i++)
Index: sys/dev/rasops/rasops.h
===
RCS file: /cvs/src/sys/dev/rasops/rasops.h,v
retrieving revision 1.22
diff -u -p -r1.22 rasops.h
--- sys/dev/rasops/rasops.h 27 Apr 2018 21:36:12 - 1.22
+++ sys/dev/rasops/rasops.h 22 Jul 2018 10:29:37 -
@@ -159,7 +159,6 @@ struct rasops_info {
* the rasops code.
*/
void rasops1_init(struct rasops_info *);
-void rasops4_init(struct rasops_info *);
void rasops8_init(struct rasops_info *);
void rasops15_init(struct rasops_info *);
void rasops24_init(struct rasops_info *);
Index: sys/dev/rasops/rasops4.c
===
RCS file: sys/dev/rasops/rasops4.c
diff -N sys/dev/rasops/rasops4.c
--- sys/dev/rasops/rasops4.c19 Dec 2014 22:44:59 - 1.11
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,479 +0,0 @@
-/* $OpenBSD: rasops4.c,v 1.11 2014/12/19 22:44:59 guenther Exp $ */
-/* $NetBSD: rasops4.c,v 1.4 2001/11/15 09:48:15 lukem Exp $*/
-
-/*-
- * Copyright (c) 1999 The NetBSD Foundation, Inc.
- * All rights reserved.
- *
- * This code is derived from software contributed to The NetBSD Foundation
- * by Andrew Doran.
- *
- * 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 B
Document xcrypt in the amd64 version of cpu.4
Hi tech@, Here is a diff to document xcrypt in the amd64 version of cpu.4. Bits taken from the i386 version. Comments? OK? Index: share/man/man4/man4.amd64/cpu.4 === RCS file: /cvs/src/share/man/man4/man4.amd64/cpu.4,v retrieving revision 1.7 diff -u -p -r1.7 cpu.4 --- share/man/man4/man4.amd64/cpu.4 12 Jan 2018 04:36:44 - 1.7 +++ share/man/man4/man4.amd64/cpu.4 5 Jun 2018 06:06:54 - @@ -52,6 +52,15 @@ offering frequency scaling with numerous Found on various AMD processors. It currently only supports a limited set of models in the K8 families. .El +.Sh INSTRUCTION SET EXTENSIONS +The presence of extended instruction sets can be determined by the +sysctl machdep. +.Bl -tag -width "tenletters" +.It xcrypt +Supports the VIA AES encryption instruction set. +If this is supported, +the libcrypto EVP AES functions automatically use this support. +.El .Sh THERMAL MONITORING The .Xr sysctl 2
Remove i386 specific mention for pcvtfonts in hier.7
Hi tech@,
Remove the i386 specific mention for pcvtfonts, they are also installed
on alpha and amd64.
>From share/misc/Makefile:
.if (${MACHINE} == "i386") || (${MACHINE} == "amd64") || \
(${MACHINE} == "alpha")
SUBDIR= pcvtfonts
.endif
Comments? OK?
Index: share/man/man7/hier.7
===
RCS file: /cvs/src/share/man/man7/hier.7,v
retrieving revision 1.159
diff -u -p -r1.159 hier.7
--- share/man/man7/hier.7 8 Nov 2017 11:24:24 - 1.159
+++ share/man/man7/hier.7 11 Jul 2018 08:24:33 -
@@ -407,7 +407,7 @@ Miscellaneous system-wide ASCII text fil
Terminal characteristics database (see
.Xr termcap 5 ) .
.It pcvtfonts/
-Additional i386 console fonts.
+Additional console fonts.
.El
.Pp
.It mk/
Add support for the VIA VX900 chipset in viapm(4)
Hi tech@,
Here is a diff to add support for the VIA VX900 chipset in viapm(4).
Comments? OK?
Index: share/man/man4/viapm.4
===
RCS file: /cvs/src/share/man/man4/viapm.4,v
retrieving revision 1.11
diff -u -p -r1.11 viapm.4
--- share/man/man4/viapm.4 16 Jul 2013 16:05:49 - 1.11
+++ share/man/man4/viapm.4 3 Jul 2018 22:11:37 -
@@ -28,8 +28,8 @@ The
.Nm
driver provides support for the bus control and power management
component of the VIA VT82C596, VT82C596B, VT82C686A, VT8231, VT8233,
-VT8233A, VT8235, VT8237, VT8237A, VT8237S, VT8251, CX700, VX800 and
-VX855 South Bridges.
+VT8233A, VT8235, VT8237, VT8237A, VT8237S, VT8251, CX700, VX800,
+VX855 and VX900 South Bridges.
Only the SMBus host interface is supported and can be used with the
.Xr iic 4
framework.
Index: sys/dev/pci/viapm.c
===
RCS file: /cvs/src/sys/dev/pci/viapm.c,v
retrieving revision 1.16
diff -u -p -r1.16 viapm.c
--- sys/dev/pci/viapm.c 5 Oct 2012 10:51:28 - 1.16
+++ sys/dev/pci/viapm.c 3 Jul 2018 22:11:37 -
@@ -53,7 +53,7 @@
/*
* Driver for the SMBus controller and power management timer
* in the VIA VT82C596[B], VT82C686A, VT8231, VT8233[A], VT8235, VT8237[A,S],
- * VT8251, CX700, VX800 and VX855 South Bridges.
+ * VT8251, CX700, VX800, VX855 and VX900 South Bridges.
* Also for the hardware monitoring part of the VIA VT82C686A and VT8231.
*/
@@ -246,7 +246,8 @@ const struct pci_matchid viapm_ids[] = {
{ PCI_VENDOR_VIATECH, PCI_PRODUCT_VIATECH_VT8251_ISA },
{ PCI_VENDOR_VIATECH, PCI_PRODUCT_VIATECH_CX700_ISA },
{ PCI_VENDOR_VIATECH, PCI_PRODUCT_VIATECH_VX800_ISA },
- { PCI_VENDOR_VIATECH, PCI_PRODUCT_VIATECH_VX855_ISA }
+ { PCI_VENDOR_VIATECH, PCI_PRODUCT_VIATECH_VX855_ISA },
+ { PCI_VENDOR_VIATECH, PCI_PRODUCT_VIATECH_VX900_ISA }
};
/*
pcidevs updates for the VIA VX900 chipset
Hi tech@, Add device IDs of the VIA VX900 chipset. Attaching a dmesg from my HP t510 Thin Client. Comments? OK? Index: sys/dev/pci/pcidevs === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.1851 diff -u -p -r1.1851 pcidevs --- sys/dev/pci/pcidevs 16 Jun 2018 21:29:39 - 1.1851 +++ sys/dev/pci/pcidevs 1 Jul 2018 13:53:17 - @@ -7427,6 +7427,7 @@ product VIATECH VT3351_HB 0x0351 VT3351 product VIATECH VX800_00x0353 VX800 Host product VIATECH P4M900 0x0364 P4M900 Host product VIATECH VT8371_HB 0x0391 VT8371 Host +product VIATECH VX900_HB 0x0410 VX900 Host product VIATECH VT6415 0x0415 VT6415 IDE product VIATECH VT8501 0x0501 VT8501 product VIATECH VT82C505 0x0505 VT82C505 @@ -7464,6 +7465,7 @@ product VIATECH K8M890_1 0x1336 K8M890 H product VIATECH VT3351_2 0x1351 VT3351 Host product VIATECH VX800_10x1353 VX800 Host product VIATECH P4M900_1 0x1364 P4M900 Host +product VIATECH VX900_ERR 0x1410 VX900 Error Reporting product VIATECH VT82C416 0x1571 VT82C416 IDE product VIATECH VT82C1595 0x1595 VT82C1595 PCI product VIATECH K8M800_2 0x2204 K8M800 Host @@ -7480,6 +7482,7 @@ product VIATECH K8M890_2 0x2336 K8M890 H product VIATECH VT3351_3 0x2351 VT3351 Host product VIATECH VX800_20x2353 VX800 Host product VIATECH P4M900_2 0x2364 P4M900 Host +product VIATECH VX900_00x2410 VX900 Host product VIATECH VT8251_PCI 0x287a VT8251 PCI product VIATECH VT8251_PCIE_0 0x287b VT8251 PCIE product VIATECH VT8251_PCIE_1 0x287c VT8251 PCIE @@ -7553,6 +7556,7 @@ product VIATECH CHROME9_HC0x3371 Chrome product VIATECH VT8237S_ISA0x3372 VT8237S ISA product VIATECH VT8237A_PPB_1 0x337a VT8237A product VIATECH VT8237A_PPB_2 0x337b VT8237A +product VIATECH VX900_DRAM 0x3410 VX900 DRAM product VIATECH VL80x_XHCI 0x3432 VL80x xHCI productVIATECH VL805_XHCI 0x3483 VL805 xHCI product VIATECH K8M800_4 0x4204 K8M800 Host @@ -7569,6 +7573,7 @@ product VIATECH K8M890_4 0x4336 K8M890 H product VIATECH VT3351_5 0x4351 VT3351 Host product VIATECH VX800_40x4353 VX800 Host product VIATECH P4M900_4 0x4364 P4M900 Host +product VIATECH VX900_10x4410 VX900 Host product VIATECH K8T890_IOAPIC 0x5238 K8T890 IOAPIC product VIATECH PT894_IOAPIC 0x5308 PT894 IOAPIC product VIATECH CX700_IDE 0x5324 CX700 IDE @@ -7579,6 +7584,7 @@ product VIATECH VT3351_IOAPIC 0x5351 VT3 product VIATECH VX800_IOAPIC 0x5353 VX800 IOAPIC product VIATECH P4M900_IOAPIC 0x5364 P4M900 IOAPIC product VIATECH VT8237S_SATA 0x5372 VT8237S SATA +product VIATECH VX900_APIC 0x5410 VX900 APIC product VIATECH RHINEII0x6100 RhineII product VIATECH VT3351_6 0x6238 VT3351 Host product VIATECH VT8251_AHCI0x6287 VT8251 AHCI @@ -7586,6 +7592,8 @@ product VIATECH K8M890_6 0x6290 K8M890 H product VIATECH P4M890_6 0x6327 P4M890 Security product VIATECH VX800_60x6353 VX800 Host product VIATECH P4M900_6 0x6364 P4M900 Security +product VIATECH VX900_SCRATCH 0x6410 VX900 Scratch +product VIATECH CHROME9_HD 0x7122 Chrome9 HD product VIATECH K8M800_7 0x7204 K8M800 Host product VIATECH VT8378_VGA 0x7205 VT8378 VGA product VIATECH PT894_50x7308 PT894 Host @@ -7601,6 +7609,7 @@ product VIATECH K8HTB_7 0x7282 K8HTB Ho product VIATECH CN700_70x7314 CN700 Host product VIATECH CX700_70x7324 CX700 Host product VIATECH VT3351_7 0x7351 VT3351 Host +product VIATECH VX900_20x7410 VX900 Host product VIATECH VT8231_ISA 0x8231 VT8231 ISA product VIATECH VT8231_PWR 0x8235 VT8231 PMG product VIATECH VT8363_AGP 0x8305 VT8363 AGP @@ -7608,6 +7617,7 @@ product VIATECH CX700_ISA 0x8324 CX700 I product VIATECH VX800_ISA 0x8353 VX800 ISA product VIATECH VT8371_PPB 0x8391 VT8371 product VIATECH VX855_ISA 0x8409 VX855 ISA +product VIATECH VX900_ISA 0x8410 VX900 ISA product VIATECH VT8501_AGP 0x8501 VT8501 AGP product VIATECH VT82C597AGP0x8597 VT82C597 AGP product VIATECH VT82C598AGP0x8598 VT82C598 AGP @@ -7617,6 +7627,7 @@ product VIATECH VX900_IDE 0x9001 VX900 I product VIATECH VX800_SDMMC0x9530 VX800 SD/MMC product VIATECH VX800_SDIO 0x95d0 VX800 SDIO product VIATECH K8T890_PPB_A 0xa238 K8T890 +product VIATECH VX900_PCIE_0 0xa410 VX900 PCIE product VIATECH P4M890_PPB_1 0xa327 P4M890 product VIATECH VX800_A0xa353 VX800 Host product VIATECH P4M900_PPB_1 0xa364 P4M900 @@ -7629,15 +7640,19 @@ product VIATECH VT8235_AGP 0xb168 VT8235 product VIATECH K8HTB_AGP 0xb188 K8HTB AGP product VIATECH VT8377_AGP
Re: cpu.4: VIA C7 CPUs support Enhanced SpeedStep (i386)
On Tue, Jun 05, 2018 at 10:04:52PM +1000, Jonathan Gray wrote:
> > VIA C7 CPUs support Enhanced SpeedStep, so reflect that in cpu.4.
> >
> > On the VIA C7 1.5Ghz:
> >
> > cpu0: VIA Esther processor 1500MHz ("CentaurHauls" 686-class) 1.51 GHz
> > cpu0:
> > FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,APIC,SEP,MTRR,PGE,CMOV,PAT,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE,NXE,SSE3,EST,TM2
> > cpu0: Enhanced SpeedStep 1501 MHz: speeds: 1500, 800 MHz
>
> If you just have the faked high/low table does it really support it
> besides setting the cpuid bit? No PSS in ACPI? There is a table
> for a 1.5GHz C7 in i386
>
> /* 1.50GHz Centaur C7-M 400 MHz FSB */
> static struct est_op C7M_754[] = {
> ID16(1500, 1004, BUS100),
> ID16(1400, 988, BUS100),
> ID16(1000, 940, BUS100),
> ID16( 800, 844, BUS100),
> ID16( 600, 844, BUS100),
> ID16( 400, 844, BUS100),
> };
Sorry for the delay, I wanted to try booting an old VIA C7 motherboard
I have (the dmesg bits from previous mail came from our dmesg archive)
before answering.
I finally was able to find it and do so, and indeed it seems there are
some issues as well:
cpu0: VIA C7 Processor 1000MHz ("CentaurHauls" 686-class) 1 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,CMOV,PAT,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE,NXE,SSE3,EST,TM2,xTPR
cpu0: unknown Enhanced SpeedStep CPU, msr 0x08100a1308000a13
cpu0: using only highest and lowest power states
cpu0: Enhanced SpeedStep 998 MHz: speeds: 1333, 1067 MHz
I'm not sure it makes sense to spend any time on this, let's forget it.
cpu.4: VIA C7 CPUs support Enhanced SpeedStep (i386)
Hi tech@,
VIA C7 CPUs support Enhanced SpeedStep, so reflect that in cpu.4.
On the VIA C7 1.5Ghz:
cpu0: VIA Esther processor 1500MHz ("CentaurHauls" 686-class) 1.51 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,APIC,SEP,MTRR,PGE,CMOV,PAT,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE,NXE,SSE3,EST,TM2
cpu0: Enhanced SpeedStep 1501 MHz: speeds: 1500, 800 MHz
Comments? OK?
Index: share/man/man4/man4.i386/cpu.4
===
RCS file: /cvs/src/share/man/man4/man4.i386/cpu.4,v
retrieving revision 1.18
diff -u -p -r1.18 cpu.4
--- share/man/man4/man4.i386/cpu.4 12 Jan 2018 04:36:44 - 1.18
+++ share/man/man4/man4.i386/cpu.4 5 Jun 2018 08:39:38 -
@@ -53,8 +53,8 @@ positions.
The processor dynamically adjusts frequency in response to load; the setperf
value is interpreted as the maximum.
.It EST
-Enhanced SpeedStep found on Intel Pentium M processors,
-offering frequency scaling with numerous positions.
+Enhanced SpeedStep found on Intel Pentium M and newer processors, as well as
+on VIA C7 processors, offering frequency scaling with numerous positions.
.It SpeedStep
Found on some Intel Pentium 3 and newer mobile chips,
it is capable of adjusting frequency between a low and high value.
Re: Remove unused C3 values (VIA)
On Sat, Jun 02, 2018 at 11:30:15AM +, Visa Hankala wrote: > On Sat, Jun 02, 2018 at 01:00:05PM +0200, Frederic Cambus wrote: > > Hi tech@, > > > > Here is a diff to remove unused C3 values. > > > > Comments? OK? > > I would keep the definitions because they can at least serve as a weak > form of documentation about the hardware. For example, > C3_CRYPT_CWLO_ALG_M indicates what bits specify the algorithm, which > in turn helps one to understand the value of C3_CRYPT_CWLO_ALG_AES. Agreed. That makes sense indeed, sorry for the noise.
Remove unused C3 values (VIA)
Hi tech@, Here is a diff to remove unused C3 values. Comments? OK? Index: sys/arch/amd64/include/specialreg.h === RCS file: /cvs/src/sys/arch/amd64/include/specialreg.h,v retrieving revision 1.72 diff -u -p -r1.72 specialreg.h --- sys/arch/amd64/include/specialreg.h 23 May 2018 05:37:01 - 1.72 +++ sys/arch/amd64/include/specialreg.h 2 Jun 2018 09:14:32 - @@ -873,14 +873,9 @@ #define C3_CPUID_DO_PMM0x002000 /* VIA C3 xcrypt-* instruction context control options */ -#defineC3_CRYPT_CWLO_ROUND_M 0x000f -#defineC3_CRYPT_CWLO_ALG_M 0x0070 #defineC3_CRYPT_CWLO_ALG_AES 0x -#defineC3_CRYPT_CWLO_KEYGEN_M 0x0080 -#defineC3_CRYPT_CWLO_KEYGEN_HW 0x #defineC3_CRYPT_CWLO_KEYGEN_SW 0x0080 #defineC3_CRYPT_CWLO_NORMAL0x -#defineC3_CRYPT_CWLO_INTERMEDIATE 0x0100 #defineC3_CRYPT_CWLO_ENCRYPT 0x #defineC3_CRYPT_CWLO_DECRYPT 0x0200 #defineC3_CRYPT_CWLO_KEY1280x000a /* 128bit, 10 rds */ Index: sys/arch/i386/include/specialreg.h === RCS file: /cvs/src/sys/arch/i386/include/specialreg.h,v retrieving revision 1.66 diff -u -p -r1.66 specialreg.h --- sys/arch/i386/include/specialreg.h 28 May 2018 20:52:44 - 1.66 +++ sys/arch/i386/include/specialreg.h 2 Jun 2018 09:14:32 - @@ -724,14 +724,9 @@ #define C3_CPUID_DO_PMM0x002000 /* VIA C3 xcrypt-* instruction context control options */ -#defineC3_CRYPT_CWLO_ROUND_M 0x000f -#defineC3_CRYPT_CWLO_ALG_M 0x0070 #defineC3_CRYPT_CWLO_ALG_AES 0x -#defineC3_CRYPT_CWLO_KEYGEN_M 0x0080 -#defineC3_CRYPT_CWLO_KEYGEN_HW 0x #defineC3_CRYPT_CWLO_KEYGEN_SW 0x0080 #defineC3_CRYPT_CWLO_NORMAL0x -#defineC3_CRYPT_CWLO_INTERMEDIATE 0x0100 #defineC3_CRYPT_CWLO_ENCRYPT 0x #defineC3_CRYPT_CWLO_DECRYPT 0x0200 #defineC3_CRYPT_CWLO_KEY1280x000a /* 128bit, 10 rds */
Enable bwfm(4) on Loongson for USB devices
Hi tech@, Here is a diff to enable bwfm(4) on Loongson for USB devices. Tested on a Lemote Yeeloong 8101B. Comments? OK? Index: sys/arch/loongson/conf/GENERIC === RCS file: /cvs/src/sys/arch/loongson/conf/GENERIC,v retrieving revision 1.57 diff -u -p -r1.57 GENERIC --- sys/arch/loongson/conf/GENERIC 24 Apr 2018 03:17:36 - 1.57 +++ sys/arch/loongson/conf/GENERIC 30 May 2018 15:45:25 - @@ -164,6 +164,7 @@ atu*at uhub?# Atmel AT76c50x based 80 aue* at uhub?# ADMtek AN986 Pegasus Ethernet axe* at uhub?# ASIX Electronics AX88172 USB Ethernet axen* at uhub?# ASIX Electronics AX88179 USB Ethernet +bwfm* at uhub?# Broadcom FullMAC cdce* at uhub?# CDC Ethernet urndis*at uhub?# Remote NDIS Ethernet cue* at uhub?# CATC USB-EL1201A based Ethernet
Add sizes for free() for octeon
Hi tech@,
Add sizes for free() for octeon.
Comments? OK?
Index: sys/arch/octeon/dev/amdcf.c
===
RCS file: /cvs/src/sys/arch/octeon/dev/amdcf.c,v
retrieving revision 1.5
diff -u -p -r1.5 amdcf.c
--- sys/arch/octeon/dev/amdcf.c 30 Dec 2017 23:08:29 - 1.5
+++ sys/arch/octeon/dev/amdcf.c 30 Apr 2018 21:40:24 -
@@ -495,7 +495,7 @@ amdcfioctl(dev_t dev, u_long xfer, caddr
lp = malloc(sizeof(*lp), M_TEMP, M_WAITOK);
amdcfgetdisklabel(dev, sc, lp, 0);
bcopy(lp, sc->sc_dk.dk_label, sizeof(*lp));
- free(lp, M_TEMP, 0);
+ free(lp, M_TEMP, sizeof(*lp));
goto exit;
case DIOCGPDINFO:
Index: sys/arch/octeon/dev/octcf.c
===
RCS file: /cvs/src/sys/arch/octeon/dev/octcf.c,v
retrieving revision 1.31
diff -u -p -r1.31 octcf.c
--- sys/arch/octeon/dev/octcf.c 30 Dec 2017 23:08:29 - 1.31
+++ sys/arch/octeon/dev/octcf.c 30 Apr 2018 21:40:24 -
@@ -563,7 +563,7 @@ octcfioctl(dev_t dev, u_long xfer, caddr
lp = malloc(sizeof(*lp), M_TEMP, M_WAITOK);
octcfgetdisklabel(dev, wd, lp, 0);
bcopy(lp, wd->sc_dk.dk_label, sizeof(*lp));
- free(lp, M_TEMP, 0);
+ free(lp, M_TEMP, sizeof(*lp));
goto exit;
case DIOCGPDINFO:
@@ -788,7 +788,7 @@ octcf_get_params(struct octcf_softc *wd,
if (error != 0) {
printf("%s: identify failed: %d\n", __func__, error);
- free(tb, M_DEVBUF, 0);
+ free(tb, M_DEVBUF, ATAPARAMS_SIZE);
return CMD_ERR;
} else {
/*
@@ -818,7 +818,7 @@ octcf_get_params(struct octcf_softc *wd,
params->atap_model[1] == 'E') ||
(params->atap_model[0] == 'F' &&
params->atap_model[1] == 'X'))) {
- free(tb, M_DEVBUF, 0);
+ free(tb, M_DEVBUF, ATAPARAMS_SIZE);
return CMD_OK;
}
for (i = 0; i < sizeof(params->atap_model); i += 2) {
@@ -834,7 +834,7 @@ octcf_get_params(struct octcf_softc *wd,
*p = swap16(*p);
}
- free(tb, M_DEVBUF, 0);
+ free(tb, M_DEVBUF, ATAPARAMS_SIZE);
return CMD_OK;
}
}
