Re: /dev/full

[Daniel Dickman]

I don’t see the point of implementing /dev/full. The python regress test is the 
only time I’ve personally run into this. And I think the issue was that 
python’s test suite made wrong assumptions about what devices exist on a 
particular system. Therefore the fix needed to be on the python side.

I considered the idea of /dev/full in base. But didn’t really see the point.

If you are going to do fault injection testing (a very worthy goal) then I 
think you’d want to go a different route than a device node for every scenario.

Out of interest, what is the use case you had in mind for such a device?


> On Mar 2, 2023, at 9:47 AM, Crystal Kolipe  wrote:
> We currently don't implement the /dev/full device, which is present in
> NetBSD, FreeBSD, and Linux.
> 
> For those who haven't heard of it, it's basically the same as /dev/zero, but
> writes to it always return ENOSPC.
> 
> The lack of /dev/full on OpenBSD has previously caused minor issues with
> third party software, for example:
> 
> https://bugs.python.org/issue21934
> 
> Adding support for /dev/full is trivial.  I've attached a patch for amd64,
> if there is interest I can easily produce a set of patches for other archs.
> 
> To create the device file, you'll need to do:
> 
> # mknod -m 666 /dev/full c 2 5
> 
> For those who are interested, I've written a more in-depth discussion about
> memory special devices, including a proposal for another such new device,
> /dev/fill:
> 
> https://research.exoticsilicon.com/articles/memory_special_devices
> 
> --- arch/amd64/amd64/mem.c.distWed Mar 24 11:26:39 2021
> +++ arch/amd64/amd64/mem.cThu Mar  2 11:10:30 2023
> @@ -88,6 +88,7 @@
>break;
>return (EPERM);
>case 2:
> +case 5:
>case 12:
>break;
> #ifdef APERTURE
> @@ -165,9 +166,13 @@
>uio->uio_resid = 0;
>return (0);
> 
> +/* minor device 5 is /dev/full */
>/* minor device 12 is /dev/zero */
> +case 5:
>case 12:
>if (uio->uio_rw == UIO_WRITE) {
> +if (minor(dev)==5)
> +return (ENOSPC);
>c = iov->iov_len;
>break;
>}

Re: [updated] console enhancement patchset

[Daniel Dickman]

On Sun, 15 Jan 2023, Crystal Kolipe wrote:

> Hi Daniel,
> 
> On Sun, Jan 15, 2023 at 05:54:39PM -0500, Daniel Dickman wrote:
> > Hi Crystal,
> > 
> > I tried your patch but it seems to tickle something on my lenovo laptop.
> > 
> > I see this message:
> > entry point at 0x1001000
> > 
> > and then nothing further seems to show up.
> 
> Thanks for testing.
> 
> * Is this the first version of the patchset that you've tested?

Yep, did not get a chance anything before this one.

> * If not, have previous versions worked on this hardware?
> 
> As of three days ago, -current now includes some of the earlier work I did on
> this, but I'm assuming that an unpatched -current kernel is running fine for
> you?
> 

That's right, unpatched -current with your earlier bits works fine.

The kernel that doesn't work for me is the very latest -current with 
only this diff.

Re: [updated] console enhancement patchset

[Daniel Dickman]

Hi Crystal,

I tried your patch but it seems to tickle something on my lenovo laptop.

I see this message:
entry point at 0x1001000

and then nothing further seems to show up.

In case helpful, dmesg from this laptop is shown below.



OpenBSD 7.2-current (GENERIC.MP) #0: Sun Jan 15 17:08:05 EST 2023
root@XXX:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16452091904 (15689MB)
avail mem = 15934099456 (15195MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.3 @ 0xca50a000 (35 entries)
bios0: vendor LENOVO version "H6CN16WW(V1.09)" date 10/12/2022
bios0: LENOVO 82ND
efi0 at bios0: UEFI 2.7
efi0: INSYDE Corp. rev 0x60324016
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP UEFI SSDT SSDT IVRS SSDT SSDT TPM2 MSDM ASF! BOOT HPET 
APIC MCFG SLIC SSDT VFCT SSDT SSDT SSDT SSDT SSDT CRAT CDIT SSDT SSDT SSDT SSDT 
SSDT SSDT FPDT WSMT SSDT SSDT SSDT SSDT SSDT SSDT BGRT
acpi0: wakeup devices GPP0(S4) GPP1(S4) GP17(S0)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Ryzen 7 5700U with Radeon Graphics, 1800.00 MHz, 17-68-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,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 
8-way L2 cache, 4MB 64b/line 16-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu0: mwait min=64, max=64, C-substates=1.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Ryzen 7 5700U with Radeon Graphics, 1800.00 MHz, 17-68-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,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 
8-way L2 cache, 4MB 64b/line 16-way L3 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD Ryzen 7 5700U with Radeon Graphics, 1800.00 MHz, 17-68-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,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 
8-way L2 cache, 4MB 64b/line 16-way L3 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: AMD Ryzen 7 5700U with Radeon Graphics, 1800.00 MHz, 17-68-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,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 
8-way L2 cache, 4MB 64b/line 16-way L3 cache
cpu3: smt 1, core 1, package 0
cpu4 at mainbus0: apid 4 (application processor)
cpu4: AMD Ryzen 7 5700U with Radeon Graphics, 1800.00 MHz, 17-68-01
cpu4: 
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,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu4: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 
8-way L2 cache, 4MB 64b/line 16-way L3 cache
cpu4: smt 

add 2 transmeta devices to pcidevs

[Daniel Dickman]

I have a laptop with these Transmeta devices:

pchb0 at pci0 dev 0 function 0 vendor "Transmeta", unknown product 0x0060 rev 
0x00
ppb0 at pci0 dev 1 function 0 vendor "Transmeta", unknown product 0x0061 rev 
0x00

NetBSD describes device 0061 as the integrated North Bridge, but I think 
this is incorrect as this is actually an AGP bridge:

product TRANSMETA TM8000NB  0x0061  TM8000 Integrated North Bridge

The PCI repository has these entries, which I feel is more correct than 
NetBSD:

0060TM8000 Northbridge  
0061TM8000 AGP bridge

However, reading the "Efficeon BIOS Programmers Guide", I chose to 
describe device as 0060 as HyperTransport instead.

The Efficeon processor has a virtual north bridge that can communicate 
with the south bridge over HyperTransport and can communicate with the 
graphics controller over an AGP bridge. For reference, see Chapter 2, 
Figure 1 showing the system block diagram.

Some contemporaneous news coverage on HyperTransport is available here for 
reference: 
https://www.eetimes.com/transmeta-links-next-generation-processor-to-hypertransport/

ok?

Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.2014
diff -u -p -u -r1.2014 pcidevs
--- pcidevs 4 Dec 2022 03:13:52 -   1.2014
+++ pcidevs 11 Dec 2022 18:51:04 -
@@ -9030,6 +9030,8 @@ product TOSHIBA2 TFIRO0x0701  Infrared
 product TOSHIBA2 SDCARD0x0805  SD
 
 /* Transmeta products */
+product TRANSMETA TM8000_HT0x0060  TM8000 HyperTransport
+product TRANSMETA TM8000_AGP   0x0061  TM8000 AGP
 product TRANSMETA NB   0x0295  Northbridge
 product TRANSMETA LONGRUN_NB   0x0395  LongRun Northbridge
 product TRANSMETA SDRAM0x0396  SDRAM

Re: wc(1): add -L flag to write length of longest line

[Daniel Dickman]

> On Sep 29, 2022, at 8:24 PM, Joerg Sonnenberger  wrote:
> 
> On Thu, Sep 29, 2022 at 08:39:16PM +1000, Jonathan Gray wrote:
>> wc counts items in files.  Finding the longest item indeed sounds
>> like a task better suited to awk.

Doesn’t gnu wc show that tabs have length 8 rather than length 1?

Do the other wc implementations differ?

> 
> Finding outliers, means and counting are all parts of the same basic
> class of operations. A good implementation of all of them requires
> constant space and a fixed time per input character. An implementation
> in awk will generally not have that property.

Did you run any benchmarks to check this? I’m not doubting you but just 
wondering if there’s a speed difference that matters in practice.




> 
> Joerg
> 

Re: When did PCs stop using ISA Timer 1?

[Daniel Dickman]

On Sat, Aug 27, 2022 at 7:15 AM Jonathan Gray  wrote:
>
> On Fri, Aug 26, 2022 at 10:21:32PM -0500, Scott Cheloha wrote:
> > I noticed that on non-LAPIC systems we program channel 0 in periodic
> > mode with an initial count of 11932 to effect a 100hz clock interrupt.
> > And then we also use that same channel to count time, but because we
> > aren't using the full 16-bit range we need to do all this checking and
> > incrementing to handle premature overflow to make it appear as though
> > the full counter is being used.
> >
> > And I had this whimsical idea: gee, wouldn't it be so much easier to
> > use channel 0 for clock interrupts and a different channel for
> > counting time?
> >
> > But then I started reading and saw that channel 1 had a dedicated
> > purpose in the bad old days.
> >
> > So I was left wondering when channel 1 stopped performing that task,
> > and whether those systems (a) predate the APIC and (b) can even run
> > OpenBSD at all.
>
> Attempting to use counter 1 would be more trouble than it is worth.

Hi Scott, we discussed this off-list, but just to share here.

There is a good writeup of how it all used to work here:
https://retrocomputing.stackexchange.com/questions/1212/where-are-the-memory-controllers-for-ibm-5150-or-altair-8800

Quoting that site:

"RAM refresh was done by a cyclic inserted DMA request using DMA
channel 4 of the 8237 DMA controller, triggered by Timer 1 of the 8253
Programmable Interval Timer."

That being said, later on channel 1 was used by video bios and some
bioses, so really it can't be used by OS safely for anything.

See:
https://www.brokenthorn.com/Resources/OSDevPit.html

"Many video cards and the BIOS may reprogram the second channel for
their own uses. This channel was originally used for generating a
timing pulse signal to signal the memory controller to refresh the
DRAM memory. In modern times, this is no longer needed as the refresh
is done by the memory controller. Because of this, there is no
guarantee at what devices may use this counter."

My guess is that any system with 32mb of RAM or more would be unlikely
to to be a place where we have to worry about channel 1 being used for
DRAM refresh.

>
> >
> > > The PCH datasheets from 100 series and later only document counter 0
> > > and counter 2.
> > >

Right, these days some chipsets don't even provide channel 1 anymore.

So either the system has channel 1 and it should be considered
reserved, or the system may not have channel 1 in which case it's not
available for use by the OS.

In either case, the OS should not use this channel.

p.s. we should probably update the comment in usr.sbin/vmd/i8253.c
which currently states:

40: * Channels 1 and 2 can be used by the guest OS as regular timers,

Re: remove cpu var from i386

[Daniel Dickman]

On Sun, 21 Aug 2022, Jonathan Gray wrote:

> On Sun, Aug 21, 2022 at 02:16:10AM -0400, Daniel Dickman wrote:
> > On Sun, 21 Aug 2022, Jonathan Gray wrote:
> > 
> > > removed from amd64 in locore.S 1.71 in 2015
> > > the cpuid_level == -1 path can go in a later step
> > 
> > Can we also remove
> >   375:extern const struct cpu_nocpuid_nameclass i386_nocpuid_cpus[];
> > 
> > from
> >   include/cpu.h
> > 
> > ?
> 
> yes, that and struct cpu_nocpuid_nameclass can go
> 

looks good to me. ok daniel@

Re: remove cpu var from i386

[Daniel Dickman]

On Sun, 21 Aug 2022, Jonathan Gray wrote:

> removed from amd64 in locore.S 1.71 in 2015
> the cpuid_level == -1 path can go in a later step

Can we also remove
  375:extern const struct cpu_nocpuid_nameclass i386_nocpuid_cpus[];

from
  include/cpu.h

?

comment fixes for i386/locore.s

[Daniel Dickman]

locore.s rev 1.113 from 2007 removed support for 80386 processors from 
copyin and copyout. However, the note about 386 CPUs in the comment for 
copyout was missed. Patch below updates the comment to match the code.

While here s/destination/source/ for the description of copyin. Taken from 
NetBSD sys/arch/i386/i386/copy.S rev 1.23.

ok?

Index: locore.s
===
RCS file: /cvs/src/sys/arch/i386/i386/locore.s,v
retrieving revision 1.195
diff -u -p -u -r1.195 locore.s
--- locore.s15 Aug 2022 04:17:50 -  1.195
+++ locore.s21 Aug 2022 05:55:46 -
@@ -472,9 +472,7 @@ ENTRY(copyout)
/*
 * We check that the end of the destination buffer is not past the end
 * of the user's address space.  If it's not, then we only need to
-* check that each page is writable.  The 486 will do this for us; the
-* 386 will not.  (We assume that pages in user space that are not
-* writable by the user are not writable by the kernel either.)
+* check that each page is readable, and the CPU will do that for us.
 */
movl%edi,%edx
addl%eax,%edx
@@ -527,7 +525,7 @@ ENTRY(copyin)
movl24+FPADD(%esp),%eax
 
/*
-* We check that the end of the destination buffer is not past the end
+* We check that the end of the source buffer is not past the end
 * of the user's address space.  If it's not, then we only need to
 * check that each page is readable, and the CPU will do that for us.
 */

Re: Consistency and cleanup in /share/misc/airport

[Daniel Dickman]

I've committed the updates for the German airports but left the
metropolitan area airports alone.

Thanks!

Re: improve transmeta pci device names

[Daniel Dickman]

On Sat, Aug 20, 2022 at 9:50 PM Jonathan Gray  wrote:
> why not just
>
> product TRANSMETA SDRAM 0x0396  SDRAM
> product TRANSMETA BIOS  0x0397  BIOS


That works too.

improve transmeta pci device names

[Daniel Dickman]

We have some generic PCI devices names:

product TRANSMETA MEM1 0x0396  Mem1
product TRANSMETA MEM2 0x0397  Mem2

Likely because these devices both appear as class=5 and subclass=0 (which 
indicates a RAM device):

# pcidump -v
...
 0:0:1: Transmeta Mem1
0x: Vendor ID: 1279, Product ID: 0396
0x0004: Command: , Status: 
0x0008: Class: 05 Memory, Subclass: 00 RAM,


NetBSD has:

product TRANSMETA SDRAM 0x0396  SDRAM Controller
product TRANSMETA BIOS_SCRATCH  0x0397  BIOS Scratchpad

The Transmeta BIOS Programmer's Guide appears to confirm that the NetBSD 
device names are correct. A copy of this guide is here:

http://datasheets.chipdb.org/Transmeta/Crusoe/TM5800/TM5800_BIOSGuide_6-14-02.pdf

Patch below updates the PCI device names for these 2 devices.

ok?


Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.2001
diff -u -p -u -r1.2001 pcidevs
--- pcidevs 16 Aug 2022 09:28:45 -  1.2001
+++ pcidevs 21 Aug 2022 00:52:28 -
@@ -8886,8 +8886,8 @@ product TOSHIBA2 SDCARD   0x0805  SD
 /* Transmeta products */
 product TRANSMETA NB   0x0295  Northbridge
 product TRANSMETA LONGRUN_NB   0x0395  LongRun Northbridge
-product TRANSMETA MEM1 0x0396  Mem1
-product TRANSMETA MEM2 0x0397  Mem2
+product TRANSMETA SDRAM0x0396  SDRAM Controller
+product TRANSMETA BIOS_SP  0x0397  BIOS Scratchpad
 
 /* Trident products */
 product TRIDENT 4DWAVE_DX  0x2000  4DWAVE DX
Index: pcidevs.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v
retrieving revision 1.1995
diff -u -p -u -r1.1995 pcidevs.h
--- pcidevs.h   16 Aug 2022 09:29:21 -  1.1995
+++ pcidevs.h   21 Aug 2022 00:52:29 -
@@ -8891,8 +8891,8 @@
 /* Transmeta products */
 #definePCI_PRODUCT_TRANSMETA_NB0x0295  /* Northbridge 
*/
 #definePCI_PRODUCT_TRANSMETA_LONGRUN_NB0x0395  /* 
LongRun Northbridge */
-#definePCI_PRODUCT_TRANSMETA_MEM1  0x0396  /* Mem1 */
-#definePCI_PRODUCT_TRANSMETA_MEM2  0x0397  /* Mem2 */
+#definePCI_PRODUCT_TRANSMETA_SDRAM 0x0396  /* SDRAM 
Controller */
+#definePCI_PRODUCT_TRANSMETA_BIOS_SP   0x0397  /* BIOS 
Scratchpad */
 
 /* Trident products */
 #definePCI_PRODUCT_TRIDENT_4DWAVE_DX   0x2000  /* 4DWAVE DX */
Index: pcidevs_data.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v
retrieving revision 1.1990
diff -u -p -u -r1.1990 pcidevs_data.h
--- pcidevs_data.h  16 Aug 2022 09:29:21 -  1.1990
+++ pcidevs_data.h  21 Aug 2022 00:52:30 -
@@ -31756,12 +31756,12 @@ static const struct pci_known_product pc
"LongRun Northbridge",
},
{
-   PCI_VENDOR_TRANSMETA, PCI_PRODUCT_TRANSMETA_MEM1,
-   "Mem1",
+   PCI_VENDOR_TRANSMETA, PCI_PRODUCT_TRANSMETA_SDRAM,
+   "SDRAM Controller",
},
{
-   PCI_VENDOR_TRANSMETA, PCI_PRODUCT_TRANSMETA_MEM2,
-   "Mem2",
+   PCI_VENDOR_TRANSMETA, PCI_PRODUCT_TRANSMETA_BIOS_SP,
+   "BIOS Scratchpad",
},
{
PCI_VENDOR_TRIDENT, PCI_PRODUCT_TRIDENT_4DWAVE_DX,

remove support for Cyrix 486DLC & Cyrix 6x86

[Daniel Dickman]

The below diff removes detection code for the Cyrix 486DLC and Cyrix 6x86 
CPUs from OpenBSD/i386.

The Cyrix 486DLC is a 486-class CPU which we no longer support.

The 6x86, also known as the M1, does not support CPUID by default. But it 
can be made to support this instruction if bit 7 in CCR4 is enabled. We 
don't do this in the tree today.

The reason to remove support for the 6x86 is because it doesn't support 
the RDTSC instruction which we we use unconditionally. Therefore I don't 
believe Cyrix CPUs older than the 6x86MX (aka the M2) can run 
OpenBSD/i386.

We keep the "cyrix6x86_cpu_setup" function in machdep because those quirks 
would still be needed on the M2.

After this diff, the CPU detection code on i386 would assume that if the 
ID bit is missing from EFLAGS, we're running on an intel 486, while if we 
have the ID bit then we use the CPUID instruction for the detection logic.

We also make the same change to amd64/include/specialreg.h to remove the 
defines for the Cyrix 486DLC. No Cyrix CPU supports amd64, so these 
defines have never made sense there.


Index: i386/i386/locore0.S
===
RCS file: /cvs/src/sys/arch/i386/i386/locore0.S,v
retrieving revision 1.7
diff -u -p -u -r1.7 locore0.S
--- i386/i386/locore0.S 15 Aug 2022 04:17:50 -  1.7
+++ i386/i386/locore0.S 20 Aug 2022 02:07:30 -
@@ -133,56 +133,6 @@ start: movw$0x1234,0x472   # warm 
boot
jnz .Ltry586
 .Lis486:   movl$CPU_486,RELOC(_C_LABEL(cpu))
 
-   /*
-* Check Cyrix CPU
-* Cyrix CPUs do not change the undefined flags following
-* execution of the divide instruction which divides 5 by 2.
-*
-* Note: CPUID is enabled on M2, so it passes another way.
-*/
-   pushfl
-   movl$0x, %eax
-   xorl%edx, %edx
-   movl$2, %ecx
-   clc
-   divl%ecx
-   jnc .Ltrycyrix486
-   popfl
-   jmp 2f
-.Ltrycyrix486:
-   movl$CPU_6x86,RELOC(_C_LABEL(cpu))  # set CPU type
-   /*
-* Check for Cyrix 486 CPU by seeing if the flags change during a
-* divide.  This is documented in the Cx486SLC/e SMM Programmer's
-* Guide.
-*/
-   xorl%edx,%edx
-   cmpl%edx,%edx   # set flags to known state
-   pushfl
-   popl%ecx# store flags in ecx
-   movl$-1,%eax
-   movl$4,%ebx
-   divl%ebx# do a long division
-   pushfl
-   popl%eax
-   xorl%ecx,%eax   # are the flags different?
-   testl   $0x8d5,%eax # only check C|PF|AF|Z|N|V
-   jne 2f  # yes; must not be Cyrix CPU
-   movl$CPU_486DLC,RELOC(_C_LABEL(cpu))# set CPU type
-
-   /* Disable caching of the ISA hole only. */
-   invd
-   movb$CCR0,%al   # Configuration Register index (CCR0)
-   outb%al,$0x22
-   inb $0x23,%al
-   orb $(CCR0_NC1|CCR0_BARB),%al
-   movb%al,%ah
-   movb$CCR0,%al
-   outb%al,$0x22
-   movb%ah,%al
-   outb%al,$0x23
-   invd
-
jmp 2f
 
 .Ltry586:  /* Use the `cpuid' instruction. */
Index: i386/i386/machdep.c
===
RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
retrieving revision 1.653
diff -u -p -u -r1.653 machdep.c
--- i386/i386/machdep.c 18 Aug 2022 13:05:43 -  1.653
+++ i386/i386/machdep.c 20 Aug 2022 02:07:30 -
@@ -498,14 +498,8 @@ char   cpu_model[120];
  * We deal with the rest in a different way.
  */
 const struct cpu_nocpuid_nameclass i386_nocpuid_cpus[] = {
-   { CPUVENDOR_INTEL, "Intel", "486SX",CPUCLASS_486,
-   NULL},  /* CPU_486SX */
{ CPUVENDOR_INTEL, "Intel", "486DX",CPUCLASS_486,
NULL},  /* CPU_486   */
-   { CPUVENDOR_CYRIX, "Cyrix", "486DLC",   CPUCLASS_486,
-   NULL},  /* CPU_486DLC */
-   { CPUVENDOR_CYRIX, "Cyrix", "6x86", CPUCLASS_486,
-   cyrix6x86_cpu_setup},   /* CPU_6x86 */
 };
 
 const char *classnames[] = {
@@ -2075,9 +2069,6 @@ identifycpu(struct cpu_info *ci)
cpu_class = class;
 
ci->cpu_class = class;
-
-   if (cpu == CPU_486DLC)
-   printf("WARNING: CYRIX 486DLC CACHE UNCHANGED.\n");
 
/*
 * Enable ring 0 write protection.
Index: i386/include/cputypes.h
===
RCS file: /cvs/src/sys/arch/i386/include/cputypes.h,v
retrieving revision 1.13
diff -u -p -u -r1.13 cputypes.h
--- i386/include/cputypes.h 15 Aug 2022 04:17:51 -  1.13
+++ i386/include/cputypes.h 20 Aug 2022 02:07:30 -
@@ -37,19 +37,10 @@
 #define

Re: remove pre-486 code from i386 platform

[Daniel Dickman]

> On Jul 29, 2022, at 2:18 AM, Tomasz Rola  wrote:
> 
> On Thu, Jul 28, 2022 at 08:06:28PM -0400, Daniel Dickman wrote:
>>> On Thu, Jul 28, 2022 at 3:37 AM Jeroen Massar  wrote:
>>> 
> [...]
>>> 
>>> I personally would not touch the .h definitions:
>>> 
>>>> 
>>>> Index: i386/include/cputypes.h
>>>> [..]
>>>> 
>>>> -#define  CPUCLASS_3860
>>>> #define   CPUCLASS_4861
> [...]
>>> Though, one could argue for the include users that they should also be 
>>> stripping their code of this use and super special casing...
>> 
>> How much of a real problem is this? These defines are ONLY available
>> on the i386 platform.
>> 
>> Wouldn't you have to be doing something super unportable to begin with
>> if you're using these defines for anything?
> 
> OTOH, if someone would want to do something super unportable, would
> you tell them to use some other operating system

Shrug. People can use whatever systems they like. I certainly do. You can too. 
This isn’t really a technical argument. It’s just an irritating comment.

> I guess it is ok to drop supporting code but...

It’s not a matter of dropping support. The current code already can’t possibly 
work on a 386. Support was dropped long ago.

> 
> I think it would be prudent to keep those few old defines, just mark
> them with relevant comment saying they are no longer being used and
> only kept to prevent someone clever from redefining those values for
> whatever clever purpose they will see in a future.

> I believe it is still possible to buy 386 in a form of so called
> industrial computer.

As I pointed out in my original email, the current code can’t possibly run on a 
real 386.

> Their life is expected to be decades
> long.
> Someone out there might be supporting this old stuff while
> making sure his
> code compiles on newer hardware, too. While not having
> the defines in *.h should be ok, it does not really cost much to keep
> them.

Should we add defines for the 286 too?

> 
> -- 
> Regards,
> Tomasz Rola
> 
> --
> ** A C programmer asked whether computer had Buddha's nature.  **
> ** As the answer, master did "rm -rif" on the programmer's home**
> ** directory. And then the C programmer became enlightened...  **
> ** **
> ** Tomasz Rola  mailto:tomasz_r...@bigfoot.com **
> 

Re: Consistency and cleanup in /share/misc/airport

[Daniel Dickman]

On Mon, Jul 25, 2022 at 5:10 AM Thomas Wager  wrote:
>
> Hi,
>
> some changes to /share/misc/airport to treat german umlauts more
> consistently, remove the "Flugplatz" (german for airport, which is kind
> of redundant as it is all airports in the list), remove NRW which does
> not exist as IATA code, remove THF which is gone since 2010.
>
> -Thomas
>
> Index: share/misc/airport
> ===
> RCS file: /cvs/src/share/misc/airport,v
> retrieving revision 1.83
> diff -u -p -u -p -r1.83 airport
> --- share/misc/airport  26 Jun 2022 06:28:51 -  1.83
> +++ share/misc/airport  24 Jul 2022 23:20:14 -
> @@ -470,7 +470,7 @@ DUD:Momona, Dunedin, New Zealand
>  DUJ:Jefferson County, Du Bois, Pennsylvania, USA
>  DUQ:Quamichan Lake, Duncan / Quam, British Columbia, Canada
>  DUR:King Shaka International, Durban, South Africa
> -DUS:Dusseldorf, Germany
> +DUS:Duesseldorf, Germany

Dusseldorf is extremely common spelling in English (which the
wikipedia page mentions). This was an interesting read though:
https://goduesseldorf.com/post/duesseldorf/

I'm not opposed to changing it though.

>  DUT:Dutch Harbor, Alaska, USA
>  DVO:Mati, Davao, Philippines
>  DXB:Dubai, UAE
> @@ -656,7 +656,7 @@ HAD:Halmstad, Halland, Sweden
>  HAH:Moroni (Hahaya), Comoros
>  HAJ:Langenhagen, Hanover, Germany
>  HAK:Haikou, China
> -HAM:Fuhlsbuettel Hamburg, Germany
> +HAM:Fuhlsbuettel, Hamburg, Germany

Wikipedia states this airport is now called Hamburg Airport?

>  HAN:Noibai, Hanoi, Vietnam
>  HAU:Karmoy, Haugesund, Norway
>  HAV:Jose Marti, Havana, Cuba
> @@ -940,7 +940,7 @@ LAW:Municipal, Lawton, Oklahoma, USA
>  LAX:Los Angeles International, California, USA
>  LBA:Leeds/Bradford, England, United Kingdom
>  LBB:Lubbock, Texas, USA
> -LBC:Lubeck, Germany
> +LBC:Luebeck, Germany

ok

>  LBE:Westmoreland County, Latrobe, Pennsylvania, USA
>  LBF:North Platte Lee Bird Field, Nebraska, USA
>  LBL:Glenn L Martin Terminal, Liberal, Kansas, USA
> @@ -1214,7 +1214,6 @@ NPL:New Plymouth, New Zealand
>  NQY:Newquay Civil, England, United Kingdom
>  NRK:Norrkoping, Sweden
>  NRT:Narita, Tokyo, Japan
> -NRW:All Airports around Nordrhein-Westfalen, Germany

No thanks. These are pretty standard ways to refer to groups of
airports that are close by. We have a bunch of these in the file and
I'd hate to lose these.

BHZ:All Airports around Belo Horizonte, MG, Brazil
BUE:All Airports around Buenos Aires, Argentina
BUH:All Airports around Bucharest, Romania
CHI:All Airports around Chicago, Illinois, USA
DTT:All Airports around Detroit, Michigan, USA
JKT:All Airports around Jakarta, Indonesia
KCK:All Airports around Kansas City, Kansas, USA
LON:All Airports around London, United Kingdom
MFW:All Airports around Miami, Ft. Lauderdale and West Palm Beach, Florida, USA
MIL:All Airports around Milano, Italy
MOW:All Airports around Moscow, Russia
NRW:All Airports around Nordrhein-Westfalen, Germany
NYC:All Airports around New York City, New York, USA
OSA:All Airports around Osaka, Japan
OSL:All Airports around Oslo, Norway
PAR:All Airports around Paris, France
QDV:All Airports around Denver, Colorado, USA
QLA:All Airports around Los Angeles, California, USA
QSF:All Airports around San Francisco, California, USA
RIO:All Airports around Rio de Janeiro, RJ, Brazil
ROM:All Airports around Roma, Italy
SAO:All Airports around Sao Paulo, SP, Brazil
STO:All Airports around Stockholm, Sweden
TYO:All Airports around Tokyo, Japan
WAS:All Airports around Washington, District of Columbia, USA
YEA:All Airports around Edmonton, Alberta, Canada
YMQ:All Airports around Montreal, Quebec, Canada
YTO:All Airports around Toronto, Ontario, Canada


>  NSB:North Seaplane Base, Bimini, Bahamas
>  NSI:Nsimalen, Yaounde, Cameroon
>  NSN:Nelson, New Zealand
> @@ -1672,7 +1671,6 @@ TGM:Tirgu Mures, Romania
>  TGU:Toncontin, Tegucigalpa, Honduras
>  TGZ:Llano San Juan, Tuxtla Gutierrez, Chiapas, Mexico
>  THE:Teresina, Piaui, Brazil
> -THF:Tempelhof, Berlin, Germany

ok

>  THN:Trollhattan, Sweden
>  THR:Mehrabad, Tehran, Iran
>  THU:Thule, Pituffik, Greenland
> @@ -1851,7 +1849,7 @@ XBR:Brockville, Ontario, Canada
>  XCM:Chatham, Ontario, Canada
>  XDM:Drummondville, Quebec, Canada
>  XFD:Stratford, Ontario, Canada
> -XFW:Flugplatz Hamburg-Finkenwerder, Hamburg, Germany
> +XFW:Hamburg-Finkenwerder, Hamburg, Germany

ok

>  XIY:Xianyang, Xi An, China
>  XLV:Niagara Falls, Ontario, Canada
>  XLZ:Truro, Nova Scotia, Canada
>

Re: remove pre-486 code from i386 platform

[Daniel Dickman]

On Thu, Jul 28, 2022 at 3:37 AM Jeroen Massar  wrote:
>
>
>
> > On 28 Jul 2022, at 04:18, Daniel Dickman  wrote:
> >
> > The diff below removes support for 386SX/DX processors. We already claim
> > we don't support anything older than a Pentium so there's no point to keep
> > this code.
> [..]
> > ok?
>
> I personally would not touch the .h definitions:
>
> >
> > Index: i386/include/cputypes.h
> > [..]
> >
> > -#define  CPUCLASS_3860
> > #define   CPUCLASS_4861
> > #define   CPUCLASS_5862
> > #define   CPUCLASS_6863
> > @@ -42,8 +41,6 @@
> >  * that might not have a cpuid instruction.
> >  */
> >
> > -#define  CPU_386SX   0   /* Intel 80386SX */
> > -#define  CPU_386 1   /* Intel 80386DX */
> > #define   CPU_486SX   2   /* Intel 80486SX */
> > #define   CPU_486 3   /* Intel 80486DX */
> > #define   CPU_486DLC  4   /* Cyrix 486DLC */
>
>
> This, so one still knows that these used to be defined for that purpose, and 
> not that they are possibly free to re-use.
>
> But more importantly, as there might be code using those definitions to 
> define including or excluding things.
>
> Though, one could argue for the include users that they should also be 
> stripping their code of this use and super special casing...

How much of a real problem is this? These defines are ONLY available
on the i386 platform.

Wouldn't you have to be doing something super unportable to begin with
if you're using these defines for anything?


>
> One option is maybe to comment those definitions out, so that they still 
> exist and one knows what they where.
>

I can leave them in but I'd be interested to understand if this is a
real problem or hypothetical.

> Greets,
>  Jeroen
>

remove pre-486 code from i386 platform

[Daniel Dickman]

The diff below removes support for 386SX/DX processors. We already claim 
we don't support anything older than a Pentium so there's no point to keep 
this code.

The main code change is in locore0.S and is to stop checking if the CPU 
we're on has the alignment check (PSL_AC) flag.

The rest of the diff is about deleting ancient comments about how things 
worked before the 486. 2 files under arch/amd64 are updated to keep them 
in sync with arch/i386.

The 486 (which was launched in 1989) added a small number of changes over 
a system with an 80386 + 80387 co-processor:
- an alignment check (AC) flag in EFLAGS; this is how we check for 386 vs 
  486 and this is what we're removing
- new bits in CR0; 386 CPUs did not support ring0 write protection
- new bits in CR3
- 3 new userland instructions: bswap / cmpxchg / xadd
- 3 new kernel mode instructions: invd / wbinvd / invlpg

I can't imagine the current code could possibly work on a real 386sx or 
386dx CPU since we seem to unconditionally call 5 out of the 6 
instructions mentioned above unconditionally. (The 6th instruction "invd" 
is used in locore0.S, but it looks like that one does check that we're on 
a 486 or newer CPU first).

fwiw, it appears that Linux 3.8 dropped support for 386 CPUs back in 2012.

ok?

Index: amd64/amd64/lapic.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/lapic.c,v
retrieving revision 1.59
diff -u -p -u -r1.59 lapic.c
--- amd64/amd64/lapic.c 31 Aug 2021 15:53:36 -  1.59
+++ amd64/amd64/lapic.c 28 Jul 2022 01:41:15 -
@@ -213,9 +213,7 @@ lapic_map(paddr_t lapic_base)
va = (vaddr_t)_apic;
} else {
/*
-* Map local apic.  If we have a local apic, it's safe to
-* assume we're on a 486 or better and can use invlpg and
-* non-cacheable PTEs
+* Map local apic.
 *
 * Whap the PTE "by hand" rather than calling pmap_kenter_pa
 * because the latter will attempt to invoke TLB shootdown
Index: amd64/stand/mbr/mbr.S
===
RCS file: /cvs/src/sys/arch/amd64/stand/mbr/mbr.S,v
retrieving revision 1.7
diff -u -p -u -r1.7 mbr.S
--- amd64/stand/mbr/mbr.S   27 Jun 2022 16:10:09 -  1.7
+++ amd64/stand/mbr/mbr.S   28 Jul 2022 01:41:16 -
@@ -112,7 +112,7 @@ start:
 *
 * Accordingly, this code will fail on very early 8086/88s, but
 * nick@ will just have to live with it.  Others will note that
-* we require an 80386 (or compatible) or above processor, anyway.
+* we require at least a Pentium compatible processor anyway.
 */
/* cli */
movw%ax, %ss
Index: i386/i386/cpu.c
===
RCS file: /cvs/src/sys/arch/i386/i386/cpu.c,v
retrieving revision 1.108
diff -u -p -u -r1.108 cpu.c
--- i386/i386/cpu.c 21 Feb 2022 10:24:28 -  1.108
+++ i386/i386/cpu.c 28 Jul 2022 01:41:18 -
@@ -406,8 +406,7 @@ cpu_init(struct cpu_info *ci)
patinit(ci);
  
/*
-* Enable ring 0 write protection (486 or above, but 386
-* no longer supported).
+* Enable ring 0 write protection
 */
lcr0(rcr0() | CR0_WP);
 
Index: i386/i386/lapic.c
===
RCS file: /cvs/src/sys/arch/i386/i386/lapic.c,v
retrieving revision 1.48
diff -u -p -u -r1.48 lapic.c
--- i386/i386/lapic.c   11 Jun 2021 05:33:16 -  1.48
+++ i386/i386/lapic.c   28 Jul 2022 01:41:18 -
@@ -85,8 +85,7 @@ lapic_map(paddr_t lapic_base)
tpr = lapic_tpr;
 
/*
-* Map local apic.  If we have a local apic, it's safe to assume
-* we're on a 486 or better and can use invlpg and non-cacheable PTEs
+* Map local apic.
 *
 * Whap the PTE "by hand" rather than calling pmap_kenter_pa because
 * the latter will attempt to invoke TLB shootdown code just as we
Index: i386/i386/locore.s
===
RCS file: /cvs/src/sys/arch/i386/i386/locore.s,v
retrieving revision 1.194
diff -u -p -u -r1.194 locore.s
--- i386/i386/locore.s  3 Jan 2022 00:44:30 -   1.194
+++ i386/i386/locore.s  28 Jul 2022 01:41:18 -
@@ -266,7 +266,7 @@ _C_LABEL(lapic_tpr):
.long   0
 #endif
 
-_C_LABEL(cpu): .long   0   # are we 386, 386sx, 486, 586 or 686
+_C_LABEL(cpu): .long   0   # are we 486, 586 or 686
 _C_LABEL(cpu_id):  .long   0   # saved from 'cpuid' instruction
 _C_LABEL(cpu_pae): .long   0   # are we using PAE paging mode?
 _C_LABEL(cpu_miscinfo):.long   0   # misc info (apic/brand id) 
from 'cpuid'
Index: i386/i386/locore0.S
===
RCS file: 

Re: remove rise detection from i386

[Daniel Dickman]

On Sun, Jul 24, 2022 at 2:55 AM Jonathan Gray  wrote:
>
> On Sun, Jul 24, 2022 at 02:16:23AM -0400, Daniel Dickman wrote:
> >http://datasheets.chipdb.org/Rise/
> >
> >Quoting the data sheet from this link:
> >
> >“The CMPXCHG8B instruction is supported and always enabled on the Rise
> >mP6 processor; however, the default CPUID function bit is set to 0 to
> >circumvent a reported bug in Windows NT”
> >
> >I don’t think we have a workaround for this quirk so I’m not sure
> >there’s value in keeping the cpu ID code.
>
> The kernel shows if the CX8 bit is set, but doesn't use it otherwise.

Agree. I think on this CPU the only consequence is that CX8 won't be
shown in dmesg. The quirk needed would be to detect the Rise CPU and
force showing CX8.

But probably no real consequence beyond that as you say.

> The toolchain assumes it exists as we default to -march=i586 since 2020.
> I'd expect a mP6 to boot just not be as recognised after the diff.

Makes sense.

>
> Still ok with the original diff.

Will commit soon unless someone shows up saying they have a Rise CPU
and they'd like to keep this code.

Re: remove rise detection from i386

[Daniel Dickman]

On Jul 24, 2022, at 12:25 AM, Jonathan Gray  wrote:On Sat, Jul 23, 2022 at 02:13:27PM -0400, Daniel Dickman wrote:The Rise mp6 was a short lived processor that was announced around 20+ years and didn't make it to market.I think we can delete the cpu identification for this cpu at this point.ok?I am ok with removing it, but I think it did ship.Sure I believe “Kirin” did but “Lynx” only made it as engineering samples.https://github.com/InstLatx64/InstLatx64/tree/master/RiseRiseRisehttp://datasheets.chipdb.org/Rise/Quoting the data sheet from this link:“The CMPXCHG8B instruction is supported and always enabled on the Rise mP6 processor; however, the default CPUID function bit is set to 0 to circumvent a reported bug in Windows NT”I don’t think we have a workaround for this quirk so I’m not sure there’s value in keeping the cpu ID code.BIOS Writer's Guide: iDRAGON mP6 MICROPROCESSORfamily 5 model 0    RiSE iDragon (0.25 um)family 5 model 2    RiSE iDragon (0.18 um)family 5 model 8    RiSE iDragon II (0.25 um)family 5 model 9    RiSE iDragon II (0.18 um)https://www.pcengines.ch/platform.htmSIS 55xCPU: Rise MP6 "Pentium class", 200 to 250 MHz, 8K I-Cache + 8K D-CacheThe SiS 55x was a licensed Rise core but I believe the cpuid is “SiS SiS SiS”STPC VegaCPU: Rise MP6 "Pentium II class" core, up to 250 MHz, 8K I-Cache + 8K D-Cacheboth SiS 55x and DM Vortex86 appear to use "SiS SiS SiS ".I think only the early vortex CPUs which used the SiS core. I don’t own one myself but I think current versions do not have this cpuid and might use “Vortex86 SoC”   See:Information on DM Vortex86DX3 SoCtortoiseit.blogspot.comnot sure what the STPC Vega would show asNor do I.Index: i386/machdep.c===RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,vretrieving revision 1.650diff -u -p -u -r1.650 machdep.c--- i386/machdep.c    12 Jul 2022 05:45:49 -    1.650+++ i386/machdep.c    23 Jul 2022 18:02:05 -@@ -782,41 +782,6 @@ const struct cpu_cpuid_nameclass i386_cp         } }     },     {-        "RiseRiseRise",-        CPUVENDOR_RISE,-        "Rise",-        /* Family 4, not available from Rise */-        { {-            CPUCLASS_486,-            {-                0, 0, 0, 0, 0, 0, 0, 0,-                0, 0, 0, 0, 0, 0, 0, 0,-                "486 class"        /* Default */-            },-            NULL-        },-        /* Family 5 */-        {-            CPUCLASS_586,-            {-                "mP6", 0, "mP6", 0, 0, 0, 0, 0,-                0, 0, 0, 0, 0, 0, 0, 0,-                "mP6"            /* Default */-            },-            NULL-        },-        /* Family 6, not yet available from Rise */-        {-            CPUCLASS_686,-            {-                0, 0, 0, 0, 0, 0, 0, 0,-                0, 0, 0, 0, 0, 0, 0, 0,-                "686 class"        /* Default */-            },-            NULL-        } }-    },-    {         "GenuineTMx86",         CPUVENDOR_TRANSMETA,         "Transmeta",Index: include/cputypes.h===RCS file: /cvs/src/sys/arch/i386/include/cputypes.h,vretrieving revision 1.11diff -u -p -u -r1.11 cputypes.h--- include/cputypes.h    7 Jul 2022 00:56:46 -    1.11+++ include/cputypes.h    23 Jul 2022 18:02:05 -@@ -63,7 +63,6 @@ #define CPUVENDOR_CYRIX        1 #define CPUVENDOR_AMD        3 #define CPUVENDOR_IDT        4-#define CPUVENDOR_RISE        5 #define CPUVENDOR_TRANSMETA    6 #define CPUVENDOR_NS        7 #define CPUVENDOR_VIA        8

remove rise detection from i386

[Daniel Dickman]

The Rise mp6 was a short lived processor that was announced around 20+ 
years and didn't make it to market.

I think we can delete the cpu identification for this cpu at this point.

ok?

Index: i386/machdep.c
===
RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
retrieving revision 1.650
diff -u -p -u -r1.650 machdep.c
--- i386/machdep.c  12 Jul 2022 05:45:49 -  1.650
+++ i386/machdep.c  23 Jul 2022 18:02:05 -
@@ -782,41 +782,6 @@ const struct cpu_cpuid_nameclass i386_cp
} }
},
{
-   "RiseRiseRise",
-   CPUVENDOR_RISE,
-   "Rise",
-   /* Family 4, not available from Rise */
-   { {
-   CPUCLASS_486,
-   {
-   0, 0, 0, 0, 0, 0, 0, 0,
-   0, 0, 0, 0, 0, 0, 0, 0,
-   "486 class" /* Default */
-   },
-   NULL
-   },
-   /* Family 5 */
-   {
-   CPUCLASS_586,
-   {
-   "mP6", 0, "mP6", 0, 0, 0, 0, 0,
-   0, 0, 0, 0, 0, 0, 0, 0,
-   "mP6"   /* Default */
-   },
-   NULL
-   },
-   /* Family 6, not yet available from Rise */
-   {
-   CPUCLASS_686,
-   {
-   0, 0, 0, 0, 0, 0, 0, 0,
-   0, 0, 0, 0, 0, 0, 0, 0,
-   "686 class" /* Default */
-   },
-   NULL
-   } }
-   },
-   {
"GenuineTMx86",
CPUVENDOR_TRANSMETA,
"Transmeta",
Index: include/cputypes.h
===
RCS file: /cvs/src/sys/arch/i386/include/cputypes.h,v
retrieving revision 1.11
diff -u -p -u -r1.11 cputypes.h
--- include/cputypes.h  7 Jul 2022 00:56:46 -   1.11
+++ include/cputypes.h  23 Jul 2022 18:02:05 -
@@ -63,7 +63,6 @@
 #define CPUVENDOR_CYRIX1
 #define CPUVENDOR_AMD  3
 #define CPUVENDOR_IDT  4
-#define CPUVENDOR_RISE 5
 #define CPUVENDOR_TRANSMETA6
 #define CPUVENDOR_NS   7
 #define CPUVENDOR_VIA  8

[patch] rename tbl man pages

[Daniel Dickman]

Over a decade ago there was some work in bsd.man.mk to build tbl pages 
with mandoc. For example this commit from 2010:


revision 1.32
date: 2010/10/17 22:47:08;  author: schwarze;  state: Exp;  lines: +8 -18;
Build tbl(1) pages with mandoc(1), not groff.
Xenocara build checked myself, base build also by jmc@, thanks!
"don't wait for me" deraadt@

Pages in base using tbl mostly look good already except for the
rare .T{ macros; there may still be a few formatting issues
in xenocara, please speak up when you run into them.
Eventually, mandoc will catch up.


Back then there was some special infrastructure to build these man pages 
if they were named something like *.6tbl.

That convention is a local OpenBSD convention, it does not exist outside 
of our tree.

At this point the special naming for these man pages is no longer needed:

* games/phantasia/phantasia.6tbl
* gnu/usr.sbin/mkhybrid/src/mkhybrid.8tbl
* share/man/man4/man4.hppa/cpu.4tbl
* share/man/man4/wi.4tbl
* share/man/man4/man4.hppa/cpu.4tbl
* usr.bin/infocmp/infocmp.1tbl
* usr.bin/tic/captoinfo.1tbl

The benefits are:
- The affected Makefiles are shortened by 3+ lines
- diffing external software like mkhybrid against the original sources 
  results in less noise
- remove an unnecessary cp step doing the build

ok on the diff below? (I've left out the man page renames from the diff 
for brevity)



Index: games/phantasia/Makefile
===
RCS file: /cvs/src/games/phantasia/Makefile,v
retrieving revision 1.18
diff -u -p -u -r1.18 Makefile
--- games/phantasia/Makefile24 Nov 2015 03:10:10 -  1.18
+++ games/phantasia/Makefile7 Jul 2022 01:24:22 -
@@ -6,7 +6,7 @@ CFLAGS+=-DTERMIOS
 DPADD= ${LIBM} ${LIBCURSES}
 LDADD= -lm -lcurses
 MAN=   phantasia.6
-CLEANFILES+=map setup setup.o phantglobs.o.bld phantasia.6
+CLEANFILES+=map setup setup.o phantglobs.o.bld
 
 all: setup phantasia
 
@@ -19,9 +19,6 @@ phantglobs.o.bld: phantglobs.c
 setup: phantglobs.o.bld setup.o monsters.asc ${DPADD} 
${HOSTCC} ${CFLAGS} ${LDFLAGS} ${LDSTATIC} -o ${.TARGET} \
  phantglobs.o.bld setup.o ${LDADD}
-
-phantasia.6: phantasia.6tbl
-   cp ${.ALLSRC} ${.TARGET}
 
 beforeinstall: 
./setup -m ${.CURDIR}/monsters.asc
Index: gnu/usr.sbin/mkhybrid/mkhybrid/Makefile
===
RCS file: /cvs/src/gnu/usr.sbin/mkhybrid/mkhybrid/Makefile,v
retrieving revision 1.7
diff -u -p -u -r1.7 Makefile
--- gnu/usr.sbin/mkhybrid/mkhybrid/Makefile 9 Sep 2015 20:02:31 -   
1.7
+++ gnu/usr.sbin/mkhybrid/mkhybrid/Makefile 7 Jul 2022 01:24:22 -
@@ -8,7 +8,6 @@
 PROG=  mkhybrid
 MAN=   mkhybrid.8
 BINDIR=/usr/sbin
-CLEANFILES+= mkhybrid.8
 .PATH: ${.CURDIR}/../src ${.CURDIR}/../src/libhfs_iso ${.CURDIR}/../src/libfile
 
 SRCS=  data.c block.c low.c lfile.c btree.c node.c record.c lvolume.c \
@@ -20,8 +19,5 @@ CFLAGS+=-DSYSTEM_ID_DEFAULT=\"OpenBSD\" 
-I${.CURDIR}/../src -I${.CURDIR}/../src/include \
-I${.CURDIR}/../src/libhfs_iso \
-I${.CURDIR}/../src/libfile
-
-mkhybrid.8: mkhybrid.8tbl
-   cp ${.ALLSRC} ${.TARGET}
 
 .include 
Index: share/man/man4/man4.hppa/Makefile
===
RCS file: /cvs/src/share/man/man4/man4.hppa/Makefile,v
retrieving revision 1.29
diff -u -p -u -r1.29 Makefile
--- share/man/man4/man4.hppa/Makefile   30 Mar 2016 06:38:44 -  1.29
+++ share/man/man4/man4.hppa/Makefile   7 Jul 2022 01:24:22 -
@@ -6,9 +6,5 @@ MAN+=   harmony.4 ie.4 intro.4 io.4 lasi.4
 MAN+=  phantomas.4 power.4 runway.4 ssio.4 uturn.4 wax.4
 # tir.4 xbar.4 mcx.4
 MANSUBDIR=hppa
-CLEANFILES+= cpu.4
-
-cpu.4: cpu.4tbl
-   cp ${.ALLSRC} ${.TARGET}
 
 .include 
Index: share/man/man4/Makefile
===
RCS file: /cvs/src/share/man/man4/Makefile,v
retrieving revision 1.817
diff -u -p -u -r1.817 Makefile
--- share/man/man4/Makefile 18 Jan 2022 07:53:39 -  1.817
+++ share/man/man4/Makefile 7 Jul 2022 01:24:22 -
@@ -113,9 +113,4 @@ SUBDIR= man4.alpha man4.amd64 man4.arm64
man4.hppa man4.i386 man4.landisk man4.loongson man4.luna88k \
man4.macppc man4.octeon man4.powerpc64 man4.riscv64 man4.sparc64
 
-CLEANFILES+= wi.4
-
-wi.4: wi.4tbl
-   cp ${.ALLSRC} ${.TARGET}
-
 .include 
Index: share/man/man4/man4.hppa/Makefile
===
RCS file: /cvs/src/share/man/man4/man4.hppa/Makefile,v
retrieving revision 1.29
diff -u -p -u -r1.29 Makefile
--- share/man/man4/man4.hppa/Makefile   30 Mar 2016 06:38:44 -  1.29
+++ share/man/man4/man4.hppa/Makefile   7 Jul 2022 01:24:22 -
@@ -6,9 +6,5 @@ MAN+=   harmony.4 ie.4 intro.4 io.4 lasi.4
 MAN+=  phantomas.4 power.4 runway.4 ssio.4 uturn.4 wax.4
 # tir.4 xbar.4 mcx.4
 

Re: quiz(6): update european countries

[Daniel Dickman]

> On Jul 5, 2022, at 1:51 AM, Otto Moerbeek  wrote:
> 
> On Mon, Jul 04, 2022 at 05:44:33PM -0400, Daniel Dickman wrote:
> 
>> 
>> 
>>> On Sun, 3 Jul 2022, Daniel Dickman wrote:
>>> 
>>> On Sat, Jul 2, 2022 at 9:26 PM Ben Fuller  wrote:
>>>> 
>>>> I noticed Montenegro doesn't have an entry. Presumably this file hasn't
>>>> been updated since before 2006!
>>> 
>>> These files could use a big overhaul and are very dated.
>>> 
>>> In the below, make sure to keep the file sorted.
>>> 
>>> In the Europe file there are other issues. For example I think
>>> Macedonia is now North Macedonia, etc.
>>> 
>>> There are many issues in the other files. For example africa doesn't
>>> have Eswatini, etc, etc.
>>> 
>>> Do you want to take a stab at doing a bigger update of the 4 quiz
>>> files? africa, america, europe, asia?
>>> 
>> 
>> I had some time on my hand and took a stab on this. A few notes:
>> 
>> Added multiple capitals for countries with more than one capital city that 
>> were missing these:
>> - Eswatini
>> - South Africa
>> - Malaysia
>> - Sri Lanka
>> 
>> Removed duplicate entries:
>> - Turkey: remove from europe, keep in asia
>> - Georgia: remove from europe, keep in asia
> 
> Both are debatable. Certainly Instanbul is in Europe.
> Many view Georgia as European.

Agree it’s debatable. Agree that politically they may be closer to Europe. But 
here I followed a geographical classification.

> 
>> 
>> For the above I followed this wikipedia classification:
>> https://en.wikipedia.org/wiki/List_of_sovereign_states_and_dependent_territories_by_continent
> 
> Which list both Georgia and Turkey as European (and Turkey also as
> Asian).

The tables do, but there is also text in the article which says.

“Transcontinental countries in Europe and Asia, classified as West Asian 
countries by the United Nations Statistics Division: Azerbaijan,  Georgia,  
Kazakhstan, and Turkey (all but Kazakhstan are members of the Council of 
Europe).”

And this is what I followed. We can keep the duplicates though. I don’t feel 
very strongly about this.

> 
>> africa:
>> - removed Dahomey as the the pre-1975 name for Benin; it's been close to 
>>  50 years since the rename.
>> - updated Swaziland -> Eswatini. I left Swaziland since Eswatini rename 
>>  happened in 2018. So going by the Benin example, seems like when we get 
>>  closer to 50 years from the rename we can drop the old name
>> - added "The" as an optional prefix for Gambia
>> - removed "Republic of" from South Africa for consistency with other 
>>  countries which don't generally include the formal prefix as part of the 
>>  name.
>> 
>> americas:
>> - added many missing countries
>> - added "The" as an optional prefix for Bahamas
>> - added missing suffix of "City" from many capitals like Guatemala, 
>>  Mexico, and Panama
>> 
>> asia:
>> - added many missing countries in Oceania (like New Zealand, Fiji, etc)
>> - added UAE in addition to United Arab Emirates
>> 
>> europe:
>> - added Montenegro
>> - added Vatican City
>> - renamed Macedonia to North Macedonia
>> - Yugoslavia -> Serbia
>> 
>> I also looked at NetBSD a bit and noticed they added a lot of territories 
>> and their capitals, but I decided not to add those in this update.
>> 
>> I also noticed NetBSD removed The Hague as a capital of The Netherlands, 
>> but I disagree with that. Maybe some of the Dutch folks on this mailing 
>> list can weigh in which is right.
> 
> The Dutch constitiution defines Amsterdam as the capital. The Hague
> only is the seat of gorvernment.


Thanks for confirming.

Re: quiz(6): update european countries

[Daniel Dickman]

On Mon, Jul 4, 2022 at 8:09 PM Daniel Dickman  wrote:
>
>
>
> > On Jul 4, 2022, at 8:07 PM, Ben Fuller  wrote:
> >
> > On Mon, Jul 04, 2022 at 19:30:19 -0400, Daniel Dickman wrote:
> >>>> Maldive Islands:Male
> >>> A more common name is just "{The }Maldives".
> >>
> >> I don't think so. See this article:
> >> https://www.bbc.com/news/magazine-18233844
> >>
> >> which states:
> >>
> >> "...according to several authoritative sources, such as the CIA World
> >> Factbook, the Times Comprehensive Atlas of the World and the US Department
> >> of State, only two countries, The Bahamas and The Gambia, should
> >> officially be referred to with the article."
> >
> > That may be so, but for the purposes of a quiz game, if I am asked "of
> > what country is Male the capital", I would answer The Maldives, and
> > would be annoyed if that was marked incorrect because only "Maldive
> > Islands" is accepted. Also, the official name is "Republic of Maldives"
> > or just "Maldives". The point is that this is a game, not a precise
> > database.
>
>
> No you would answer “the Maldives” because it is a group of island. Not “The 
> Maldives” (note the capital T) which is not the name of the country.
>
> I’m afraid I still don’t agree with you.

Rereading what you wrote, I agree the NetBSD approach is better than
our current approach of "Maldive Islands". So my local diff now has
the same as NetBSD:

Maldiv{e Island}s:Male

For the prefix "The" -- we also do not have "The United States of
America" or "The Sudan" or "The Philippines" and similar. So I don't
think the optional prefix "The" should be added except for the 2
official cases.

Re: quiz(6): update european countries

[Daniel Dickman]

> On Jul 4, 2022, at 8:07 PM, Ben Fuller  wrote:
> 
> On Mon, Jul 04, 2022 at 19:30:19 -0400, Daniel Dickman wrote:
>>>> Maldive Islands:Male
>>> A more common name is just "{The }Maldives".
>> 
>> I don't think so. See this article: 
>> https://www.bbc.com/news/magazine-18233844
>> 
>> which states:
>> 
>> "...according to several authoritative sources, such as the CIA World 
>> Factbook, the Times Comprehensive Atlas of the World and the US Department 
>> of State, only two countries, The Bahamas and The Gambia, should 
>> officially be referred to with the article."
> 
> That may be so, but for the purposes of a quiz game, if I am asked "of
> what country is Male the capital", I would answer The Maldives, and
> would be annoyed if that was marked incorrect because only "Maldive
> Islands" is accepted. Also, the official name is "Republic of Maldives"
> or just "Maldives". The point is that this is a game, not a precise
> database.


No you would answer “the Maldives” because it is a group of island. Not “The 
Maldives” (note the capital T) which is not the name of the country.

I’m afraid I still don’t agree with you.

[patch] remove nexgen detection from i386

[Daniel Dickman]

The patch below removes the (small) amount of code used to identify NexGen 
CPUs. I'm doubtful that these CPUs would be supported anymore and we don't 
do anything with the information once we identify a NexGen CPU.

The code does a division early in the i386 boot process (in locore0) and 
checks the result of the ZF flag. Apparently ZF would have a different 
value on a NexGen vs an Intel CPU.

According to my research some NexGen CPUs were:
  Nx586-P66
  Nx586-P75
  Nx586-P80
  Nx586-P90
  Nx586-P100
  Nx586-P110
  Nx586-P120
  Nx586-P133

And:
  Nx586-PF100
  Nx586-PF110

The models with a "P" did not include an FPU, while the models with "PF" 
did include an integrated FPU.

According to this site, there were originally plans for a separate Nx587 
FPU but it was never officially released:

https://www.x86-guide.net/en/fpu/NexGen-Nx587-2.html

On our i386 page we state that we support:

"All CPUs compatible with the Intel Pentium or later, with 
Intel-compatible hardware floating point support should work."

Therefore none of the FPU-less NexGen CPUs are ones we state we support.

Looking at what we implement for our recognition code, we only implement 
half of the algorithm to identify NexGen cpus that don't have the cpuid 
instruction. We ignore NexGen cpus that support the cpuid instruction 
(which would return the string "NexGenDriven"). So the ones lacking cpuid 
support probably don't have an FPU and aren't supported. While the ones 
with the FPU are likely ones that support the cpuid instruction, but our 
detection code doesn't detect them.

So it looks like neither case would be supported in the current code.

One thing I was not able to find out is the precise details of which of 
these CPUs do support the CPUID instruction and which ones don't. I've 
looked for these CPUs on ebay for the past few years but they seem to be 
fairly impossible to find with the last ones probably sitting in the hands 
of collectors. So the above is just a guess on my part.

Finally I keep reading that the Nx586 is not actually Pentium clone, but 
rather an i386 clone. I don't have a good way to test this, but I've read 
that instructions like CMPXCHG8B (pentium), INVLPG (486), XADD (486) might 
not be directly supported by NexGen cpus. There is discussion of this 
here:

https://www.cpu-world.com/forum/viewtopic.php?p=189409

"...the truth is that the Nx586 is an extremely fast 386 processor. Later 
they added some 486 instructions via hypercode, which is stored in the 
BIOS EEPROM, but only the application-oriented ones. So while you can run 
most of the applications that were compiled for an 486, you can't run an 
operating system which requires a 486 or even a Pentium."

Below diff tested on my transmeta notebook running i386 which continues to 
run fine and doesn't change the transmeta detection code.

In the diff I left the ".Lis386" label even though it isn't needed 
anymore, but I think it's a useful comment to keep.

ok?


Index: i386/locore0.S
===
RCS file: /cvs/src/sys/arch/i386/i386/locore0.S,v
retrieving revision 1.5
diff -u -p -u -r1.5 locore0.S
--- i386/locore0.S  31 Dec 2021 10:44:05 -  1.5
+++ i386/locore0.S  3 Jul 2022 21:06:50 -
@@ -132,25 +132,6 @@ start: movw$0x1234,0x472   # warm 
boot
testl   %eax,%eax
jnz .Ltry486
 
-   /*
-* Try the test of a NexGen CPU -- ZF will not change on a DIV
-* instruction on a NexGen, it will on an i386.  Documented in
-* Nx586 Processor Recognition Application Note, NexGen, Inc.
-*/
-   movl$0x,%eax
-   xorl%edx,%edx
-   movl$2,%ecx
-   divl%ecx
-   jnz .Lis386
-
-.Lisnx586:
-   /*
-* Don't try cpuid, as Nx586s reportedly don't support the
-* PSL_ID bit.
-*/
-   movl$CPU_NX586,RELOC(_C_LABEL(cpu))
-   jmp 2f
-
 .Lis386:
movl$CPU_386,RELOC(_C_LABEL(cpu))
jmp 2f
Index: i386/machdep.c
===
RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
retrieving revision 1.648
diff -u -p -u -r1.648 machdep.c
--- i386/machdep.c  1 Feb 2022 20:29:55 -   1.648
+++ i386/machdep.c  3 Jul 2022 21:06:51 -
@@ -510,8 +510,6 @@ const struct cpu_nocpuid_nameclass i386_
NULL},  /* CPU_486DLC */
{ CPUVENDOR_CYRIX, "Cyrix", "6x86", CPUCLASS_486,
cyrix6x86_cpu_setup},   /* CPU_6x86 */
-   { CPUVENDOR_NEXGEN,"NexGen","586",  CPUCLASS_386,
-   NULL},  /* CPU_NX586 */
 };
 
 const char *classnames[] = {
Index: include/cputypes.h
===
RCS file: /cvs/src/sys/arch/i386/include/cputypes.h,v
retrieving revision 1.10
diff -u -p -u -r1.10 cputypes.h
--- 

Re: quiz(6): update european countries

[Daniel Dickman]

On Mon, 4 Jul 2022, Ben Fuller wrote:

> On Mon, Jul 04, 2022 at 17:44:33 -0400, Daniel Dickman wrote:
> > I had some time on my hand and took a stab on this. A few notes:
> 
> Ach, you beat me to sending a patch. I made almost exactly the same changes as
> you have. I've noted some of my thoughts below.
> 
> > I also looked at NetBSD a bit and noticed they added a lot of territories 
> > and their capitals, but I decided not to add those in this update.
> 
> I wonder what their opinion on Kosovo was.

I've left out disputed areas in this update.

> 
> >  Maldive Islands:Male
> 
> A more common name is just "{The }Maldives".

I don't think so. See this article: 
https://www.bbc.com/news/magazine-18233844

which states:

"...according to several authoritative sources, such as the CIA World 
Factbook, the Times Comprehensive Atlas of the World and the US Department 
of State, only two countries, The Bahamas and The Gambia, should 
officially be referred to with the article."


> 
> >  Netherlands|Holland:The Hague|'sGravenhage|den Haag|Amsterdam
> 
> To the best of my knowledge, Amsterdam is the formal capital (perhaps it
> should come first in the alternatives) but for the purposes of a quiz
> game I think The Hague is also an acceptable answer.

Researching this more, I feel like I'm coming into agreement with the 
NetBSD change after all about removing The Hague.

> 
> >  R[u|o]mania:Bucharest|Bucuresti
> 
> Perhaps switch the order of [u|o] here so that Romania is printed (the
> more common spelling, I think)

I think it's right to make it Romania. Rumania is common in non-English 
languages and my internet research leads me to believe that Romania is the 
official anglicization preferred by the Romanian government (at least 
according to their consulate web pages that I visited).

> 
> >  Ukraine:Kiev|Kyiv
> There's been some commotion about preferring the Ukrainian spelling Kyiv to 
> the
> Russian Kiev.
> 

Maybe let's leave for a separate commit as I want to steer clear of 
contentious issues.

I do note this reference which I've read through:
https://en.wikipedia.org/wiki/KyivNotKiev

And again, I see the spelling as Kyiv on the English section of a .ua govt 
site I visited.

Re: quiz(6): update european countries

[Daniel Dickman]

On Sun, 3 Jul 2022, Daniel Dickman wrote:

> On Sat, Jul 2, 2022 at 9:26 PM Ben Fuller  wrote:
> >
> > I noticed Montenegro doesn't have an entry. Presumably this file hasn't
> > been updated since before 2006!
> 
> These files could use a big overhaul and are very dated.
> 
> In the below, make sure to keep the file sorted.
> 
> In the Europe file there are other issues. For example I think
> Macedonia is now North Macedonia, etc.
> 
> There are many issues in the other files. For example africa doesn't
> have Eswatini, etc, etc.
> 
> Do you want to take a stab at doing a bigger update of the 4 quiz
> files? africa, america, europe, asia?
> 

I had some time on my hand and took a stab on this. A few notes:

Added multiple capitals for countries with more than one capital city that 
were missing these:
- Eswatini
- South Africa
- Malaysia
- Sri Lanka

Removed duplicate entries:
- Turkey: remove from europe, keep in asia
- Georgia: remove from europe, keep in asia

For the above I followed this wikipedia classification:
https://en.wikipedia.org/wiki/List_of_sovereign_states_and_dependent_territories_by_continent

africa:
- removed Dahomey as the the pre-1975 name for Benin; it's been close to 
  50 years since the rename.
- updated Swaziland -> Eswatini. I left Swaziland since Eswatini rename 
  happened in 2018. So going by the Benin example, seems like when we get 
  closer to 50 years from the rename we can drop the old name
- added "The" as an optional prefix for Gambia
- removed "Republic of" from South Africa for consistency with other 
  countries which don't generally include the formal prefix as part of the 
  name.

americas:
- added many missing countries
- added "The" as an optional prefix for Bahamas
- added missing suffix of "City" from many capitals like Guatemala, 
  Mexico, and Panama

asia:
- added many missing countries in Oceania (like New Zealand, Fiji, etc)
- added UAE in addition to United Arab Emirates

europe:
- added Montenegro
- added Vatican City
- renamed Macedonia to North Macedonia
- Yugoslavia -> Serbia

I also looked at NetBSD a bit and noticed they added a lot of territories 
and their capitals, but I decided not to add those in this update.

I also noticed NetBSD removed The Hague as a capital of The Netherlands, 
but I disagree with that. Maybe some of the Dutch folks on this mailing 
list can weigh in which is right.

anyone want to ok this update?

Index: africa
===
RCS file: /cvs/src/games/quiz/datfiles/africa,v
retrieving revision 1.5
diff -u -p -u -r1.5 africa
--- africa  2 Dec 2014 12:43:09 -   1.5
+++ africa  4 Jul 2022 21:34:34 -
@@ -1,6 +1,6 @@
 Algeria:Alg[iers|er]
 Angola:Luanda
-Benin|Dahomey:Porto[-| ]Novo
+Benin:Porto[-| ]Novo
 Botswana:Gaborone
 Burkina Faso:Ouagadougou
 Burundi:Bujumbura
@@ -16,9 +16,10 @@ Djibouti:Djibouti City
 Egypt:Cairo
 Equatorial Guinea:Malabo
 Eritrea:Asmara
+Eswatini|Swaziland:Mbabane|Lobamba
 Ethiopia:Addis Ababa
 Gabon:Libreville
-Gambia:Banjul
+{The }Gambia:Banjul
 Ghana:Accra
 Guinea-Bissau:Bissau
 Guinea:Conakry
@@ -42,10 +43,9 @@ Senegal:Dakar
 Seychelles:Victoria
 Sierra Leone:Freetown
 Somalia:Mogadishu
-{Rep{ublic} of }South Africa:Pretoria
+South Africa:Pretoria|Cape Town|Bloemfontein
 South Sudan:Juba
 Sudan:Khartoum
-Swaziland:Mbabane
 Tanzania:Dodoma
 Togo:Lome
 Tunisia:Tunis
Index: america
===
RCS file: /cvs/src/games/quiz/datfiles/america,v
retrieving revision 1.2
diff -u -p -u -r1.2 america
--- america 2 Dec 2014 12:43:09 -   1.2
+++ america 4 Jul 2022 21:34:34 -
@@ -1,6 +1,8 @@
+Antigua and Barbuda:St. John's
 Argentina:Buenos Aires
-Bahamas:Nassau
+{The }Bahamas:Nassau
 Barbados:Bridgetown
+Belize:Belmopan
 Bolivia:La Paz|Sucre
 Bra[z|s]il:Brasilia
 Canada:Ottawa
@@ -8,19 +10,25 @@ Chile:Santiago
 Colombia:Bogota
 Costa Rica:San Jose
 Cuba:Ha[v|b]ana
+Dominica:Roseau
 Dominican Republic:Santo Domingo
 Ecuador:Quito
 El Salvador:San Salvador
-Guatemala:Guatemala
+Greenland:Nuuk
+Grenada:St. George's
+Guatemala:Guatemala City
 Guyana:Georgetown
-Haiti:Port au Prince
+Haiti:Port[-| ]au[-| ]Prince
 Honduras:Tegucigalpa
 Jamaica:Kingston
-Mexico:Mexico
+Mexico:Mexico City
 Nicaragua:Managua
-Panama:Panama
+Panama:Panama City
 Paraguay:Asuncion
 Peru:Lima
+Saint Lucia:Castries
+Saint Vincent and the Grenadines:Kingstown
+Suriname:Paramaribo
 Trinidad{ and Tobago}:Port of Spain
 United States|US{A}:Washington
 Uruguay:Montevideo
Index: asia
===
RCS file: /cvs/src/games/quiz/datfiles/asia,v
retrieving revision 1.5
diff -u -p -u -r1.5 asia
--- asia24 Nov 2014 06:31:50 -  1.5
+++ asia4 Jul 2022 21:34:34 -
@@ -10,6 +10,7 @@ Cambodia:P{h}nom Penh
 China:Be

Re: quiz(6): update european countries

[Daniel Dickman]

On Sat, Jul 2, 2022 at 9:26 PM Ben Fuller  wrote:
>
> I noticed Montenegro doesn't have an entry. Presumably this file hasn't
> been updated since before 2006!

These files could use a big overhaul and are very dated.

In the below, make sure to keep the file sorted.

In the Europe file there are other issues. For example I think
Macedonia is now North Macedonia, etc.

There are many issues in the other files. For example africa doesn't
have Eswatini, etc, etc.

Do you want to take a stab at doing a bigger update of the 4 quiz
files? africa, america, europe, asia?

>
> diff --git games/quiz/datfiles/europe games/quiz/datfiles/europe
> index 83af7320713..fec2746c3b2 100644
> --- games/quiz/datfiles/europe
> +++ games/quiz/datfiles/europe
> @@ -27,6 +27,7 @@ Luxembourg:Luxembourg
>  Malta:Valletta
>  Moldova:Chisinau|Kishinev
>  Monaco:Monaco
> +Montenegro:Podgori[ca|tsa]
>  Netherlands|Holland:The Hague|'sGravenhage|den Haag|Amsterdam
>  Norway:Oslo
>  Poland:Wars[aw|zawa]
> @@ -41,4 +42,4 @@ Sweden:Stockholm
>  Switzerland:Bern{e}
>  Turkey:Ankara
>  Ukraine:Kiev|Kyiv
> -Yugoslavia:Belgrade|Beograd
> +Serbia:Belgrade|Beograd
>

Re: Microkernel

[Daniel Dickman]




> On May 21, 2022, at 4:16 PM, Daniel Douglas Dyrseth  
> wrote:
> Hi
> Is porting natively a microkernel like seL4, Minix's or rewriting one for 
> OpenBSD an option and something the developers could implement? I see this as 
> an excellent addition to the already most robust OS in the world.

This mailing list is for diffs and patches not pie in the sky questions. 
There’s misc@ for that.

To save you having to post again though, the answer is no.

sel4 is GPL licensed. But if you wanted to write an OpenBSD personality to run 
on top of sel4, no one would stop you.


> 
> Sincerely
> Daniel Douglas Dyrseth

Re: new: lang/polyml

[Daniel Dickman]

> On Jan 12, 2022, at 2:06 AM, Philip Guenther  wrote:
> 
> 
>> On Tue, Jan 11, 2022 at 4:09 PM Daniel Dickman  wrote:
> 
>> On Mon, Jan 10, 2022 at 8:12 PM Leo Larnack  wrote:
>> >
>> > i386
>> >
>> 
>> 
>> 
>> with this diff I was able to install includes, rebuild ld.so and
>> ctfconv. I've not managed to build a release yet.
> ...
> 
> Umm, with what diff?  There was no diff in nor attached to that message.  :-/

I see sthen already sent you the link. Leo was asked to split his diff by 
architecture. I did the testing for the i386 diff he proposed.


> 
> (That was a lot of lines of output.  I don't know about ports@, but my 
> expectation would be there would be *zero* reviewers of anything before, say, 
> the last 50 lines of output before the switch to actual compilation.  
> Standard "make lots of noise so when a failure occurs we can see the leadup, 
> but we'll ignore it otherwise" style of output, like a base build.  You read 
> the lead up to the warnings and errors only.  )

Yeah. No this is very bad  advice.

I’m going to have to *strongly* disagree with you here Philip. I don’t expect 
most people to be setting up i386 boxes to test this so providing the full logs 
would be helpful to compare against amd64 which is obviously working for Leo. I 
think Stuart was making the same point.

If I tested on amd64 then I’d expect most people would be able to check it 
themselves.

> 
> 
> Philip Guenther
> 

Re: new: lang/polyml

[Daniel Dickman]

On Mon, Jan 10, 2022 at 8:12 PM Leo Larnack  wrote:
>
> i386
>



with this diff I was able to install includes, rebuild ld.so and
ctfconv. I've not managed to build a release yet.

Unfortunately polyml still fails to build, but I it did get quite a
bit further. most of the build log shown below.


checking whether _WIN32 is declared... no
checking how to print strings... print -r
checking for a sed that does not truncate output... (cached) /usr/bin/sed
checking for fgrep... (cached) /usr/bin/fgrep
checking for ld used by cc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... (cached) 131072
checking how to convert i386-unknown-openbsd7.0 file names to
i386-unknown-openbsd7.0 format... func_convert_file_noop
checking how to convert i386-unknown-openbsd7.0 file names to
toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... match_pattern
/lib[^/]+(\.so\.[0-9]+\.[0-9]+|\.so|_pic\.a)$
checking for dlltool... no
checking how to associate runtime and link libraries... print -r --
checking for ar... (cached) ar
checking for archiver @FILE support... @
checking for strip... (cached) strip
checking for ranlib... (cached) ranlib
checking command to parse /usr/bin/nm -B output from cc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... mt
checking if mt is a manifest tool... no
checking for dlfcn.h... (cached) yes
checking for objdir... .libs
checking if cc supports -fno-rtti -fno-exceptions... yes
checking for cc option to produce PIC... -fPIC -DPIC
checking if cc PIC flag -fPIC -DPIC works... yes
checking if cc static flag -static works... yes
checking if cc supports -c -o file.o... yes
checking if cc supports -c -o file.o... (cached) yes
checking whether the cc linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... openbsd7.0 ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether c++ accepts -g... (cached) yes
checking dependency style of c++... gcc3
checking how to run the C++ preprocessor... c++ -E
checking for ld used by c++... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether the c++ linker (/usr/bin/ld) supports shared libraries... yes
checking for c++ option to produce PIC... -fPIC -DPIC
checking if c++ PIC flag -fPIC -DPIC works... yes
checking if c++ static flag -static works... yes
checking if c++ supports -c -o file.o... yes
checking if c++ supports -c -o file.o... (cached) yes
checking whether the c++ linker (/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... openbsd7.0 ld.so
checking how to hardcode library paths into programs... immediate
checking for gcc... (cached) cc
checking whether we are using the GNU C compiler... (cached) yes
checking whether cc accepts -g... (cached) yes
checking for cc option to accept ISO C89... (cached) none needed
checking whether cc understands -c and -o together... (cached) yes
checking dependency style of cc... (cached) gcc3
checking whether make sets $(MAKE)... (cached) yes
checking how to run the C preprocessor... cc -E
checking dependency style of cc... gcc3
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking for library containing dlopen... none required
checking for library containing floor... -lm
checking for _ prefix in compiled symbols... no
checking for size_t... (cached) yes
checking for working alloca.h... (cached) no
checking for alloca... (cached) yes
checking for dirent.h that defines DIR... (cached) yes
checking for library containing opendir... none required
checking for ANSI C header files... (cached) yes
checking for sys/wait.h that is POSIX.1 compatible... (cached) yes
checking for stdio.h... (cached) yes
checking for time.h... (cached) yes
checking for fcntl.h... (cached) yes
checking for float.h... (cached) yes
checking for limits.h... (cached) yes
checking for locale.h... (cached) yes
checking for malloc.h... (cached) no
checking for netdb.h... (cached) yes
checking for netinet/in.h... (cached) yes
checking for stddef.h... (cached) yes

Re: 2 diffs for dev/acpi/dsdt.c

[Daniel Dickman]

On Fri, 26 Feb 2021, YASUOKA Masahiko wrote:

> Hi,
> 
> My vaio repeatedly crashed by "Data modified on freelist"(*1) or other
> memory corruptions.  After my long time debug, I found the route cause
> is a handling of references of LocalX, like the following:
> 
> If ((SMRW (0x0B, 0x16, 0x21, RefOf (Local0)) == Zero))
> 
> In the called control method, "RefOf (Local1)" is referred as Arg3, is
> stored a value like the following:
> 
> Arg3 = \_SB.PCI0.LPCB.EC0.SMD0
> 
> In aml_store(), lvalue is reset if lvalue is a LocalX.  But since that
> was done before resolving the reference, lvalue was not reset if
> lvalue is a reference of LocalX.
> 

I can't ok the diff, but I did test that it doesn't do anything bad on one 
of my boxes if it helps

dmesg below.


--

OpenBSD 6.9-beta (GENERIC.MP) #0: Fri Feb 26 02:20:57 EST 2021
user@domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8192258048 (7812MB)
avail mem = 7928631296 (7561MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.1 @ 0xbc4b1000 (82 entries)
bios0: vendor Dell Inc. version "1.5.0" date 07/09/2018
bios0: Dell Inc. Inspiron 7375
acpi0 at bios0: ACPI 5.0Undefined scope: \\_SB_.PCI0.LPC0.EC0_

acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP UEFI SSDT SLIC MSDM SSDT CRAT CDIT UEFI ASF! BOOT HPET 
APIC MCFG SLIC WSMT VFCT IVRS SSDT SSDT SSDT SSDT FPDT SSDT BGRT
acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP2(S4) GPP3(S4) GPP4(S4) GPP5(S4) 
GPP6(S4) GP17(S4) XHC0(S0) XHC1(S0) GP18(S4) LID_(S3)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx, 1996.61 MHz, 17-11-00
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 5 2500U with Radeon Vega Mobile Gfx, 1996.26 MHz, 17-11-00
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 5 2500U with Radeon Vega Mobile Gfx, 1996.25 MHz, 17-11-00
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 5 2500U with Radeon Vega Mobile Gfx, 1996.26 MHz, 17-11-00
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 

Re: Poison file names

[Daniel Dickman]

John,

I'm now able to clone the repo from windows following this commit:
https://github.com/openbsd/src/commit/6e49571c59fe1f1e78405e5a57a1e8dc40029e00

Two caveats:
1) if you wanted to bisect the repo on windows or checkout any earlier
commit than the one above, it won't be possible to do from windows.
you'd need to get on a different filesystem.
2) there's no guarantees someone doesn't commit something in the
future that's a problem (although hopefully chances are low of that
happening)

Here's how it looked on my end from windows, only a few regress
conflicts remain, but the checkout works now.

$ git clone https://github.com/openbsd/src.git
Cloning into 'src'...
remote: Enumerating objects: 137, done.
remote: Counting objects: 100% (137/137), done.
remote: Compressing objects: 100% (102/102), done.
remote: Total 1983701 (delta 53), reused 85 (delta 35), pack-reused 1983564
Receiving objects: 100% (1983701/1983701), 1.14 GiB | 9.48 MiB/s, done.
Resolving deltas: 100% (1579758/1579758), done.
Updating files: 100% (89835/89835), done.
warning: the following paths have collided (e.g. case-sensitive paths
on a case-insensitive filesystem) and only one from the same
colliding group is in the working tree:

  'regress/usr.bin/jot/regress.wDn.out'
  'regress/usr.bin/jot/regress.wdn.out'
  'regress/usr.bin/jot/regress.wO.out'
  'regress/usr.bin/jot/regress.wo.out'
  'regress/usr.bin/jot/regress.wU.out'
  'regress/usr.bin/jot/regress.wu.out'
  'regress/usr.bin/mandoc/roff/esc/O.in'
  'regress/usr.bin/mandoc/roff/esc/o.in'
  'regress/usr.bin/mandoc/roff/esc/O.out_ascii'
  'regress/usr.bin/mandoc/roff/esc/o.out_ascii'
  'regress/usr.bin/rcs/rcs-Aflag.out'
  'regress/usr.bin/rcs/rcs-aflag.out'


On Fri, Dec 11, 2020 at 1:58 PM  wrote:
>
> I would like to be able to clone the github mirror on windows.  I do
> wind up
> using 7z on the tar file as a workaround, but it would be nice if github
> "just worked".  The com files is what the clone fails on, and those
> seemed
> easy enough to address, but if it is actually a deep rat hole, I
> certainly
> understand.
>

Re: Poison file names

[Daniel Dickman]

On Sun, Dec 13, 2020 at 7:51 PM Jonathan Gray  wrote:
>
> On Sun, Dec 13, 2020 at 03:44:54PM -0500, Daniel Dickman wrote:
> >
> >
> > On Sat, 12 Dec 2020, Jonathan Gray wrote:
> >
> > > games/battlestar/com1.c
> > > games/battlestar/com2.c
> > > games/battlestar/com3.c
> > > games/battlestar/com4.c
> > > games/battlestar/com5.c
> > > games/battlestar/com6.c
> > > games/battlestar/com7.c
> > > usr.bin/mail/aux.c
> >
> > Diff below syncs with netbsd commits from 2001 to avoid filenames that are
> > reserved on windows.
> >
> > for battlestar, rename comX.c --> commandX.c
> >
> > for mail, rename aux.c --> support.c
> >
> > ok?
>
> I don't think it is worth doing without doing all of it.

there are 3 different issues here, this is 1 of the issues which I
think should be a stand-alone commit. (note, I do have one ok so far),
are you saying you're against this one going in? If so, I won't commit
it.

I like the fact that we sync with NetBSD so for me that's the main
reason to do this one irrespective of the other 2 issues.

> regress parts
>

looks fairly straightforward to do as a second commit, but I'd imagine
ingo would likely want to weigh in about at least the mandoc bits in
regress.

> The pod names ... are less straightforward.

probably not too tough to work around, again I'd imagine marc might
want to weigh in.

Re: Poison file names

[Daniel Dickman]

On Sat, 12 Dec 2020, Jonathan Gray wrote:

> games/battlestar/com1.c
> games/battlestar/com2.c
> games/battlestar/com3.c
> games/battlestar/com4.c
> games/battlestar/com5.c
> games/battlestar/com6.c
> games/battlestar/com7.c
> usr.bin/mail/aux.c

Diff below syncs with netbsd commits from 2001 to avoid filenames that are 
reserved on windows.

for battlestar, rename comX.c --> commandX.c

for mail, rename aux.c --> support.c

ok?

(the file renames are not shown in the diff below)


Index: games/battlestar/Makefile
===
RCS file: /cvs/src/games/battlestar/Makefile,v
retrieving revision 1.10
diff -u -p -u -r1.10 Makefile
--- games/battlestar/Makefile   25 Nov 2015 23:18:11 -  1.10
+++ games/battlestar/Makefile   13 Dec 2020 20:33:50 -
@@ -1,7 +1,8 @@
 #  $OpenBSD: Makefile,v 1.10 2015/11/25 23:18:11 deraadt Exp $
 
 PROG=  battlestar
-SRCS=  battlestar.c com1.c com2.c com3.c com4.c com5.c com6.c com7.c \
+SRCS=  battlestar.c command1.c command2.c command3.c command4.c \
+   command5.c command6.c command7.c \
init.c cypher.c getcom.c parse.c room.c save.c fly.c misc.c \
globals.c dayfile.c nightfile.c dayobjs.c nightobjs.c words.c
 MAN=   battlestar.6
Index: usr.bin/mail/Makefile
===
RCS file: /cvs/src/usr.bin/mail/Makefile,v
retrieving revision 1.12
diff -u -p -u -r1.12 Makefile
--- usr.bin/mail/Makefile   16 Sep 2018 02:38:57 -  1.12
+++ usr.bin/mail/Makefile   13 Dec 2020 20:33:50 -
@@ -1,7 +1,7 @@
 #  $OpenBSD: Makefile,v 1.12 2018/09/16 02:38:57 millert Exp $
 
 PROG=  mail
-SRCS=  version.c aux.c cmd1.c cmd2.c cmd3.c cmdtab.c collect.c \
+SRCS=  version.c support.c cmd1.c cmd2.c cmd3.c cmdtab.c collect.c \
edit.c fio.c head.c v7.local.c lex.c list.c main.c names.c \
popen.c quit.c send.c strings.c temp.c tty.c vars.c
 SFILES=mail.help mail.tildehelp

Re: Poison file names

[Daniel Dickman]

On Wed, Dec 9, 2020 at 4:50 AM Jonathan Gray  wrote:
>
> On Tue, Dec 08, 2020 at 11:36:37PM -0700, jo...@armadilloaerospace.com wrote:
> > The game battlestar has source files names com1.c through com7.c, which
> > are illegal on windows due to ancient dos com port rules.
> >
> > I understand there might not be much sympathy for that, but being able
> > to have the full source tree on a windows system can be convenient, and
> > it should be a painless change.
> >
> > Any chance someone could do that rename in the repository and change
> > the Makefile?
>
> NetBSD renamed them all to command for that reason.
>
> https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file
>
> usr.sbin/pkg_add/pod/OpenBSD::*.pod would also be a problem due to colons
>

Hi John, maybe you can say more how you're getting the files to a
windows system? If we rename the battlestar files, and given it won't
completely solve things for you as jsg@ points out, does it make any
difference for you?

I do this myself too from time to time by extracting the src.tar.gz
using 7z (https://www.7-zip.org/). That tool seems to automatically
rename the comX.c files to _comX.c. And for the pod files it seems to
automatically replace the invalid ":" characters with "_".

The only annoyance I have left is that there are a small number of
remaining conflicts from upper/lower case on unix vs windows.

Bottom line, for me extracting with 7z and just pressing
"automatically rename" on the first conflict seems to work as all
those conflicting filenames are for things I really don't look at on
my windows box.

But maybe you could tell us more if changing battlestar would
partially improve things for you? Either way, I don't object to
syncing battlestar with netbsd's 2001 commit.

Re: [PATCH] Add IOMMU support for Intel VT-d and AMD-Vi

[Daniel Dickman]

> [PATCH] Add IOMMU support for Intel VT-d and AMD Vi
>
> This hooks each pci device and overrides bus_dmamap_xxx to issue
> remap of DMA requests to virtual DMA space.  It protects devices
> from issuing I/O requests to memory in the system that is outside
> the requested DMA space.

Hi Jordan, thanks for working on this. I would like to see iommu 
support...

> + uint64_tefr;
> + uint8_t reserved[8];
> +} __packd;

...that being said, is the above a typo?

atheros pcidevs

[Daniel Dickman]

Looking to add a few Atheros devices to pcidevs. ok?

Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1928
diff -u -p -u -r1.1928 pcidevs
--- pcidevs 30 Jun 2020 04:37:24 -  1.1928
+++ pcidevs 18 Jul 2020 16:53:55 -
@@ -1081,6 +1081,7 @@ product ATHEROS AR5212_7  0x0019  AR5212
 product ATHEROS AR2413 0x001a  AR2413
 product ATHEROS AR5413 0x001b  AR5413
 product ATHEROS AR5424 0x001c  AR5424
+product ATHEROS AR2417 0x001d  AR2417
 product ATHEROS AR5416 0x0023  AR5416
 product ATHEROS AR5418 0x0024  AR5418
 product ATHEROS AR9160 0x0027  AR9160
@@ -1095,6 +1096,9 @@ product ATHEROS AR94850x0032  AR9485
 product ATHEROS AR9462 0x0034  AR9462
 product ATHEROS AR9565 0x0036  AR9565
 product ATHEROS QCA988X0x003c  QCA986x/988x
+product ATHEROS QCA61740x003e  QCA6174
+product ATHEROS QCA61640x0041  QCA6164
+product ATHEROS QCA93770x0042  QCA9377
 product ATHEROS AR5210_AP  0x0207  AR5210
 product ATHEROS AR5212_IBM 0x1014  AR5212
 product ATHEROS AR5210_DEFAULT 0x1107  AR5210

Re: problems with libm

[Daniel Dickman]

> On Jul 1, 2019, at 2:50 AM, Moritz Buhl  wrote:
> 
> Hi,
> 
> while testing arm hardware on OpenBSD I noticed that some floating point
> operations cause failures of other tests.
> In fact the current libm is incorrect according to the ISO C Std Annex
> G. I found this out after porting some FreeBSD lib msun tests. Many edge
> cases for complex floating point operations are not covered at all.

You’re saying that OpenBSD complex functions in libm may have some rough edges? 
Sounds right to me.

In the past I’ve found running the numpy regress tests to be a decent suite of 
tests for libm. I remember the last time I looked at the remaining failures 
they were mostly related to complex math from what I could tell.

I can share my wip update of numpy 1.16.4 if you’d be interesting in these 
tests on arm. In fact I would be interested in the results from that platform...

> 
> My question on this is what I should do about this. Port the FreeBSD
> msun library? Ignore the problem? Patch the current implementation?

Patches to correct the current code would be very welcome. (In my case 
especially if it improves numpy test results).

> 
> I attached a test that is currently breaking. There are many more. To
> fix these I just copied the FreeBSD file that implements the failing
> function. But I am not sure if this is a good approach.

I’ll take a look at this on some of the platforms I have access to, but arm is 
not a platform I own. In my experience, the failures can be platform dependent 
so we’ll see if I can reproduce elsewhere or not.

In general it would be useful to send minimal code illustrating failures and 
then show the outputs on the platform you’re testing.

Here’s an example libm problem report you could use as a template for reporting 
problems if you’d like:

https://marc.info/?l=openbsd-tech=140167886413618=2

> 
> mbuhl
> 
> Index: regress/lib/libm/msun/Makefile
> ===
> RCS file: /cvs/src/regress/lib/libm/msun/Makefile,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 Makefile
> --- regress/lib/libm/msun/Makefile21 Feb 2019 16:14:03 -1.1.1.1
> +++ regress/lib/libm/msun/Makefile31 May 2019 19:50:32 -
> @@ -1,6 +1,7 @@
> # $OpenBSD: Makefile,v 1.1.1.1 2019/02/21 16:14:03 bluhm Exp $
> 
> TESTS =
> +TESTS +=cexp_test
> TESTS +=conj_test
> TESTS +=fenv_test
> TESTS +=lrint_test
> Index: regress/lib/libm/msun/cexp_test.c
> ===
> RCS file: regress/lib/libm/msun/cexp_test.c
> diff -N regress/lib/libm/msun/cexp_test.c
> --- /dev/null1 Jan 1970 00:00:00 -
> +++ regress/lib/libm/msun/cexp_test.c1 Jun 2019 05:40:51 -
> @@ -0,0 +1,326 @@
> +/*-
> + * Copyright (c) 2008-2011 David Schultz 
> + * 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.
> + */
> +
> +/*
> + * Tests for corner cases in cexp*().
> + */
> +
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "test-utils.h"
> +
> +#pragma STDC FENV_ACCESSON
> +#pragmaSTDC CX_LIMITED_RANGEOFF
> +
> +/*
> + * Test that a function returns the correct value and sets the
> + * exception flags correctly. The exceptmask specifies which
> + * exceptions we should check. We need to be lenient for several
> + * reasons, but mainly because on some architectures it's impossible
> + * to raise FE_OVERFLOW without raising FE_INEXACT. In some cases,
> + * whether cexp() raises an invalid exception is unspecified.
> + *
> + * These are macros instead of functions so that assert provides more
> + * 

add core4g thermal id to pcidevs

[Daniel Dickman]

Add core 4g thermal id from one of my systems. ok?


Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1866
diff -u -p -u -r1.1866 pcidevs
--- pcidevs 8 Nov 2018 06:54:13 -   1.1866
+++ pcidevs 10 Nov 2018 20:53:00 -
@@ -3092,6 +3092,7 @@ product INTEL 80960RM 0x0962  i960 RM
 product INTEL 80960RN  0x0964  i960 RN
 product INTEL NVME 0x0953  NVMe
 product INTEL CORE4G_D_ULT_GT1 0x0a02  HD Graphics
+product INTEL CORE4G_THERM 0x0a03  Core 4G Thermal
 product INTEL CORE4G_HB_1  0x0a04  Core 4G Host
 product INTEL CORE4G_M_ULT_GT1 0x0a06  HD Graphics
 product INTEL CORE4G_S_ULT_GT1 0x0a0a  HD Graphics

[patch] remove mention of sbrk from csh(1)

[Daniel Dickman]

sync the text in csh(1) with text from getrlimit(2) and remove mention of 
sbrk.

ok?

Index: csh.1
===
RCS file: /cvs/src/bin/csh/csh.1,v
retrieving revision 1.79
diff -u -p -u -r1.79 csh.1
--- csh.1   12 Dec 2017 11:34:38 -  1.79
+++ csh.1   10 Nov 2018 18:44:27 -
@@ -1852,9 +1852,7 @@ the maximum number of CPU-seconds to be 
 .It Ar filesize
 the largest single file (in bytes) that can be created.
 .It Ar datasize
-the maximum growth of the data+stack region via
-.Xr sbrk  2
-beyond the end of the program text.
+the maximum growth (in bytes) of the data segment.
 .It Ar stacksize
 the maximum
 size of the automatically-extended stack region.

[patch] remove sbrk from mkhybrid

[Daniel Dickman]

Below patch removes use of sbrk from mkhybrid.

sbrk is only used here when mkhybrid is run in verbose mode to print a 
diagnostic (see src/mkisofs.c).

ok?


Index: src/config.h
===
RCS file: /cvs/src/gnu/usr.sbin/mkhybrid/src/config.h,v
retrieving revision 1.1
diff -u -p -u -r1.1 config.h
--- src/config.h10 Oct 2000 20:40:12 -  1.1
+++ src/config.h10 Nov 2018 18:33:54 -
@@ -20,7 +20,7 @@
 #define HAVE_MEMMOVE 1
 
 /* Define if you have the sbrk function.  */
-#define HAVE_SBRK 1
+/* #undef HAVE_SBRK */
 
 /* Define if you have the  header file.  */
 #define HAVE_DIRENT_H 1

Re: tcsh -- build without sbrk

[Daniel Dickman]

(dropping ports@)

> On Nov 5, 2018, at 9:22 AM, Marc Espie  wrote:
> 
>> On Mon, Nov 05, 2018 at 09:15:28AM -0500, Daniel Dickman wrote:
>>   gcc uses them for precompiled headers (PCH) which is a local diff added
>>   by kurt@ in 2009. its likely nothing in base uses PCH but i don't know
>>   what in ports needs this:
> 
> This has always been a mess. I suspect it's not really important these days
> because pch only make sense for large C++ codebases, which are definitely
> not going to be happy with the gcc from base anyway.
> 
> There is also some snippet using sbrk to avoid malloc in gmon.c.
> 
> That might be more of an issue...

i did not run into anything else when i compiled base gcc on an i386 system 
with a modified libc. looked to me like just the pch functionality, although 
we’d need to test every platform to be certain, i guess.

> 
>>   [3]https://github.com/openbsd/src/commit/cfee5d1
>> 
>>   choices there would be to disable PCH support or maybe there's a
>>   different way to reimplement without brk/sbrk.
> 
>>   clang looks like they have a HAVE_SBRK ifdef or something like that. so
>>   usage can likely be turned off but i don't know this codebase that well
>>   so that's just an assumption.
> 
> Yep, I'll have to look.


let me know if you want me to test any llvm diffs on my system.

Re: tcsh -- build without sbrk

[Daniel Dickman]

> On Nov 5, 2018, at 8:47 AM, Marc Espie  wrote:
> 
>> On Mon, Nov 05, 2018 at 08:43:56AM -0500, Daniel Dickman wrote:
>> 
>> 
>>> On Nov 5, 2018, at 8:30 AM, Marc Espie  wrote:
>>> 
>>> Or we could just finally remove brk and sbrk from the libc ?
>>> 
>>> 
>> 
>> you won’t get very far. they are still needed in base (gcc, clang, mkhybrid).
> 
> The big question is, are they still *needed* or do those tools just *use them
> if they find them*.


mkhybrid is an easy diff.

gcc uses them for precompiled headers (PCH) which is a local diff added by 
kurt@ in 2009. its likely nothing in base uses PCH but i don’t know what in 
ports needs this:
https://github.com/openbsd/src/commit/cfee5d1

choices there would be to disable PCH support or maybe there’s a different way 
to reimplement without brk/sbrk.

clang looks like they have a HAVE_SBRK ifdef or something like that. so usage 
can likely be turned off but i don’t know this codebase that well so that’s 
just an assumption.

Re: Status of openbsd/macppc port?

[Daniel Dickman]

> On Aug 17, 2018, at 8:37 AM, Solene Rapenne  wrote:
> 
> The sad state is that less and less
> ports are running on them.
> 

The last package count for 6.3 shows macppc had the most packages after amd64 
and i386.

Can you share examples of ports you’re missing? I’d be interested to look at 
anything that’s not working (and doesn’t take 3 weeks to build).

ps. numpy on macppc was broken for a short period of time which took out part 
of the tree, but that is fixed as far as i know. see this thread:
https://marc.info/?t=15321658432=1=2

Re: Status of openbsd/macppc port?

[Daniel Dickman]

On Fri, Aug 17, 2018 at 8:48 AM, Mark Cave-Ayland
 wrote:
> On 17/08/18 13:34, Jonathan Gray wrote:
>
>> On Fri, Aug 17, 2018 at 12:15:10PM +0100, Mark Cave-Ayland wrote:
>>> Hi all,
>>>
>>> I was just wondering what is the current state of the openbsd/macppc
>>> port? As part of my recent work on qemu-system-ppc I now have a patch
>>> that can boot OpenBSD macppc under the New World (-M mac99,via=pmu)
>>> machine but I'm seeing quite a bit of instability in OpenBSD compared to
>>> all my other test OSs.
>>>
>>> For those that are interested I have included screenshots below:
>>>
>>> OpenBSD 6.3
>>> - Hangs just after USB detection
>>> - https://www.ilande.co.uk/tmp/qemu/openbsd-6.3.png
>>>
>>> OpenBSD 6.2
>>> - Panics just after USB detection
>>> - https://www.ilande.co.uk/tmp/qemu/openbsd-6.2.png
>>>
>>> OpenBSD 6.1
>>> - Boots all the way to the installer but causes qemu-system-ppc to
>>> terminate fairly easily after pressing a few keys with "qemu: fatal:
>>> ERROR: instruction should not need address translation"
>>> - https://www.ilande.co.uk/tmp/qemu/openbsd-6.1.png
>>>
>>> Note I also get a constant stream of messages on the console related to
>>> OpenPIC:
>>>
>>> qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f
>>> qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f
>>> qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f
>>> qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f
>>> qemu-system-ppc: openpic_iack: bad raised IRQ 28 ctpr 8 ivpr 0x4045001c
>>> qemu-system-ppc: openpic_iack: bad raised IRQ 28 ctpr 8 ivpr 0x4045001c
>>> qemu-system-ppc: openpic_iack: bad raised IRQ 28 ctpr 8 ivpr 0x4045001c
>>> etc.
>>>
>>>
>>> Obviously I can't categorically state that QEMU's emulation is perfect,
>>> but it can now reliably run all of Linux, MacOS, NetBSD and FreeBSD in
>>> my local tests which makes me suspect that OpenBSD is trying to do
>>> something different here.
>>
>> Builds are done natively on real hardware (xserves).  Your work on
>> qemu-system-ppc would be improved by being able to compare to a real
>> machine while it is still possible to find some that work.  You could
>> search bugs@ but I don't believe any of those problems have been reported
>> running on actual macppc machines.
>
> Thanks for information. I guess there is a difference between being able
> to build and run the guest OS - for example do the builds get regularly
> tested on any Sawtooth-type PowerMac3,1 machines (which is effectively
> what QEMU is trying to emulate)?
>

Hi Mark,

I regularly run macppc. Here's my dmesg from a PowerMac10,2 which is a
Mac Mini G4 and where I do all my ports building:
http://dickman.org/openbsd/dmesg/dmesg.macppc

I also have other macppc hardware which runs quite well. The only
problem case is my G5 where the hard drive does not get detected.

Hope this helps.

Re: head(1) -c

[Daniel Dickman]

On Wed, Mar 9, 2016 at 9:35 PM, Michael McConville  wrote:
> Jeremie Courreges-Anglas wrote:
>> >> @@ -66,13 +66,18 @@ main(int argc, char *argv[])
>> >>argv++;
>> >>}
>> >>
>> >> -  while ((ch = getopt(argc, argv, "n:")) != -1) {
>> >> +  while ((ch = getopt(argc, argv, "c:n:")) != -1) {
>> >>switch (ch) {
>> >> +  case 'c':
>> >> +  dobytes = 1;
>> >> +  p = optarg;
>> >> +  break;
>> >>case 'n':
>> >> +  dobytes = 0;
>> >
>> > It's already initialized to 0, which is necessary for the head -count
>> > style syntax.
>>
>> I followed the behavior of GNU head here: the last specified option
>> wins.  IIRC FreeBSD head(1) makes -c and -n incompatible.
>
> I feel like erroring on multiple options would be an improvement. I
> guess I can propose that as a separate diff when you're done.
>

I don't think erroring would be expected behaviour.

I think jca@ has the right approach (especially if it matches what
FreeBSD and others do in this case). Some posix tools say what they do
in this case with text like this:
"...the last option specified in each set shall determine the output."

The equivalent in our man pages is text like:

"It is not an error to specify more than one of the following mutually
exclusive options..."

"Where more than one option is specified from the same mutually
exclusive group, the last option given overrides the others"

(e.g. man df, man ls, etc).

Re: Does grep need a version?

[Daniel Dickman]

you're missing at least the removal of the flag in the standards section of the 
man page.

I agree with deraadt though, this needs a check of ports.

> On Dec 8, 2015, at 12:06 AM, Michael McConville  wrote:
> 
> It's been 0.9 since the original import in 2003...
> 
> 
> Index: grep.1
> ===
> RCS file: /cvs/src/usr.bin/grep/grep.1,v
> retrieving revision 1.43
> diff -u -p -r1.43 grep.1
> --- grep.113 Jan 2015 04:45:34 -1.43
> +++ grep.18 Dec 2015 04:59:35 -
> @@ -244,9 +244,6 @@ Nonexistent and unreadable files are ign
> (i.e. their error messages are suppressed).
> .It Fl U
> Search binary files, but do not attempt to print them.
> -.It Fl V
> -Display version information.
> -All other options are ignored.
> .It Fl v
> Selected lines are those
> .Em not
> Index: grep.c
> ===
> RCS file: /cvs/src/usr.bin/grep/grep.c,v
> retrieving revision 1.55
> diff -u -p -r1.55 grep.c
> --- grep.c28 Nov 2015 01:17:12 -1.55
> +++ grep.c8 Dec 2015 04:59:35 -
> @@ -137,7 +137,6 @@ static const struct option long_options[
>{"basic-regexp",no_argument,NULL, 'G'},
>{"with-filename",no_argument,NULL, 'H'},
>{"binary",no_argument,NULL, 'U'},
> -{"version",no_argument,NULL, 'V'},
>{"text",no_argument,NULL, 'a'},
>{"byte-offset",no_argument,NULL, 'b'},
>{"count",no_argument,NULL, 'c'},
> @@ -328,10 +327,6 @@ main(int argc, char *argv[])
>break;
>case 'U':
>binbehave = BIN_FILE_BIN;
> -break;
> -case 'V':
> -fprintf(stderr, "grep version %u.%u\n", VER_MAJ, VER_MIN);
> -exit(0);
>break;
> #ifndef NOZ
>case 'Z':
> Index: grep.h
> ===
> RCS file: /cvs/src/usr.bin/grep/grep.h,v
> retrieving revision 1.23
> diff -u -p -r1.23 grep.h
> --- grep.h7 Dec 2015 18:50:06 -1.23
> +++ grep.h8 Dec 2015 04:59:35 -
> @@ -34,9 +34,6 @@
> #include 
> #include 
> 
> -#define VER_MAJ 0
> -#define VER_MIN 9
> -
> #define BIN_FILE_BIN0
> #define BIN_FILE_SKIP1
> #define BIN_FILE_TEXT2
> 

Re: Wrong return type in uvm(9)

[Daniel Dickman]

On Thu, Oct 29, 2015 at 10:31 PM, Michael McConville  wrote:
> This one confused me for a few minutes. See sys/uvm/uvm_user.c for the
> function definition.
>
> ok?

looks like it's been out of sync since r1.10 in 2002.

ok.

>
>
> Index: share/man/man9/uvm.9
> ===
> RCS file: /cvs/src/share/man/man9/uvm.9,v
> retrieving revision 1.60
> diff -u -p -r1.60 uvm.9
> --- share/man/man9/uvm.915 Jan 2015 21:19:22 -  1.60
> +++ share/man/man9/uvm.930 Oct 2015 02:29:52 -
> @@ -131,7 +131,7 @@ function initialises the swap subsystem.
>  .Fn uvm_map_checkprot "vm_map_t map" "vaddr_t start" "vaddr_t end" 
> "vm_prot_t protection"
>  .Ft int
>  .Fn uvm_map_protect "vm_map_t map" "vaddr_t start" "vaddr_t end" "vm_prot_t 
> new_prot" "boolean_t set_max"
> -.Ft int
> +.Ft void
>  .Fn uvm_deallocate "vm_map_t map" "vaddr_t start" "vsize_t size"
>  .Ft struct vmspace *
>  .Fn uvmspace_alloc "vaddr_t min" "vaddr_t max" "boolean_t pageable" 
> "boolean_t remove_holes"
>

Re: Don't allow "rm -rf /"

[Daniel Dickman]

committed with a minor tweak Thanks!

>
> Do I miss something simpler?
>
> Index: bin/rm/rm.1
> ===
> RCS file: /var/cvs/src/bin/rm/rm.1,v
> retrieving revision 1.37
> diff -u -p -r1.37 rm.1
> --- bin/rm/rm.1 25 May 2014 19:07:36 -  1.37
> +++ bin/rm/rm.1 22 Aug 2015 21:49:02 -
> @@ -102,6 +102,7 @@ The
>  utility removes symbolic links, not the files referenced by the links.
>  .Pp
>  It is an error to attempt to remove the files
> +.Dq / ,
>  .Dq \&.
>  or
>  .Dq .. .
> Index: bin/rm/rm.c
> ===
> RCS file: /var/cvs/src/bin/rm/rm.c,v
> retrieving revision 1.30
> diff -u -p -r1.30 rm.c
> --- bin/rm/rm.c 16 Jan 2015 06:39:32 -  1.30
> +++ bin/rm/rm.c 23 Aug 2015 11:52:28 -
> @@ -54,7 +54,7 @@ extern char *__progname;
>  int dflag, eval, fflag, iflag, Pflag, stdin_ok;
>
>  intcheck(char *, char *, struct stat *);
> -void   checkdot(char **);
> +void   checkdotorslash(char **);
>  void   rm_file(char **);
>  intrm_overwrite(char *, struct stat *);
>  intpass(int, off_t, char *, size_t);
> @@ -105,7 +105,7 @@ main(int argc, char *argv[])
> if (argc < 1 && fflag == 0)
> usage();
>
> -   checkdot(argv);
> +   checkdotorslash(argv);
>
> if (*argv) {
> stdin_ok = isatty(STDIN_FILENO);
> @@ -383,12 +383,12 @@ check(char *path, char *name, struct sta
>   */
>  #define ISDOT(a)   ((a)[0] == '.' && (!(a)[1] || ((a)[1] == '.' && 
> !(a)[2])))
>  void
> -checkdot(char **argv)
> +checkdotorslash(char **argv)
>  {
> char *p, **save, **t;
> -   int complained;
> +   int dotcomplained, slashcomplained;
>
> -   complained = 0;
> +   dotcomplained = slashcomplained = 0;
> for (t = argv; *t;) {
> /* strip trailing slashes */
> p = strrchr (*t, '\0');
> @@ -402,14 +402,20 @@ checkdot(char **argv)
> p = *t;
>
> if (ISDOT(p)) {
> -   if (!complained++)
> +   if (!dotcomplained++)
> warnx("\".\" and \"..\" may not be removed");
> -   eval = 1;
> -   for (save = t; (t[0] = t[1]) != NULL; ++t)
> -   continue;
> -   t = save;
> -   } else
> +   } else if (*p == '\0') {
> +   if (!slashcomplained++)
> +   warnx("\"/\" may not be removed");
> +   } else {
> ++t;
> +   continue;
> +   }
> +
> +   eval = 1;
> +   for (save = t; (t[0] = t[1]) != NULL; ++t)
> +   continue;
> +   t = save;
> }
>  }
>
>

Re: Brainy: a few bugs

[Daniel Dickman]

On Fri, Sep 11, 2015 at 3:18 PM, Maxime Villard  wrote:
>
> _19/ UNINITIALIZED VARIABLE: sys/arch/i386/i386/bios.c rev1.112
>

Fixed. Thanks.

Re: ed(1): keep custom prompt string that was specified by -p

[Daniel Dickman]

On Thu, Jun 18, 2015 at 10:18 AM, Jason McIntyre j...@kerhand.co.uk wrote:
 On Thu, Jun 18, 2015 at 03:56:15PM +0200, Theo Buehler wrote:

 From looking at the source code, I'm quite sure that the other BSD's
 behavior is the same as the current behavior in OpenBSD.

 I agree that the formulations in the manpages and POSIX aren't explicit,
 let alone unambiguous, as to what exactly is supposed to happen when
 pressing P.

 However, what POSIX claims about P being a synonym of p is bogus:

 *  BSD does not support the P command; moreover, in BSD it is
synonymous with the p command.

 Compare this with the following session:

 $ ed
 p
 ?
 P
 *p
 ?
 *P
 q
 $

 The source code in FreeBSD and NetBSD shows that the print command p
 and the prompt command P are treated completely differently there as
 well.


 the posix stuff no doubt relates to traditional bsd behaviour. obviously
 P is now supported.

 if other systems behave this way and no one steps up to support the idea
 of changing behaviour, i'll add a note to the doc. but i'll wait and see
 first.

 jmc


I think Theo's proposed change is correct.

ok daniel@

Re: Brainy: OpenSSH Memory Leak

[Daniel Dickman]

On Sat, Sep 20, 2014 at 3:07 PM, Maxime Villard m...@m00nbsd.net wrote:
 Hi,
 I put here a bug among others:

 Index: ssh-ed25519.c
 ===
 RCS file: /cvs/src/usr.bin/ssh/ssh-ed25519.c,v
 retrieving revision 1.4
 diff -u -r1.4 ssh-ed25519.c
 --- ssh-ed25519.c   24 Jun 2014 01:13:21 -  1.4
 +++ ssh-ed25519.c   29 Aug 2014 10:28:35 -
 @@ -125,8 +125,10 @@
 r = SSH_ERR_INVALID_FORMAT;
 goto out;
 }
 -   if (datalen = SIZE_MAX - len)
 -   return SSH_ERR_INVALID_ARGUMENT;
 +   if (datalen = SIZE_MAX - len) {
 +   r = SSH_ERR_INVALID_ARGUMENT;
 +   goto out;
 +   }
 smlen = len + datalen;
 mlen = smlen;
 if ((sm = malloc(smlen)) == NULL || (m = xmalloc(mlen)) == NULL) {

 Found by my code scanner.

 Maxime


applied. thanks.

Re: [patch]lock and unlock like GnuRCS

[Daniel Dickman]

Fritjof, have you let the gnu rcs project know about the segfault?
Maybe see how they choose to fix things and then follow their lead?


On Mon, Oct 6, 2014 at 10:47 AM, Nicholas Marriott
nicholas.marri...@gmail.com wrote:

 I think that GNU RCS segfaulting for -u -l is enough justification to do
 what we like, so a message (and last flag wins) like -L/-U would be fine
 with me.

 But if we want to do what they probably meant to happen then better to
 match -l -u like Fritjof's diff.


 On Fri, Oct 03, 2014 at 12:55:35PM +0200, Otto Moerbeek wrote:
  On Thu, Oct 02, 2014 at 12:56:10AM +0100, Nicholas Marriott wrote:
 
  
   OTOH, check out what we do with rcs -L and -U...
 
  I kinda like that, because it tells you exactly what it is doing.
 
-Otto
 
  
  
   On Thu, Oct 02, 2014 at 12:54:13AM +0100, Nicholas Marriott wrote:
Matching GNU RCS seems preferable to me but I don't feel strongly about
it.
   
I wouldn't mention this in the man page, it hardly seems like behaviour
anyone should (or will need to) rely on.
   
   
On Wed, Oct 01, 2014 at 07:41:52PM -0400, Daniel Dickman wrote:
 posix commands (like ls(1) for example) keep the last option when 
 mutually exclusive options are specified. does it make sense to keep 
 rcs consistent with that convention? also is a man page diff needed?


  On Oct 1, 2014, at 7:17 PM, Nicholas Marriott 
  nicholas.marri...@gmail.com wrote:
 
  The existing behaviour isn't wildly useful, makes sense to me, ok 
  nicm
 
 
  On Wed, Oct 01, 2014 at 11:33:33PM +0200, Fritjof Bornebusch wrote:
  Hi tech,
 
  the OpenRCS rcs command produces the following output if -l and -u 
  is
  used in the same command:
 
  $ rcs -l1.1 -u1.1 foo.txt
  RCS file: foo.txt,v
  1.1 locked
  1.1 unlocked
 
  $ rcs -u1.1 -l1.1 foo.txt
  RCS file: foo.txt,v
  1.1 locked
  1.1 unlocked
 
  I've looked at GnuRCS and it has another way to handle these 
  parameters
  (it seems the other BSDs use GnuRCS, too).
 
  Debian 7.5:
  $ rcs -l1.1 -u1.1 foo.txt
  RCS file: foo.txt,v
  rcs: foo.txt,v: no lock set on revision 1.1
  1.1 locked
 
  $ rcs -u1.1 -l1.1 foo.txt
  Segmentation fault
 
  Well, I think the Segmentation fault isn't that important :), 
  but GnuRCS
  does not lock and unlock a file by using the same command like 
  OpenRCS.
 
  I think the different implementations of RCS should share the same
  behaviour:
 
  $ rcs -l1.1 -u1.1 foo.txt
  RCS file: foo.txt,v
  1.1 locked
  done
 
  $ rcs -u1.1 -l1.1 foo.txt
  RCS file: foo.txt,v
  1.1 unlocked
  done
 
  fritjof
 
 
  Index: rcsprog.c
  ===
  RCS file: /cvs/src/usr.bin/rcs/rcsprog.c,v
  retrieving revision 1.151
  diff -u -p -r1.151 rcsprog.c
  --- rcsprog.c12 Jul 2011 21:00:32 -1.151
  +++ rcsprog.c3 Aug 2014 15:42:34 -
  @@ -234,9 +234,10 @@ rcs_main(int argc, char **argv)
 lkmode = RCS_LOCK_STRICT;
 break;
 case 'l':
  -/* XXX - Check with -u flag. */
  -lrev = rcs_optarg;
  -rcsflags |= RCSPROG_LFLAG;
  +if (!(rcsflags  RCSPROG_UFLAG)) {
  +lrev = rcs_optarg;
  +rcsflags |= RCSPROG_LFLAG;
  +}
 break;
 case 'm':
 if (logstr != NULL)
  @@ -272,9 +273,10 @@ rcs_main(int argc, char **argv)
 lkmode = RCS_LOCK_LOOSE;
 break;
 case 'u':
  -/* XXX - Check with -l flag. */
  -urev = rcs_optarg;
  -rcsflags |= RCSPROG_UFLAG;
  +if (!(rcsflags  RCSPROG_LFLAG)) {
  +urev = rcs_optarg;
  +rcsflags |= RCSPROG_UFLAG;
  +}
 break;
 case 'V':
 printf(%s\n, rcs_version);
 

Re: [patch]lock and unlock like GnuRCS

[Daniel Dickman]

On Tue, Oct 7, 2014 at 3:34 AM, Otto Moerbeek o...@drijf.net wrote:
 On Tue, Oct 07, 2014 at 03:10:44AM -0400, Daniel Dickman wrote:

 Fritjof, have you let the gnu rcs project know about the segfault?
 Maybe see how they choose to fix things and then follow their lead?

 That will only slow things down. Do what -L -U does is better, imo.

 -Otto

between the 2 choices this would be my choice too.

Re: [patch]lock and unlock like GnuRCS

[Daniel Dickman]

posix commands (like ls(1) for example) keep the last option when mutually 
exclusive options are specified. does it make sense to keep rcs consistent with 
that convention? also is a man page diff needed?


 On Oct 1, 2014, at 7:17 PM, Nicholas Marriott nicholas.marri...@gmail.com 
 wrote:
 
 The existing behaviour isn't wildly useful, makes sense to me, ok nicm
 
 
 On Wed, Oct 01, 2014 at 11:33:33PM +0200, Fritjof Bornebusch wrote:
 Hi tech,
 
 the OpenRCS rcs command produces the following output if -l and -u is 
 used in the same command:
 
 $ rcs -l1.1 -u1.1 foo.txt
 RCS file: foo.txt,v
 1.1 locked
 1.1 unlocked
 
 $ rcs -u1.1 -l1.1 foo.txt
 RCS file: foo.txt,v
 1.1 locked
 1.1 unlocked
 
 I've looked at GnuRCS and it has another way to handle these parameters 
 (it seems the other BSDs use GnuRCS, too).
 
 Debian 7.5:
 $ rcs -l1.1 -u1.1 foo.txt
 RCS file: foo.txt,v
 rcs: foo.txt,v: no lock set on revision 1.1
 1.1 locked
 
 $ rcs -u1.1 -l1.1 foo.txt
 Segmentation fault
 
 Well, I think the Segmentation fault isn't that important :), but GnuRCS 
 does not lock and unlock a file by using the same command like OpenRCS.
 
 I think the different implementations of RCS should share the same 
 behaviour:
 
 $ rcs -l1.1 -u1.1 foo.txt
 RCS file: foo.txt,v
 1.1 locked
 done
 
 $ rcs -u1.1 -l1.1 foo.txt
 RCS file: foo.txt,v
 1.1 unlocked
 done
 
 fritjof
 
 
 Index: rcsprog.c
 ===
 RCS file: /cvs/src/usr.bin/rcs/rcsprog.c,v
 retrieving revision 1.151
 diff -u -p -r1.151 rcsprog.c
 --- rcsprog.c12 Jul 2011 21:00:32 -1.151
 +++ rcsprog.c3 Aug 2014 15:42:34 -
 @@ -234,9 +234,10 @@ rcs_main(int argc, char **argv)
lkmode = RCS_LOCK_STRICT;
break;
case 'l':
 -/* XXX - Check with -u flag. */
 -lrev = rcs_optarg;
 -rcsflags |= RCSPROG_LFLAG;
 +if (!(rcsflags  RCSPROG_UFLAG)) {
 +lrev = rcs_optarg;
 +rcsflags |= RCSPROG_LFLAG;
 +}
break;
case 'm':
if (logstr != NULL)
 @@ -272,9 +273,10 @@ rcs_main(int argc, char **argv)
lkmode = RCS_LOCK_LOOSE;
break;
case 'u':
 -/* XXX - Check with -l flag. */
 -urev = rcs_optarg;
 -rcsflags |= RCSPROG_UFLAG;
 +if (!(rcsflags  RCSPROG_LFLAG)) {
 +urev = rcs_optarg;
 +rcsflags |= RCSPROG_UFLAG;
 +}
break;
case 'V':
printf(%s\n, rcs_version);
 

possible bug in asinhl on sparc64 (libm)

[Daniel Dickman]

according to the numpy developers asinhl on sparc64 might be buggy. I
haven't worked out a test case yet but just reporting in case anyone else
wants to take a look as well.

bug report:
https://github.com/numpy/numpy/issues/5026#issuecomment-54711361

lynx: disable old protocols

[Daniel Dickman]

Patch below turns off the following ancient protocols built into lynx: 
bibp, finger, gopher, and news.

For some urls, lynx will invoke an external command. Turn off telnet, 
rlogin and tn3270 urls by defining them to false(1) as documented in the 
lynx manual.

Finally, turn off the file editor which can be accessed with g.enter 
using the --disable-dired switch.

ok to commit?

Index: Makefile.bsd-wrapper
===
RCS file: /home/cvs/src/gnu/usr.bin/lynx/Makefile.bsd-wrapper,v
retrieving revision 1.24
diff -u -p -u -r1.24 Makefile.bsd-wrapper
--- Makefile.bsd-wrapper15 Apr 2014 20:55:42 -  1.24
+++ Makefile.bsd-wrapper11 Jul 2014 02:47:31 -
@@ -5,7 +5,10 @@ CLEANFILES+= lynx.1
 DPADD= ${LIBSSL} ${LIBCRYPTO}
 
 GNUCFLAGS= CC=${CC} CFLAGS=${CFLAGS} ${COPTS} ${OPT} 
LDFLAGS=${LDFLAGS}
-CONFIGURE_ARGS= --with-ssl=/usr --enable-widec --enable-ipv6 --enable-debug
+CONFIGURE_ARGS= --with-ssl=/usr --enable-widec --enable-ipv6 --enable-debug \
+   --disable-bibp-urls --disable-finger --disable-gopher 
--disable-news \
+   --disable-dired
+
 HTMLDIR=   /usr/share/doc/html
 HELPFILES= keystrokes/alt_edit_help.html keystrokes/bookmark_help.html \
keystrokes/cookie_help.html keystrokes/dired_help.html \
@@ -39,12 +42,18 @@ config: .FORCE
PATH=/bin:/usr/bin:/sbin:/usr/sbin \
${GNUCFLAGS} \
INSTALL_PROGRAM=${INSTALL} ${INSTALL_COPY} ${INSTALL_STRIP} \
+   TELNET=/usr/bin/false \
+   RLOGIN=/usr/bin/false \
+   TN3270=/usr/bin/false \
sh ${.CURDIR}/configure --prefix=/usr --sysconfdir=/etc 
--disable-color-style ${CONFIGURE_ARGS}
 
 config.status:
PATH=/bin:/usr/bin:/sbin:/usr/sbin \
${GNUCFLAGS} \
INSTALL_PROGRAM=${INSTALL} ${INSTALL_COPY} ${INSTALL_STRIP} \
+   TELNET=/usr/bin/false \
+   RLOGIN=/usr/bin/false \
+   TN3270=/usr/bin/false \
sh ${.CURDIR}/configure --prefix=/usr --sysconfdir=/etc 
--disable-color-style ${CONFIGURE_ARGS} ${CF}
 
 lynx.1:${.CURDIR}/lynx.man

Re: lynx: disable old protocols

[Daniel Dickman]

 On Jul 10, 2014, at 11:50 PM, Adam Thompson athom...@athompso.net wrote:
 
 As a user, not a developer...
 I still use finger, gopher, and news URLs at least once a year each. As a 
 user, I disagree with turning support for those schemes off completely.
 Finger and news I can use another tool, and I'd concede that no-one really 
 *needs* a news reader in base. (I still find having a finger client of some 
 sort in base useful at one site, however.)

finger(1) is still in base. (for now). do you really need to access a finger 
client from inside a web browser?

for news, do any of the news packages in ports work as a replacement?

 Gopher, however, is not as dead as everyone assumes.
 I believe I can re-enable tn3270 and telnet schemes manually, which is fine. 
 I still use both of those fairly often.

tn3270 is no longer in base so trying this protocol from lynx already does 
nothing today. I'm just making it slightly more explicit...

for telnet same thing as finger, do you really need to access this from within 
lynx? why doesn't using telnet from the command line work for you?

 The other protocols are irrelevant to me.

thanks for your feedback.

 -Adam
 
 On July 10, 2014 10:05:45 PM CDT, Daniel Dickman didick...@gmail.com wrote:
 Patch below turns off the following ancient protocols built into lynx: 
 bibp, finger, gopher, and news.
 
 For some urls, lynx will invoke an external command. Turn off telnet, 
 rlogin and tn3270 urls by defining them to false(1) as documented in the 
 lynx manual.
 
 Finally, turn off the file editor which can be accessed with g.enter 
 using the --disable-dired switch.
 
 ok to commit?
 
 Index: Makefile.bsd-wrapper
 
 RCS file: /home/cvs/src/gnu/usr.bin/lynx/Makefile.bsd-wrapper,v
 retrieving revision 1.24
 diff -u -p -u -r1.24 Makefile.bsd-wrapper
 --- Makefile.bsd-wrapper 15 Apr 2014 20:55:42 - 1.24
 +++ Makefile.bsd-wrapper 11 Jul 2014 02:47:31 -
 @@ -5,7 +5,10 @@ CLEANFILES+= lynx.1
  DPADD= ${LIBSSL} ${LIBCRYPTO}
  
  GNUCFLAGS= CC=${CC} CFLAGS=${CFLAGS} ${COPTS} ${OPT} 
 LDFLAGS=${LDFLAGS}
 -CONFIGURE_ARGS= --with-ssl=/usr
 --enable-widec --enable-ipv6 --enable-debug
 +CONFIGURE_ARGS= --with-ssl=/usr --enable-widec --enable-ipv6 --enable-debug 
 \
 +  --disable-bibp-urls --disable-finger --disable-gopher --disable-news \
 +  --disable-dired
 +
  HTMLDIR= /usr/share/doc/html
  HELPFILES= keystrokes/alt_edit_help.html keystrokes/bookmark_help.html \
keystrokes/cookie_help.html keystrokes/dired_help.html \
 @@ -39,12 +42,18 @@ config: .FORCE
   PATH=/bin:/usr/bin:/sbin:/usr/sbin \
   ${GNUCFLAGS} \
   INSTALL_PROGRAM=${INSTALL} ${INSTALL_COPY} ${INSTALL_STRIP} \
 + TELNET=/usr/bin/false \
 + RLOGIN=/usr/bin/false \
 + TN3270=/usr/bin/false \
   sh ${.CURDIR}/configure --prefix=/usr --sysconfdir=/etc 
 --disable-color-style ${CONFIGURE_ARGS}
  
  config.status:
   PATH=/bin:/usr/bin:/sbin:/usr/sbin \
   ${GNUCFLAGS} \
   INSTALL_PROGRAM=${INSTALL} ${INSTALL_COPY} ${INSTALL_STRIP} \
 + TELNET=/usr/bin/false \
 +
 RLOGIN=/usr/bin/false \
 + TN3270=/usr/bin/false \
   sh ${.CURDIR}/configure --prefix=/usr --sysconfdir=/etc 
 --disable-color-style ${CONFIGURE_ARGS} ${CF}
  
  lynx.1: ${.CURDIR}/lynx.man
 
 -- 
 Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: port-modules.5 small fix

[Daniel Dickman]

On Tue, Jul 8, 2014 at 9:59 PM, Brian Callahan bcal...@devio.us wrote:
 Hi everyone --

 port-modules.5 is missing an If to make a complete sentence.
 OK?

ok daniel@


 ~Brian

 Index: port-modules.5
 ===
 RCS file: /cvs/src/share/man/man5/port-modules.5,v
 retrieving revision 1.172
 diff -u -p -r1.172 port-modules.5
 --- port-modules.5  2 Apr 2014 15:00:27 -   1.172
 +++ port-modules.5  9 Jul 2014 01:37:23 -
 @@ -1184,6 +1184,7 @@ is appended to
  .Ev MODGNOME_RUN_DEPENDS
  and a link to /usr/bin/true is created under
  .Pa ${WRKDIR}/bin/desktop-file-validate .
 +If
  .Ev MODGNOME_TOOLS
  is set to docbook,
  .Pa textproc/docbook-xsl

Re: nextafterl(3) possible bug

[Daniel Dickman]

 confirming that this patch fixes the failing numpy regress test on i386.

 let me know if you want me to test a different diff.

 Here's a better diff, inspired by what FreeBSD has.

 ok?



ok with me. numpy works with this diff too.

Re: __vfwprintf set but not used 'uio'

[Daniel Dickman]

On Tue, Jun 3, 2014 at 7:35 PM, enh e...@google.com wrote:
 GCC 4.9 complains:

 bionic/libc/upstream-openbsd/lib/libc/stdio/vfwprintf.c:328:16: error:
 variable 'uio' set but not used [-Werror=unused-but-set-variable]
   struct __suio uio; /* output information: summary */
 ^

 suggested patch:


I can't really comment on the correctness of your patch without fully
working through the code, but I'll note that vfwprintf.c was derived
from vfprintf.c and that file looks like it has a PRINT macro which
makes use of uio.

Do you know if something was overlooked in the process of converting
vfprintf to vfwprintf where uio should actually be used inside
vfwprintf? Or did you work out that nothing was missed during that
conversion and your patch below is definitely the correct one.

Either way I can vouch for the comment at the top of both files This
code is large and complicated...



 diff --git a/libc/upstream-openbsd/lib/libc/stdio/vfwprintf.c
 b/libc/upstream-openbsd/lib/libc/stdio/vfwprintf.c
 index 745b4d9..0ac346a 100644
 --- a/lib/libc/stdio/vfwprintf.c
 +++ b/lib/libc/stdio/vfwprintf.c
 @@ -325,8 +325,6 @@ __vfwprintf(FILE * __restrict fp, const wchar_t *
 __restrict fmt0, __va_list ap)
   int size; /* size of converted field or string */
   const char *xdigs; /* digits for %[xX] conversion */
  #define NIOV 8
 - struct __suio uio; /* output information: summary */
 - struct __siov iov[NIOV];/* ... and individual io vectors */
   wchar_t buf[BUF]; /* buffer with space for digits of uintmax_t */
   wchar_t ox[2]; /* space for 0x; ox[1] is either x, X, or \0 */
   union arg *argtable; /* args, built due to positional arg */
 @@ -463,9 +461,6 @@ __vfwprintf(FILE * __restrict fp, const wchar_t *
 __restrict fmt0, __va_list ap)
   argtable = NULL;
   nextarg = 1;
   va_copy(orgap, ap);
 - uio.uio_iov = iov;
 - uio.uio_resid = 0;
 - uio.uio_iovcnt = 0;
   ret = 0;
   convbuf = NULL;

  --elliott

Re: exp2(3) bug?

[Daniel Dickman]

Hi Benjamin,

On Mon, Jun 2, 2014 at 3:34 AM, Benjamin Baier program...@netzbasis.de wrote:
 You might want to read up on floating point arithmetic. (rounding and
 representation)


The error in floating point calculations is typically measured in
ulps. The error shown in this example is far too big for the
existing calculation to be correct. I'm linking to the wikipedia
article for some background reading for you but there's a lot more
info on the web on this topic:
http://en.wikipedia.org/wiki/Unit_in_the_last_place



 On 06/02/14 05:13, Daniel Dickman wrote:

 I hit this problem while working with the numpy 1.8.1 regress suite
 which has some tests that are currently failing.

 Here is a reduced test case of the logaddexp2 python function which
 ends up calling exp2. Is this a bug in the openbsd exp2
 implementation?

 ---8---
 #include stdio.h
 #include stdlib.h
 #include math.h

 int main(void) {
  double x;
  double y;

  // x = log2(5)
  x = 2.32192809489;
  // y = 2**(log2(5))
  y = exp2(x);

  printf(expected: 5.0\n);
  printf(actual:   %f\n, y);

 ---8---

 on a linux/x86_64 machine:

 # gcc -lm test.c  ./a.out
 expected: 5.0
 actual:   5.00

 on an openbsd/i386 machine:

 # gcc -lm test.c  ./a.out
 expected: 5.0
 actual:   4.994404

Re: exp2(3) bug?

[Daniel Dickman]

On Mon, Jun 2, 2014 at 5:33 AM, Mark Kettenis mark.kette...@xs4all.nl wrote:
 Date: Mon, 2 Jun 2014 10:17:53 +0200 (CEST)
 From: Mark Kettenis mark.kette...@xs4all.nl

  Date: Mon, 02 Jun 2014 09:34:20 +0200
  From: Benjamin Baier program...@netzbasis.de
 
  You might want to read up on floating point arithmetic. (rounding and
  representation)

 Well, the difference between 4.994404 and 5.0 is a bit large to blame
 rounding and binary representation.  And other OpenBSD platforms
 (amd64, sparc64, powerpc) return the expected result.  So I'd say that
 there is a bug in the i386-specific implementation of exp2(3).

 And here is a fix.  There actually isn't any i386-specific code, but
 i386 is special and needs STRICT_ALIGN() to work properly for double
 as well as float.  FreeBSD made the same change a while ago:


Fixes my test case and the numpy test. So ok daniel@ for what it's worth...


 http://svnweb.FreeBSD.org/base/head/lib/msun/src/math_private.h?revision=240827view=markup

 Haven't run the regression tests yet with this change.


 Index: src/math_private.h
 ===
 RCS file: /cvs/src/lib/libm/src/math_private.h,v
 retrieving revision 1.16
 diff -u -p -r1.16 math_private.h
 --- src/math_private.h  12 Nov 2013 20:35:09 -  1.16
 +++ src/math_private.h  2 Jun 2014 09:30:13 -
 @@ -349,7 +349,7 @@ do {  
   \
  #defineSTRICT_ASSIGN(type, lval, rval) do {\
 volatile type __lval;   \
 \
 -   if (sizeof(type) = sizeof(double)) \
 +   if (sizeof(type) = sizeof(long double))\
 (lval) = (rval);\
 else {  \
 __lval = (rval);\

nextafterl(3) possible bug

[Daniel Dickman]

From the numpy test suite, I think I might have found a bug in
nextafterl(3). The result_ld variable below comes back as nan on
i386. But doing the same calculations with floats returns the expected
values.

A test on Linux also shows the expected results for both the float and
long double cases.

---[ on linux/x86_64 ]---

# gcc -lm test2.c  ./a.out
1.00e+00
-5.421011e-20
OK
1.00
-0.00
OK

---[ on openbsd/i386 ]---

# gcc -lm test2.c  ./a.out
1.00e+00
nan   -- this looks wrong
1.00
-0.00
OK

---[ test2.c ]---

#include stdio.h
#include stdlib.h
#include math.h

int main(void) {
long double one_ld;
long double zero_ld;
long double after_ld;
long double result_ld;

one_ld = 1.0L;
zero_ld = 0.0L;

after_ld = nextafterl(one_ld, zero_ld);
printf(%Le\n, after_ld);
result_ld = after_ld - one_ld;
// result_ld should not be nan
printf(%Le\n, result_ld);
if (result_ld  0)
printf(OK\n);

float one_f;
float zero_f;
float after_f;
float result_f;

one_f = 1.0;
zero_f = 0.0;

after_f = nextafterf(one_f, zero_f);
printf(%f\n, after_f);
result_f = after_f - one_f;
printf(%f\n, result_f);
if (result_f  0)
printf(OK\n);
}

Re: nextafterl(3) possible bug

[Daniel Dickman]

 Another bug.  Intel chose an extended precision format with an
 explicit integer bit, and the code doesn't handle that.  Assuming we
 don't support machines with extended precision format that have an
 implicit integer bit, the following diff (an adaptation of the code in
 glibc) should fix things.  Not entirely happy with the fix though, so
 I'm still thinking about improvements.

confirming that this patch fixes the failing numpy regress test on i386.

let me know if you want me to test a different diff.


 Index: src/ld80/s_nextafterl.c
 ===
 RCS file: /cvs/src/lib/libm/src/ld80/s_nextafterl.c,v
 retrieving revision 1.4
 diff -u -p -r1.4 s_nextafterl.c
 --- src/ld80/s_nextafterl.c 12 Nov 2013 21:07:28 -  1.4
 +++ src/ld80/s_nextafterl.c 2 Jun 2014 13:21:58 -
 @@ -32,8 +32,8 @@ nextafterl(long double x, long double y)
 ix = esx0x7fff;/* |x| */
 iy = esy0x7fff;/* |y| */

 -   if (((ix==0x7fff)((hx|lx)!=0)) ||   /* x is nan */
 -   ((iy==0x7fff)((hy|ly)!=0))) /* y is nan */
 +   if (((ix==0x7fff)((hx=0x7fff|lx)!=0)) ||   /* x is nan */
 +   ((iy==0x7fff)((hy-0x7fff|ly)!=0))) /* y is nan */
return x+y;
 if(x==y) return y;  /* x=y, return y */
 if((ix|hx|lx)==0) { /* x == 0 */
 @@ -47,31 +47,50 @@ nextafterl(long double x, long double y)
 if(ixiy||((ix==iy)  (hxhy||((hx==hy)(lxly) {
   /* x  y, x -= ulp */
 if(lx==0) {
 -   if (hx==0) esx -= 1;
 -   hx -= 1;
 +   if (hx = 0x8000) {
 + if (esx == 0) {
 +   --hx;
 + } else {
 +   esx -= 1;
 +   hx = hx - 1;
 +   if (esx  0)
 + hx |= 0x8000;
 + }
 +   } else
 + hx -= 1;
 }
 lx -= 1;
 } else {/* x  y, x += ulp */
 lx += 1;
 if(lx==0) {
 hx += 1;
 -   if (hx==0)
 +   if (hx==0 || (esx == 0  hx == 0x8000)) {
 esx += 1;
 +   hx |= 0x8000;
 +   }
 }
 }
 } else {/* x  0 */
 if(esy=0||(ixiy||((ix==iy)(hxhy||((hx==hy)(lxly)){
   /* x  y, x -= ulp */
 if(lx==0) {
 -   if (hx==0) esx -= 1;
 -   hx -= 1;
 +   if (hx = 0x8000) {
 +   esx -= 1;
 +   hx = hx - 1;
 +   if ((esx0x7fff)  0)
 + hx |= 0x8000;
 +   } else
 + hx -= 1;
 }
 lx -= 1;
 } else {/* x  y, x += ulp */
 lx += 1;
 if(lx==0) {
 hx += 1;
 -   if (hx==0) esx += 1;
 +   if (hx==0 || (esx == 0x8000  hx == 0x8000)) {
 +   esx += 1;
 +   hx |= 0x8000;
 +   }
 }
 }
 }

exp2(3) bug?

[Daniel Dickman]

I hit this problem while working with the numpy 1.8.1 regress suite
which has some tests that are currently failing.

Here is a reduced test case of the logaddexp2 python function which
ends up calling exp2. Is this a bug in the openbsd exp2
implementation?

---8---
#include stdio.h
#include stdlib.h
#include math.h

int main(void) {
double x;
double y;

// x = log2(5)
x = 2.32192809489;
// y = 2**(log2(5))
y = exp2(x);

printf(expected: 5.0\n);
printf(actual:   %f\n, y);

---8---

on a linux/x86_64 machine:

# gcc -lm test.c  ./a.out
expected: 5.0
actual:   5.00

on an openbsd/i386 machine:

# gcc -lm test.c  ./a.out
expected: 5.0
actual:   4.994404

acpi rsdp patch

[Daniel Dickman]

The ACPI RSDP table has a checksum and an extended checksum. At the moment 
if the ACPI rvision is zero, the checksum is checked and if the revision 
is more recent only the extended checksum field is checked.

However the spec says that the checksum field ...must sum to zero. At 
the moment this isn't being checked if the revision is = 2. I checked 
intel's acpica implementation and it looks this is what they're doing 
too.

Patch below is for i386 and amd64. I tested on i386.

ok?

Index: i386//i386/acpi_machdep.c
===
RCS file: /home/cvs/src/sys/arch/i386/i386/acpi_machdep.c,v
retrieving revision 1.53
diff -u -p -u -r1.53 acpi_machdep.c
--- i386//i386/acpi_machdep.c   25 Apr 2014 14:37:06 -  1.53
+++ i386//i386/acpi_machdep.c   23 May 2014 01:37:15 -
@@ -112,22 +112,23 @@ acpi_scan(struct acpi_mem_map *handle, p
 
if (acpi_map(pa, len, handle))
return (NULL);
-   for (ptr = handle-va, i = 0;
-i  len;
-ptr += 16, i += 16)
-   if (memcmp(ptr, RSDP_SIG, sizeof(RSDP_SIG) - 1) == 0) {
-   rsdp = (struct acpi_rsdp1 *)ptr;
-   /*
-* Only checksum whichever portion of the
-* RSDP that is actually present
-*/
-   if (rsdp-revision == 0 
-   acpi_checksum(ptr, sizeof(struct acpi_rsdp1)) == 0)
+   for (ptr = handle-va, i = 0; i  len; ptr += 16, i += 16) {
+   /* is there a valid signature? */
+   if (memcmp(ptr, RSDP_SIG, sizeof(RSDP_SIG) - 1))
+   continue;
+
+   /* is the checksum valid? */
+   if (acpi_checksum(ptr, sizeof(struct acpi_rsdp1)) != 0)
+   continue;
+
+   /* check the extended checksum as needed */
+   rsdp = (struct acpi_rsdp1 *)ptr;
+   if (rsdp-revision == 0)
+   return (ptr);
+   else if (rsdp-revision = 2  rsdp-revision = 4)
+   if (acpi_checksum(ptr, sizeof(struct acpi_rsdp)) == 0)
return (ptr);
-   else if (rsdp-revision = 2  rsdp-revision = 4 
-   acpi_checksum(ptr, sizeof(struct acpi_rsdp)) == 0)
-   return (ptr);
-   }
+   }
acpi_unmap(handle);
 
return (NULL);
Index: amd64//amd64/acpi_machdep.c
===
RCS file: /home/cvs/src/sys/arch/amd64/amd64/acpi_machdep.c,v
retrieving revision 1.60
diff -u -p -u -r1.60 acpi_machdep.c
--- amd64//amd64/acpi_machdep.c 25 Apr 2014 14:37:06 -  1.60
+++ amd64//amd64/acpi_machdep.c 23 May 2014 01:37:45 -
@@ -106,22 +106,23 @@ acpi_scan(struct acpi_mem_map *handle, p
 
if (acpi_map(pa, len, handle))
return (NULL);
-   for (ptr = handle-va, i = 0;
-i  len;
-ptr += 16, i += 16)
-   if (memcmp(ptr, RSDP_SIG, sizeof(RSDP_SIG) - 1) == 0) {
-   rsdp = (struct acpi_rsdp1 *)ptr;
-   /*
-* Only checksum whichever portion of the
-* RSDP that is actually present
-*/
-   if (rsdp-revision == 0 
-   acpi_checksum(ptr, sizeof(struct acpi_rsdp1)) == 0)
+   for (ptr = handle-va, i = 0; i  len; ptr += 16, i += 16) {
+   /* is there a valid signature? */
+   if (memcmp(ptr, RSDP_SIG, sizeof(RSDP_SIG) - 1))
+   continue;
+
+   /* is the checksum valid? */
+   if (acpi_checksum(ptr, sizeof(struct acpi_rsdp1)) != 0)
+   continue;
+
+   /* check the extended checksum as needed */
+   rsdp = (struct acpi_rsdp1 *)ptr;
+   if (rsdp-revision == 0)
+   return (ptr);
+   else if (rsdp-revision = 2  rsdp-revision = 4)
+   if (acpi_checksum(ptr, sizeof(struct acpi_rsdp)) == 0)
return (ptr);
-   else if (rsdp-revision = 2  rsdp-revision = 4 
-   acpi_checksum(ptr, sizeof(struct acpi_rsdp)) == 0)
-   return (ptr);
-   }
+   }
acpi_unmap(handle);
 
return (NULL);

Re: exp() / expl() on Linux and OpenBSD (expl() bug?)

[Daniel Dickman]

I think I recently ran into a similar issue but I suspect the root cause might 
be the same. I think the floorl function is wrong for numbers slightly larger 
than -1 to numbers slightly below 0. In this range floorl returns -0 instead of 
-1.

 On Feb 5, 2014, at 3:57 AM, David Coppa dco...@openbsd.org wrote:
 
 
 Hi!
 
 I hit this problem while working on updating math/R from version
 2.15.3 to the latest version (3.0.2).
 
 It started happening since upstream switched from double functions
 to C99 long double functions (expl, fabsl, ...), during the R-3
 development cycle.
 
 Take the following reduced test-case, adapted from what R's code
 does:
 
 ---8---
 
 #include stdio.h
 #include stdlib.h
 #include math.h
 
 int main(void) {
double theta = 1;
long double lambda, pr, pr2;
 
lambda = (0.5*theta);
pr = exp(-lambda);
pr2 = expl(-lambda);
 
printf(theta == %g, pr == %Lg, pr2 == %Lg\n, theta, pr, pr2);
exit(0);
 }
 
 ---8---
 
 This produces the following output on Linux (x86_64):
 
 theta == 1, pr == 0.606531, pr2 == 0.606531
 
 While on OpenBSD -current amd64:
 
 theta == 1, pr == 0.606531, pr2 == nan
 
 And indeed R-3's testsuite fails with the error message
 NaNs produced:
 
 Warning in pchisq(1e-300, df = 0, ncp = lam) : NaNs produced
 stopifnot(all.equal(p00, exp(-lam/2)),
 +   all.equal(p.0, exp(-lam/2)))
 Error: all.equal(p.0, exp(-lam/2)) is not TRUE
 Execution halted
 
 Is this a bug in our expl() ?
 
 Ciao,
 David
 

Re: [patch] start adding support for compcert compiler

[Daniel Dickman]

 I'm trying to port compcert to openbsd. Here's a first patch to allow
 jot to be compiled with compcert.

 Wouldn't it be better to check for __STDC_VERSION__ = 199901L rather than a
 list of compilers? (I don't have a source tree close by which is why I don't
 have a patch.)

Supporting _Bool and claiming support for C99 are independent of each
other. For example gcc supports _Bool in c89 mode (see example below).
Compcert relies on the gnu c preprocessor so its behaviour is the same
as gcc's.

I don't think testing for __STDC_VERSION__ would work here.

# -- gcc 
-
[~] cat testcase.c
#include stdio.h

int main(int argc, char* argv[]) {
_Bool a = 1;
if (a) {
printf(here\n);
}
}
[~] gcc -std=c89 testcase.c
[~] ./a.out
here

[patch] instal tip on macppc

[Daniel Dickman]

Tell people the equivalent of the Command and Option keys for anyone 
using a PC keyboard instead of a Mac keyboard... 

Index: prep
===
RCS file: /home/cvs/src/distrib/notes/macppc/prep,v
retrieving revision 1.19
diff -u -p -u -r1.19 prep
--- prep11 Feb 2013 10:09:12 -  1.19
+++ prep25 Nov 2013 05:11:25 -
@@ -6,9 +6,10 @@ and diagnostics are performed but before
 operating system.
 
 To access Open Firmware, you should simultaneously hold down the
-Command, Option, O, and F keys immediately upon booting.  You will
-be presented with information and a  prompt that will look something
-like this (example taken from a Power Macintosh G4):
+Command, Option, O, and F keys immediately upon booting.  (On a PC keyboard,
+use the Windows key instead of the Command key and use Alt instead of the
+Option key).  You will be presented with information and a  prompt that
+will look something like this (example taken from a Power Macintosh G4):
 
 Apple PowerMac3,1 2.4f1 BootROM built on 02/18/00 at 09:44:35
 Copyright 1994-2000 Apple Computer, Inc.

[patch] start adding support for compcert compiler

[Daniel Dickman]

I'm trying to port compcert to openbsd. Here's a first patch to allow 
jot to be compiled with compcert.

Before the patch is applied compcert fails because _Bool is predefined as 
per C99:

# ccomp -fall -c /usr/src/usr.bin/jot/jot.c
/usr/include/stdbool.h:20: Error: illegal combination of type specifiers.
Fatal error.
1 error detected.
*** Error 2 in /usr/src/usr.bin/jot (sys.mk:87 'jot.o')
#

After the patch below is applied:

# ccomp -fall -c /usr/src/usr.bin/jot/jot.c
#


Index: include/stdbool.h
===
RCS file: /home/cvs/src/include/stdbool.h,v
retrieving revision 1.5
diff -u -p -u -r1.5 stdbool.h
--- include/stdbool.h   24 Jul 2010 22:17:03 -  1.5
+++ include/stdbool.h   23 Nov 2013 22:38:23 -
@@ -10,7 +10,7 @@
 
 #ifndef __cplusplus
 
-#if (defined(__GNUC__)  __GNUC__ = 3) || defined(__PCC__) || defined(lint)
+#if (defined(__GNUC__)  __GNUC__ = 3) || defined(__COMPCERT__) || 
defined(__PCC__) || defined(lint)
 /* Support for _C99: type _Bool is already built-in. */
 #define false  0
 #define true   1
Index: sys/sys/types.h
===
RCS file: /home/cvs/src/sys/sys/types.h,v
retrieving revision 1.39
diff -u -p -u -r1.39 types.h
--- sys/sys/types.h 14 Sep 2013 01:35:02 -  1.39
+++ sys/sys/types.h 23 Nov 2013 22:40:59 -
@@ -241,7 +241,7 @@ struct  uio;
 #endif
 
 #ifdef _KERNEL
-#if (defined(__GNUC__)  __GNUC__ = 3) || defined(__PCC__) || defined(lint)
+#if (defined(__GNUC__)  __GNUC__ = 3) || defined(__COMPCERT__) || 
defined(__PCC__) || defined(lint)
 /* Support for _C99: type _Bool is already built-in. */
 #define false  0
 #define true   1

uvm(9) patch

[Daniel Dickman]

minor patch for uvm(9) :-

- remove redundant sentence about misc functions
- note that pmap(9) is the MD portion of UVM.
- Convert reference to Chuck's dissertation to .Rs/.Re section
- uvm is no longer new.
- Remove (Missouri). St. Louis should be enough to remove any confusion
  between wustl.edu and washington.edu.

jmc was okay with this but asked me to send to tech.

Index: uvm.9
===
RCS file: /home/cvs/src/share/man/man9/uvm.9,v
retrieving revision 1.49
diff -u -r1.49 uvm.9
--- uvm.9   17 Jul 2013 20:21:55 -  1.49
+++ uvm.9   19 Jul 2013 03:33:03 -
@@ -72,7 +72,10 @@
 The swapper process swaps in runnable processes that are currently swapped out,
 if there is room.
 .Pp
-There are also several miscellaneous functions.
+UVM has a machine independent and a machine dependent layer.
+See
+.Xr pmap 9
+for the machine dependent layer.
 .Sh INITIALISATION
 .nr nS 1
 .Ft void
@@ -1044,9 +1047,15 @@
 .Xr ddb 4 ,
 .Xr options 4 ,
 .Xr pmap 9
+.Rs
+.%A Charles D. Cranor
+.%T Design and Implementation of the UVM Virtual Memory System, D.Sc. 
dissertation
+.%C St. Louis, Missouri
+.%Q Department of Computer Science, Sever Institute of Technology, Washington 
University
+.%D August 1998
+.Re
 .Sh HISTORY
-UVM is a new VM system developed at Washington University in St. Louis
-(Missouri).
+The UVM virtual memory system was developed at Washington University in St. 
Louis.
 UVM's roots lie partly in the Mach-based
 .Bx 4.4
 VM system, the
@@ -1063,8 +1072,6 @@
 .Bx
 including page loanout, map entry passing, simplified
 copy-on-write, and clustered anonymous memory pageout.
-UVM is also further documented in an August 1998 dissertation
-by Charles D. Cranor.
 .Pp
 UVM appeared in
 .Ox 2.9 .

sysv_ipc dropped clauses 3/4

[Daniel Dickman]

It looks like copyright for sys/kern/sysv_ipc.c was assigned to NetBSD
in rev 1.13 in 1998:

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/sysv_ipc.c.diff?r1=1.12r2=1.13only_with_tag=MAINf=h

NetBSD then dropped clauses 3  4 in rev 1.21 in 2008:

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/sysv_ipc.c.diff?r1=1.20r2=1.21only_with_tag=MAINf=h

Not sure if there's any interest in updating in OpenBSD...

[patch] sys/arch/macppc rcs ids

[Daniel Dickman]

fix rcs ids.

Index: elf32_powerpc_merge.x
===
RCS file: /home/cvs/src/sys/arch/macppc/stand/boot.mac/elf32_powerpc_merge.x,v
retrieving revision 1.1
diff -u -r1.1 elf32_powerpc_merge.x
--- elf32_powerpc_merge.x   5 Dec 2006 20:30:26 -   1.1
+++ elf32_powerpc_merge.x   2 Sep 2011 02:32:14 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: */
+/* $OpenBSD$ */
 OUTPUT_ARCH(powerpc)
 SECTIONS
 {
Index: fixcoff.c
===
RCS file: /home/cvs/src/sys/arch/macppc/stand/boot.mac/fixcoff.c,v
retrieving revision 1.1
diff -u -r1.1 fixcoff.c
--- fixcoff.c   5 Dec 2006 20:30:26 -   1.1
+++ fixcoff.c   2 Sep 2011 02:32:25 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: */
+/* $OpenBSD$ */
 /* $NetBSD: fixcoff.c,v 1.10 2006/04/07 02:34:55 gdamore Exp $ */
 
 /*

phantasia(6) remove unused code

[Daniel Dickman]

I guess the intent was to get a custom message at build time which would 
be shown when phantasia starts up. But --

(1) That would make the build interactive.
(2) _PATH_PHANTDIR is not defined anywhere so this won't compile.
(3) As the ifdef macro says, this can be done from the Makefile if 
needed...


Index: setup.c
===
RCS file: /home/cvs/src/games/phantasia/setup.c,v
retrieving revision 1.10
diff -u -r1.10 setup.c
--- setup.c 15 Dec 2010 06:40:39 -  1.10
+++ setup.c 23 Jun 2011 02:55:27 -
@@ -175,42 +175,6 @@
}
}
 
-#ifdef MAKE_INSTALLS_THIS_AND_DOESNT_WANT_TO_HEAR_ABOUT_IT
-/* write to motd file */
-printf(One line 'motd' ? );
-if (fgets(Databuf, SZ_DATABUF, stdin) == NULL)
-   Databuf[0] = '\0';
-snprintf(path, sizeof(path), %s%s, prefix?prefix:, _PATH_MOTD);
-if ((fp = fopen(path, w)) == NULL)
-   Error(Cannot update %s.\n, path);
-else
-   {
-   fwrite(Databuf, sizeof(char), strlen(Databuf), fp);
-   fclose(fp);
-   }
-
-/* report compile-time options */
-printf(Compiled options:\n\n);
-printf(Phantasia destination directory:  %s\n, _PATH_PHANTDIR);
-printf(Wizard: root UID: 0\n);
-
-#ifdef BSD41
-printf(Compiled for BSD 4.1\n);
-#endif
-
-#ifdef BSD42
-printf(Compiled for BSD 4.2\n);
-#endif
-
-#ifdef SYS3
-printf(Compiled for System III\n);
-#endif
-
-#ifdef SYS5
-printf(Compiled for System V\n);
-#endif
-#endif
-
 exit(0);
 /*NOTREACHED*/
 }

get rid of trigraphs from rbootd and pppd

[Daniel Dickman]

Get rid of trigraphs. No effect with gcc since the default is to ignore 
trigraphs, but does get rid of the warnings during build.


Index: /usr/src/usr.sbin/rbootd/rbootd.c
===
RCS file: /usr/cvs/src/usr.sbin/rbootd/rbootd.c,v
retrieving revision 1.23
diff -u -r1.23 rbootd.c
--- /usr/src/usr.sbin/rbootd/rbootd.c   27 Oct 2009 23:59:54 -  1.23
+++ /usr/src/usr.sbin/rbootd/rbootd.c   18 May 2011 04:31:34 -
@@ -142,7 +142,7 @@
char *errmsg;
 
if ((IntfName = BpfGetIntfName(errmsg)) == NULL) {
-   syslog(LOG_NOTICE, restarted (??));
+   syslog(LOG_NOTICE, restarted (?\?));
/* BpfGetIntfName() returns safe names, using %m */
syslog(LOG_ERR, %s, errmsg);
DoExit();
Index: usr.sbin/pppd/chat/chat.c
===
RCS file: /usr/cvs/src/usr.sbin/pppd/chat/chat.c,v
retrieving revision 1.28
diff -u -r1.28 chat.c
--- usr.sbin/pppd/chat/chat.c   12 Aug 2010 02:00:28 -  1.28
+++ usr.sbin/pppd/chat/chat.c   18 May 2011 04:30:47 -
@@ -1203,7 +1203,7 @@
 
 if (verbose) {
if (quiet)
-   logmsg(send (??));
+   logmsg(send (?\?));
else
logmsg(send (%v), s);
 }

[patch] stop changing files on rebuild

[Daniel Dickman]

The files below change with every build because they include the `date` 
they were generated (and etcsum changes because it references some of the 
files that keep changing).

/etc/mail/localhost.cf
/etc/mail/sendmail.cf
/etc/mail/submit.cf
/usr/share/info/dir
/var/db/sysmerge/etcsum

The patch below removes the `date` so all of the above will stay constant 
after a rebuild unless there are real changes.


Index: gnu/usr.bin/texinfo/util/gen-dir-node
===
RCS file: /usr/cvs/src/gnu/usr.bin/texinfo/util/gen-dir-node,v
retrieving revision 1.5
diff -u -r1.5 gen-dir-node
--- gnu/usr.bin/texinfo/util/gen-dir-node   17 Jul 2006 16:12:36 -  
1.5
+++ gnu/usr.bin/texinfo/util/gen-dir-node   12 May 2011 02:09:26 -
@@ -47,7 +47,6 @@
 ### output the dir header
 echo -*- Text -*-
 echo This file was generated automatically by $0.
-echo This version was generated on `date`
 echo by `whoami`@`hostname` for `(cd ${INFODIR}; pwd)`
 
 cat  moobler
Index: gnu/usr.sbin/sendmail/cf/sh/makeinfo.sh
===
RCS file: /usr/cvs/src/gnu/usr.sbin/sendmail/cf/sh/makeinfo.sh,v
retrieving revision 1.2
diff -u -r1.2 makeinfo.sh
--- gnu/usr.sbin/sendmail/cf/sh/makeinfo.sh 15 Jan 2001 21:08:59 -  
1.2
+++ gnu/usr.sbin/sendmail/cf/sh/makeinfo.sh 12 May 2011 02:41:33 -
@@ -52,7 +52,7 @@
 else
host=`uname -n`
 fi
-echo '#' built by $user@$host on `date`
+echo '#' built by $user@$host
 echo '#' in `pwd` | sed 's/\/tmp_mnt//'
 echo '#' using $1 as configuration include directory | sed 's/\/tmp_mnt//'
 echo define(\`__HOST__', $host)dnl

Re: [PATCH] flip order of steps in release(8)

[Daniel Dickman]

 Sorry, I don't think this makes sense.  I always start with doing a
 make obj.  It's way too easy to mess things things up if you forget to
 do that step, so running anything in my source tree without doing make
 obj first makes me very nervous.

 Does changing the order actually fix something?

i believe so. when i followed the existing order in release(8) but
without remembering to recreate /usr/obj first i got /usr/obj does
not exist for every symlink being created.

   # cd /usr/src  nice make obj
   === lib
   === lib/csu
   === lib/csu/alpha
   /usr/src/lib/csu/alpha/obj - /usr/obj/lib/csu/alpha
   /usr/obj does not exist
   === lib/csu/amd64
   /usr/src/lib/csu/amd64/obj - /usr/obj/lib/csu/amd64
   /usr/obj does not exist
   === lib/csu/arm
   /usr/src/lib/csu/arm/obj - /usr/obj/lib/csu/arm
   /usr/obj does not exist
   === lib/csu/hppa
   /usr/src/lib/csu/hppa/obj - /usr/obj/lib/csu/hppa
   /usr/obj does not exist
   

flipping the steps will ensure that make obj won't have this issue.

Re: [PATCH] flip order of steps in release(8)

[Daniel Dickman]

 how did you end up without /usr/obj?

 $ tar tzf base48.tgz ./usr/obj
 ./usr/obj
 $

user error on my part. but:

(1) Let me turn this around. What's the objection to making the
change? is there something that would break? why not protect against
user error when possible to do so?
(2) xenocara does things in this same order. (see step 5 in release(8)
says to do make bootstrap before make obj and looking at make
bootstrap it does a make distrib-dirs) so it makes sense to me from
a consistency standpoint.

but i won't push this further. it's not a big deal.

[PATCH] flip order of steps in release(8)

[Daniel Dickman]

I think it might be better to create missing directories (especially 
/usr/obj) before creating the symlinks. This is one less opportunity for 
someone to mess up if /usr/obj is missing for some reason...


Index: release.8
===
RCS file: /usr/cvs/src/share/man/man8/release.8,v
retrieving revision 1.61
diff -u -r1.61 release.8
@@ -188,13 +188,13 @@
sudo rm -rf .old 
 .Ed
 .Pp
-Re-build your obj directories:
-.Pp
-.Dl $ cd /usr/src  nice make obj
-.Pp
 Create directories that might be missing:
 .Pp
 .Dl $ cd /usr/src/etc  env DESTDIR=/ sudo make distrib-dirs
+.Pp
+Re-build your obj directories:
+.Pp
+.Dl $ cd /usr/src  nice make obj
 .Pp
 Begin the build:
 .Pp

[PATCH] change diff return value on xcalloc failure

[Daniel Dickman]

The diff(1) man page (and posix) specify the following as exit values:

   0   No differences were found.
   1   Differences were found.
   1  An error occurred.

So I think the patch below is needed.



Index: xmalloc.c
===
RCS file: /usr/cvs/src/usr.bin/diff/xmalloc.c,v
retrieving revision 1.2
diff -u -r1.2 xmalloc.c
--- xmalloc.c   7 Jun 2009 08:39:13 -   1.2
+++ xmalloc.c   16 Jul 2010 08:22:29 -
@@ -41,12 +41,12 @@
void *ptr;
 
if (size == 0 || nmemb == 0)
-   errx(1, xcalloc: zero size);
+   errx(2, xcalloc: zero size);
if (SIZE_MAX / nmemb  size)
-   errx(1, xcalloc: nmemb * size  SIZE_MAX);
+   errx(2, xcalloc: nmemb * size  SIZE_MAX);
ptr = calloc(nmemb, size);
if (ptr == NULL)
-   errx(1, xcalloc: out of memory (allocating %lu bytes),
+   errx(2, xcalloc: out of memory (allocating %lu bytes),
(u_long)(size * nmemb));
return ptr;
 }

Re: [BUG] Fix int 0x15, e820 call

[Daniel Dickman]

 If you notice, the asm part does a setc %b1.  And in your
 case, that would simply nuke %ecx.  The original code did not
 take into account the length returned, it ignored it as it
 was asking for the max, some biosen always return the max,
 and nothing should ever return more than what was asked for,
 or less than 20 bytes.
 
 I don't know how this fixes any bug off hand.  The following
 diff may.  Compiled tested, but otherwise not tested.  Similar
 diff would need to be made for i386:
 
 

You're right. My original analysis was wrong.

ACPI 3.0 specifies that 24 bytes should be returned so until this code is 
reworked to handle that case as well, I'd say better to leave things alone 
unless something can be shown to break due to the missing size check.

Thanks for taking a look.

[PATCH] Fix for jbrickshooter

[Daniel Dickman]

The shell script to launch jbrickshooter depends on having the JRE 
installed and fails if only the JDK is available.

# jbrickshooter
/usr/local/bin/jbrickshooter[2]: /usr/local/jre-1.7.0/bin/java: not found

The patch below fixes things to use javaPathHelper which is more robust 
and will work if either the JDK or the JRE are available. While at it, 
also update to jbrickshooter 1.4.1.


Index: Makefile
===
RCS file: /usr/cvs/ports/games/jbrickshooter/Makefile,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 Makefile
--- Makefile11 Oct 2009 18:47:35 -  1.1.1.1
+++ Makefile3 Mar 2010 23:19:51 -
@@ -2,7 +2,7 @@
 
 COMMENT =  brick shooter reflexion game
 
-V= 1.4.0
+V= 1.4.1
 DISTNAME=  JBrickShooter_v${V}
 PKGNAME=   jbrickshooter-${V}
 CATEGORIES=games java
@@ -24,6 +24,8 @@
 MODJAVA_VER=   1.7
 MODJAVA_JRERUN= Yes
 
+RUN_DEPENDS=   ::java/javaPathHelper
+
 NO_REGRESS=Yes
 NO_BUILD=  Yes
 
@@ -31,7 +33,9 @@
 PKG_ARCH=  *
 
 do-install:
-   @echo #!/bin/sh\n${LOCALBASE}/jre-1.7.0/bin/java -jar 
${TRUEPREFIX}/share/jbrickshooter/jbrickshooter.jar  ${WRKSRC}/jbrickshooter
+   @sed -e 's,%%TRUEPREFIX%%,${TRUEPREFIX},' \
+ ${FILESDIR}/jbrickshooter \
+ ${WRKSRC}/jbrickshooter
${INSTALL_DATA_DIR} ${PREFIX}/share/jbrickshooter
cp ${WRKSRC}/jbrickshooter.jar ${PREFIX}/share/jbrickshooter
chown -R ${SHAREOWN}:${SHAREGRP} ${PREFIX}/share/jbrickshooter
Index: distinfo
===
RCS file: /usr/cvs/ports/games/jbrickshooter/distinfo,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 distinfo
--- distinfo11 Oct 2009 18:47:35 -  1.1.1.1
+++ distinfo3 Mar 2010 23:06:10 -
@@ -1,5 +1,5 @@
-MD5 (JBrickShooter_v1.4.0.zip) = 69c9K5JqiDSYrJi37mUL+A==
-RMD160 (JBrickShooter_v1.4.0.zip) = HMKkNWSdgTDnfJ5XfGBQh0m8IQ4=
-SHA1 (JBrickShooter_v1.4.0.zip) = 5jIvX0jskMK97M5ORmfRqOO9XP8=
-SHA256 (JBrickShooter_v1.4.0.zip) = 
RCiE5KPPrwX3NGDr0Qek+3E5SHH8Yf6R9JDb+LzbFGo=
-SIZE (JBrickShooter_v1.4.0.zip) = 106583
+MD5 (JBrickShooter_v1.4.1.zip) = ehYMWQw3dHeQrmZY9U4dng==
+RMD160 (JBrickShooter_v1.4.1.zip) = MZhb4GR7wXVt0Qtxmr8OrN5mMbU=
+SHA1 (JBrickShooter_v1.4.1.zip) = YZjD/6f8huWPmduDkF/sUNuCv6g=
+SHA256 (JBrickShooter_v1.4.1.zip) = 
KNVe0hn1mwq5CGvFT36DHDk0Io8dEF8XpcdvfVXgSdY=
+SIZE (JBrickShooter_v1.4.1.zip) = 112497
Index: files/jbrickshooter
===
RCS file: files/jbrickshooter
diff -N files/jbrickshooter
--- /dev/null   1 Jan 1970 00:00:00 -
+++ files/jbrickshooter 3 Mar 2010 22:47:43 -
@@ -0,0 +1,2 @@
+#!/bin/sh
+`javaPathHelper -c jbrickshooter` -jar 
%%TRUEPREFIX%%/share/jbrickshooter/jbrickshooter.jar

Re: Bug in ftp(1)

[Daniel Dickman]

On Fri, 12 Feb 2010, Stuart Henderson wrote:

 On 2010/02/11 23:44, Daniel Dickman wrote:
  ftp(1) will reliably stall for me when doing uploads. I tracked the 
  problem down to the keep-alive option. Not sure how widespread this issue 
  is as I'd imagine it depends on what server is on the receiving end. But 
  here's a sample transcript which gets stuck every time and requires me to 
  kill the process... the patch below turns off this functionality by 
  default as it doesn't really work all that well for me for uploads. 
  (Downloads on this same server work fine though).
 
 ftp(1) doesn't read until after the transfer finishes, so the
 server has to queue a big batch of 200 NOOP command successful
 or similar replies and send them in a batch at the end of the
 transfer.
 
 Every other ftp client that I've investigated which has this
 option reads the replies after each line, which is more friendly
 to the server. I'm not sure if it's implicated in this problem,
 but I think it's fairly likely.
 
 I've played around with moving getreply() into send_noop_char()
 but something more than this is needed as it freezes after trying
 to read the first response. 
 
 One problem with disabling keepalive is that some people behind
 crappy nat gateways need it, and there's no easy way to set this
 from the installer (without adding ugly questions, anyway), but
 OTOH pushing them towards using http might be a more sane work-
 around there...
 
 

Ok. What about the following defaults:
- interactive mode: disable keep-alive by default.
- auto-fetch mode:  preserve current behaviour (60s between NOOPs by
  default) since I haven't seen any issues with keep-alive when doing
  downloads. This should keep the installer working as before.

At least until the problem can be diagnosed and fixed properly...


Index: ftp.1
===
RCS file: /usr/cvs/src/usr.bin/ftp/ftp.1,v
retrieving revision 1.79
diff -u -r1.79 ftp.1
--- ftp.1   9 Aug 2009 20:16:39 -   1.79
+++ ftp.1   12 Feb 2010 10:46:15 -
@@ -174,9 +174,10 @@
 the control connection during a transfer.
 Well-behaved servers queue those commands, and process them after the
 transfer.
-By default,
+By default, this functionality is turned off unless auto-fetching.
+In that case, the default is for
 .Nm
-will send a byte every 60 seconds.
+to send a byte every 60 seconds.
 .It Fl m
 Causes
 .Nm
Index: ftp.c
===
RCS file: /usr/cvs/src/usr.bin/ftp/ftp.c,v
retrieving revision 1.79
diff -u -r1.79 ftp.c
--- ftp.c   6 Jun 2009 23:14:44 -   1.79
+++ ftp.c   12 Feb 2010 09:59:56 -
@@ -325,7 +325,7 @@
return (r);
 }
 
-int keep_alive_timeout = 60;   /* 0 - no timeout */
+int keep_alive_timeout = -1;   /* 0 - no timeout */
 
 static int full_noops_sent = 0;
 static time_t last_timestamp = 0;  /* 0 - no measurement yet */
Index: main.c
===
RCS file: /usr/cvs/src/usr.bin/ftp/main.c,v
retrieving revision 1.80
diff -u -r1.80 main.c
--- main.c  9 Aug 2009 18:36:11 -   1.80
+++ main.c  12 Feb 2010 11:05:59 -
@@ -314,6 +314,8 @@
 
if (argc  0) {
if (isurl(argv[0])) {
+   if (keep_alive_timeout  0)
+   keep_alive_timeout = 60;
rval = auto_fetch(argc, argv, outfile);
if (rval = 0)  /* -1 == connected and cd-ed */
exit(rval);
@@ -321,6 +323,9 @@
 #ifndef SMALL
char *xargv[5];
 
+   if (keep_alive_timeout  0)
+   keep_alive_timeout = 0;
+
if (setjmp(toplevel))
exit(0);
(void)signal(SIGINT, (sig_t)intr);
@@ -345,6 +350,9 @@
}
}
 #ifndef SMALL
+   if (keep_alive_timeout  0)
+   keep_alive_timeout = 0;
+
controlediting();
top = setjmp(toplevel) == 0;
if (top) {

Re: [PATCH] bug in fts_open

[Daniel Dickman]

Note: the patch below is NOT recommended for 4.7 as this will change
the semantics of fts_open and will BREAK things like gzip - and
possibly other stuff.

Calls to fts_open should probably be audited first...


On Thu, Jan 28, 2010 at 2:06 AM, Daniel Dickman didick...@gmail.com wrote:
 As reported on the git mailing list[1], find(1) should exit with non-zero
 status when a non-existent path is given which I think is also the intent
 of the find(1) code.

 [1] http://marc.info/?l=gitm=126186443524638

 For example:

 B  B  B  B # find /no-such-path
 B  B  B  B find: fts_open: No such file or directory
 B  B  B  B # echo $?
 B  B  B  B 0
 B  B  B  B ^^^ --- should be something non-zero.

 Looking at the code for find, we have the following in
 /usr/src/usr.bin/find/find.c, line 153:

 B  B  B  B if (!(tree = fts_open(paths, ftsoptions, NULL)))
 B  B  B  B  B  B  B  B err(1, fts_open);

 This looks right and fts_open(1) says:

 B  B  B  B If an error occurs, fts_open() returns NULL and sets
 B  B  B  B errno appropriately.

 Debugging, it seems like errno comes back as ENOENT but the variable
 tree is not set to null...

 Debugging a bit more it seems like fts_open calls fts_stat which
 returns FTS_NS but the code path for fts_open doesn't go into the error
 path at this point. Therefore, I propose the patch below.

 With the patch applied I get:

 B  B  B  B # find /no-such-path
 B  B  B  B find: fts_open: No such file or directory
 B  B  B  B # echo $?
 B  B  B  B 1

 Index: fts.c
 ===
 RCS file: /usr/cvs/src/lib/libc/gen/fts.c,v
 retrieving revision 1.43
 diff -u -r1.43 fts.c
 --- fts.c B  B  B  27 Aug 2009 16:19:27 - B  B  B 1.43
 +++ fts.c B  B  B  28 Jan 2010 06:48:11 -
 @@ -117,6 +117,10 @@
 B  B  B  B  B  B  B  B p-fts_accpath = p-fts_name;
 B  B  B  B  B  B  B  B p-fts_info = fts_stat(sp, p, ISSET(FTS_COMFOLLOW));

 + B  B  B  B  B  B  B  /* stat(2) failed, so fts_open should error. */
 + B  B  B  B  B  B  B  if (p-fts_info == FTS_NS)
 + B  B  B  B  B  B  B  B  B  B  B  goto mem3;
 +
 B  B  B  B  B  B  B  B /* Command-line . and .. are real directories.
*/
 B  B  B  B  B  B  B  B if (p-fts_info == FTS_DOT)
 B  B  B  B  B  B  B  B  B  B  B  B p-fts_info = FTS_D;

Re: [PATCH] bug in fts_open

[Daniel Dickman]

On Thu, 28 Jan 2010, Otto Moerbeek wrote:

 On Thu, Jan 28, 2010 at 03:25:21AM -0500, Daniel Dickman wrote:
 
  Note: the patch below is NOT recommended for 4.7 as this will change
  the semantics of fts_open and will BREAK things like gzip - and
  possibly other stuff.
  
  Calls to fts_open should probably be audited first...
 
 yes, this is tricky stuff. Compare this to getting a Permission
 denied, because the dir is not accessible. Currently find also returns
 with 0 in that case.

Yes. I think this is also a bug.

 
 The main question is: should toplevel dirs be handled differently than
 deeper dirs?

I think so. POSIX says:

The following exit values shall be returned:
0
All path operands were traversed successfully.
0
An error occurred.

So the error condition above should be logically the same as the 
following:

0
Some path operand was not traversed successfully.

And since the deeper dirs are not path operands I think the implication 
is that being able to traverse them or not shouldn't matter.

 
   -Otto
 
  
  
  On Thu, Jan 28, 2010 at 2:06 AM, Daniel Dickman didick...@gmail.com wrote:
   As reported on the git mailing list[1], find(1) should exit with non-zero
   status when a non-existent path is given which I think is also the intent
   of the find(1) code.
  
   [1] http://marc.info/?l=gitm=126186443524638
  
   For example:
  
   B  B  B  B # find /no-such-path
   B  B  B  B find: fts_open: No such file or directory
   B  B  B  B # echo $?
   B  B  B  B 0
   B  B  B  B ^^^ --- should be something non-zero.
  
   Looking at the code for find, we have the following in
   /usr/src/usr.bin/find/find.c, line 153:
  
   B  B  B  B if (!(tree = fts_open(paths, ftsoptions, NULL)))
   B  B  B  B  B  B  B  B err(1, fts_open);
  
   This looks right and fts_open(1) says:
  
   B  B  B  B If an error occurs, fts_open() returns NULL and sets
   B  B  B  B errno appropriately.
  
   Debugging, it seems like errno comes back as ENOENT but the variable
   tree is not set to null...
  
   Debugging a bit more it seems like fts_open calls fts_stat which
   returns FTS_NS but the code path for fts_open doesn't go into the error
   path at this point. Therefore, I propose the patch below.
  
   With the patch applied I get:
  
   B  B  B  B # find /no-such-path
   B  B  B  B find: fts_open: No such file or directory
   B  B  B  B # echo $?
   B  B  B  B 1
  
   Index: fts.c
   ===
   RCS file: /usr/cvs/src/lib/libc/gen/fts.c,v
   retrieving revision 1.43
   diff -u -r1.43 fts.c
   --- fts.c B  B  B  27 Aug 2009 16:19:27 - B  B  B 1.43
   +++ fts.c B  B  B  28 Jan 2010 06:48:11 -
   @@ -117,6 +117,10 @@
   B  B  B  B  B  B  B  B p-fts_accpath = p-fts_name;
   B  B  B  B  B  B  B  B p-fts_info = fts_stat(sp, p, 
   ISSET(FTS_COMFOLLOW));
  
   + B  B  B  B  B  B  B  /* stat(2) failed, so fts_open should error. */
   + B  B  B  B  B  B  B  if (p-fts_info == FTS_NS)
   + B  B  B  B  B  B  B  B  B  B  B  goto mem3;
   +
   B  B  B  B  B  B  B  B /* Command-line . and .. are real directories.
  */
   B  B  B  B  B  B  B  B if (p-fts_info == FTS_DOT)
   B  B  B  B  B  B  B  B  B  B  B  B p-fts_info = FTS_D;

[PATCH] slightly simplify building a release

[Daniel Dickman]

The patch below allows the sequence of steps to build the base system to 
be the same as the steps for building xenocara. essentially:

# make bootstrap
# make obj
# make
# make release

At least for me, it's nice to have to type (and remember) fewer 
keystrokes. No patch for release(8) for now, since the old procedure will 
continue to work...

Index: Makefile
===
RCS file: /usr/cvs/src/Makefile,v
retrieving revision 1.114
diff -u -r1.114 Makefile
--- Makefile2 Dec 2005 01:17:20 -   1.114
+++ Makefile25 Jan 2010 03:59:32 -
@@ -57,6 +57,9 @@
 includes:
cd ${.CURDIR}/include  ${MAKE} prereq  exec ${SUDO} ${MAKE} includes
 
+bootstrap:
+   @cd ${.CURDIR}/etc  env DESTDIR=/ ${SUDO} ${MAKE} distrib-dirs
+
 beforeinstall:
cd ${.CURDIR}/etc  exec ${MAKE} DESTDIR=${DESTDIR} distrib-dirs
cd ${.CURDIR}/include  exec ${MAKE} includes
@@ -78,6 +81,9 @@
cd ${.CURDIR}/gnu/lib  ${MAKE} depend  ${MAKE}  \
NOMAN=1 exec ${SUDO} ${MAKE} install
${MAKE} depend  ${MAKE}  exec ${SUDO} ${MAKE} install
+
+release:
+   @cd ${.CURDIR}/etc  ${MAKE} release
 
 CROSS_TARGETS=cross-env cross-dirs cross-obj cross-includes cross-binutils \
cross-gcc cross-tools cross-lib cross-bin cross-etc-root-var \

[PATCH] /usr/bin/sort posix patch

[Daniel Dickman]

The patch below adds support for sort's missing -C option (as per 
POSIX:2008). This option behaves like -c except that it suppresses 
output on STDERR.

Index: extern.h
===
RCS file: /usr/cvs/src/usr.bin/sort/extern.h,v
retrieving revision 1.7
diff -u -r1.7 extern.h
--- extern.h26 Jun 2003 00:12:39 -  1.7
+++ extern.h21 Dec 2009 04:36:24 -
@@ -61,7 +61,8 @@
 int optval(int, int);
 voidorder(union f_handle,
int (*)(int, union f_handle, int, RECHEADER *, u_char *, struct 
field *),
-   struct field *);
+   struct field *,
+   int c_warn);
 voidputline(RECHEADER *, FILE *);
 voidputrec(RECHEADER *, FILE *);
 voidrd_append(int, union f_handle, int, FILE *, u_char *, u_char *);
Index: msort.c
===
RCS file: /usr/cvs/src/usr.bin/sort/msort.c,v
retrieving revision 1.22
diff -u -r1.22 msort.c
--- msort.c 27 Oct 2009 23:59:43 -  1.22
+++ msort.c 21 Dec 2009 04:48:43 -
@@ -232,7 +232,8 @@
 void
 order(union f_handle infile,
 int (*get)(int, union f_handle, int, RECHEADER *, u_char *, struct field 
*),
-struct field *ftbl)
+struct field *ftbl,
+int c_warn)
 {
u_char *crec_end, *prec_end, *trec_end;
int c;
@@ -256,13 +257,17 @@
while (get(-1, infile, 1, crec, crec_end, ftbl) == 0) {
if (0  (c = cmp(prec, crec))) {
crec-data[crec-length-1] = 0;
-   errx(1, found disorder: %s,
-   crec-data+crec-offset);
+   c_warn ?
+   errx(1, found disorder: %s,
+   crec-data+crec-offset) :
+   exit(1);
}
if (UNIQUE  !c) {
crec-data[crec-length-1] = 0;
-   errx(1, found non-uniqueness: %s,
-   crec-data+crec-offset);
+   c_warn ?
+   errx(1, found non-uniqueness: %s,
+   crec-data+crec-offset) :
+   exit(1);
}
/* Swap pointers so that this record is on place
 * pointed to by prec and new record is read to place
Index: sort.1
===
RCS file: /usr/cvs/src/usr.bin/sort/sort.1,v
retrieving revision 1.34
diff -u -r1.34 sort.1
--- sort.1  16 Aug 2009 09:41:08 -  1.34
+++ sort.1  21 Dec 2009 04:08:01 -
@@ -40,7 +40,7 @@
 .Nd sort or merge text files
 .Sh SYNOPSIS
 .Nm sort
-.Op Fl bcdfHimnrsuz
+.Op Fl bCcdfHimnrsuz
 .Sm off
 .Op Fl k\ \ Ar field1 Op , Ar field2
 .Sm on
@@ -74,6 +74,11 @@
 .Fl c
 produces no output, except the error messages on
 .Em stderr .
+.It Fl C
+Same as
+.Fl c
+except that no error message is sent to
+.Em stderr .
 .It Fl m
 Merge only; the input files are assumed to be pre-sorted.
 .It Fl o Ar output
@@ -96,7 +101,9 @@
 Unique: suppress all but one in each set of lines having equal keys.
 If used with the
 .Fl c
-option, also check that there are no lines with duplicate keys.
+or
+.Fl C
+options, also check that there are no lines with duplicate keys.
 .El
 .Pp
 The following options override the default ordering rules.
Index: sort.c
===
RCS file: /usr/cvs/src/usr.bin/sort/sort.c,v
retrieving revision 1.38
diff -u -r1.38 sort.c
--- sort.c  28 Oct 2009 20:41:39 -  1.38
+++ sort.c  21 Dec 2009 04:52:47 -
@@ -93,7 +93,7 @@
 {
int (*get)(int, union f_handle, int, RECHEADER *, u_char *, struct 
field *);
int ch, i, stdinflag = 0, tmp = 0;
-   char nfields = 0, cflag = 0, mflag = 0;
+   char nfields = 0, cflag = 0, c_warn = 0, mflag = 0;
char *outfile, *outpath = 0;
struct field *fldtab, *ftpos;
union f_handle filelist;
@@ -111,7 +111,7 @@
fixit(argc, argv);
if (!issetugid()  (outfile = getenv(TMPDIR)))
tmpdir = outfile;
-   while ((ch = getopt(argc, argv, bcdfik:mHno:rR:t:T:uy:zs)) != -1) {
+   while ((ch = getopt(argc, argv, bCcdfik:mHno:rR:t:T:uy:zs)) != -1) {
switch (ch) {
case 'b': fldtab-flags |= BI | BT;
break;
@@ -159,8 +159,13 @@
case 'u':
UNIQUE = 1;
break;
+   case 'C':
+   cflag = 1;
+   c_warn = 0;
+   break;
case 'c':
cflag = 1;
+   c_warn = 1;