[PATCH] FIX: pf(4) DIOCKILLSTATES ioctl with port_op may not work correctly.

[UMEZAWA Takeshi]

Hello,

I have found a trivial bug in pf(4) DIOCKILLSTATES ioctl.

No functional change by this patch.


UMEZAWA Takeshi (FAMILY Given) umez...@iij.ad.jp
Internet Initiative Japan Inc.



diff --git a/sys/net/pf_ioctl.c b/sys/net/pf_ioctl.c
index 426d8ea..ad861d5 100644
--- a/sys/net/pf_ioctl.c
+++ b/sys/net/pf_ioctl.c
@@ -1351,14 +1351,14 @@ pfioctl(dev_t dev, u_long cmd, caddr_t addr, int flags, 
struct proc *p)
sk = s-key[PF_SK_STACK];
srcaddr = sk-addr[1];
dstaddr = sk-addr[0];
-   srcport = sk-port[0];
+   srcport = sk-port[1];
dstport = sk-port[0];
} else {
sk = s-key[PF_SK_WIRE];
srcaddr = sk-addr[0];
dstaddr = sk-addr[1];
srcport = sk-port[0];
-   dstport = sk-port[0];
+   dstport = sk-port[1];
}
if ((!psk-psk_af || sk-af == psk-psk_af)
 (!psk-psk_proto || psk-psk_proto ==

sysctl rndstats

[Ted Unangst]

sysctl kern.random prints out a series of unintelligble numbers.
add some labels for more pretty.

also stop printing unused values. i don't need to verify that the pad
bytes are still zero. for that matter, we don't even need pad bytes.

Index: sys/dev/rndvar.h
===
RCS file: /cvs/src/sys/dev/rndvar.h,v
retrieving revision 1.29
diff -u -p -r1.29 rndvar.h
--- sys/dev/rndvar.h8 Jan 2011 19:45:08 -   1.29
+++ sys/dev/rndvar.h26 Mar 2013 05:56:40 -
@@ -44,14 +44,9 @@
 struct rndstats {
quad_t rnd_total;   /* total bits of entropy generated */
quad_t rnd_used;/* strong data bits read so far */
-   quad_t rnd_reads;   /* strong read calls -- unused */
quad_t arc4_reads;  /* aRC4 data bytes read so far */
quad_t arc4_nstirs; /* arc4 pool stirs */
-   quad_t arc4_stirs;  /* arc4 pool stirs (bits used) -- unused */
 
-   quad_t rnd_pad[5];
-
-   quad_t rnd_waits;   /* sleeps for data -- unused */
quad_t rnd_enqs;/* enqueue calls */
quad_t rnd_deqs;/* dequeue calls */
quad_t rnd_drops;   /* queue-full drops */
Index: sbin/sysctl/sysctl.c
===
RCS file: /cvs/src/sbin/sysctl/sysctl.c,v
retrieving revision 1.184
diff -u -p -r1.184 sysctl.c
--- sbin/sysctl/sysctl.c20 Sep 2012 20:11:58 -  1.184
+++ sbin/sysctl/sysctl.c26 Mar 2013 06:05:45 -
@@ -869,33 +869,27 @@ parse(char *string, int flags)
 
if (!nflag)
(void)printf(%s%s, string, equ);
-   (void)printf(
-   %llu %llu %llu %llu %llu %llu %llu %llu %llu %llu %llu %llu 
%llu %llu %llu %llu,
-   (unsigned long long)rndstats-rnd_total,
-   (unsigned long long)rndstats-rnd_used,
-   (unsigned long long)rndstats-rnd_reads,
-   (unsigned long long)rndstats-arc4_reads,
-   (unsigned long long)rndstats-arc4_nstirs,
-   (unsigned long long)rndstats-arc4_stirs,
-   (unsigned long long)rndstats-rnd_pad[0],
-   (unsigned long long)rndstats-rnd_pad[1],
-   (unsigned long long)rndstats-rnd_pad[2],
-   (unsigned long long)rndstats-rnd_pad[3],
-   (unsigned long long)rndstats-rnd_pad[4],
-   (unsigned long long)rndstats-rnd_waits,
-   (unsigned long long)rndstats-rnd_enqs,
-   (unsigned long long)rndstats-rnd_deqs,
-   (unsigned long long)rndstats-rnd_drops,
-   (unsigned long long)rndstats-rnd_drople);
-   for (i = 0; i  
sizeof(rndstats-rnd_ed)/sizeof(rndstats-rnd_ed[0]);
+   printf(tot: %llu used: %llu read: %llu stirs: %llu
+enqs: %llu deqs: %llu drops: %llu ledrops: %llu,
+   rndstats-rnd_total, rndstats-rnd_used,
+   rndstats-arc4_reads, rndstats-arc4_nstirs,
+   rndstats-rnd_enqs, rndstats-rnd_deqs,
+   rndstats-rnd_drops, rndstats-rnd_drople);
+   printf( ed:);
+   for (i = 0;
+   i  sizeof(rndstats-rnd_ed)/sizeof(rndstats-rnd_ed[0]);
i++)
-   (void)printf( %llu, (unsigned long 
long)rndstats-rnd_ed[i]);
-   for (i = 0; i  
sizeof(rndstats-rnd_sc)/sizeof(rndstats-rnd_sc[0]);
+   printf( %llu, (unsigned long 
long)rndstats-rnd_ed[i]);
+   printf( sc:);
+   for (i = 0;
+   i  sizeof(rndstats-rnd_sc)/sizeof(rndstats-rnd_sc[0]);
i++)
-   (void)printf( %llu, (unsigned long 
long)rndstats-rnd_sc[i]);
-   for (i = 0; i  
sizeof(rndstats-rnd_sb)/sizeof(rndstats-rnd_sb[0]);
+   printf( %llu, (unsigned long 
long)rndstats-rnd_sc[i]);
+   printf( sb:);
+   for (i = 0;
+   i  sizeof(rndstats-rnd_sb)/sizeof(rndstats-rnd_sb[0]);
i++)
-   (void)printf( %llu, (unsigned long 
long)rndstats-rnd_sb[i]);
+   printf( %llu, (unsigned long 
long)rndstats-rnd_sb[i]);
printf(\n);
return;
}

cleanup ossaudio compat

[Ted Unangst]

As much as it pains me to submit a diff that contains + in the compat
directory, this is still mostly -. Calling our mixer devices NetBSD
devices doesn't make a whole lot of sense. Also kill some other dead
code.

The comment still doesn't make a lot of sense to me. The comment says
only 32 devices are available, but OSS_SOUND_MIXER_NRDEVICES is
defined to be 17. I leave the thinking to somebody else.

Index: ossaudio.c
===
RCS file: /cvs/src/sys/compat/ossaudio/ossaudio.c,v
retrieving revision 1.14
diff -u -p -r1.14 ossaudio.c
--- ossaudio.c  22 Apr 2012 05:43:14 -  1.14
+++ ossaudio.c  26 Mar 2013 06:21:55 -
@@ -494,14 +494,14 @@ oss_ioctl_audio(p, uap, retval)
return (error);
 }
 
-/* If the NetBSD mixer device should have more than 32 devices
+/* If the mixer device should have more than 32 devices
  * some will not be available to Linux */
-#define NETBSD_MAXDEVS 64
+#define MAX_MIXER_DEVS 64
 struct audiodevinfo {
int done;
dev_t dev;
int16_t devmap[OSS_SOUND_MIXER_NRDEVICES], 
-   rdevmap[NETBSD_MAXDEVS];
+   rdevmap[MAX_MIXER_DEVS];
 u_long devmask, recmask, stereomask;
u_long caps, source;
 };
@@ -532,16 +532,10 @@ getdevinfo(fp, p)
{ AudioNtreble, OSS_SOUND_MIXER_TREBLE },
{ AudioNbass,   OSS_SOUND_MIXER_BASS },
{ AudioNspeaker,OSS_SOUND_MIXER_SPEAKER },
-/* { AudioNheadphone,  ?? },*/
{ AudioNoutput, OSS_SOUND_MIXER_OGAIN },
{ AudioNinput,  OSS_SOUND_MIXER_IGAIN },
-/* { AudioNmaster, OSS_SOUND_MIXER_SPEAKER },*/
-/* { AudioNstereo, ?? },*/
-/* { AudioNmono,   ?? },*/
{ AudioNfmsynth,OSS_SOUND_MIXER_SYNTH },
-/* { AudioNwave,   OSS_SOUND_MIXER_PCM },*/
{ AudioNmidi,   OSS_SOUND_MIXER_SYNTH },
-/* { AudioNmixerout,   ?? },*/
{ 0, -1 }
};
register const struct oss_devs *dp;
@@ -572,9 +566,9 @@ getdevinfo(fp, p)
di-caps = 0;
for(i = 0; i  OSS_SOUND_MIXER_NRDEVICES; i++)
di-devmap[i] = -1;
-   for(i = 0; i  NETBSD_MAXDEVS; i++)
+   for(i = 0; i  MAX_MIXER_DEVS; i++)
di-rdevmap[i] = -1;
-   for(i = 0; i  NETBSD_MAXDEVS; i++) {
+   for(i = 0; i  MAX_MIXER_DEVS; i++) {
mi.index = i;
if (ioctlf(fp, AUDIO_MIXER_DEVINFO, (caddr_t)mi, p)  0)
break;
@@ -822,11 +816,6 @@ oss_ioctl_sequencer(p, uap, retval)
 { 
struct file *fp;
struct filedesc *fdp;
-#if 0
-   u_long com;
-   int idat;
-   int error;
-#endif
 
fdp = p-p_fd;
if ((fp = fd_getfile(fdp, SCARG(uap, fd))) == NULL)
@@ -835,9 +824,6 @@ oss_ioctl_sequencer(p, uap, retval)
if ((fp-f_flag  (FREAD | FWRITE)) == 0)
return (EBADF);
 
-#if 0
-   com = SCARG(uap, com);
-#endif
retval[0] = 0;
 
return EINVAL;

ye olde magicke

[Ted Unangst]

An analysis of the kernel using sophisticated machine learning pattern
matching algorithms reveals the presence of several function that are
never called and can be deleted.

Index: sys/exec_aout.h
===
RCS file: /cvs/src/sys/sys/exec_aout.h,v
retrieving revision 1.22
diff -u -p -r1.22 exec_aout.h
--- sys/exec_aout.h 6 Oct 2006 20:58:17 -   1.22
+++ sys/exec_aout.h 26 Mar 2013 06:32:06 -
@@ -192,11 +192,6 @@ intexec_aout_prep_zmagic(struct proc *,
 intexec_aout_prep_nmagic(struct proc *, struct exec_package *);
 intexec_aout_prep_omagic(struct proc *, struct exec_package *);
 
-/* For compatibility modules */
-intexec_aout_prep_oldzmagic(struct proc *, struct exec_package *);
-intexec_aout_prep_oldnmagic(struct proc *, struct exec_package *);
-intexec_aout_prep_oldomagic(struct proc *, struct exec_package *);
-
 /*
  * MD portion
  */
Index: compat/common/compat_exec.c
===
RCS file: compat/common/compat_exec.c
diff -N compat/common/compat_exec.c
--- compat/common/compat_exec.c 15 Nov 2001 06:22:29 -  1.7
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,190 +0,0 @@
-/* $OpenBSD: compat_exec.c,v 1.7 2001/11/15 06:22:29 art Exp $ */
-/* $NetBSD: compat_exec.c,v 1.1 1996/05/18 15:52:21 christos Exp $ */
-
-/*
- * Copyright (c) 1993, 1994 Christopher G. Demetriou
- * 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.
- * 3. All advertising materials mentioning features or use of this software
- *must display the following acknowledgement:
- *  This product includes software developed by Christopher G. Demetriou.
- * 4. The name of the author may not be used to endorse or promote products
- *derived from this software without specific prior written permission
- *
- * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``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 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.
- */
-
-#include sys/param.h
-#include sys/systm.h
-#include sys/proc.h
-#include sys/malloc.h
-#include sys/vnode.h
-#include sys/exec.h
-#include sys/resourcevar.h
-#include uvm/uvm_extern.h
-
-/*
- * exec_aout_prep_oldzmagic():
- * Prepare the vmcmds to build a vmspace for an old ZMAGIC
- * binary. [386BSD/BSDI/4.4BSD/NetBSD0.8]
- *
- * Cloned from exec_aout_prep_zmagic() in kern/exec_aout.c; a more verbose
- * description of operation is there.
- * There were copies of this in the mac68k, hp300, and i386 ports.
- */
-int
-exec_aout_prep_oldzmagic(p, epp)
-   struct proc *p;
-   struct exec_package *epp;
-{
-   struct exec *execp = epp-ep_hdr;
-
-   epp-ep_taddr = 0;
-   epp-ep_tsize = execp-a_text;
-   epp-ep_daddr = epp-ep_taddr + execp-a_text;
-   epp-ep_dsize = execp-a_data + execp-a_bss;
-   epp-ep_entry = execp-a_entry;
-
-   /*
-* check if vnode is in open for writing, because we want to
-* demand-page out of it.  if it is, don't do it, for various
-* reasons
-*/
-   if ((execp-a_text != 0 || execp-a_data != 0) 
-   epp-ep_vp-v_writecount != 0) {
-#ifdef DIAGNOSTIC
-   if (epp-ep_vp-v_flag  VTEXT)
-   panic(exec: a VTEXT vnode has writecount != 0);
-#endif
-   return ETXTBSY;
-   }
-   vn_marktext(epp-ep_vp);
-
-   /* set up command for text segment */
-   NEW_VMCMD(epp-ep_vmcmds, vmcmd_map_pagedvn, execp-a_text,
-   epp-ep_taddr, epp-ep_vp, PAGE_SIZE,
-   VM_PROT_READ|VM_PROT_EXECUTE);
-
-   /* set up command for data segment */
-   NEW_VMCMD(epp-ep_vmcmds, vmcmd_map_pagedvn, execp-a_data,
-   epp-ep_daddr, epp-ep_vp,
-   execp-a_text + PAGE_SIZE,
-   VM_PROT_READ|VM_PROT_WRITE|VM_PROT_EXECUTE);
-
-   /* set up command for bss 

nfs pathconf

[Ted Unangst]

After an absence of 9 years, I make my triumphant return to sys/nfs.
There are some silly programs out there (looking at you boost) that
actually use pathconf instead of just hard coding 1024 for max path
length. If you run them from nfs, fireworks ensue.

Here's a pathconf implementation for nfs, copied mostly from ufs. Even
if some of these values are lies, they're better than nothing. My
theory is that the values you care about (NAME_MAX, PATH_MAX) are
going to be right, and the values you don't (REC_MAX_XFER_SIZE) are
harmless even if incorrect.

Index: nfs_vnops.c
===
RCS file: /cvs/src/sys/nfs/nfs_vnops.c,v
retrieving revision 1.140
diff -u -p -r1.140 nfs_vnops.c
--- nfs_vnops.c 17 Nov 2012 22:28:26 -  1.140
+++ nfs_vnops.c 26 Mar 2013 07:04:53 -
@@ -61,6 +61,7 @@
 #include sys/hash.h
 #include sys/queue.h
 #include sys/specdev.h
+#include sys/unistd.h
 
 #include uvm/uvm_extern.h
 
@@ -2937,19 +2938,70 @@ loop:
 
 /*
  * Return POSIX pathconf information applicable to nfs.
- *
- * The NFS V2 protocol doesn't support this, so just return EINVAL
- * for V2.
  */
 /* ARGSUSED */
 int
 nfs_pathconf(void *v)
 {
-#if 0
struct vop_pathconf_args *ap = v;
-#endif
+   struct nfsmount *nmp = VFSTONFS(ap-a_vp-v_mount);
+   int error = 0;
 
-   return (EINVAL);
+   switch (ap-a_name) {
+   case _PC_LINK_MAX:
+   *ap-a_retval = LINK_MAX;
+   break;
+   case _PC_NAME_MAX:
+   *ap-a_retval = NAME_MAX;
+   break;
+   case _PC_PATH_MAX:
+   *ap-a_retval = PATH_MAX;
+   break;
+   case _PC_PIPE_BUF:
+   *ap-a_retval = PIPE_BUF;
+   break;
+   case _PC_CHOWN_RESTRICTED:
+   *ap-a_retval = 1;
+   break;
+   case _PC_NO_TRUNC:
+   *ap-a_retval = 1;
+   break;
+   case _PC_PRIO_IO:
+   *ap-a_retval = 0;
+   break;
+   case _PC_SYNC_IO:
+   *ap-a_retval = 0;
+   break;
+   case _PC_ALLOC_SIZE_MIN:
+   *ap-a_retval = NFS_FABLKSIZE;
+   break;
+   case _PC_FILESIZEBITS:
+   *ap-a_retval = 64;
+   break;
+   case _PC_REC_INCR_XFER_SIZE:
+   *ap-a_retval = min(nmp-nm_rsize, nmp-nm_wsize);
+   break;
+   case _PC_REC_MAX_XFER_SIZE:
+   *ap-a_retval = -1; /* means ``unlimited'' */
+   break;
+   case _PC_REC_MIN_XFER_SIZE:
+   *ap-a_retval = min(nmp-nm_rsize, nmp-nm_wsize);
+   break;
+   case _PC_REC_XFER_ALIGN:
+   *ap-a_retval = PAGE_SIZE;
+   break;
+   case _PC_SYMLINK_MAX:
+   *ap-a_retval = MAXPATHLEN;
+   break;
+   case _PC_2_SYMLINKS:
+   *ap-a_retval = 1;
+   break;
+   default:
+   error = EINVAL;
+   break;
+   }
+
+   return (error);
 }
 
 /*

max crypto

[Ted Unangst]

There's a rather futile check for wrap around in crypto.c. The problem
is, if the number of crypto devs is anywhere near wrapping, the
malloc call a few lines below has long since exploded.

Just define a static max count and don't go over it.

Index: crypto.c
===
RCS file: /cvs/src/sys/crypto/crypto.c,v
retrieving revision 1.59
diff -u -p -r1.59 crypto.c
--- crypto.c11 Jan 2011 15:42:05 -  1.59
+++ crypto.c26 Mar 2013 07:35:33 -
@@ -245,8 +245,7 @@ crypto_get_driverid(u_int8_t flags)
 
/* Out of entries, allocate some more. */
if (i == crypto_drivers_num) {
-   /* Be careful about wrap-around. */
-   if (2 * crypto_drivers_num = crypto_drivers_num) {
+   if (crypto_drivers_num = CRYPTO_DRIVERS_MAX) {
splx(s);
return -1;
}
Index: cryptodev.h
===
RCS file: /cvs/src/sys/crypto/cryptodev.h,v
retrieving revision 1.56
diff -u -p -r1.56 cryptodev.h
--- cryptodev.h 29 Jun 2012 14:48:04 -  1.56
+++ cryptodev.h 26 Mar 2013 07:35:54 -
@@ -57,6 +57,7 @@
 
 /* Some initial values */
 #define CRYPTO_DRIVERS_INITIAL 4
+#define CRYPTO_DRIVERS_MAX 128
 #define CRYPTO_SW_SESSIONS 32
 
 /* HMAC values */

uvm combine clearbits

[Ted Unangst]

uvm_pagefree calls atomic_clearbits_int too many times. Just
accumulate the flags we need to zap, then do it once.

Index: uvm_page.c
===
RCS file: /cvs/src/sys/uvm/uvm_page.c,v
retrieving revision 1.122
diff -u -p -r1.122 uvm_page.c
--- uvm_page.c  12 Mar 2013 21:10:11 -  1.122
+++ uvm_page.c  26 Mar 2013 07:45:56 -
@@ -1053,6 +1053,7 @@ void
 uvm_pagefree(struct vm_page *pg)
 {
int saved_loan_count = pg-loan_count;
+   u_int flags_to_clear = 0;
 
 #ifdef DEBUG
if (pg-uobject == (void *)0xdeadbeef 
@@ -1115,7 +1116,7 @@ uvm_pagefree(struct vm_page *pg)
 
if (pg-pg_flags  PQ_ACTIVE) {
TAILQ_REMOVE(uvm.page_active, pg, pageq);
-   atomic_clearbits_int(pg-pg_flags, PQ_ACTIVE);
+   flags_to_clear |= PQ_ACTIVE;
uvmexp.active--;
}
if (pg-pg_flags  PQ_INACTIVE) {
@@ -1123,7 +1124,7 @@ uvm_pagefree(struct vm_page *pg)
TAILQ_REMOVE(uvm.page_inactive_swp, pg, pageq);
else
TAILQ_REMOVE(uvm.page_inactive_obj, pg, pageq);
-   atomic_clearbits_int(pg-pg_flags, PQ_INACTIVE);
+   flags_to_clear |= PQ_INACTIVE;
uvmexp.inactive--;
}
 
@@ -1138,15 +1139,16 @@ uvm_pagefree(struct vm_page *pg)
if (pg-uanon) {
pg-uanon-an_page = NULL;
pg-uanon = NULL;
-   atomic_clearbits_int(pg-pg_flags, PQ_ANON);
+   flags_to_clear |= PQ_ANON;
}
 
/*
 * Clean page state bits.
 */
-   atomic_clearbits_int(pg-pg_flags, PQ_AOBJ); /* XXX: find culprit */
-   atomic_clearbits_int(pg-pg_flags, PQ_ENCRYPT|
-   PG_ZERO|PG_FAKE|PG_BUSY|PG_RELEASED|PG_CLEAN|PG_CLEANCHK);
+   flags_to_clear |= PQ_AOBJ; /* XXX: find culprit */
+   flags_to_clear |= PQ_ENCRYPT|PG_ZERO|PG_FAKE|PG_BUSY|PG_RELEASED|
+   PG_CLEAN|PG_CLEANCHK;
+   atomic_clearbits_int(pg-pg_flags, flags_to_clear);
 
/*
 * and put on free queue

mpls includes

[Ted Unangst]

the netmpls code includes various headers it doesn't really need.

Index: mpls.h
===
RCS file: /cvs/src/sys/netmpls/mpls.h,v
retrieving revision 1.25
diff -u -p -r1.25 mpls.h
--- mpls.h  8 Sep 2010 08:00:56 -   1.25
+++ mpls.h  26 Mar 2013 08:05:43 -
@@ -35,7 +35,6 @@
 
 #include sys/param.h
 #include sys/time.h
-#include sys/proc.h
 #include sys/queue.h
 
 #include net/if.h
Index: mpls_raw.c
===
RCS file: /cvs/src/sys/netmpls/mpls_raw.c,v
retrieving revision 1.8
diff -u -p -r1.8 mpls_raw.c
--- mpls_raw.c  3 Sep 2010 13:12:31 -   1.8
+++ mpls_raw.c  26 Mar 2013 08:05:21 -
@@ -31,7 +31,6 @@
  */
 
 #include sys/param.h
-#include sys/malloc.h
 #include sys/mbuf.h
 #include sys/errno.h
 #include sys/protosw.h
@@ -39,12 +38,10 @@
 #include sys/socket.h
 #include sys/socketvar.h
 #include sys/systm.h
-#include sys/proc.h
 #include sys/sysctl.h
 
 #include net/if.h
 #include net/if_types.h
-#include net/route.h
 
 #include netmpls/mpls.h
 
Index: mpls_shim.c
===
RCS file: /cvs/src/sys/netmpls/mpls_shim.c,v
retrieving revision 1.6
diff -u -p -r1.6 mpls_shim.c
--- mpls_shim.c 28 Jan 2009 22:18:44 -  1.6
+++ mpls_shim.c 26 Mar 2013 08:03:49 -
@@ -31,14 +31,12 @@
  */
 
 #include sys/param.h
-#include sys/malloc.h
 #include sys/mbuf.h
 #include sys/errno.h
 #include sys/socket.h
 #include sys/systm.h
 
 #include net/if.h
-#include net/route.h
 
 #include netmpls/mpls.h
 

rename NCHNAMLEN

[Ted Unangst]

it's 2013. we don't have to pay extra for vowels.

Index: nfs/nfs_vnops.c
===
RCS file: /cvs/src/sys/nfs/nfs_vnops.c,v
retrieving revision 1.140
diff -u -p -r1.140 nfs_vnops.c
--- nfs/nfs_vnops.c 17 Nov 2012 22:28:26 -  1.140
+++ nfs/nfs_vnops.c 26 Mar 2013 08:59:30 -
@@ -2455,7 +2456,7 @@ nfs_readdirplusrpc(struct vnode *vp, str
info.nmi_md = mdsav2;
dp-d_type = IFTODT(
VTTOIF(np-n_vattr.va_type));
-   if (cnp-cn_namelen = NCHNAMLEN) {
+   if (cnp-cn_namelen = 
NAMECACHE_MAXLEN) {
ndp-ni_vp = newvp;
cache_purge(ndp-ni_dvp);
nfs_cache_enter(ndp-ni_dvp,
Index: kern/vfs_cache.c
===
RCS file: /cvs/src/sys/kern/vfs_cache.c,v
retrieving revision 1.34
diff -u -p -r1.34 vfs_cache.c
--- kern/vfs_cache.c4 Jan 2012 18:11:51 -   1.34
+++ kern/vfs_cache.c26 Mar 2013 08:59:59 -
@@ -48,7 +48,7 @@
 
 /*
  * For simplicity (and economy of storage), names longer than
- * a maximum length of NCHNAMLEN are not cached; they occur
+ * a maximum length of NAMECACHE_MAXLEN are not cached; they occur
  * infrequently in any case, and are almost never of interest.
  *
  * Upon reaching the last segment of a path, if the reference
@@ -148,7 +148,7 @@ cache_lookup(struct vnode *dvp, struct v
cnp-cn_flags = ~MAKEENTRY;
return (-1);
}
-   if (cnp-cn_namelen  NCHNAMLEN) {
+   if (cnp-cn_namelen  NAMECACHE_MAXLEN) {
nchstats.ncs_long++;
cnp-cn_flags = ~MAKEENTRY;
return (-1);
@@ -342,7 +342,7 @@ cache_enter(struct vnode *dvp, struct vn
 {
struct namecache *ncp, *lncp;
 
-   if (!doingcache || cnp-cn_namelen  NCHNAMLEN)
+   if (!doingcache || cnp-cn_namelen  NAMECACHE_MAXLEN)
return;
 
/*
Index: sys/namei.h
===
RCS file: /cvs/src/sys/sys/namei.h,v
retrieving revision 1.27
diff -u -p -r1.27 namei.h
--- sys/namei.h 30 Sep 2011 03:43:27 -  1.27
+++ sys/namei.h 26 Mar 2013 08:58:58 -
@@ -165,7 +165,7 @@ struct nameidata {
  * names looked up by namei.
  */
 
-#defineNCHNAMLEN   31  /* maximum name segment length we 
bother with */
+#defineNAMECACHE_MAXLEN31  /* maximum name segment length 
we bother with */
 
 struct namecache {
TAILQ_ENTRY(namecache) nc_lru;  /* Regular Entry LRU chain */
@@ -177,7 +177,7 @@ struct  namecache {
struct  vnode *nc_vp;   /* vnode the name refers to */
u_long  nc_vpid;/* capability number of nc_vp */
charnc_nlen;/* length of name */
-   charnc_name[NCHNAMLEN]; /* segment name */
+   charnc_name[NAMECACHE_MAXLEN];  /* segment name */
 };
 
 #ifdef _KERNEL

Re: rename NCHNAMLEN

[Mark Kettenis]

 Date: Tue, 26 Mar 2013 05:03:59 -0400
 From: Ted Unangst t...@tedunangst.com
 
 it's 2013. we don't have to pay extra for vowels.

Even in 2013, my terminals are still 80 columns wide.  This makes some
of the lines wrap.  Not really an improvement if you ask me.

 Index: nfs/nfs_vnops.c
 ===
 RCS file: /cvs/src/sys/nfs/nfs_vnops.c,v
 retrieving revision 1.140
 diff -u -p -r1.140 nfs_vnops.c
 --- nfs/nfs_vnops.c   17 Nov 2012 22:28:26 -  1.140
 +++ nfs/nfs_vnops.c   26 Mar 2013 08:59:30 -
 @@ -2455,7 +2456,7 @@ nfs_readdirplusrpc(struct vnode *vp, str
   info.nmi_md = mdsav2;
   dp-d_type = IFTODT(
   VTTOIF(np-n_vattr.va_type));
 - if (cnp-cn_namelen = NCHNAMLEN) {
 + if (cnp-cn_namelen = 
 NAMECACHE_MAXLEN) {
   ndp-ni_vp = newvp;
   cache_purge(ndp-ni_dvp);
   nfs_cache_enter(ndp-ni_dvp,
 Index: kern/vfs_cache.c
 ===
 RCS file: /cvs/src/sys/kern/vfs_cache.c,v
 retrieving revision 1.34
 diff -u -p -r1.34 vfs_cache.c
 --- kern/vfs_cache.c  4 Jan 2012 18:11:51 -   1.34
 +++ kern/vfs_cache.c  26 Mar 2013 08:59:59 -
 @@ -48,7 +48,7 @@
  
  /*
   * For simplicity (and economy of storage), names longer than
 - * a maximum length of NCHNAMLEN are not cached; they occur
 + * a maximum length of NAMECACHE_MAXLEN are not cached; they occur
   * infrequently in any case, and are almost never of interest.
   *
   * Upon reaching the last segment of a path, if the reference
 @@ -148,7 +148,7 @@ cache_lookup(struct vnode *dvp, struct v
   cnp-cn_flags = ~MAKEENTRY;
   return (-1);
   }
 - if (cnp-cn_namelen  NCHNAMLEN) {
 + if (cnp-cn_namelen  NAMECACHE_MAXLEN) {
   nchstats.ncs_long++;
   cnp-cn_flags = ~MAKEENTRY;
   return (-1);
 @@ -342,7 +342,7 @@ cache_enter(struct vnode *dvp, struct vn
  {
   struct namecache *ncp, *lncp;
  
 - if (!doingcache || cnp-cn_namelen  NCHNAMLEN)
 + if (!doingcache || cnp-cn_namelen  NAMECACHE_MAXLEN)
   return;
  
   /*
 Index: sys/namei.h
 ===
 RCS file: /cvs/src/sys/sys/namei.h,v
 retrieving revision 1.27
 diff -u -p -r1.27 namei.h
 --- sys/namei.h   30 Sep 2011 03:43:27 -  1.27
 +++ sys/namei.h   26 Mar 2013 08:58:58 -
 @@ -165,7 +165,7 @@ struct nameidata {
   * names looked up by namei.
   */
  
 -#define  NCHNAMLEN   31  /* maximum name segment length we 
 bother with */
 +#define  NAMECACHE_MAXLEN31  /* maximum name segment length 
 we bother with */
  
  struct   namecache {
   TAILQ_ENTRY(namecache) nc_lru;  /* Regular Entry LRU chain */
 @@ -177,7 +177,7 @@ structnamecache {
   struct  vnode *nc_vp;   /* vnode the name refers to */
   u_long  nc_vpid;/* capability number of nc_vp */
   charnc_nlen;/* length of name */
 - charnc_name[NCHNAMLEN]; /* segment name */
 + charnc_name[NAMECACHE_MAXLEN];  /* segment name */
  };
  
  #ifdef _KERNEL
 
 

goodbye to some isa devices

[Ted Unangst]

These isa devs are already disabled and not particularly popular among
our users.  affected: tcic, sea, wds, eg, el

Index: arch/i386/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/i386/conf/GENERIC,v
retrieving revision 1.744
diff -u -p -r1.744 GENERIC
--- arch/i386/conf/GENERIC  15 Mar 2013 09:10:52 -  1.744
+++ arch/i386/conf/GENERIC  26 Mar 2013 08:20:40 -
@@ -188,7 +188,6 @@ nvt*at iic? # Novoton 
W83795G
 pcic0  at isa? port 0x3e0 iomem 0xd iosiz 0x1
 pcic1  at isa? port 0x3e2 iomem 0xe iosiz 0x4000
 pcic2  at isa? port 0x3e4 iomem 0xe iosiz 0x4000
-tcic0  at isa? disable port 0x240 iomem 0xd iosiz 0x1
 
 # ISA Plug-and-Play PCMCIA controllers
 #option DEBUG_ISAPNP
@@ -199,7 +198,6 @@ pcic*   at pci?
 
 # PCMCIA bus support
 pcmcia*at pcic?
-pcmcia* at tcic?
 
 # CardBus bus support
 cardbus*   at cardslot?
@@ -464,13 +462,10 @@ siop* at pci? # NCR 538XX SCSI control
 adv*   at pci? # AdvanSys 1200A/B and ULTRA SCSI
 adw*   at pci? # AdvanSys ULTRA WIDE SCSI
 pcscp* at pci? # AMD 53c974 PCscsi-PCI SCSI
-sea0   at isa? disable iomem 0xc8000 irq 5 # Seagate ST0[12] SCSI controllers
 trm*   at pci? # Tekram DC-3x5U SCSI Controllers
 uha0   at isa? port 0x330  # UltraStor [13]4f SCSI controllers
 uha1   at isa? disable port 0x334 # UltraStor [13]4f SCSI controllers
 uha*   at eisa?# UltraStor 24f SCSI controllers
-wds0   at isa? disable port 0x350 irq 15 drq 6 # WD7000 and TMC-7000 
controllers
-#wds1  at isa? port 0x358 irq 11 drq 5
 
 scsibus* at scsi?
 sd*at scsibus? # SCSI disk drives
@@ -511,8 +506,6 @@ ne0 at isa? port 0x240 irq 9# NE[12]00
 ne1at isa? port 0x300 irq 10   # NE[12]000 ethernet
 ne2at isa? port 0x280 irq 9# NE[12]000 ethernet
 ne*at isapnp?  # NE[12]000 PnP ethernet
-eg0at isa? disable port 0x310 irq 5# 3C505/Etherlink+ ethernet
-el0at isa? disable port 0x300 irq 9# 3C501 ethernet
 ep0at isa? # 3C509 ethernet
 ep*at isapnp?  # 3C509 PnP ethernet
 ep*at isa? # 3C509 ethernet
Index: arch/i386/conf/RAMDISK_CD
===
RCS file: /cvs/src/sys/arch/i386/conf/RAMDISK_CD,v
retrieving revision 1.194
diff -u -p -r1.194 RAMDISK_CD
--- arch/i386/conf/RAMDISK_CD   16 Nov 2012 02:15:38 -  1.194
+++ arch/i386/conf/RAMDISK_CD   26 Mar 2013 08:19:13 -
@@ -223,13 +223,11 @@ siop* at pci? # NCR 538XX SCSI control
 adv*   at pci? # AdvanSys 1200A/B and ULTRA SCSI
 adw*   at pci? # AdvanSys ULTRA WIDE SCSI
 pcscp* at pci? # AMD 53c974 PCscsi-PCI SCSI
-sea0   at isa? disable iomem 0xc8000 irq 5 # Seagate ST0[12] SCSI 
controllers
 trm*   at pci? # Tekram DC-3x5U SCSI Controllers
 uha0   at isa? port 0x330  # UltraStor [13]4f SCSI controllers
 uha1   at isa? disable port 0x334 # UltraStor [13]4f SCSI controllers
 uha*   at eisa?# UltraStor 24f SCSI controllers
-wds0   at isa? disable port 0x350 irq 15 drq 6 # WD7000 and TMC-7000 
controllers
-#wds1  at isa? port 0x358 irq 11 drq 5
+
 softraid0  at root # Software RAID
 
 # I2O
@@ -272,8 +270,6 @@ ne0 at isa? port 0x240 irq 9# NE[12]000
 ne1at isa? port 0x300 irq 10   # NE[12]000 ethernet
 ne2at isa? port 0x280 irq 9# NE[12]000 ethernet
 ne*at isapnp?  # NE[12]000 PnP ethernet
-eg0at isa? disable port 0x310 irq 5 # 3C505/Etherlink+ ethernet
-el0at isa? disable port 0x300 irq 9 # 3C501 ethernet
 ep0at isa? # 3C509 ethernet
 ep*at isa? # 3C509 ethernet
 ep*at isapnp?  # 3C509 PnP ethernet
Index: arch/i386/conf/files.i386
===
RCS file: /cvs/src/sys/arch/i386/conf/files.i386,v
retrieving revision 1.211
diff -u -p -r1.211 files.i386
--- arch/i386/conf/files.i386   6 Sep 2012 20:20:30 -   1.211
+++ arch/i386/conf/files.i386   26 Mar 2013 08:19:33 -
@@ -362,12 +362,6 @@ file   dev/isa/i82365_isapnp.c pcic_isapnp
 # Code common to ISA and ISAPnP attachments
 file   dev/isa/i82365_isasubr.cpcic_isa | pcic_isapnp | pcic_pci
 
-# Databook TCIC/2 pcmcia/isa bridge
-device tcic: pcmciabus
-file   dev/ic/tcic2.c  tcic
-attach tcic at isa with tcic_isa
-file   dev/isa/tcic2_isa.c tcic_isa
-
 #
 # Machine-independent PCMCIA drivers
 #
Index: dev/isa/files.isa
===
RCS file: 

Re: rename NCHNAMLEN

[Ted Unangst]

On Tue, Mar 26, 2013 at 10:09, Mark Kettenis wrote:
 Date: Tue, 26 Mar 2013 05:03:59 -0400
 From: Ted Unangst t...@tedunangst.com

 it's 2013. we don't have to pay extra for vowels.
 
 Even in 2013, my terminals are still 80 columns wide.  This makes some
 of the lines wrap.  Not really an improvement if you ask me.

oops, sorry, mine were a little wider and i didn't notice. easy to fix.

besides improving readability (imo), i find it much easier typing real
words, even if they're a little longer. i can visually confirm that
i'm actually grepping for the identifier used by the code and not some
subtly transposed variant.

Index: kern/vfs_cache.c
===
RCS file: /cvs/src/sys/kern/vfs_cache.c,v
retrieving revision 1.34
diff -u -p -r1.34 vfs_cache.c
--- kern/vfs_cache.c4 Jan 2012 18:11:51 -   1.34
+++ kern/vfs_cache.c26 Mar 2013 08:59:59 -
@@ -48,7 +48,7 @@
 
 /*
  * For simplicity (and economy of storage), names longer than
- * a maximum length of NCHNAMLEN are not cached; they occur
+ * a maximum length of NAMECACHE_MAXLEN are not cached; they occur
  * infrequently in any case, and are almost never of interest.
  *
  * Upon reaching the last segment of a path, if the reference
@@ -148,7 +148,7 @@ cache_lookup(struct vnode *dvp, struct v
cnp-cn_flags = ~MAKEENTRY;
return (-1);
}
-   if (cnp-cn_namelen  NCHNAMLEN) {
+   if (cnp-cn_namelen  NAMECACHE_MAXLEN) {
nchstats.ncs_long++;
cnp-cn_flags = ~MAKEENTRY;
return (-1);
@@ -342,7 +342,7 @@ cache_enter(struct vnode *dvp, struct vn
 {
struct namecache *ncp, *lncp;
 
-   if (!doingcache || cnp-cn_namelen  NCHNAMLEN)
+   if (!doingcache || cnp-cn_namelen  NAMECACHE_MAXLEN)
return;
 
/*
Index: sys/namei.h
===
RCS file: /cvs/src/sys/sys/namei.h,v
retrieving revision 1.27
diff -u -p -r1.27 namei.h
--- sys/namei.h 30 Sep 2011 03:43:27 -  1.27
+++ sys/namei.h 26 Mar 2013 09:23:43 -
@@ -165,7 +165,7 @@ struct nameidata {
  * names looked up by namei.
  */
 
-#defineNCHNAMLEN   31  /* maximum name segment length we 
bother with */
+#defineNAMECACHE_MAXLEN 31 /* maximum name segment length we bother 
with */
 
 struct namecache {
TAILQ_ENTRY(namecache) nc_lru;  /* Regular Entry LRU chain */
@@ -177,7 +177,7 @@ struct  namecache {
struct  vnode *nc_vp;   /* vnode the name refers to */
u_long  nc_vpid;/* capability number of nc_vp */
charnc_nlen;/* length of name */
-   charnc_name[NCHNAMLEN]; /* segment name */
+   charnc_name[NAMECACHE_MAXLEN];  /* segment name */
 };
 
 #ifdef _KERNEL
Index: nfs/nfs_vnops.c
===
RCS file: /cvs/src/sys/nfs/nfs_vnops.c,v
retrieving revision 1.140
diff -u -p -r1.140 nfs_vnops.c
--- nfs/nfs_vnops.c 17 Nov 2012 22:28:26 -  1.140
+++ nfs/nfs_vnops.c 26 Mar 2013 09:22:26 -
@@ -2455,7 +2456,8 @@ nfs_readdirplusrpc(struct vnode *vp, str
info.nmi_md = mdsav2;
dp-d_type = IFTODT(
VTTOIF(np-n_vattr.va_type));
-   if (cnp-cn_namelen = NCHNAMLEN) {
+   if (cnp-cn_namelen =
+   NAMECACHE_MAXLEN) {
ndp-ni_vp = newvp;
cache_purge(ndp-ni_dvp);
nfs_cache_enter(ndp-ni_dvp,

Intel D945GPT on recently built -current running with framebuffer all VCONs

[Rod Whitworth]

OpenBSD 5.3-current (GENERIC) #11: Tue Mar 26 13:32:47 EST 2013
r...@nero.witworx.com:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Celeron(R) D CPU 3.20GHz (GenuineIntel 686-class) 3.21 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,CNXT-ID,CX16,xTPR,PDCM,LAHF
real mem  = 1063272448 (1014MB)
avail mem = 1034477568 (986MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 05/04/07, SMBIOS rev. 2.3 @ 0xe5410 (31 
entries)
bios0: vendor Intel Corp. version NT94510J.86A.4078.2007.0504.0047 date 
05/04/2007
bios0: Intel Corporation D945GTP
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC WDDT MCFG ASF! HPET SSDT
acpi0: wakeup devices SLPB(S4) P32_(S4) UAR1(S4) UAR2(S4) PEX0(S4) PEX1(S4) 
PEX2(S4) PEX3(S4) PEX4(S4) PEX5(S4) UHC1(S3) UHC2(S3) UHC3(S3) UHC4(S3) 
EHCI(S3) AC9M(S4) AZAL(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 133MHz
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 2
acpimcfg0 at acpi0 addr 0xf000, bus 0-127
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 4 (P32_)
acpiprt2 at acpi0: bus 1 (PEX0)
acpiprt3 at acpi0: bus -1 (PEX1)
acpiprt4 at acpi0: bus 2 (PEX2)
acpiprt5 at acpi0: bus 3 (PEX3)
acpiprt6 at acpi0: bus -1 (PEX4)
acpiprt7 at acpi0: bus -1 (PEX5)
acpicpu0 at acpi0
acpibtn0 at acpi0: SLPB
bios0: ROM list: 0xc/0xae00!
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Intel 82945G Host rev 0x02
vga1 at pci0 dev 2 function 0 Intel 82945G Video rev 0x02
intagp0 at vga1
agp0 at intagp0: aperture at 0x4000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: apic 2 int 16
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x01: msi
azalia0: codecs: Sigmatel STAC9220/1
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x01: apic 2 int 17
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 2 Intel 82801GB PCIE rev 0x01: apic 2 int 18
pci2 at ppb1 bus 2
ppb2 at pci0 dev 28 function 3 Intel 82801GB PCIE rev 0x01: apic 2 int 19
pci3 at ppb2 bus 3
uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x01: apic 2 int 23
uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x01: apic 2 int 19
uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x01: apic 2 int 18
uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x01: apic 2 int 16
ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x01: apic 2 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
ppb3 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0xe1
pci4 at ppb3 bus 4
fxp0 at pci4 dev 8 function 0 Intel 82801GB LAN rev 0x01, i82562: apic 2 int 
20, address 00:16:76:90:35:68
inphy0 at fxp0 phy 1: i82562ET 10/100 PHY, rev. 0
ichpcib0 at pci0 dev 31 function 0 Intel 82801GB LPC rev 0x01: PM disabled
pciide0 at pci0 dev 31 function 1 Intel 82801GB IDE rev 0x01: DMA, channel 0 
configured to compatibility, channel 1 configured to compatibility
atapiscsi0 at pciide0 channel 0 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: ASUS, DRW-1814BL, 1.10 ATAPI 5/cdrom removable
cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 4
pciide0: channel 1 ignored (disabled)
pciide1 at pci0 dev 31 function 2 Intel 82801GB SATA rev 0x01: DMA, channel 0 
configured to native-PCI, channel 1 configured to native-PCI
pciide1: using apic 2 int 19 for native-PCI interrupt
wd0 at pciide1 channel 0 drive 0: ST3160815AS
wd0: 16-sector PIO, LBA48, 152627MB, 312581808 sectors
wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 6
ichiic0 at pci0 dev 31 function 3 Intel 82801GB SMBus rev 0x01: apic 2 int 19
iic0 at ichiic0
adt0 at iic0 addr 0x2e: emc6d100 rev 0x68
spdmem0 at iic0 addr 0x50: 512MB DDR2 SDRAM non-parity PC2-5300CL5
spdmem1 at iic0 addr 0x52: 512MB DDR2 SDRAM non-parity PC2-5300CL5
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 Intel UHCI root hub rev 1.00/1.00 addr 1
usb2 at uhci1: USB revision 1.0
uhub2 at usb2 Intel UHCI root hub rev 1.00/1.00 addr 1
usb3 at uhci2: USB revision 1.0
uhub3 at usb3 Intel UHCI root hub rev 1.00/1.00 addr 1
usb4 at uhci3: USB revision 1.0
uhub4 at usb4 Intel UHCI root hub rev 1.00/1.00 addr 1
isa0 at ichpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
npx0 at 

Re: Intel D945GPT on recently built -current running with framebuffer and all VCONs

[Rod Whitworth]

I have sent the previous message to dmesg@ and to this list so that the
involved devs can see that not only the Intel 915 stuff works but so
does the D945.

Hope this is useful to jsg@  co.

Rod/

*** NOTE *** Please DO NOT CC me. I am subscribed to the list.
Mail to the sender address that does not originate at the list server is 
tarpitted. The reply-to: address is provided for those who feel compelled to 
reply off list. Thankyou.

Rod/
---
This life is not the real thing.
It is not even in Beta.
If it was, then OpenBSD would already have a man page for it.

Re: goodbye to some isa devices

[Mark Kettenis]

 Date: Tue, 26 Mar 2013 05:20:27 -0400
 From: Ted Unangst t...@tedunangst.com
 
 These isa devs are already disabled and not particularly popular among
 our users.  affected: tcic, sea, wds, eg, el

The reason these devices are disabled is probably that their probe
routines are destructive.  So the fact that they are disabled doesn't
necessarily mean that they don't work properly.

I don't think maintaining these drivers is currently a huge burden on
us.  But decoupling them from the build will almost certainly lead to
some degree of bitrot.

 Index: arch/i386/conf/GENERIC
 ===
 RCS file: /cvs/src/sys/arch/i386/conf/GENERIC,v
 retrieving revision 1.744
 diff -u -p -r1.744 GENERIC
 --- arch/i386/conf/GENERIC15 Mar 2013 09:10:52 -  1.744
 +++ arch/i386/conf/GENERIC26 Mar 2013 08:20:40 -
 @@ -188,7 +188,6 @@ nvt*  at iic? # Novoton 
 W83795G
  pcic0at isa? port 0x3e0 iomem 0xd iosiz 0x1
  pcic1at isa? port 0x3e2 iomem 0xe iosiz 0x4000
  pcic2at isa? port 0x3e4 iomem 0xe iosiz 0x4000
 -tcic0at isa? disable port 0x240 iomem 0xd iosiz 0x1
  
  # ISA Plug-and-Play PCMCIA controllers
  #option DEBUG_ISAPNP
 @@ -199,7 +198,6 @@ pcic* at pci?
  
  # PCMCIA bus support
  pcmcia*  at pcic?
 -pcmcia* at tcic?
  
  # CardBus bus support
  cardbus* at cardslot?
 @@ -464,13 +462,10 @@ siop*   at pci? # NCR 538XX SCSI control
  adv* at pci? # AdvanSys 1200A/B and ULTRA SCSI
  adw* at pci? # AdvanSys ULTRA WIDE SCSI
  pcscp*   at pci? # AMD 53c974 PCscsi-PCI SCSI
 -sea0 at isa? disable iomem 0xc8000 irq 5 # Seagate ST0[12] SCSI controllers
  trm* at pci? # Tekram DC-3x5U SCSI Controllers
  uha0 at isa? port 0x330  # UltraStor [13]4f SCSI controllers
  uha1 at isa? disable port 0x334 # UltraStor [13]4f SCSI controllers
  uha* at eisa?# UltraStor 24f SCSI controllers
 -wds0 at isa? disable port 0x350 irq 15 drq 6 # WD7000 and TMC-7000 
 controllers
 -#wds1at isa? port 0x358 irq 11 drq 5
  
  scsibus* at scsi?
  sd*  at scsibus? # SCSI disk drives
 @@ -511,8 +506,6 @@ ne0   at isa? port 0x240 irq 9# 
 NE[12]00
  ne1  at isa? port 0x300 irq 10   # NE[12]000 ethernet
  ne2  at isa? port 0x280 irq 9# NE[12]000 ethernet
  ne*  at isapnp?  # NE[12]000 PnP ethernet
 -eg0  at isa? disable port 0x310 irq 5# 3C505/Etherlink+ ethernet
 -el0  at isa? disable port 0x300 irq 9# 3C501 ethernet
  ep0  at isa? # 3C509 ethernet
  ep*  at isapnp?  # 3C509 PnP ethernet
  ep*  at isa? # 3C509 ethernet
 Index: arch/i386/conf/RAMDISK_CD
 ===
 RCS file: /cvs/src/sys/arch/i386/conf/RAMDISK_CD,v
 retrieving revision 1.194
 diff -u -p -r1.194 RAMDISK_CD
 --- arch/i386/conf/RAMDISK_CD 16 Nov 2012 02:15:38 -  1.194
 +++ arch/i386/conf/RAMDISK_CD 26 Mar 2013 08:19:13 -
 @@ -223,13 +223,11 @@ siop*   at pci? # NCR 538XX SCSI control
  adv* at pci? # AdvanSys 1200A/B and ULTRA SCSI
  adw* at pci? # AdvanSys ULTRA WIDE SCSI
  pcscp*   at pci? # AMD 53c974 PCscsi-PCI SCSI
 -sea0 at isa? disable iomem 0xc8000 irq 5 # Seagate ST0[12] SCSI 
 controllers
  trm* at pci? # Tekram DC-3x5U SCSI Controllers
  uha0 at isa? port 0x330  # UltraStor [13]4f SCSI controllers
  uha1 at isa? disable port 0x334 # UltraStor [13]4f SCSI controllers
  uha* at eisa?# UltraStor 24f SCSI controllers
 -wds0 at isa? disable port 0x350 irq 15 drq 6 # WD7000 and TMC-7000 
 controllers
 -#wds1at isa? port 0x358 irq 11 drq 5
 +
  softraid0at root # Software RAID
  
  # I2O
 @@ -272,8 +270,6 @@ ne0   at isa? port 0x240 irq 9# NE[12]000
  ne1  at isa? port 0x300 irq 10   # NE[12]000 ethernet
  ne2  at isa? port 0x280 irq 9# NE[12]000 ethernet
  ne*  at isapnp?  # NE[12]000 PnP ethernet
 -eg0  at isa? disable port 0x310 irq 5 # 3C505/Etherlink+ ethernet
 -el0  at isa? disable port 0x300 irq 9 # 3C501 ethernet
  ep0  at isa? # 3C509 ethernet
  ep*  at isa? # 3C509 ethernet
  ep*  at isapnp?  # 3C509 PnP ethernet
 Index: arch/i386/conf/files.i386
 ===
 RCS file: /cvs/src/sys/arch/i386/conf/files.i386,v
 retrieving revision 1.211
 diff -u -p -r1.211 files.i386
 --- arch/i386/conf/files.i386 6 Sep 2012 20:20:30 -   1.211
 +++ arch/i386/conf/files.i386 26 Mar 2013 08:19:33 -
 @@ -362,12 +362,6 @@ file dev/isa/i82365_isapnp.c 

Re: goodbye to some isa devices

[Ted Unangst]

On Tue, Mar 26, 2013 at 11:13, Mark Kettenis wrote:
 Date: Tue, 26 Mar 2013 05:20:27 -0400
 From: Ted Unangst t...@tedunangst.com

 These isa devs are already disabled and not particularly popular among
 our users.  affected: tcic, sea, wds, eg, el
 
 The reason these devices are disabled is probably that their probe
 routines are destructive.  So the fact that they are disabled doesn't
 necessarily mean that they don't work properly.
 
 I don't think maintaining these drivers is currently a huge burden on
 us.  But decoupling them from the build will almost certainly lead to
 some degree of bitrot.

Perfection is achieved when there's nothing left to take away. :)

It's not so much that we spend time maintaining the source, but I do
spend time compiling it. And I have to download it (3 times!) every
time I install a new snapshot. Cumulatively, I've probably spent hours
of my life waiting for these drivers' bits to go from here to there. I
will selfishly claim that if I save five minutes of time this year by
not compiling these files, that right there is more benefit than
retaining support.

I targeted disabled devices figuring they were least likely to be
missed, but I honestly question the utility of any of these ISA
network and SCSI drivers. They're going to be slow as shit. Besides,
at this point, due to adding so many new drivers (kernel size has
more than doubled in last ten years) the minimum RAM requirement is
basically past ISA only machines. The segment of machines that lack
PCI but support 32M or more of RAM is very narrow. And unlike sparc or
vax, I don't think running OpenBSD on some ancient 486 is historically
interesting.

Re: uthum(4): Microdia's USB TEMPer variant

[SASANO Takayoshi]

Hello, Luis.

Now I am rewriting a driver for Microdia's USB TEMPer with
advices from yuo@ and deraadt@.

Please wait a while and thank you for trying my patch.

Thanks.
-- 
SASANO Takayoshi u...@mx5.nisiq.net

Re: goodbye to some isa devices

[Loganaden Velvindron]

On Tue, Mar 26, 2013 at 5:09 PM, Ted Unangst t...@tedunangst.com wrote:
 On Tue, Mar 26, 2013 at 11:13, Mark Kettenis wrote:
 Date: Tue, 26 Mar 2013 05:20:27 -0400
 From: Ted Unangst t...@tedunangst.com

 These isa devs are already disabled and not particularly popular among
 our users.  affected: tcic, sea, wds, eg, el

 The reason these devices are disabled is probably that their probe
 routines are destructive.  So the fact that they are disabled doesn't
 necessarily mean that they don't work properly.

 I don't think maintaining these drivers is currently a huge burden on
 us.  But decoupling them from the build will almost certainly lead to
 some degree of bitrot.

 Perfection is achieved when there's nothing left to take away. :)

 It's not so much that we spend time maintaining the source, but I do
 spend time compiling it. And I have to download it (3 times!) every
 time I install a new snapshot. Cumulatively, I've probably spent hours
 of my life waiting for these drivers' bits to go from here to there. I
 will selfishly claim that if I save five minutes of time this year by
 not compiling these files, that right there is more benefit than
 retaining support.

 I targeted disabled devices figuring they were least likely to be
 missed, but I honestly question the utility of any of these ISA
 network and SCSI drivers. They're going to be slow as shit. Besides,
 at this point, due to adding so many new drivers (kernel size has
 more than doubled in last ten years) the minimum RAM requirement is
 basically past ISA only machines. The segment of machines that lack
 PCI but support 32M or more of RAM is very narrow. And unlike sparc or
 vax, I don't think running OpenBSD on some ancient 486 is historically
 interesting.


I still run OpenBSD as a wireless AP on a pentium-1 166Mhz with 48Mb RAM, and
3 PCI cards. ISA sound card was removed :-)



-- 
Brightest day,
Blackest night,
No bug shall escape my sight,
And those who worship evil's mind,
be wary of my powers,
puffy lantern's light !

Re: goodbye to some isa devices

[Kenneth R Westerback]

On Tue, Mar 26, 2013 at 09:09:14AM -0400, Ted Unangst wrote:
 On Tue, Mar 26, 2013 at 11:13, Mark Kettenis wrote:
  Date: Tue, 26 Mar 2013 05:20:27 -0400
  From: Ted Unangst t...@tedunangst.com
 
  These isa devs are already disabled and not particularly popular among
  our users.  affected: tcic, sea, wds, eg, el
  
  The reason these devices are disabled is probably that their probe
  routines are destructive.  So the fact that they are disabled doesn't
  necessarily mean that they don't work properly.
  
  I don't think maintaining these drivers is currently a huge burden on
  us.  But decoupling them from the build will almost certainly lead to
  some degree of bitrot.
 
 Perfection is achieved when there's nothing left to take away. :)
 
 It's not so much that we spend time maintaining the source, but I do
 spend time compiling it. And I have to download it (3 times!) every
 time I install a new snapshot. Cumulatively, I've probably spent hours
 of my life waiting for these drivers' bits to go from here to there. I
 will selfishly claim that if I save five minutes of time this year by
 not compiling these files, that right there is more benefit than
 retaining support.
 
 I targeted disabled devices figuring they were least likely to be
 missed, but I honestly question the utility of any of these ISA
 network and SCSI drivers. They're going to be slow as shit. Besides,
 at this point, due to adding so many new drivers (kernel size has
 more than doubled in last ten years) the minimum RAM requirement is
 basically past ISA only machines. The segment of machines that lack
 PCI but support 32M or more of RAM is very narrow. And unlike sparc or
 vax, I don't think running OpenBSD on some ancient 486 is historically
 interesting.
 

The ISA SCSI drivers have certainly received no love from me as a
deliberate policy. This of course may be good or bad for their
functionality. :-)

And then there are the EISA SCSI drivers.

 Ken

Re: uvm combine clearbits

[Bob Beck]

On Tue, Mar 26, 2013 at 1:51 AM, Ted Unangst t...@tedunangst.com wrote:
 uvm_pagefree calls atomic_clearbits_int too many times.

Is there some sort of evidence that this is a problem - performace or
stability wise?

Just
 accumulate the flags we need to zap, then do it once.


I get what you're trying to do, but given that there are already
enough cases of this in that code and you're now just making a few
special cases of saving the flag to avoid a few calls I don't think
it's worth the added cleverness in code that people like me have to
spend a lot of time wading through looking for errors - particularly
the types of errors that involve can this sleep or not...  So I
don't personaly think this turdshining is worth it. I would
rather just see the bits set and know they are set just as in every other case.


 Index: uvm_page.c
 ===
 RCS file: /cvs/src/sys/uvm/uvm_page.c,v
 retrieving revision 1.122
 diff -u -p -r1.122 uvm_page.c
 --- uvm_page.c  12 Mar 2013 21:10:11 -  1.122
 +++ uvm_page.c  26 Mar 2013 07:45:56 -
 @@ -1053,6 +1053,7 @@ void
  uvm_pagefree(struct vm_page *pg)
  {
 int saved_loan_count = pg-loan_count;
 +   u_int flags_to_clear = 0;

  #ifdef DEBUG
 if (pg-uobject == (void *)0xdeadbeef 
 @@ -1115,7 +1116,7 @@ uvm_pagefree(struct vm_page *pg)

 if (pg-pg_flags  PQ_ACTIVE) {
 TAILQ_REMOVE(uvm.page_active, pg, pageq);
 -   atomic_clearbits_int(pg-pg_flags, PQ_ACTIVE);
 +   flags_to_clear |= PQ_ACTIVE;
 uvmexp.active--;
 }
 if (pg-pg_flags  PQ_INACTIVE) {
 @@ -1123,7 +1124,7 @@ uvm_pagefree(struct vm_page *pg)
 TAILQ_REMOVE(uvm.page_inactive_swp, pg, pageq);
 else
 TAILQ_REMOVE(uvm.page_inactive_obj, pg, pageq);
 -   atomic_clearbits_int(pg-pg_flags, PQ_INACTIVE);
 +   flags_to_clear |= PQ_INACTIVE;
 uvmexp.inactive--;
 }

 @@ -1138,15 +1139,16 @@ uvm_pagefree(struct vm_page *pg)
 if (pg-uanon) {
 pg-uanon-an_page = NULL;
 pg-uanon = NULL;
 -   atomic_clearbits_int(pg-pg_flags, PQ_ANON);
 +   flags_to_clear |= PQ_ANON;
 }

 /*
  * Clean page state bits.
  */
 -   atomic_clearbits_int(pg-pg_flags, PQ_AOBJ); /* XXX: find culprit */
 -   atomic_clearbits_int(pg-pg_flags, PQ_ENCRYPT|
 -   PG_ZERO|PG_FAKE|PG_BUSY|PG_RELEASED|PG_CLEAN|PG_CLEANCHK);
 +   flags_to_clear |= PQ_AOBJ; /* XXX: find culprit */
 +   flags_to_clear |= PQ_ENCRYPT|PG_ZERO|PG_FAKE|PG_BUSY|PG_RELEASED|
 +   PG_CLEAN|PG_CLEANCHK;
 +   atomic_clearbits_int(pg-pg_flags, flags_to_clear);

 /*
  * and put on free queue

Re: goodbye to some isa devices

[Ted Unangst]

On Tue, Mar 26, 2013 at 14:26, Creamy wrote:

 but I honestly question the utility of any of these ISA
 network and SCSI drivers.
 
 Perhaps somebody who is new to coding might be able to learn something
 from them?

The last thing this world needs is more programmers who learned to
code by reading old unmaintained ISA drivers.

write_opt=nodir support for ustar

[Vadim Zhukov]

Any objections for supporting write_opt=nodir for ustar archives?
Another option for Ruby gems will be going with GNU tar. :(

--
  WBR,
Vadim Zhukov


Index: options.c
===
RCS file: /cvs/src/bin/pax/options.c,v
retrieving revision 1.76
diff -u -p -r1.76 options.c
--- options.c   4 Dec 2012 02:24:45 -   1.76
+++ options.c   26 Mar 2013 16:16:45 -
@@ -119,7 +119,7 @@ FSUB fsub[] = {
 /* 5: POSIX USTAR */
{ustar, 10240, BLKMULT, 0, 1, BLKMULT, 0, ustar_id, ustar_strd,
ustar_rd, tar_endrd, ustar_stwr, ustar_wr, tar_endwr, tar_trail,
-   rd_wrfile, wr_rdfile, bad_opt},
+   rd_wrfile, wr_rdfile, tar_opt},
 };
 #defineF_OCPIO 0   /* format when called as cpio -6 */
 #defineF_ACPIO 1   /* format when called as cpio -c */
Index: tar.c
===
RCS file: /cvs/src/bin/pax/tar.c,v
retrieving revision 1.44
diff -u -p -r1.44 tar.c
--- tar.c   4 Dec 2012 02:24:45 -   1.44
+++ tar.c   26 Mar 2013 16:16:45 -
@@ -914,6 +914,12 @@ ustar_wr(ARCHD *arcn)
}
 
/*
+* user asked that dirs not be written to the archive
+*/
+   if (arcn-type == PAX_DIR  tar_nodir)
+   return (1);
+
+   /*
 * check the length of the linkname
 */
if (((arcn-type == PAX_SLK) || (arcn-type == PAX_HLK) ||

Re: goodbye to some isa devices

[Mark Kettenis]

 Date: Tue, 26 Mar 2013 09:09:14 -0400
 From: Ted Unangst t...@tedunangst.com
 
 On Tue, Mar 26, 2013 at 11:13, Mark Kettenis wrote:
  Date: Tue, 26 Mar 2013 05:20:27 -0400
  From: Ted Unangst t...@tedunangst.com
 
  These isa devs are already disabled and not particularly popular among
  our users.  affected: tcic, sea, wds, eg, el
  
  The reason these devices are disabled is probably that their probe
  routines are destructive.  So the fact that they are disabled doesn't
  necessarily mean that they don't work properly.
  
  I don't think maintaining these drivers is currently a huge burden on
  us.  But decoupling them from the build will almost certainly lead to
  some degree of bitrot.
 
 Perfection is achieved when there's nothing left to take away. :)
 
 It's not so much that we spend time maintaining the source, but I do
 spend time compiling it. And I have to download it (3 times!) every
 time I install a new snapshot. Cumulatively, I've probably spent hours
 of my life waiting for these drivers' bits to go from here to there. I
 will selfishly claim that if I save five minutes of time this year by
 not compiling these files, that right there is more benefit than
 retaining support.
 
 I targeted disabled devices figuring they were least likely to be
 missed, but I honestly question the utility of any of these ISA
 network and SCSI drivers. They're going to be slow as shit. Besides,
 at this point, due to adding so many new drivers (kernel size has
 more than doubled in last ten years) the minimum RAM requirement is
 basically past ISA only machines. The segment of machines that lack
 PCI but support 32M or more of RAM is very narrow. And unlike sparc or
 vax, I don't think running OpenBSD on some ancient 486 is historically
 interesting.

Probably true.  I'm not necessarily opposed.  Although it would make
me sad if we didn't run on a machine that some other OS would still
support.

Re: goodbye to some isa devices

[Creamy]

Sorry, but I think there is some seriously strange reasoning going on here.

 It's not so much that we spend time maintaining the source, but I do
 spend time compiling it.

Err, don't you use a custom kernel configuration?  Unless you're working
on those drivers, why are you compiling them in anyway?  Yes, I've read
the FAQ, and I know we're all supposed to be using the GENERIC kernel,
but who does?  Mine is customisted beyond recognition.

 And I have to download it (3 times!) every
 time I install a new snapshot. Cumulatively, I've probably spent hours
 of my life waiting for these drivers' bits to go from here to there. I
 will selfishly claim that if I save five minutes of time this year by
 not compiling these files, that right there is more benefit than
 retaining support.

There is certainly a case that five minutes multiplied by the number of
OpenBSD users does add up to a significant amount of wasted time, but
why are you assuming that these disabled by default drivers are not used
by a significant number of people?

 I targeted disabled devices figuring they were least likely to be
 missed,

I disagree here, there are plenty of enabled devices that nobody owns or
cares about.  The two issues are completely separate.

 but I honestly question the utility of any of these ISA
 network and SCSI drivers.

Perhaps somebody who is new to coding might be able to learn something
from them?

 Besides,
 at this point, due to adding so many new drivers (kernel size has
 more than doubled in last ten years) the minimum RAM requirement is
 basically past ISA only machines.

This is an issue for the install media.  After that, you should be
running a custom kernel if you're using an obsolete machine.

 The segment of machines that lack
 PCI but support 32M or more of RAM is very narrow.

True.

 And unlike sparc or vax, I don't think running OpenBSD on some
 ancient 486 is historically interesting.

But OpenBSD doesn't run on the really interesting Vaxen, anyway.  If it
did, I'd have an 11-series Vax here tomorrow.  I even have some 9-track
tape in the loft, just waiting for it.

The truth is, running OpenBSD on a MicroVax, is no more fun than an
old 486, it's just slower.

 boot

loginout.exe

oh, what nostalgia.  Not.  Have you ever used those machines, with their
crashing removable disk packs. and tape drives that unwound 2400 feet
of tape all over the place in just a few seconds?  You're seeing them
through rose-tinted glasses if you did.

Not to mention that the decent Vaxen need three phase power.  Great.

Looking to the future, when are we going to drop 486 support, anyway?

-- 
Creamy

Re: goodbye to some isa devices

[Todd T. Fries]

Penned by Ted Unangst on 20130326  8:09.14, we have:
| On Tue, Mar 26, 2013 at 11:13, Mark Kettenis wrote:
|  Date: Tue, 26 Mar 2013 05:20:27 -0400
|  From: Ted Unangst t...@tedunangst.com
| 
|  These isa devs are already disabled and not particularly popular among
|  our users.  affected: tcic, sea, wds, eg, el
|  
|  The reason these devices are disabled is probably that their probe
|  routines are destructive.  So the fact that they are disabled doesn't
|  necessarily mean that they don't work properly.
|  
|  I don't think maintaining these drivers is currently a huge burden on
|  us.  But decoupling them from the build will almost certainly lead to
|  some degree of bitrot.
| 
| Perfection is achieved when there's nothing left to take away. :)
| 
| It's not so much that we spend time maintaining the source, but I do
| spend time compiling it. And I have to download it (3 times!) every
| time I install a new snapshot. Cumulatively, I've probably spent hours
| of my life waiting for these drivers' bits to go from here to there. I
| will selfishly claim that if I save five minutes of time this year by
| not compiling these files, that right there is more benefit than
| retaining support.
| 
| I targeted disabled devices figuring they were least likely to be
| missed, but I honestly question the utility of any of these ISA
| network and SCSI drivers. They're going to be slow as shit. Besides,
| at this point, due to adding so many new drivers (kernel size has
| more than doubled in last ten years) the minimum RAM requirement is
| basically past ISA only machines. The segment of machines that lack
| PCI but support 32M or more of RAM is very narrow. And unlike sparc or
| vax, I don't think running OpenBSD on some ancient 486 is historically
| interesting.

I have some of these devices actually.  Haven't used them in a few
years, mainly due to office moves and boxes of unpacked unsorted stuff.
I do clearly recall that it is useful to only enable some isa devices if
one has them.

I guess the question is, are we moving to a world where isa is not
supported and/or supportable?

Sure, if I'm doing build tests I'm going to load a box with mem and the
fastest disks and nics I have.

If I'm testing hardware support and such, I'm going to want to get
thorough coverage of the drivers we build and purport to support.

I'd wager a bet that I could make my sea(4) scsi adapter work more
reliably than any variant of usb wi(4), so perhaps we should disable usb
wi(4) to save you time building instead?

Thanks,
-- 
Todd Fries .. t...@fries.net

 
|\  1.636.410.0632 (voice)
| Free Daemon Consulting, LLC\  1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com\  1.866.792.3418 (FAX)
| PO Box 16169, Oklahoma City, OK 73113  \  sip:freedae...@ekiga.net
| ..in support of free software solutions. \  sip:4052279...@ekiga.net
 \
 
  37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
http://todd.fries.net/pgp.txt

Re: goodbye to some isa devices

[Miod Vallat]

 These isa devs are already disabled and not particularly popular among
 our users.  affected: tcic, sea, wds, eg, el

No objection against removing them from kernel configs (or commenting
them out), but keep files.isa unchanged please.

Re: uvm combine clearbits

[Miod Vallat]

  uvm_pagefree calls atomic_clearbits_int too many times.
 
 Is there some sort of evidence that this is a problem - performace or
 stability wise?

Platforms which can't do ll/sc style atomic operations usually wrap
these operations within splhigh()/splx() calls, which are a tad
expensive.

In that particular diff, Ted makes sure to flip the bits only during the
time the vm_page is not on any TAILQ, and before it is put on the free
list.

This is narrow enough to me.

Re: goodbye to some isa devices

[Franco Fichtner]

On Mar 26, 2013, at 6:26 PM, Creamy cre...@nocrater.com wrote:

 but I honestly question the utility of any of these ISA
 network and SCSI drivers.
 
 Perhaps somebody who is new to coding might be able to learn something
 from them?

There is such a vast amount of code in the different BSD flavours
alone that it becomes very unlikely someone will stumble upon ISA
code bits, especially if one is a novice programmer. And how many
of those are old enough to have seen what ISA looks like nowadays?

Looking at diffs which remove ISA relevant stuff is probably the only
time they will see it -- that's educational *and* teducational at the
same time. Sorry for the bad pun.

 Looking to the future, when are we going to drop 486 support, anyway?

Now, that's a more interesting thing ask.

Re: goodbye to some isa devices

[Theo de Raadt]

I really don't see the point of removing these from the tree.  I just
don't see greater value from removal, vs retention. 

Sure you can remove their compilation in GENERIC by #'ing them there.
That I can understand.  But if you remove the lines, noone can ever
use them again because they won't know the locator information, so you
are making a decision for others.

Same thing with the stanzas in dev/isa/files.isa; if you remove those
then noone else can ever use the code.

If that is your goal, look at it this way.

You talk about time.  Removing them won't save you time; you just
spent time looking for some of the bits, and your diff is nowhere near
complete.  There will be bits everywhere all the way through the tree
all the way to the man pages, which you'll end up leaving for others,
so others will be compelled to clean that up, and not do something
else.  That's a real time loss.  I'm writing this mail, which is a
time loss.

Secondly, those drivers are not standing in the way of any changes in
the tree.  We are not changing any API they depend on.  There are too
many of these drivers to even consider changing an API that all of
these drivers depend on, and you will not attritition them down to a
manageable subset in any case.

Third, we don't know if someone is running them or not.  dmesglog is
not authoritative.

Re: goodbye to some isa devices

[Theo de Raadt]

 I don't think maintaining these drivers is currently a huge burden on
 us.  But decoupling them from the build will almost certainly lead to
 some degree of bitrot.

This 2nd sentence is the truth.  At least when something is coupled to
the build, it might warn us of the unintended consequences of something
else in the tree.  There is no point in half-disconnecting something
from the tree; it is just leaving a mess for someone else down the line.

Re: uvm combine clearbits

[Theo de Raadt]

   uvm_pagefree calls atomic_clearbits_int too many times.
  
  Is there some sort of evidence that this is a problem - performace or
  stability wise?
 
 Platforms which can't do ll/sc style atomic operations usually wrap
 these operations within splhigh()/splx() calls, which are a tad
 expensive.
 
 In that particular diff, Ted makes sure to flip the bits only during the
 time the vm_page is not on any TAILQ, and before it is put on the free
 list.
 
 This is narrow enough to me.

Same opinion.

Re: uvm combine clearbits

[Bob Beck]

On Tue, Mar 26, 2013 at 10:55 AM, Miod Vallat m...@online.fr wrote:
  uvm_pagefree calls atomic_clearbits_int too many times.

 Is there some sort of evidence that this is a problem - performace or
 stability wise?

 Platforms which can't do ll/sc style atomic operations usually wrap
 these operations within splhigh()/splx() calls, which are a tad
 expensive.

 In that particular diff, Ted makes sure to flip the bits only during the
 time the vm_page is not on any TAILQ, and before it is put on the free
 list.

 This is narrow enough to me.


Yeah, ok, in light of that explanation I'm better with this. No
objections here then.

Re: goodbye to some isa devices

[Alexey E. Suslikov]

Todd T. Fries todd at fries.net writes:

 I'd wager a bet that I could make my sea(4) scsi adapter work more
 reliably than any variant of usb wi(4), so perhaps we should disable usb
 wi(4) to save you time building instead?

My 2 cents.

Nuke tcic0 *and* pcic*:
* searching archives bring dmesgs from 3.x/4.x era,
* how big chances are to run 5.x on laptops with these
PCMCIA controllers?

Not sure about ancient 3Com's, but they are Ethernet at
least, in contract to Token-Ring device like tr*.

Do we support Token-Ring?

Cheers,
Alexey

Re: nfs pathconf

[Bob Beck]

Well, you're right about one thing - the comment there says that it should
just return EINVAL for nfs v2 - and I think it should - but that code returns
EINVAL for v3 - and that's wrong.  We have server side support for this in v3
and what we should probably be doing is actually doing the rpc call to the v3
server in the v3 case and returning what it returns - and doing EINVAL
in the v2 case.


On Tue, Mar 26, 2013 at 1:12 AM, Ted Unangst t...@tedunangst.com wrote:
 After an absence of 9 years, I make my triumphant return to sys/nfs.
 There are some silly programs out there (looking at you boost) that
 actually use pathconf instead of just hard coding 1024 for max path
 length. If you run them from nfs, fireworks ensue.

 Here's a pathconf implementation for nfs, copied mostly from ufs. Even
 if some of these values are lies, they're better than nothing. My
 theory is that the values you care about (NAME_MAX, PATH_MAX) are
 going to be right, and the values you don't (REC_MAX_XFER_SIZE) are
 harmless even if incorrect.

 Index: nfs_vnops.c
 ===
 RCS file: /cvs/src/sys/nfs/nfs_vnops.c,v
 retrieving revision 1.140
 diff -u -p -r1.140 nfs_vnops.c
 --- nfs_vnops.c 17 Nov 2012 22:28:26 -  1.140
 +++ nfs_vnops.c 26 Mar 2013 07:04:53 -
 @@ -61,6 +61,7 @@
  #include sys/hash.h
  #include sys/queue.h
  #include sys/specdev.h
 +#include sys/unistd.h

  #include uvm/uvm_extern.h

 @@ -2937,19 +2938,70 @@ loop:

  /*
   * Return POSIX pathconf information applicable to nfs.
 - *
 - * The NFS V2 protocol doesn't support this, so just return EINVAL
 - * for V2.
   */
  /* ARGSUSED */
  int
  nfs_pathconf(void *v)
  {
 -#if 0
 struct vop_pathconf_args *ap = v;
 -#endif
 +   struct nfsmount *nmp = VFSTONFS(ap-a_vp-v_mount);
 +   int error = 0;

 -   return (EINVAL);
 +   switch (ap-a_name) {
 +   case _PC_LINK_MAX:
 +   *ap-a_retval = LINK_MAX;
 +   break;
 +   case _PC_NAME_MAX:
 +   *ap-a_retval = NAME_MAX;
 +   break;
 +   case _PC_PATH_MAX:
 +   *ap-a_retval = PATH_MAX;
 +   break;
 +   case _PC_PIPE_BUF:
 +   *ap-a_retval = PIPE_BUF;
 +   break;
 +   case _PC_CHOWN_RESTRICTED:
 +   *ap-a_retval = 1;
 +   break;
 +   case _PC_NO_TRUNC:
 +   *ap-a_retval = 1;
 +   break;
 +   case _PC_PRIO_IO:
 +   *ap-a_retval = 0;
 +   break;
 +   case _PC_SYNC_IO:
 +   *ap-a_retval = 0;
 +   break;
 +   case _PC_ALLOC_SIZE_MIN:
 +   *ap-a_retval = NFS_FABLKSIZE;
 +   break;
 +   case _PC_FILESIZEBITS:
 +   *ap-a_retval = 64;
 +   break;
 +   case _PC_REC_INCR_XFER_SIZE:
 +   *ap-a_retval = min(nmp-nm_rsize, nmp-nm_wsize);
 +   break;
 +   case _PC_REC_MAX_XFER_SIZE:
 +   *ap-a_retval = -1; /* means ``unlimited'' */
 +   break;
 +   case _PC_REC_MIN_XFER_SIZE:
 +   *ap-a_retval = min(nmp-nm_rsize, nmp-nm_wsize);
 +   break;
 +   case _PC_REC_XFER_ALIGN:
 +   *ap-a_retval = PAGE_SIZE;
 +   break;
 +   case _PC_SYMLINK_MAX:
 +   *ap-a_retval = MAXPATHLEN;
 +   break;
 +   case _PC_2_SYMLINKS:
 +   *ap-a_retval = 1;
 +   break;
 +   default:
 +   error = EINVAL;
 +   break;
 +   }
 +
 +   return (error);
  }

  /*

Re: nfs pathconf

[Theo de Raadt]

 and doing EINVAL in the v2 case.

Which won't solve the problem described in his mail.

Re: goodbye to some isa devices

[Alexey E. Suslikov]

Alexey E. Suslikov alexey.suslikov at gmail.com writes:

 Not sure about ancient 3Com's, but they are Ethernet at
 least, in contract to Token-Ring device like tr*.
 
 Do we support Token-Ring?

Joystick driver?

Re: nfs pathconf

[Philip Guenther]

On Tue, Mar 26, 2013 at 10:53 AM, Bob Beck b...@obtuse.com wrote:
 Well, you're right about one thing - the comment there says that it should
 just return EINVAL for nfs v2 - and I think it should - but that code returns
 EINVAL for v3 - and that's wrong.  We have server side support for this in v3
 and what we should probably be doing is actually doing the rpc call to the v3
 server in the v3 case and returning what it returns -

Sure, though nfsv3's pathconf call only supports a small subset of
pathconf() values:

struct nfsv3_pathconf {
u_int32_t pc_linkmax;
u_int32_t pc_namemax;
u_int32_t pc_notrunc;
u_int32_t pc_chownrestricted;
u_int32_t pc_caseinsensitive;
u_int32_t pc_casepreserving;
};


 and doing EINVAL in the v2 case.

I'm with tedu and Theo on this: giving best guess answers will provide
a better result than returning EINVAL.


Philip Guenther

Re: goodbye to some isa devices

[Ted Unangst]

 If I'm testing hardware support and such, I'm going to want to get
 thorough coverage of the drivers we build and purport to support.

Next time mail in your dmesg! :)

 I'd wager a bet that I could make my sea(4) scsi adapter work more
 reliably than any variant of usb wi(4), so perhaps we should disable usb
 wi(4) to save you time building instead?

Actually, I deliberately excluded drivers with multiple bus attachments
because the attachment shim is usually pretty small. Unless we're
disabling wi at pcmcia too (and I don't think we are), there's not much
point in removing just the usb part. Just for the record.

Re: goodbye to some isa devices

[Franco Fichtner]

On Mar 26, 2013, at 10:06 PM, Creamy cre...@nocrater.com wrote:

 Looking to the future, when are we going to drop 486 support, anyway?
 
 Now, that's a more interesting thing ask.
 
 How much of the hardware survives now, anyway?  I mean at least the old
 Vaxen were, (and are), maintainable.  486 motherboard dies, what do you
 do?  Chances are it's a multi-layer pcb, so if traces go bad within it,
 a repair is going to be almost impossible.

From personal experience, the oldest things I've used *recently* was a
Pentium Pro a few years back for providing Internet connectivity. That
was when we barely had a single Mbit/s per line here in Germany. To be
honest, it was about 8 years ago. I know a case study means nothing,
so let me try another route.

You would only need to upgrade to the latest and greatest release if
one of the following is true:

(1) Your system is connected to the Internet and thus
requires frequent security updates.

(2) You want to run services that are bleeding edge
like OpenSMTPD out of the box.

(3) You are crazy.

But seriously, if there is no networking, there is no need to run a
recent release. And you will be able to run 5.3 in any case. And why
would you use networking anyway with such small throughput, the
likelihood of your tiny IBM disk (a, those were the days!)
failing on you any second now. All you've got there is a ticking
time bomb. Nobody in their right mind would have such a system as
mission critical infrastructure. :)

Re: nfs pathconf

[Bob Beck]

On Tue, Mar 26, 2013 at 11:58 AM, Theo de Raadt dera...@cvs.openbsd.org wrote:
 and doing EINVAL in the v2 case.

 Which won't solve the problem described in his mail.

Of course it will - in the NFS v3 case, and in theory you'll be
getting what the server supports.

I don't think we should go outside the nfs v2 spec and return values
we hope are ok in the nfs v2 case - remember here we're returning
the client values and hoping the server can support it. So what you're
saying is that it's better to return a potentially unsafe value, and
have filenames that a potential server might not handle?  I'm not
buying that.  in that special case of I'm running some software that
does this, I'd rather realize I'm running it on v2 that doesn't
support it by having it fail than just using the client side value and
hope like heck it works out.  Presumably, if I'm running v2, I'm
doing it for specefic reasons that v2 is better for and I know what
I'm doing.  I'd rather not have the client start to do v3 like things
on v2 just so things might work. - at that point I should be
noticing the error, and the fix is mount it v3

Re: nfs pathconf

[Ted Unangst]

On Tue, Mar 26, 2013 at 12:51, Bob Beck wrote:
 On Tue, Mar 26, 2013 at 11:58 AM, Theo de Raadt dera...@cvs.openbsd.org
 wrote:
 and doing EINVAL in the v2 case.

 Which won't solve the problem described in his mail.
 
 Of course it will - in the NFS v3 case, and in theory you'll be
 getting what the server supports.
 
 I don't think we should go outside the nfs v2 spec and return values
 we hope are ok in the nfs v2 case - remember here we're returning
 the client values and hoping the server can support it. So what you're
 saying is that it's better to return a potentially unsafe value, and
 have filenames that a potential server might not handle?  I'm not
 buying that.  in that special case of I'm running some software that

Well, there's a certain amount of stupidity in pathconf already.
PATH_MAX could cross a mount point and then become something else
entirely. (Actually, that's an argument for factoring it up and
handling it above the fs layer, but that's another diff.)

 does this, I'd rather realize I'm running it on v2 that doesn't
 support it by having it fail than just using the client side value and
 hope like heck it works out.  Presumably, if I'm running v2, I'm
 doing it for specefic reasons that v2 is better for and I know what
 I'm doing.  I'd rather not have the client start to do v3 like things
 on v2 just so things might work. - at that point I should be
 noticing the error, and the fix is mount it v3

Maybe you're using amd? hahaha. I don't think the nfs v2 spec demands
that pathconf not work, it just doesn't support it because it didn't
exist.

Let me explain my philosophy towards pathconf. It's like those
configure scripts that check to see if you have a working version of
strcpy. If you don't, you are so utterly boned you'll find out soon
enough. If the nfs server isn't going to let you create a 255
character name, you'll find out soon enough. pathconf is one of those
design by committee anti-portability features. It's silly it's even in
the kernel. It should be a libc stub that whispers sweet nothings in
your ear.

Re: goodbye to some isa devices

[Franco Fichtner]

On Mar 26, 2013, at 11:11 PM, Creamy cre...@nocrater.com wrote:
 On Tue, Mar 26, 2013 at 10:50:40PM +0400, Franco Fichtner wrote:
 Nobody in their right mind would have such a system as
 mission critical infrastructure. :)
 
 What, like using a Honeywell 316 as a nuclear power station
 reactor temperature monitor in to the early 2000s, until it's
 hard disk failed?
 
 Don't worry, it's been replaced with a couple of PDP11/70's,
 so we can all sleep well at night.
 
 N.B. This one *isn't* a joke.

Point taken; you are right. Scenario (3) is the most likely.

Re: nfs pathconf

[Bob Beck]

 Let me explain my philosophy towards pathconf. It's like those
 configure scripts that check to see if you have a working version of
 strcpy. If you don't, you are so utterly boned you'll find out soon
 enough. If the nfs server isn't going to let you create a 255
 character name, you'll find out soon enough. pathconf is one of those
 design by committee anti-portability features. It's silly it's even in
 the kernel. It should be a libc stub that whispers sweet nothings in
 your ear.

So, does that make the case for fixing this in VOP_PATHCONF instead?

Call the underlying filesystem call if it's there? and if not return the
something sane there?  then we have our something defaultly sane
shit in one place?

Just thinking outloud...

Re: nfs pathconf

[Theo de Raadt]

  Let me explain my philosophy towards pathconf. It's like those
  configure scripts that check to see if you have a working version of
  strcpy. If you don't, you are so utterly boned you'll find out soon
  enough. If the nfs server isn't going to let you create a 255
  character name, you'll find out soon enough. pathconf is one of those
  design by committee anti-portability features. It's silly it's even in
  the kernel. It should be a libc stub that whispers sweet nothings in
  your ear.
 
 So, does that make the case for fixing this in VOP_PATHCONF instead?
 
 Call the underlying filesystem call if it's there? and if not return the
 something sane there?  then we have our something defaultly sane
 shit in one place?

For some of the variables, you don't need to walk the path.  For others,
you do.  Not enough axe murderers prowling the parking lots before austin
group meetings.

Fix profiling support in gcc 4.2

[Paul Irofti]

Good evening everyone,

I discovered about one or two weeks ago that I can't link any debug
libraries on OpenBSD. At first I thought it was a cmake update[1] but
then I started digging further and it turns out its our gcc.

What threw me off is that gcc-4.7 from ports behaves the same way, but
I later discovered it's the same issue.

Anyway, the problem pops up when doing something like this:

---
$ cc -shared -fpic  -o libtest.so.0.0  `lorder test.so test1.so|tsort -q`
$
---

versus something like this:

---
$ cc -shared -fpic  -pg -o libtest.so.0.0  `lorder test.so test1.so|tsort -q`
/usr/bin/ld: warning: cannot find entry symbol _start; defaulting to
00400260
$
---

This used to work in the past and no longer does on -current.

I tested on a 5.1 system and the last command links libtest properly
without an error.

I tracked it down to the commit that enabled PIE support on OpenBSD.

I looked at the specs from other operating systems and Linux
distributions and I haven't found any -nopie references not only in the
libs section, but throughout the entire spec.

Thus I propose the following diff that removes the nopie bits.

An identical diff is needed for the ports tree and I will take care of
it if this is accepted. So comments, okays?

Cheers,
Paul Irofti


[1] -- http://marc.info/?l=openbsd-portsm=136371733926696w=2

Index: gcc/gcc.c
===
RCS file: /cvs/src/gnu/gcc/gcc/gcc.c,v
retrieving revision 1.2
diff -u -p -r1.2 gcc.c
--- gcc/gcc.c   28 Aug 2012 18:59:28 -  1.2
+++ gcc/gcc.c   26 Mar 2013 19:33:05 -
@@ -684,7 +684,7 @@ proper position among the other output f
 
 #ifndef LINK_PIE_SPEC
 #ifdef HAVE_LD_PIE
-#define LINK_PIE_SPEC %{pie:-pie} %{p|pg|nopie:-nopie} 
+#define LINK_PIE_SPEC %{pie:-pie} 
 #else
 #define LINK_PIE_SPEC %{pie:} 
 #endif

Re: Fix profiling support in gcc 4.2

[Pascal Stumpf]

On Tue, 26 Mar 2013 21:48:42 +0200, Paul Irofti wrote:
 Good evening everyone,
 
 I discovered about one or two weeks ago that I can't link any debug
 libraries on OpenBSD. At first I thought it was a cmake update[1] but
 then I started digging further and it turns out its our gcc.

This is not about debug, but profiling libraries.

 What threw me off is that gcc-4.7 from ports behaves the same way, but
 I later discovered it's the same issue.
 
 Anyway, the problem pops up when doing something like this:
 
 ---
 $ cc -shared -fpic  -o libtest.so.0.0  `lorder test.so test1.so|tsort -q`
 $
 ---
 
 versus something like this:
 
 ---
 $ cc -shared -fpic  -pg -o libtest.so.0.0  `lorder test.so test1.so|tsort -q`
 /usr/bin/ld: warning: cannot find entry symbol _start; defaulting to
 00400260
 $
 ---
 
 This used to work in the past and no longer does on -current.

It used to work in the sense that it produced a shared library with
profiling and debug information.  But this information is useless on
OpenBSD.  Profiling only works with static executables/libraries.
Adding support for shared libraries would be non-trivial, and probably
need support in ld.so.  Look at sprof on Linux (even there, gprof
doesn't support shared libraries).

The correct approach here is probably to error out when -pg is given in
combination with -shared on OpenBSD.

Have you seen this command line in a real-world build system?  In that
case, just disable -pg.

 I tested on a 5.1 system and the last command links libtest properly
 without an error.
 
 I tracked it down to the commit that enabled PIE support on OpenBSD.
 
 I looked at the specs from other operating systems and Linux
 distributions and I haven't found any -nopie references not only in the
 libs section, but throughout the entire spec.

That's because nobody else has the -nopie option in ld.

 Thus I propose the following diff that removes the nopie bits.

No, this would break linking profiled executables.

 An identical diff is needed for the ports tree and I will take care of
 it if this is accepted. So comments, okays?
 
 Cheers,
 Paul Irofti
 
 
 [1] -- http://marc.info/?l=openbsd-portsm=136371733926696w=2
 
 Index: gcc/gcc.c
 ===
 RCS file: /cvs/src/gnu/gcc/gcc/gcc.c,v
 retrieving revision 1.2
 diff -u -p -r1.2 gcc.c
 --- gcc/gcc.c 28 Aug 2012 18:59:28 -  1.2
 +++ gcc/gcc.c 26 Mar 2013 19:33:05 -
 @@ -684,7 +684,7 @@ proper position among the other output f
  
  #ifndef LINK_PIE_SPEC
  #ifdef HAVE_LD_PIE
 -#define LINK_PIE_SPEC %{pie:-pie} %{p|pg|nopie:-nopie} 
 +#define LINK_PIE_SPEC %{pie:-pie} 
  #else
  #define LINK_PIE_SPEC %{pie:} 
  #endif
 
 

Re: Fix profiling support in gcc 4.2

[Paul Irofti]

On Tue, Mar 26, 2013 at 09:15:38PM +0100, Pascal Stumpf wrote:
 On Tue, 26 Mar 2013 21:48:42 +0200, Paul Irofti wrote:
  Good evening everyone,
  
  I discovered about one or two weeks ago that I can't link any debug
  libraries on OpenBSD. At first I thought it was a cmake update[1] but
  then I started digging further and it turns out its our gcc.
 
 This is not about debug, but profiling libraries.

Yes, I know that. As the email subject says. My debug libraries are also
compiled with profiling info.

  What threw me off is that gcc-4.7 from ports behaves the same way, but
  I later discovered it's the same issue.
  
  Anyway, the problem pops up when doing something like this:
  
  ---
  $ cc -shared -fpic  -o libtest.so.0.0  `lorder test.so test1.so|tsort -q`
  $
  ---
  
  versus something like this:
  
  ---
  $ cc -shared -fpic  -pg -o libtest.so.0.0  `lorder test.so test1.so|tsort 
  -q`
  /usr/bin/ld: warning: cannot find entry symbol _start; defaulting to
  00400260
  $
  ---
  
  This used to work in the past and no longer does on -current.
 
 It used to work in the sense that it produced a shared library with
 profiling and debug information.  But this information is useless on
 OpenBSD.  Profiling only works with static executables/libraries.

Well, then perhaps just ignore the option when passed without nopie?

 Adding support for shared libraries would be non-trivial, and probably
 need support in ld.so.  Look at sprof on Linux (even there, gprof
 doesn't support shared libraries).

Interesting, I will, thanks!

 The correct approach here is probably to error out when -pg is given in
 combination with -shared on OpenBSD.
 
 Have you seen this command line in a real-world build system?  In that
 case, just disable -pg.

Yes I did. I've been building this way for three years now.

I would just set something like this, and it would work like a charm:

set (CMAKE_CXX_FLAGS_DEBUG  -O0 -g -pg)
set (CMAKE_CXX_FLAGS_MINSIZEREL -Os -DNDEBUG)
set (CMAKE_CXX_FLAGS_RELEASE-O2 -DNDEBUG)
set (CMAKE_CXX_FLAGS_RELWITHDEBINFO -O2 -DNDEBUG -g)

But now, when I tried to build inside a clean object directory I ran
into this issue.

  I tested on a 5.1 system and the last command links libtest properly
  without an error.
  
  I tracked it down to the commit that enabled PIE support on OpenBSD.
  
  I looked at the specs from other operating systems and Linux
  distributions and I haven't found any -nopie references not only in the
  libs section, but throughout the entire spec.
 
 That's because nobody else has the -nopie option in ld.

Okay.

  Thus I propose the following diff that removes the nopie bits.
 
 No, this would break linking profiled executables.

I don't understand how, can you go into more details please?

Anyway, can we then just ignore the -pg option if it doesn't work for
shared instead of breaking the link? Or do you have a better solution?

Thanks,
Paul Irofti

Re: Fix profiling support in gcc 4.2

[Mark Kettenis]

 Date: Tue, 26 Mar 2013 23:54:20 +0200
 From: Paul Irofti p...@irofti.net
 I don't understand how, can you go into more details please?
 
 Anyway, can we then just ignore the -pg option if it doesn't work for
 shared instead of breaking the link? Or do you have a better solution?

Perhaps ld shouldn't set link_info.shared to FALSE when it sees -nopie?

Re: Fix profiling support in gcc 4.2

[Pascal Stumpf]

On Tue, 26 Mar 2013 23:54:20 +0200, Paul Irofti wrote:
 On Tue, Mar 26, 2013 at 09:15:38PM +0100, Pascal Stumpf wrote:
  On Tue, 26 Mar 2013 21:48:42 +0200, Paul Irofti wrote:
   Good evening everyone,
   
   I discovered about one or two weeks ago that I can't link any debug
   libraries on OpenBSD. At first I thought it was a cmake update[1] but
   then I started digging further and it turns out its our gcc.
  
  This is not about debug, but profiling libraries.
 
 Yes, I know that. As the email subject says. My debug libraries are also
 compiled with profiling info.
 
   What threw me off is that gcc-4.7 from ports behaves the same way, but
   I later discovered it's the same issue.
   
   Anyway, the problem pops up when doing something like this:
   
   ---
   $ cc -shared -fpic  -o libtest.so.0.0  `lorder test.so test1.so|tsort -q`
   $
   ---
   
   versus something like this:
   
   ---
   $ cc -shared -fpic  -pg -o libtest.so.0.0  `lorder test.so test1.so|tsort 
   -q`
   /usr/bin/ld: warning: cannot find entry symbol _start; defaulting to
   00400260
   $
   ---
   
   This used to work in the past and no longer does on -current.
  
  It used to work in the sense that it produced a shared library with
  profiling and debug information.  But this information is useless on
  OpenBSD.  Profiling only works with static executables/libraries.
 
 Well, then perhaps just ignore the option when passed without nopie?

You probably mean with -shared.  At the moment, -pg implies -nopie at
the linking stage.

  Adding support for shared libraries would be non-trivial, and probably
  need support in ld.so.  Look at sprof on Linux (even there, gprof
  doesn't support shared libraries).
 
 Interesting, I will, thanks!
 
  The correct approach here is probably to error out when -pg is given in
  combination with -shared on OpenBSD.
  
  Have you seen this command line in a real-world build system?  In that
  case, just disable -pg.
 
 Yes I did. I've been building this way for three years now.
 
 I would just set something like this, and it would work like a charm:
 
 set (CMAKE_CXX_FLAGS_DEBUG  -O0 -g -pg)
 set (CMAKE_CXX_FLAGS_MINSIZEREL -Os -DNDEBUG)
 set (CMAKE_CXX_FLAGS_RELEASE-O2 -DNDEBUG)
 set (CMAKE_CXX_FLAGS_RELWITHDEBINFO -O2 -DNDEBUG -g)
 
 But now, when I tried to build inside a clean object directory I ran
 into this issue.

Hmm, okay; but as far as I know, this will *never* produce a shared
library that's actually suitable for being profiled.  Even when using
sprof on Linux, the documentation out there on the net suggests you
should use -g, not -pg.  So, if you actually want to build profiling
(and not just debug) libraries, it takes more build system changes that
just setting CFLAGS to -pg: You need to create a static library with a
_p suffix instead of a shared one.

   I tested on a 5.1 system and the last command links libtest properly
   without an error.
   
   I tracked it down to the commit that enabled PIE support on OpenBSD.
   
   I looked at the specs from other operating systems and Linux
   distributions and I haven't found any -nopie references not only in the
   libs section, but throughout the entire spec.
  
  That's because nobody else has the -nopie option in ld.
 
 Okay.
 
   Thus I propose the following diff that removes the nopie bits.
  
  No, this would break linking profiled executables.
 
 I don't understand how, can you go into more details please?

At the moment, profiling does not have PIC (or PIE) support.  So
everything compiled with profiling is non-PIE (-pg implies -fno-pie when
compiling).  The linker, however, defaults to -pie on all PIE archs.  So
it needs to be told to not try to generate a position-independent
executable when dealing with profiling (which is exactly what the spec
you proposed to remove does) or you end up with could not use
relocation foo when making a shared object errors.

 Anyway, can we then just ignore the -pg option if it doesn't work for
 shared instead of breaking the link? Or do you have a better solution?

I could do that (if I figure out the correct gcc specs), sure.

 Thanks,
 Paul Irofti
 
 

Re: Fix profiling support in gcc 4.2

[Pascal Stumpf]

On Tue, 26 Mar 2013 23:05:05 +0100 (CET), Mark Kettenis wrote:
  Date: Tue, 26 Mar 2013 23:54:20 +0200
  From: Paul Irofti p...@irofti.net
  I don't understand how, can you go into more details please?
  
  Anyway, can we then just ignore the -pg option if it doesn't work for
  shared instead of breaking the link? Or do you have a better solution?
 
 Perhaps ld shouldn't set link_info.shared to FALSE when it sees -nopie?

At the ld level, it basically breaks down to the question what the
desired behaviour is when nonsensical combinations of -nopie and -shared
are encountered.  At the moment, -nopie cancels out a previously
encountered -shared, so

ld -shared -nopie ...

will try to generate a non-shared, non-pie object, while

ld -nopie -shared ...

will behave the same as ld -shared.  I think this is the behaviour
most people would expect, but I might be wrong.  Other opinions?

Re: Fix profiling support in gcc 4.2

[Philip Guenther]

On Tue, Mar 26, 2013 at 3:45 PM, Pascal Stumpf pascal.stu...@cubes.de wrote:
...
 Anyway, can we then just ignore the -pg option if it doesn't work for
 shared instead of breaking the link? Or do you have a better solution?

 I could do that (if I figure out the correct gcc specs), sure.

Change this:
   %l %{pie:-pie} %{p|pg|nopie:-nopie}

to this:
   %{pie:-pie} %{p|pg|nopie:-nopie} %l

in the link_command spec.

...but I also like Mark's suggestion, to make -nopie not change the
link mode (shared-object vs executable).


Philip Guenther

Re: Fix profiling support in gcc 4.2

[Pascal Stumpf]

On Tue, 26 Mar 2013 16:39:54 -0700, Philip Guenther wrote:
 On Tue, Mar 26, 2013 at 3:45 PM, Pascal Stumpf pascal.stu...@cubes.de wrote:
 ...
  Anyway, can we then just ignore the -pg option if it doesn't work for
  shared instead of breaking the link? Or do you have a better solution?
 
  I could do that (if I figure out the correct gcc specs), sure.
 
 Change this:
%l %{pie:-pie} %{p|pg|nopie:-nopie}
 
 to this:
%{pie:-pie} %{p|pg|nopie:-nopie} %l
 
 in the link_command spec.

That would require changing how LINK_PIE_SPEC is integrated into
LINK_COMMAND_SPEC, and it exploits the -nopie/-shared ordering nits I
mentioned, so I'm not a fan of that.  I thought of something like this:

Index: gcc.c
===
RCS file: /home/pascal/cvs/src/gnu/gcc/gcc/gcc.c,v
retrieving revision 1.2
diff -u -p -r1.2 gcc.c
--- gcc.c   28 Aug 2012 18:59:28 -  1.2
+++ gcc.c   26 Mar 2013 23:29:00 -
@@ -684,7 +684,7 @@ proper position among the other output f
 
 #ifndef LINK_PIE_SPEC
 #ifdef HAVE_LD_PIE
-#define LINK_PIE_SPEC %{pie:-pie} %{p|pg|nopie:-nopie} 
+#define LINK_PIE_SPEC %{pie:-pie} %{!shared:%{p|pg:-nopie}} %{nopie:-nopie} 
 #else
 #define LINK_PIE_SPEC %{pie:} 
 #endif

 ...but I also like Mark's suggestion, to make -nopie not change the
 link mode (shared-object vs executable).
 
 
 Philip Guenther
 
 

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...