Re: softraid crypto: preallocate crypops and dma buffers.

2011-06-20 Thread Todd T. Fries
Penned by roberth on 20110620 21:05.14, we have:
| On Mon, 20 Jun 2011 20:12:28 -0500
| Marco Peereboom  wrote:
| 
| > I am liking this diff quite a bit but it needs more testers.  So if
| > you are using softraid crypto please try this diff.
| 
| Still working for me.

And me.

Volume  Status   Size Device  
softraid0 0 Online  262939136 sd0 RAID1
  0 Online  262939136 0:0.0   noencl 
  1 Online  262939136 0:1.0   noencl 
softraid0 1 Online99755925504 sd1 CRYPTO
  0 Online99755925504 1:0.0   noencl 
softraid0 2 Online 9228489728 sd2 CRYPTO
  0 Online 9228489728 2:0.0   noencl 

-- 
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)
| 2525 NW Expy #525, Oklahoma City, OK 73112  \  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: softraid crypto: preallocate crypops and dma buffers.

2011-06-20 Thread roberth
On Mon, 20 Jun 2011 20:12:28 -0500
Marco Peereboom  wrote:

> I am liking this diff quite a bit but it needs more testers.  So if
> you are using softraid crypto please try this diff.

Still working for me.



Re: softraid crypto: preallocate crypops and dma buffers.

2011-06-20 Thread Marco Peereboom
I am liking this diff quite a bit but it needs more testers.  So if you
are using softraid crypto please try this diff.

On Fri, Jun 17, 2011 at 07:53:05PM +0100, Owain Ainsworth wrote:
> So here's the problem: ENOMEM on io in a hba driver is bad juju.
> 
> In more detail: 
> 
> When preparing for each io softraid crypto does a
> sr_crypto_getcryptop(). This operation does a few things:
> 
> - allocate a uio and iovec from a pool.
> - if this is a read then allocate a dma buffer with dma_alloc (up to
>MAXPHYS, i.e. 64k)
> - allocate a cryptop to be used with the crypto(9) framework.
> - initialise the above for use in the io.
> 
> So if you are getting very low on memory, one of these operations
> (probably the dma alloc) will fail. when this happens softraid returns
> XS_DRIVER_STUFFUP to scsi land. This returns an EIO back to callers.
> 
> Now it is fairly common to use softdep in these situations, synchronous
> filesystems are slw. softdep has certain assumptions about how
> things will work. if a queued dependancy fails that invalidates these
> assumptions. softraid panics in this case. I used to hit this repeatedly
> (several times a day) before I bought more memory.
> 
> in general, most disk controllers prealloc everything they need (that
> isn't passed down to them) so that this won't be a problem.
> 
> This diff does the same for softraid crypto. It'll eat just over 1meg of
> kva, but it is hardly the only driver to need to do that.
> 
> The only slightly scary thing here is the cryptodesc list manipulations
> (the comments explain why they are necesary).
> 
> I'm typing from a machine that runs this. todd@ is also testing it and
> marco kindly did some horrible io torture on a machine running this too
> and it runs quite nicely.
> 
> A side benefit is that due to missing out allocations in every disk io
> this is actually slightly faster in io too.
> 
> More testing would be appreciated. Cheers,
> 
> -0-
> 
> diff --git dev/softraid_crypto.c dev/softraid_crypto.c
> index 3259121..a60824e 100644
> --- dev/softraid_crypto.c
> +++ dev/softraid_crypto.c
> @@ -56,9 +56,26 @@
>  #include 
>  #include 
>  
> -struct cryptop   *sr_crypto_getcryptop(struct sr_workunit *, int);
> +/*
> + * the per-io data that we need to preallocate. We can't afford to allow io
> + * to start failing when memory pressure kicks in.
> + * We can store this in the WU because we assert that only one
> + * ccb per WU will ever be active.
> + */
> +struct sr_crypto_wu {
> + TAILQ_ENTRY(sr_crypto_wu)cr_link;
> + struct uio   cr_uio;
> + struct iovec cr_iov;
> + struct cryptop  *cr_crp;
> + struct cryptodesc   *cr_descs;
> + struct sr_workunit  *cr_wu;
> + void*cr_dmabuf;
> +};
> +
> +
> +struct sr_crypto_wu *sr_crypto_wu_get(struct sr_workunit *, int);
> +void sr_crypto_wu_put(struct sr_crypto_wu *);
>  int  sr_crypto_create_keys(struct sr_discipline *);
> -void *sr_crypto_putcryptop(struct cryptop *);
>  int  sr_crypto_get_kdf(struct bioc_createraid *,
>   struct sr_discipline *);
>  int  sr_crypto_decrypt(u_char *, u_char *, u_char *, size_t, int);
> @@ -78,7 +95,7 @@ int sr_crypto_meta_opt_load(struct sr_discipline *,
>   struct sr_meta_opt *);
>  int  sr_crypto_write(struct cryptop *);
>  int  sr_crypto_rw(struct sr_workunit *);
> -int  sr_crypto_rw2(struct sr_workunit *, struct cryptop *);
> +int  sr_crypto_rw2(struct sr_workunit *, struct sr_crypto_wu *);
>  void sr_crypto_intr(struct buf *);
>  int  sr_crypto_read(struct cryptop *);
>  void sr_crypto_finish_io(struct sr_workunit *);
> @@ -230,40 +247,35 @@ done:
>   return (rv);
>  }
>  
> -struct cryptop *
> -sr_crypto_getcryptop(struct sr_workunit *wu, int encrypt)
> +
> +struct sr_crypto_wu *
> +sr_crypto_wu_get(struct sr_workunit *wu, int encrypt)
>  {
>   struct scsi_xfer*xs = wu->swu_xs;
>   struct sr_discipline*sd = wu->swu_dis;
> - struct cryptop  *crp = NULL;
> + struct sr_crypto_wu *crwu;
>   struct cryptodesc   *crd;
> - struct uio  *uio = NULL;
> - int flags, i, n, s;
> + int flags, i, n;
>   daddr64_t   blk = 0;
>   u_int   keyndx;
>  
> - DNPRINTF(SR_D_DIS, "%s: sr_crypto_getcryptop wu: %p encrypt: %d\n",
> + DNPRINTF(SR_D_DIS, "%s: sr_crypto_wu_get wu: %p encrypt: %d\n",
>   DEVNAME(sd->sd_sc), wu, encrypt);
>  
> - s = splbio();
> - uio = pool_get(&sd->mds.mdd_crypto.sr_uiopl, PR_ZERO | PR_NOWAIT);
> - if (uio == NULL)
> - goto poolunwind;
> - uio->uio_iov = pool_get(&sd->mds.mdd_crypto.sr_iovpl,
> - PR_ZERO | PR_NOWAIT);
> - if (uio->uio_iov == NULL)
> -

Re: 4096 byte sector devices (a.k.a. disks > 3TB)

2011-06-20 Thread Marco Peereboom
On Mon, Jun 20, 2011 at 08:30:40PM -0400, Kenneth R Westerback wrote:
> I committed a fix to fdisk(8) today to un-break the -i and -e options
> on 4096-byte devices. To make a long story short, it had been working
> accidentally until I committed a 4.9 change to fdisk(8) to make
> it pay attention to the errors returned from MBR_read().
> 
> However this has raised once more concerns about what is going to
> happen when 4096-byte sector devices become common, then the norm,
> and then the smallest disks available.
> 
> There has been a lot of work done in the last few years to de-couple
> the internal kernel view of a disk (a series of 512 byte blocks)
> and the 'real world' view of potentially different sector size
> devices. With seemless translation being done behind the scenes.
> 
> However, as today has shown, there may well be further unreconstructed
> code making invalid assumptions or currently silently working
> accidentally and waiting for the day when it can blow up your
> machine.
> 
> So if you have such a device (disks >3TB are your best bet) I would
> be very interested in hearing how hard you have to work to break
> something. Of course the clever can also create vnd's with such
> large sectors but actual hardware is more convincing.
> 
> Various filesystems (supported ones only please!), utilities such as
> fdisk, disklabel, newfs, fsck, dump, restore, etc. Anything which
> may do any serious disk i/o or is suspected of attempting raw, low
> level i/o.

It just occurred to me that softraid crypto would benefit quite a bit
from 4096 byte sectors.  And... we can use softraid to force 4096 byte
sectors pretty trivially so it can be used a test harness as well in
lieu of 3096 byte sector disks.

> 
>  Ken



4096 byte sector devices (a.k.a. disks > 3TB)

2011-06-20 Thread Kenneth R Westerback
I committed a fix to fdisk(8) today to un-break the -i and -e options
on 4096-byte devices. To make a long story short, it had been working
accidentally until I committed a 4.9 change to fdisk(8) to make
it pay attention to the errors returned from MBR_read().

However this has raised once more concerns about what is going to
happen when 4096-byte sector devices become common, then the norm,
and then the smallest disks available.

There has been a lot of work done in the last few years to de-couple
the internal kernel view of a disk (a series of 512 byte blocks)
and the 'real world' view of potentially different sector size
devices. With seemless translation being done behind the scenes.

However, as today has shown, there may well be further unreconstructed
code making invalid assumptions or currently silently working
accidentally and waiting for the day when it can blow up your
machine.

So if you have such a device (disks >3TB are your best bet) I would
be very interested in hearing how hard you have to work to break
something. Of course the clever can also create vnd's with such
large sectors but actual hardware is more convincing.

Various filesystems (supported ones only please!), utilities such as
fdisk, disklabel, newfs, fsck, dump, restore, etc. Anything which
may do any serious disk i/o or is suspected of attempting raw, low
level i/o.

 Ken



dev/ic bzero casts

2011-06-20 Thread Ted Unangst
there's no need to cast to char *.

Index: dc.c
===
RCS file: /home/tedu/cvs/src/sys/dev/ic/dc.c,v
retrieving revision 1.122
diff -u -r1.122 dc.c
--- dc.c5 Mar 2011 13:39:26 -   1.122
+++ dc.c20 Jun 2011 23:22:22 -
@@ -749,7 +749,7 @@
struct dc_mii_frame frame;
int i, phy_reg;
 
-   bzero((char *)&frame, sizeof(frame));
+   bzero(&frame, sizeof(frame));
 
if (DC_IS_ADMTEK(sc) && phy != DC_ADMTEK_PHYADDR)
return;
@@ -903,7 +903,7 @@
sc->dc_cdata.dc_tx_cnt++;
sframe = &sc->dc_ldata->dc_tx_list[i];
sp = &sc->dc_ldata->dc_sbuf[0];
-   bzero((char *)sp, DC_SFRAME_LEN);
+   bzero(sp, DC_SFRAME_LEN);
 
sframe->dc_data = htole32(sc->sc_listmap->dm_segs[0].ds_addr +
offsetof(struct dc_list_data, dc_sbuf));
@@ -1126,7 +1126,7 @@
sc->dc_cdata.dc_tx_cnt++;
sframe = &sc->dc_ldata->dc_tx_list[i];
sp = &sc->dc_ldata->dc_sbuf[0];
-   bzero((char *)sp, DC_SFRAME_LEN);
+   bzero(sp, DC_SFRAME_LEN);
 
sframe->dc_data = htole32(sc->sc_listmap->dm_segs[0].ds_addr +
offsetof(struct dc_list_data, dc_sbuf));
@@ -1934,7 +1934,7 @@
 * 82c169 chips.
 */
if (sc->dc_flags & DC_PNIC_RX_BUG_WAR)
-   bzero((char *)mtod(m_new, char *), m_new->m_len);
+   bzero(mtod(m_new, char *), m_new->m_len);
 
bus_dmamap_sync(sc->sc_dmat, sc->dc_cdata.dc_rx_chain[i].sd_map, 0,
sc->dc_cdata.dc_rx_chain[i].sd_map->dm_mapsize,
@@ -3112,7 +3112,7 @@
sc->dc_cdata.dc_rx_chain[i].sd_mbuf = NULL;
}
}
-   bzero((char *)&sc->dc_ldata->dc_rx_list,
+   bzero(&sc->dc_ldata->dc_rx_list,
sizeof(sc->dc_ldata->dc_rx_list));
 
/*
@@ -3136,7 +3136,7 @@
sc->dc_cdata.dc_tx_chain[i].sd_mbuf = NULL;
}
}
-   bzero((char *)&sc->dc_ldata->dc_tx_list,
+   bzero(&sc->dc_ldata->dc_tx_list,
sizeof(sc->dc_ldata->dc_tx_list));
 
bus_dmamap_sync(sc->sc_dmat, sc->sc_listmap,
Index: if_wi.c
===
RCS file: /home/tedu/cvs/src/sys/dev/ic/if_wi.c,v
retrieving revision 1.149
diff -u -r1.149 if_wi.c
--- if_wi.c 30 Aug 2010 20:42:27 -  1.149
+++ if_wi.c 20 Jun 2011 23:25:38 -
@@ -226,7 +226,7 @@
printf(": unable to read station address\n");
return (error);
}
-   bcopy((char *)&mac.wi_mac_addr, (char *)&ic->ic_myaddr,
+   bcopy(&mac.wi_mac_addr, &ic->ic_myaddr,
IEEE80211_ADDR_LEN);
 
wi_get_id(sc);
@@ -332,7 +332,7 @@
sc->wi_flags |= WI_FLAGS_HAS_WEP;
timeout_set(&sc->sc_timo, funcs->f_inquire, sc);
 
-   bzero((char *)&sc->wi_stats, sizeof(sc->wi_stats));
+   bzero(&sc->wi_stats, sizeof(sc->wi_stats));
 
/* Find supported rates. */
rates.wi_type = WI_RID_DATA_RATES;
@@ -730,12 +730,12 @@
m->m_pkthdr.len = m->m_len =
letoh16(rx_frame.wi_dat_len) + WI_SNAPHDR_LEN;
 
-   bcopy((char *)&rx_frame.wi_dst_addr,
-   (char *)&eh->ether_dhost, ETHER_ADDR_LEN);
-   bcopy((char *)&rx_frame.wi_src_addr,
-   (char *)&eh->ether_shost, ETHER_ADDR_LEN);
-   bcopy((char *)&rx_frame.wi_type,
-   (char *)&eh->ether_type, ETHER_TYPE_LEN);
+   bcopy(&rx_frame.wi_dst_addr,
+   &eh->ether_dhost, ETHER_ADDR_LEN);
+   bcopy(&rx_frame.wi_src_addr,
+   &eh->ether_shost, ETHER_ADDR_LEN);
+   bcopy(&rx_frame.wi_type,
+   &eh->ether_type, ETHER_TYPE_LEN);
 
if (wi_read_data(sc, id, WI_802_11_OFFSET,
mtod(m, caddr_t) + sizeof(struct ether_header),
@@ -1402,7 +1402,7 @@
 
ifp = &sc->sc_ic.ic_if;
 
-   bzero((char *)&mcast, sizeof(mcast));
+   bzero(&mcast, sizeof(mcast));
 
mcast.wi_type = WI_RID_MCAST_LIST;
mcast.wi_len = ((ETHER_ADDR_LEN / 2) * 16) + 1;
@@ -1416,7 +1416,7 @@
ETHER_FIRST_MULTI(step, &sc->sc_ic.ic_ac, enm);
while (enm != NULL) {
if (i >= 16) {
-   bzero((char *)&mcast, sizeof(mcast));
+   bzero(&mcast, sizeof(mcast));
break;
}
 
@@ -1424,7 +1424,7 @@
ifp->if_flags |= IFF_ALLMULTI;
goto allmulti;
}
-   bcopy(enm->enm_addrlo, (char *)&mcast.wi_mcast[i],
+   bcopy(enm->enm_addrlo, &mcast.wi_mcast[i],
ETHER_ADDR_LEN);
i++;
   

raidframe bzero casts

2011-06-20 Thread Ted Unangst
yeah, i know.  no need to cast to char *.  also, no need to cast void 
return of bzero to void.

Index: rf_alloclist.c
===
RCS file: /home/tedu/cvs/src/sys/dev/raidframe/rf_alloclist.c,v
retrieving revision 1.4
diff -u -r1.4 rf_alloclist.c
--- rf_alloclist.c  16 Dec 2002 07:01:03 -  1.4
+++ rf_alloclist.c  20 Jun 2011 22:17:04 -
@@ -185,6 +185,6 @@
if (p == NULL) {
return (NULL);
}
-   bzero((char *) p, sizeof(RF_AllocListElem_t));
+   bzero(p, sizeof(RF_AllocListElem_t));
return (p);
 }
Index: rf_cvscan.c
===
RCS file: /home/tedu/cvs/src/sys/dev/raidframe/rf_cvscan.c,v
retrieving revision 1.5
diff -u -r1.5 rf_cvscan.c
--- rf_cvscan.c 16 Dec 2002 07:01:03 -  1.5
+++ rf_cvscan.c 20 Jun 2011 22:17:10 -
@@ -352,7 +352,7 @@
 
RF_MallocAndAdd(hdr, sizeof(RF_CvscanHeader_t), (RF_CvscanHeader_t *),
clList);
-   bzero((char *) hdr, sizeof(RF_CvscanHeader_t));
+   bzero(hdr, sizeof(RF_CvscanHeader_t));
hdr->range_for_avg = RF_MAX(range, 1);
hdr->change_penalty = RF_MAX(penalty, 0);
hdr->direction = rf_cvscan_RIGHT;
Index: rf_dagutils.c
===
RCS file: /home/tedu/cvs/src/sys/dev/raidframe/rf_dagutils.c,v
retrieving revision 1.4
diff -u -r1.4 rf_dagutils.c
--- rf_dagutils.c   16 Dec 2002 07:01:03 -  1.4
+++ rf_dagutils.c   20 Jun 2011 22:17:20 -
@@ -246,7 +246,7 @@
 
RF_FREELIST_GET(rf_dagh_freelist, dh, next, (RF_DagHeader_t *));
if (dh) {
-   bzero((char *) dh, sizeof(RF_DagHeader_t));
+   bzero(dh, sizeof(RF_DagHeader_t));
}
return (dh);
 }
Index: rf_driver.c
===
RCS file: /home/tedu/cvs/src/sys/dev/raidframe/rf_driver.c,v
retrieving revision 1.12
diff -u -r1.12 rf_driver.c
--- rf_driver.c 26 Jun 2008 05:42:17 -  1.12
+++ rf_driver.c 20 Jun 2011 22:17:25 -
@@ -636,7 +636,7 @@
desc->state = 0;
 
desc->status = 0;
-   bzero((char *) &desc->tracerec, sizeof(RF_AccTraceEntry_t));
+   bzero(&desc->tracerec, sizeof(RF_AccTraceEntry_t));
desc->callbackFunc = (void (*) (RF_CBParam_t)) cbF; /* XXX */
desc->callbackArg = cbA;
desc->next = NULL;
Index: rf_evenodd.c
===
RCS file: /home/tedu/cvs/src/sys/dev/raidframe/rf_evenodd.c,v
retrieving revision 1.5
diff -u -r1.5 rf_evenodd.c
--- rf_evenodd.c16 Dec 2002 07:01:03 -  1.5
+++ rf_evenodd.c20 Jun 2011 22:17:44 -
@@ -529,7 +529,7 @@
asmap->qInfo;
 
/* Fire off the DAG. */
-   bzero((char *) &tracerec, sizeof(tracerec));
+   bzero(&tracerec, sizeof(tracerec));
rd_dag_h->tracerec = &tracerec;
 
if (rf_verifyParityDebug) {
@@ -601,7 +601,7 @@
wrBlock->succedents[0]->params[2].v = psID;
wrBlock->succedents[0]->params[3].v =
RF_CREATE_PARAM3(RF_IO_NORMAL_PRIORITY, 0, 0, which_ru);
-   bzero((char *) &tracerec, sizeof(tracerec));
+   bzero(&tracerec, sizeof(tracerec));
wr_dag_h->tracerec = &tracerec;
if (rf_verifyParityDebug) {
printf("Parity verify write dag:\n");
@@ -633,7 +633,7 @@
wrBlock->succedents[0]->params[2].v = psID;
wrBlock->succedents[0]->params[3].v =
RF_CREATE_PARAM3(RF_IO_NORMAL_PRIORITY, 0, 0, which_ru);
-   bzero((char *) &tracerec, sizeof(tracerec));
+   bzero(&tracerec, sizeof(tracerec));
wr_dag_h->tracerec = &tracerec;
if (rf_verifyParityDebug) {
printf("Dag of write new second redundant information"
Index: rf_evenodd_dagfuncs.c
===
RCS file: /home/tedu/cvs/src/sys/dev/raidframe/rf_evenodd_dagfuncs.c,v
retrieving revision 1.7
diff -u -r1.7 rf_evenodd_dagfuncs.c
--- rf_evenodd_dagfuncs.c   16 Dec 2002 07:01:04 -  1.7
+++ rf_evenodd_dagfuncs.c   20 Jun 2011 22:18:11 -
@@ -454,7 +454,7 @@
RF_AccTraceEntry_t *tracerec = node->dagHdr->tracerec;
RF_Etimer_t timer;
 
-   bzero((char *) node->results[0], rf_RaidAddressToByte(raidPtr, 
failedPDA->numSector));
+   bzero(node->results[0], rf_RaidAddressToByte(raidPtr, 
failedPDA->numSector));
if (node->dagHdr->status == rf_enable) {
RF_ETIMER_START(timer);
for (i = 0; i < node->numParams - 2; i += 2)
@@ -538,8 +538,8 @@
 #endif
RF_ASSERT(*((long *) dest[0]) == 0);
RF_ASSERT(*((long *) dest[1]) == 0);
-   bzero((char *) P, bytesPerEU);
-   bzero((

Re: fix a few uvm includes

2011-06-20 Thread Ted Unangst
On Mon, Jun 20, 2011 at 3:43 PM, Miod Vallat  wrote:
>> uvm_extern.h is the header people should be consuming.  change a few uvm.h
>> to uvm_extern.h.
>
> This is not what, say, kern_fork.c does. If you include , you
> don't need any other , and definitely not
> .

kern_fork.c was relying on vnode.h to get uvm.h, so it's added.  I was
undecided on whether to include both or not, I think there's already
several examples of that in the tree.  I went with both as a hint that
uvm.h was intentional, but can easily remove the uvm_extern.h
includes.

>> also, simplify and move the bufcache adjustment code from sysctl to the
>> vfs_bio.c where it fits nicer.
>
> Separate diff please.

OK, this happened because it's another file that needed dma_constraint.



grep -o

2011-06-20 Thread Ted Unangst
this was proposed a while ago, but got sidetracked by some nonstandard 
option discussion. bringing it back in slightly different form.

-o only prints the matching parts of a line, not the entire line.  While 
this is possible using awk, the same could be said of everything grep 
does.  It is intended to match the behavior of the same option in gnu 
grep.

Index: grep.1
===
RCS file: /home/tedu/cvs/src/usr.bin/grep/grep.1,v
retrieving revision 1.40
diff -u -r1.40 grep.1
--- grep.1  4 Mar 2011 03:11:22 -   1.40
+++ grep.1  20 Jun 2011 19:38:55 -
@@ -38,7 +38,7 @@
 .Sh SYNOPSIS
 .Nm grep
 .Bk -words
-.Op Fl abcEFGHhIiLlnqRsUVvwxZ
+.Op Fl abcEFGHhIiLlnoqRsUVvwxZ
 .Op Fl A Ar num
 .Op Fl B Ar num
 .Op Fl C Ns Op Ar num
@@ -228,6 +228,8 @@
 .Fl q
 is
 specified.
+.It Fl o
+Print each match, but only the match, not the containing line.
 .It Fl q
 Quiet mode:
 suppress normal output.
Index: grep.c
===
RCS file: /home/tedu/cvs/src/usr.bin/grep/grep.c,v
retrieving revision 1.43
diff -u -r1.43 grep.c
--- grep.c  4 Mar 2011 03:11:23 -   1.43
+++ grep.c  20 Jun 2011 19:36:39 -
@@ -74,6 +74,7 @@
 int iflag; /* -i: ignore case */
 int lflag; /* -l: only show names of files with matches */
 int nflag; /* -n: show line numbers in front of matching lines */
+int oflag; /* -o: print each match */
 int qflag; /* -q: quiet mode (don't output anything) */
 int sflag; /* -s: silent mode (ignore errors) */
 int vflag; /* -v: only show non-matching lines */
@@ -117,9 +118,9 @@
 }
 
 #ifdef NOZ
-static char *optstr = "0123456789A:B:CEFGHILRUVabce:f:hilnqrsuvwxy";
+static char *optstr = "0123456789A:B:CEFGHILRUVabce:f:hilnoqrsuvwxy";
 #else
-static char *optstr = "0123456789A:B:CEFGHILRUVZabce:f:hilnqrsuvwxy";
+static char *optstr = "0123456789A:B:CEFGHILRUVZabce:f:hilnoqrsuvwxy";
 #endif
 
 struct option long_options[] =
@@ -382,6 +383,9 @@
break;
case 'n':
nflag = 1;
+   break;
+   case 'o':
+   oflag = 1;
break;
case 'q':
qflag = 1;
Index: grep.h
===
RCS file: /home/tedu/cvs/src/usr.bin/grep/grep.h,v
retrieving revision 1.16
diff -u -r1.16 grep.h
--- grep.h  4 Mar 2011 03:11:23 -   1.16
+++ grep.h  20 Jun 2011 19:34:58 -
@@ -65,7 +65,7 @@
 /* Command line flags */
 extern int  Aflag, Bflag, Eflag, Fflag, Gflag, Hflag, Lflag,
 Rflag, Zflag,
-bflag, cflag, hflag, iflag, lflag, nflag, qflag, sflag,
+bflag, cflag, hflag, iflag, lflag, nflag, oflag, qflag, sflag,
 vflag, wflag, xflag;
 extern int  binbehave;
 
@@ -84,7 +84,7 @@
 void   *grep_malloc(size_t size);
 void   *grep_calloc(size_t nmemb, size_t size);
 void   *grep_realloc(void *ptr, size_t size);
-voidprintline(str_t *line, int sep);
+voidprintline(str_t *line, int sep, regmatch_t *pmatch);
 int fastcomp(fastgrep_t *, const char *);
 voidfgrepcomp(fastgrep_t *, const char *);
 
Index: queue.c
===
RCS file: /home/tedu/cvs/src/usr.bin/grep/queue.c,v
retrieving revision 1.5
diff -u -r1.5 queue.c
--- queue.c 9 Feb 2006 09:54:47 -   1.5
+++ queue.c 20 Jun 2011 19:33:23 -
@@ -107,7 +107,7 @@
queue_t *item;
 
while ((item = dequeue()) != NULL) {
-   printline(&item->data, '-');
+   printline(&item->data, '-', NULL);
free_item(item);
}
 }
Index: util.c
===
RCS file: /home/tedu/cvs/src/usr.bin/grep/util.c,v
retrieving revision 1.39
diff -u -r1.39 util.c
--- util.c  2 Jul 2010 22:18:03 -   1.39
+++ util.c  20 Jun 2011 19:34:30 -
@@ -48,9 +48,9 @@
 
 static int linesqueued;
 static int procline(str_t *l, int);
-static int grep_search(fastgrep_t *, unsigned char *, size_t, regmatch_t 
*pmatch);
+static int grep_search(fastgrep_t *, char *, size_t, regmatch_t *pmatch);
 #ifndef SMALL
-static int grep_cmp(const unsigned char *, const unsigned char *, size_t);
+static int grep_cmp(const char *, const char *, size_t);
 static voidgrep_revstr(unsigned char *, int);
 #endif
 
@@ -169,19 +169,25 @@
 {
regmatch_t  pmatch;
int c, i, r;
+   int offset;
 
+   c = 0;
+   i = 0;
if (matchall) {
-   c = !vflag;
goto print;
}
 
-   for (c = i = 0; i < patterns; i++) {
+   for (i = 0; i < pat

Re: fix a few uvm includes

2011-06-20 Thread Miod Vallat
> uvm_extern.h is the header people should be consuming.  change a few uvm.h 
> to uvm_extern.h.

This is not what, say, kern_fork.c does. If you include , you
don't need any other , and definitely not
.

> also, simplify and move the bufcache adjustment code from sysctl to the 
> vfs_bio.c where it fits nicer.

Separate diff please.



fix a few uvm includes

2011-06-20 Thread Ted Unangst
uvm_extern.h is the header people should be consuming.  change a few uvm.h 
to uvm_extern.h.

a couple other sys .h headers included uvm when they don't need to.  fix 
that.

fix a few .c files that depended on getting headers from headers.

also, simplify and move the bufcache adjustment code from sysctl to the 
vfs_bio.c where it fits nicer.

Index: arch/i386/i386/machdep.c
===
RCS file: /home/tedu/cvs/src/sys/arch/i386/i386/machdep.c,v
retrieving revision 1.500
diff -u -r1.500 machdep.c
--- arch/i386/i386/machdep.c5 Jun 2011 19:41:07 -   1.500
+++ arch/i386/i386/machdep.c20 Jun 2011 19:26:09 -
@@ -83,7 +83,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -101,6 +100,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 
Index: kern/exec_subr.c
===
RCS file: /home/tedu/cvs/src/sys/kern/exec_subr.c,v
retrieving revision 1.28
diff -u -r1.28 exec_subr.c
--- kern/exec_subr.c14 Nov 2006 18:00:27 -  1.28
+++ kern/exec_subr.c20 Jun 2011 19:22:34 -
@@ -41,7 +41,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #ifdef DEBUG
 /*
Index: kern/init_main.c
===
RCS file: /home/tedu/cvs/src/sys/kern/init_main.c,v
retrieving revision 1.177
diff -u -r1.177 init_main.c
--- kern/init_main.c18 Apr 2011 21:44:56 -  1.177
+++ kern/init_main.c20 Jun 2011 19:22:34 -
@@ -85,7 +85,7 @@
 
 #include 
 
-#include 
+#include 
 
 #include 
 #include 
Index: kern/kern_fork.c
===
RCS file: /home/tedu/cvs/src/sys/kern/kern_fork.c,v
retrieving revision 1.126
diff -u -r1.126 kern_fork.c
--- kern/kern_fork.c6 Jun 2011 17:05:46 -   1.126
+++ kern/kern_fork.c20 Jun 2011 19:27:20 -
@@ -64,6 +64,7 @@
 
 #include 
 #include 
+#include 
 
 intnprocs = 1; /* process 0 */
 intrandompid;  /* when set to 1, pid's go random */
Index: kern/kern_sysctl.c
===
RCS file: /home/tedu/cvs/src/sys/kern/kern_sysctl.c,v
retrieving revision 1.203
diff -u -r1.203 kern_sysctl.c
--- kern/kern_sysctl.c  9 Jun 2011 21:10:55 -   1.203
+++ kern/kern_sysctl.c  20 Jun 2011 19:22:34 -
@@ -565,22 +565,17 @@
return (sysctl_int(oldp, oldlenp, newp, newlen,
&rthreads_enabled));
case KERN_CACHEPCT: {
-   u_int64_t dmapages;
-   int opct, pgs;
-   opct = bufcachepercent;
+   int newpct = bufcachepercent;
error = sysctl_int(oldp, oldlenp, newp, newlen,
-   &bufcachepercent);
+   &newpct);
if (error)
return(error);
-   if (bufcachepercent > 90 || bufcachepercent < 5) {
-   bufcachepercent = opct;
+   if (newpct > 90 || newpct < 5) {
return (EINVAL);
}
-   dmapages = uvm_pagecount(&dma_constraint);
-   if (bufcachepercent != opct) {
-   pgs = bufcachepercent * dmapages / 100;
-   bufadjust(pgs); /* adjust bufpages */
-   bufhighpages = bufpages; /* set high water mark */
+   if (bufcachepercent != newpct) {
+   bufcachepercent = newpct;
+   bufadjustpct();
}
return(0);
}
Index: kern/uipc_mbuf.c
===
RCS file: /home/tedu/cvs/src/sys/kern/uipc_mbuf.c,v
retrieving revision 1.157
diff -u -r1.157 uipc_mbuf.c
--- kern/uipc_mbuf.c4 May 2011 16:05:49 -   1.157
+++ kern/uipc_mbuf.c20 Jun 2011 19:22:34 -
@@ -89,7 +89,6 @@
 
 #include 
 
-#include 
 #include 
 
 #ifdef DDB
Index: kern/vfs_bio.c
===
RCS file: /home/tedu/cvs/src/sys/kern/vfs_bio.c,v
retrieving revision 1.130
diff -u -r1.130 vfs_bio.c
--- kern/vfs_bio.c  5 Jun 2011 19:41:04 -   1.130
+++ kern/vfs_bio.c  20 Jun 2011 19:22:34 -
@@ -58,6 +58,7 @@
 #include 
 
 #include 
+#include/* need dma_constraint */
 
 #include 
 
@@ -119,6 +120,8 @@
 struct proc *cleanerproc;
 int bd_req;/* Sleep point for cleaner daemon. */
 
+void bufadjust(int);
+
 void
 bremfree(struct buf *bp)
 {
@@ -322,6 +325,18 @@
tsleep(&needbuffer, PRIBIO, "needbuffer", 0);
}
splx(s);
+}
+
+void
+bufadjustpct(void)
+{
+   u_int64_t dmapages;
+   int pgs;
+
+   dmapages = uvm_pagecount(&dma_constraint);
+   pgs = bufcachepercent * dmapages / 100;
+   bufadjust(pgs); /* adjust bufpages */
+   bufhighpages

Re: hibernate_machdep.c depends on acpi

2011-06-20 Thread Mike Larkin
On Mon, Jun 20, 2011 at 06:38:40PM +0200, Mike Belopuhov wrote:
> On Mon, Jun 20, 2011 at 13:22 +0200, Mark Kettenis wrote:
> > > Date: Mon, 20 Jun 2011 11:04:24 +0200
> > > From: Mike Belopuhov 
> > > 
> > > hi,
> > > 
> > > the hibernate_machdep.c file depends on the acpi so it would be
> > > nice if we excluded this file if kernel config doesn't reference
> > > acpi. a simple fix that establishes the dependency is below. ok?
> > 
> > The hibernate code doesn't really depend on ACPI.  Currently it is
> > only called by the acpi code, but it should work just as well on
> > systems without ACPI.
> > 
> 
> it's an unfortunate consequence of putting an assembler chunk of the
> hibernate code into the acpi_wakecode.S.

We could split that up I suppose. There are two functions in there that
are needed in hibernate, one to swap stacks and the other to bounce down
to the S3 resume trampoline.

-ml



Re: hibernate_machdep.c depends on acpi

2011-06-20 Thread Mike Larkin
On Mon, Jun 20, 2011 at 01:02:01PM +0100, Owain Ainsworth wrote:
> On Mon, Jun 20, 2011 at 01:54:38PM +0200, Mark Kettenis wrote:
> > > Date: Mon, 20 Jun 2011 13:22:52 +0200 (CEST)
> > > From: Mark Kettenis 
> > > 
> > > > Date: Mon, 20 Jun 2011 11:04:24 +0200
> > > > From: Mike Belopuhov 
> > > > 
> > > > hi,
> > > > 
> > > > the hibernate_machdep.c file depends on the acpi so it would be
> > > > nice if we excluded this file if kernel config doesn't reference
> > > > acpi. a simple fix that establishes the dependency is below. ok?
> > > 
> > > The hibernate code doesn't really depend on ACPI.  Currently it is
> > > only called by the acpi code, but it should work just as well on
> > > systems without ACPI.
> > > 
> > > The code should be !small_kernel though; it seems it is currently
> > > wasting ramdisk space.
> > 
> > Turns out it isn't actually wasting space, or at least not a lot of
> > it, since the whole file is wrapped in #ifndef SMALL_KERNEL.  We could
> > still consider adding !small_kernel, since it will speed up building
> > ramdisk kernels a bit.
> 
> Agreed, !small_kernel in the config is much nicer than wrapping the
> whole file in an #ifndef.
> 
> If no one else does this i'll whip up the diff later today.
> 
> -0-
> -- 
> The sooner all the animals are dead, the sooner we'll find their money.
>   -- Ed Bluestone, "The National Lampoon"

I'm ok with the diff, mlarkin@

PS Nathanael Rensen  pointed this out to me
a few months back, just never got around to it.

-ml



Re: pf flag PFDESC_IP_REAS

2011-06-20 Thread Claudio Jeker
On Mon, Jun 20, 2011 at 02:09:39AM +0200, Alexander Bluhm wrote:
> Hi,
> 
> We accept more TCP reset packets in pf, if fragment reassembly is
> turned off.  That does not make sense to me.  It came into the tree
> here:
> 
> revision 1.443
> date: 2004/04/27 18:28:07;  author: frantzen;  state: Exp;  lines: +9 -6
> validate the sequence numbers on TCP resets are an exact match.  check is only
> enabled when we're doing full frag reassembly and thus have full seq info
> ok markus@
> 
> Nowadays we have full fragment reassembly on by default, the fragment
> cache has gone.  When the user turns it off, he has to cope with
> the consequences.  Fragmented TCP reset packets too short for the
> sequence number are likely to be evil.
> 
> ok to remove PFDESC_IP_REAS?
> 

Yes please. OK claudio@ and sorry for the conflict.
The codepath with this check is only entered with either not fragmented
packets or with packets that are reassembled. So there is no way you could
end up there with a fragment. Plus it removes the pd from
pf_normalize_ip() which is something I planned to do soon.

> 
> Index: net/pf.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/net/pf.c,v
> retrieving revision 1.747
> diff -u -p -r1.747 pf.c
> --- net/pf.c  2 Jun 2011 22:08:40 -   1.747
> +++ net/pf.c  17 Jun 2011 23:59:35 -
> @@ -3617,8 +3617,7 @@ pf_tcp_track_full(struct pf_state_peer *
>   (ackskew <= (MAXACKWINDOW << sws)) &&
>   /* Acking not more than one window forward */
>   ((th->th_flags & TH_RST) == 0 || orig_seq == src->seqlo ||
> - (orig_seq == src->seqlo + 1) || (orig_seq + 1 == src->seqlo) ||
> - (pd->flags & PFDESC_IP_REAS) == 0)) {
> + (orig_seq == src->seqlo + 1) || (orig_seq + 1 == src->seqlo))) {
>   /* Require an exact/+1 sequence match on resets when possible */
>  
>   if (dst->scrub || src->scrub) {
> @@ -5810,7 +5809,7 @@ pf_test(int dir, struct ifnet *ifp, stru
>   h = mtod(m, struct ip *);
>   if (pf_status.reass &&
>   (h->ip_off & htons(IP_MF | IP_OFFMASK)) &&
> - pf_normalize_ip(m0, dir, kif, &reason, &pd) != PF_PASS) {
> + pf_normalize_ip(m0, dir, kif, &reason) != PF_PASS) {
>   action = PF_DROP;
>   goto done;
>   }
> @@ -6090,7 +6089,7 @@ pf_test6(int fwdir, struct ifnet *ifp, s
>  
>   /* packet reassembly */
>   if (pf_status.reass &&
> - pf_normalize_ip6(m0, fwdir, kif, &reason, &pd) != PF_PASS) {
> + pf_normalize_ip6(m0, fwdir, kif, &reason) != PF_PASS) {
>   action = PF_DROP;
>   goto done;
>   }
> Index: net/pf_norm.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/net/pf_norm.c,v
> retrieving revision 1.133
> diff -u -p -r1.133 pf_norm.c
> --- net/pf_norm.c 24 May 2011 14:01:52 -  1.133
> +++ net/pf_norm.c 17 Jun 2011 23:58:35 -
> @@ -740,7 +740,7 @@ pf_refragment6(struct mbuf **m0, struct 
>  
>  int
>  pf_normalize_ip(struct mbuf **m0, int dir, struct pfi_kif *kif,
> -u_short *reason, struct pf_pdesc *pd)
> +u_short *reason)
>  {
>   struct mbuf *m = *m0;
>   struct ip   *h = mtod(m, struct ip *);
> @@ -787,7 +787,6 @@ pf_normalize_ip(struct mbuf **m0, int di
>   if (h->ip_off & ~htons(IP_DF))
>   h->ip_off &= htons(IP_DF);
>  
> - pd->flags |= PFDESC_IP_REAS;
>   return (PF_PASS);
>  
>   drop:
> @@ -798,7 +797,7 @@ pf_normalize_ip(struct mbuf **m0, int di
>  #ifdef INET6
>  int
>  pf_normalize_ip6(struct mbuf **m0, int dir, struct pfi_kif *kif,
> -u_short *reason, struct pf_pdesc *pd)
> +u_short *reason)
>  {
>   struct mbuf *m = *m0;
>   struct ip6_hdr  *h = mtod(m, struct ip6_hdr *);
> @@ -924,7 +923,6 @@ pf_normalize_ip6(struct mbuf **m0, int d
>   if (m == NULL)
>   return (PF_PASS);
>  
> - pd->flags |= PFDESC_IP_REAS;
>   return (PF_PASS);
>  
>   shortpkt:
> Index: net/pfvar.h
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/net/pfvar.h,v
> retrieving revision 1.332
> diff -u -p -r1.332 pfvar.h
> --- net/pfvar.h   24 May 2011 14:01:52 -  1.332
> +++ net/pfvar.h   17 Jun 2011 23:58:57 -
> @@ -1221,8 +1221,6 @@ struct pf_pdesc {
>   u_int16_t   *proto_sum;
>  
>   u_int16_trdomain;   /* original routing domain */
> - u_int16_tflags;
> -#define PFDESC_IP_REAS   0x0002  /* IP frags would've been 
> reassembled */
>   sa_family_t  af;
>   u_int8_t proto;
>   u_int8_t tos;
> @@ -1777,10 +1775,8 @@ intpf_match_gid(u_int8_t, gid_t, gid_t,
>  
>  int  pf_refragment6(struct mbuf **, struct m_tag *mtag, int);
>  void pf_normalize_init(void);
> -int  pf_normalize_ip(struct mbu

Re: Convert SO_RTABLE protocol level to SOL_SOCKET

2011-06-20 Thread Claudio Jeker
On Mon, Jun 20, 2011 at 06:30:11PM +0200, Mike Belopuhov wrote:
> Now that we support SO_RTABLE on the socket level, it makes
> sense to cleanup the tree.  OK?
> 

The if (getsockopt() && errno != ENOPROTOOPT) constructs are in my opinion
evil but the sa_family == AF_INET check is not much better but I guess you
should have a closer look at tcpbench:
if (ptb->Vflag) {
if (setsockopt(sock, SOL_SOCKET, SO_RTABLE,
&ptb->Vflag, sizeof(ptb->Vflag)) == -1 &&
errno != ENOPROTOOPT)
err(1, "setsockopt SO_RTABLE");
} else if (ptb->Vflag)
warnx("rtable only supported on AF_INET");

That does not make sense.
The other changes are OK claudio@

> Index: sbin/ping/ping.c
> ===
> RCS file: /home/cvs/src/sbin/ping/ping.c,v
> retrieving revision 1.88
> diff -u -p -r1.88 ping.c
> --- sbin/ping/ping.c  3 Jul 2010 04:44:51 -   1.88
> +++ sbin/ping/ping.c  20 Jun 2011 15:31:59 -
> @@ -312,7 +312,7 @@ main(int argc, char *argv[])
>   errx(1, "rtable value is %s: %s",
>   errstr, optarg);
>  
> - if (setsockopt(s, IPPROTO_IP, SO_RTABLE, &rtableid,
> + if (setsockopt(s, SOL_SOCKET, SO_RTABLE, &rtableid,
>   sizeof(rtableid)) == -1)
>   err(1, "setsockopt SO_RTABLE");
>   break;
> Index: usr.bin/nc/netcat.c
> ===
> RCS file: /home/cvs/src/usr.bin/nc/netcat.c,v
> retrieving revision 1.100
> diff -u -p -r1.100 netcat.c
> --- usr.bin/nc/netcat.c   9 Jan 2011 22:16:46 -   1.100
> +++ usr.bin/nc/netcat.c   20 Jun 2011 15:50:35 -
> @@ -552,7 +552,7 @@ remote_connect(const char *host, const c
>   continue;
>  
>   if (rtableid) {
> - if (setsockopt(s, IPPROTO_IP, SO_RTABLE, &rtableid,
> + if (setsockopt(s, SOL_SOCKET, SO_RTABLE, &rtableid,
>   sizeof(rtableid)) == -1)
>   err(1, "setsockopt SO_RTABLE");
>   }
> Index: usr.bin/tcpbench/tcpbench.c
> ===
> RCS file: /home/cvs/src/usr.bin/tcpbench/tcpbench.c,v
> retrieving revision 1.21
> diff -u -p -r1.21 tcpbench.c
> --- usr.bin/tcpbench/tcpbench.c   16 Mar 2011 08:06:10 -  1.21
> +++ usr.bin/tcpbench/tcpbench.c   20 Jun 2011 15:53:59 -
> @@ -719,9 +719,10 @@ server_init(struct addrinfo *aitop, stru
>   warn("socket");
>   continue;
>   }
> - if (ptb->Vflag && ai->ai_family == AF_INET) {
> - if (setsockopt(sock, IPPROTO_IP, SO_RTABLE,
> - &ptb->Vflag, sizeof(ptb->Vflag)) == -1)
> + if (ptb->Vflag) {
> + if (setsockopt(sock, SOL_SOCKET, SO_RTABLE,
> + &ptb->Vflag, sizeof(ptb->Vflag)) == -1 &&
> + errno != ENOPROTOOPT)
>   err(1, "setsockopt SO_RTABLE");
>   } else if (ptb->Vflag)
>   warnx("rtable only supported on AF_INET");
> @@ -817,9 +818,10 @@ client_init(struct addrinfo *aitop, int 
>   warn("socket");
>   continue;
>   }
> - if (ptb->Vflag && ai->ai_family == AF_INET) {
> - if (setsockopt(sock, IPPROTO_IP, SO_RTABLE,
> - &ptb->Vflag, sizeof(ptb->Vflag)) == -1)
> + if (ptb->Vflag) {
> + if (setsockopt(sock, SOL_SOCKET, SO_RTABLE,
> + &ptb->Vflag, sizeof(ptb->Vflag)) == -1 &&
> + errno != ENOPROTOOPT)
>   err(1, "setsockopt SO_RTABLE");
>   } else if (ptb->Vflag)
>   warnx("rtable only supported on AF_INET");
> Index: usr.bin/telnet/commands.c
> ===
> RCS file: /home/cvs/src/usr.bin/telnet/commands.c,v
> retrieving revision 1.52
> diff -u -p -r1.52 commands.c
> --- usr.bin/telnet/commands.c 3 Jul 2010 04:44:51 -   1.52
> +++ usr.bin/telnet/commands.c 20 Jun 2011 16:00:02 -
> @@ -2397,7 +2397,7 @@ tn(argc, argv)
>   continue;
>  
>   if (rtableid) {
> - if (setsockopt(net, IPPROTO_IP, SO_RTABLE, &rtableid,
> + if (setsockopt(net, SOL_SOCKET, SO_RTABLE, &rtableid,
>   sizeof(rtableid)) == -1)
>   perror("setsockopt (SO_RTABLE)");
>  

Re: hibernate_machdep.c depends on acpi

2011-06-20 Thread Mike Belopuhov
On Mon, Jun 20, 2011 at 13:22 +0200, Mark Kettenis wrote:
> > Date: Mon, 20 Jun 2011 11:04:24 +0200
> > From: Mike Belopuhov 
> > 
> > hi,
> > 
> > the hibernate_machdep.c file depends on the acpi so it would be
> > nice if we excluded this file if kernel config doesn't reference
> > acpi. a simple fix that establishes the dependency is below. ok?
> 
> The hibernate code doesn't really depend on ACPI.  Currently it is
> only called by the acpi code, but it should work just as well on
> systems without ACPI.
> 

it's an unfortunate consequence of putting an assembler chunk of the
hibernate code into the acpi_wakecode.S.



Re: hibernate_machdep.c depends on acpi

2011-06-20 Thread Theo de Raadt
> The code should be !small_kernel though; it seems it is currently
> wasting ramdisk space.

Yes, it should be !small_kernel



Convert SO_RTABLE protocol level to SOL_SOCKET

2011-06-20 Thread Mike Belopuhov
Now that we support SO_RTABLE on the socket level, it makes
sense to cleanup the tree.  OK?

Index: sbin/ping/ping.c
===
RCS file: /home/cvs/src/sbin/ping/ping.c,v
retrieving revision 1.88
diff -u -p -r1.88 ping.c
--- sbin/ping/ping.c3 Jul 2010 04:44:51 -   1.88
+++ sbin/ping/ping.c20 Jun 2011 15:31:59 -
@@ -312,7 +312,7 @@ main(int argc, char *argv[])
errx(1, "rtable value is %s: %s",
errstr, optarg);
 
-   if (setsockopt(s, IPPROTO_IP, SO_RTABLE, &rtableid,
+   if (setsockopt(s, SOL_SOCKET, SO_RTABLE, &rtableid,
sizeof(rtableid)) == -1)
err(1, "setsockopt SO_RTABLE");
break;
Index: usr.bin/nc/netcat.c
===
RCS file: /home/cvs/src/usr.bin/nc/netcat.c,v
retrieving revision 1.100
diff -u -p -r1.100 netcat.c
--- usr.bin/nc/netcat.c 9 Jan 2011 22:16:46 -   1.100
+++ usr.bin/nc/netcat.c 20 Jun 2011 15:50:35 -
@@ -552,7 +552,7 @@ remote_connect(const char *host, const c
continue;
 
if (rtableid) {
-   if (setsockopt(s, IPPROTO_IP, SO_RTABLE, &rtableid,
+   if (setsockopt(s, SOL_SOCKET, SO_RTABLE, &rtableid,
sizeof(rtableid)) == -1)
err(1, "setsockopt SO_RTABLE");
}
Index: usr.bin/tcpbench/tcpbench.c
===
RCS file: /home/cvs/src/usr.bin/tcpbench/tcpbench.c,v
retrieving revision 1.21
diff -u -p -r1.21 tcpbench.c
--- usr.bin/tcpbench/tcpbench.c 16 Mar 2011 08:06:10 -  1.21
+++ usr.bin/tcpbench/tcpbench.c 20 Jun 2011 15:53:59 -
@@ -719,9 +719,10 @@ server_init(struct addrinfo *aitop, stru
warn("socket");
continue;
}
-   if (ptb->Vflag && ai->ai_family == AF_INET) {
-   if (setsockopt(sock, IPPROTO_IP, SO_RTABLE,
-   &ptb->Vflag, sizeof(ptb->Vflag)) == -1)
+   if (ptb->Vflag) {
+   if (setsockopt(sock, SOL_SOCKET, SO_RTABLE,
+   &ptb->Vflag, sizeof(ptb->Vflag)) == -1 &&
+   errno != ENOPROTOOPT)
err(1, "setsockopt SO_RTABLE");
} else if (ptb->Vflag)
warnx("rtable only supported on AF_INET");
@@ -817,9 +818,10 @@ client_init(struct addrinfo *aitop, int 
warn("socket");
continue;
}
-   if (ptb->Vflag && ai->ai_family == AF_INET) {
-   if (setsockopt(sock, IPPROTO_IP, SO_RTABLE,
-   &ptb->Vflag, sizeof(ptb->Vflag)) == -1)
+   if (ptb->Vflag) {
+   if (setsockopt(sock, SOL_SOCKET, SO_RTABLE,
+   &ptb->Vflag, sizeof(ptb->Vflag)) == -1 &&
+   errno != ENOPROTOOPT)
err(1, "setsockopt SO_RTABLE");
} else if (ptb->Vflag)
warnx("rtable only supported on AF_INET");
Index: usr.bin/telnet/commands.c
===
RCS file: /home/cvs/src/usr.bin/telnet/commands.c,v
retrieving revision 1.52
diff -u -p -r1.52 commands.c
--- usr.bin/telnet/commands.c   3 Jul 2010 04:44:51 -   1.52
+++ usr.bin/telnet/commands.c   20 Jun 2011 16:00:02 -
@@ -2397,7 +2397,7 @@ tn(argc, argv)
continue;
 
if (rtableid) {
-   if (setsockopt(net, IPPROTO_IP, SO_RTABLE, &rtableid,
+   if (setsockopt(net, SOL_SOCKET, SO_RTABLE, &rtableid,
sizeof(rtableid)) == -1)
perror("setsockopt (SO_RTABLE)");
}
Index: usr.sbin/dhcrelay/dhcrelay.c
===
RCS file: /home/cvs/src/usr.sbin/dhcrelay/dhcrelay.c,v
retrieving revision 1.34
diff -u -p -r1.34 dhcrelay.c
--- usr.sbin/dhcrelay/dhcrelay.c3 Jul 2010 04:44:52 -   1.34
+++ usr.sbin/dhcrelay/dhcrelay.c20 Jun 2011 16:05:40 -
@@ -176,7 +176,7 @@ main(int argc, char *argv[])
if (setsockopt(sp->fd, SOL_SOCKET, SO_REUSEPORT,
&opt, sizeof(opt)) == -1)
error("setsockopt: %m");
-   if (setsockopt(sp->fd, IPPROTO_IP, SO_RTABLE, &rdomain,
+   if (setsockopt(sp->fd, SOL_SOCKET, SO_RTABLE, &rdomain,
sizeof(rdomain)) == -1)
error("setsockopt

Re: X configuration changes for synaptics - please test

2011-06-20 Thread Bryan Vyhmeister
Sorry about that. Attached instead of inline. My dmesg and Xorg.0.log
are now inline.

Bryan


OpenBSD 4.9-current (GENERIC.MP) #0: Sun Jun 19 17:02:51 PDT 2011
r...@nine.dsvc.net:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Atom(TM) CPU N270 @ 1.60GHz ("GenuineIntel" 686-class) 1.60 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE
real mem  = 2137387008 (2038MB)
avail mem = 2092212224 (1995MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 03/05/09, BIOS32 rev. 0 @
0xfdc40, SMBIOS rev. 2.5 @ 0xf2350 (34 entries)
bios0: vendor Dell Inc. version "A04" date 03/05/2009
bios0: Dell Inc. Vostro A90
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC HPET MCFG TCPA TMOR APIC BOOT SSDT
acpi0: wakeup devices LID0(S3) HDEF(S4) PXS1(S4) PXS2(S4) PXS3(S3)
PXS4(S4) PXS5(S4) PXS6(S4) USB1(S0) USB2(S0) USB3(S0) USB4(S0)
USB7(S0) SLT0(S4) SLT1(S4) SLT2(S4) SL
T3(S4) SLT6(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
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Atom(TM) CPU N270 @ 1.60GHz ("GenuineIntel" 686-class) 1.60 GHz
cpu1: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (RP01)
acpiprt2 at acpi0: bus 3 (RP02)
acpiprt3 at acpi0: bus 4 (RP03)
acpiprt4 at acpi0: bus -1 (RP04)
acpiprt5 at acpi0: bus -1 (RP05)
acpiprt6 at acpi0: bus -1 (RP06)
acpiprt7 at acpi0: bus 5 (PCIB)
acpiec0 at acpi0
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpitz0 at acpi0: critical temperature is 102 degC
acpibtn0 at acpi0: LID0
acpibtn1 at acpi0: PWRB
acpibtn2 at acpi0: SLPB
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT1 serial 11 type Lion oem "DELL"
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: LCD_
bios0: ROM list: 0xc/0xec00! 0xcf000/0x1000 0xe/0x1800!
cpu0: Enhanced SpeedStep 1597 MHz: speeds: 1600, 1333, 1067, 800 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82945GME Host" rev 0x03
vga1 at pci0 dev 2 function 0 "Intel 82945GME Video" rev 0x03
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0 at vga1: apic 1 int 16
drm0 at inteldrm0
"Intel 82945GM Video" rev 0x03 at pci0 dev 2 function 1 not configured
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02: msi
azalia0: codecs: Realtek ALC268
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: apic 1 int 17
pci1 at ppb0 bus 2
"JMicron SD/MMC" rev 0x00 at pci1 dev 0 function 0 not configured
sdhc0 at pci1 dev 0 function 2 "JMicron SD Host Controller" rev 0x00:
apic 1 int 16
sdmmc0 at sdhc0
"JMicron Memory Stick" rev 0x00 at pci1 dev 0 function 3 not configured
ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: apic 1 int 16
pci2 at ppb1 bus 3
iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 5100" rev 0x00: msi,
MIMO 1T2R, MoW, address 00:21:6b:94:12:fa
ppb2 at pci0 dev 28 function 2 "Intel 82801GB PCIE" rev 0x02: apic 1 int 18
pci3 at ppb2 bus 4
re0 at pci3 dev 0 function 0 "Realtek 8101E" rev 0x02: RTL8102EL
(0x2480), apic 1 int 18, address 00:24:e8:a6:6a:d3
rlphy0 at re0 phy 7: RTL8201L 10/100 PHY, rev. 1
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x02: apic 1 int 23
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x02: apic 1 int 19
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x02: apic 1 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x02: apic 1 int 16
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x02: apic 1 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 82801BAM Hub-to-PCI" rev 0xe2
pci4 at ppb3 bus 5
ichpcib0 at pci0 dev 31 function 0 "Intel 82801GBM LPC" rev 0x02: PM disabled
pciide0 at pci0 dev 31 function 1 "Intel 82801GB IDE" rev 0x02: DMA,
channel 0 configured to compatibility, channel 1 configured to
compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 1-sector PIO, LBA, 14559MB, 29818656 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
pciide0: channel 1 ignored (disabled)
ichiic0 at pci0 dev 31 function 3 "Intel 82801GB SMBus" rev 0x02: apic 1 int 19
iic0 at ichiic0
spdmem0 at iic0 addr 0x50: 2GB DDR2 SDRAM non-parity PC2-5300CL5 SO-DIMM
usb1 at uhci0: 

Re: X configuration changes for synaptics - please test

2011-06-20 Thread Bryan Vyhmeister
Attached is my dmesg output and Xorg.0.log from my Dell Vostro A90. My
primary motivation for testing this was to see if I could disable
tapping and by default, that is how it works. I am now also able to
scroll with the touchpad. All of this works seamlessly without an
xorg.conf. Everything has been working as expected since yesterday
when I installed everything. Great work guys!

I used the two initial patches (wscons_config.2.diff and
xf86-input-keyboard.diff) along with synaptics.v2.diff.

Bryan

[demime 1.01d removed an attachment of type application/octet-stream which had 
a name of mini9-dmesg]

[demime 1.01d removed an attachment of type text/x-log which had a name of 
mini9-Xorg.0.log]



Re: hibernate_machdep.c depends on acpi

2011-06-20 Thread Mark Kettenis
> Date: Mon, 20 Jun 2011 12:31:57 +0100
> From: Stuart Henderson 
> 
> On 2011/06/20 13:22, Mark Kettenis wrote:
> > > Date: Mon, 20 Jun 2011 11:04:24 +0200
> > > From: Mike Belopuhov 
> > > 
> > > hi,
> > > 
> > > the hibernate_machdep.c file depends on the acpi so it would be
> > > nice if we excluded this file if kernel config doesn't reference
> > > acpi. a simple fix that establishes the dependency is below. ok?
> > 
> > The hibernate code doesn't really depend on ACPI.  Currently it is
> > only called by the acpi code, but it should work just as well on
> > systems without ACPI.
> 
> Currently the hibernate code doesn't link if ACPI is not in kernel config.

Then that problem should be fixed.  Meanwhile, I don't think it is a
big issue if people can't compile their frankenkernels.



Re: hibernate_machdep.c depends on acpi

2011-06-20 Thread Owain Ainsworth
On Mon, Jun 20, 2011 at 01:54:38PM +0200, Mark Kettenis wrote:
> > Date: Mon, 20 Jun 2011 13:22:52 +0200 (CEST)
> > From: Mark Kettenis 
> > 
> > > Date: Mon, 20 Jun 2011 11:04:24 +0200
> > > From: Mike Belopuhov 
> > > 
> > > hi,
> > > 
> > > the hibernate_machdep.c file depends on the acpi so it would be
> > > nice if we excluded this file if kernel config doesn't reference
> > > acpi. a simple fix that establishes the dependency is below. ok?
> > 
> > The hibernate code doesn't really depend on ACPI.  Currently it is
> > only called by the acpi code, but it should work just as well on
> > systems without ACPI.
> > 
> > The code should be !small_kernel though; it seems it is currently
> > wasting ramdisk space.
> 
> Turns out it isn't actually wasting space, or at least not a lot of
> it, since the whole file is wrapped in #ifndef SMALL_KERNEL.  We could
> still consider adding !small_kernel, since it will speed up building
> ramdisk kernels a bit.

Agreed, !small_kernel in the config is much nicer than wrapping the
whole file in an #ifndef.

If no one else does this i'll whip up the diff later today.

-0-
-- 
The sooner all the animals are dead, the sooner we'll find their money.
-- Ed Bluestone, "The National Lampoon"



Re: ksh completion

2011-06-20 Thread LEVAI Daniel
On Sun, Jun 19, 2011 at 15:26:26 -0400, STeve Andre' wrote:
> I hope not.  I've seen this as well.  I want to test this, seeing as
> how I just
> bumped into this.  Can you post the last patch for this?

Alexander has a whole bunch of excelent stuff for ksh in his repo. Seven
patches IIRC, and they really improve the usability of ksh (including
the command completing).
Hope he'll repost them (or the URL for it) soon.


Daniel

-- 
LIVAI Daniel
PGP key ID = 0x83B63A8F
Key fingerprint = DBEC C66B A47A DFA2 792D  650C C69B BE4C 83B6 3A8F



Re: hibernate_machdep.c depends on acpi

2011-06-20 Thread Mark Kettenis
> Date: Mon, 20 Jun 2011 13:22:52 +0200 (CEST)
> From: Mark Kettenis 
> 
> > Date: Mon, 20 Jun 2011 11:04:24 +0200
> > From: Mike Belopuhov 
> > 
> > hi,
> > 
> > the hibernate_machdep.c file depends on the acpi so it would be
> > nice if we excluded this file if kernel config doesn't reference
> > acpi. a simple fix that establishes the dependency is below. ok?
> 
> The hibernate code doesn't really depend on ACPI.  Currently it is
> only called by the acpi code, but it should work just as well on
> systems without ACPI.
> 
> The code should be !small_kernel though; it seems it is currently
> wasting ramdisk space.

Turns out it isn't actually wasting space, or at least not a lot of
it, since the whole file is wrapped in #ifndef SMALL_KERNEL.  We could
still consider adding !small_kernel, since it will speed up building
ramdisk kernels a bit.



Re: hibernate_machdep.c depends on acpi

2011-06-20 Thread Mark Kettenis
> Date: Mon, 20 Jun 2011 11:04:24 +0200
> From: Mike Belopuhov 
> 
> hi,
> 
> the hibernate_machdep.c file depends on the acpi so it would be
> nice if we excluded this file if kernel config doesn't reference
> acpi. a simple fix that establishes the dependency is below. ok?

The hibernate code doesn't really depend on ACPI.  Currently it is
only called by the acpi code, but it should work just as well on
systems without ACPI.

The code should be !small_kernel though; it seems it is currently
wasting ramdisk space.

> Index: arch/i386/conf/files.i386
> ===
> RCS file: /home/cvs/src/sys/arch/i386/conf/files.i386,v
> retrieving revision 1.203
> diff -u -p -r1.203 files.i386
> --- arch/i386/conf/files.i386 23 May 2011 09:54:20 -  1.203
> +++ arch/i386/conf/files.i386 17 Jun 2011 10:28:40 -
> @@ -24,7 +24,7 @@ filearch/i386/i386/est.c!small_kernel
>  file arch/i386/i386/gdt.c
>  file arch/i386/i386/in_cksum.s   inet
>  file arch/i386/i386/machdep.c
> -file arch/i386/i386/hibernate_machdep.c
> +file arch/i386/i386/hibernate_machdep.c  acpi
>  file arch/i386/i386/via.c
>  file arch/i386/i386/amd64errata.c!small_kernel
>  file arch/i386/i386/kgdb_machdep.c   kgdb



Re: hibernate_machdep.c depends on acpi

2011-06-20 Thread Stuart Henderson
On 2011/06/20 13:22, Mark Kettenis wrote:
> > Date: Mon, 20 Jun 2011 11:04:24 +0200
> > From: Mike Belopuhov 
> > 
> > hi,
> > 
> > the hibernate_machdep.c file depends on the acpi so it would be
> > nice if we excluded this file if kernel config doesn't reference
> > acpi. a simple fix that establishes the dependency is below. ok?
> 
> The hibernate code doesn't really depend on ACPI.  Currently it is
> only called by the acpi code, but it should work just as well on
> systems without ACPI.

Currently the hibernate code doesn't link if ACPI is not in kernel config.



hibernate_machdep.c depends on acpi

2011-06-20 Thread Mike Belopuhov
hi,

the hibernate_machdep.c file depends on the acpi so it would be
nice if we excluded this file if kernel config doesn't reference
acpi. a simple fix that establishes the dependency is below. ok?

Index: arch/i386/conf/files.i386
===
RCS file: /home/cvs/src/sys/arch/i386/conf/files.i386,v
retrieving revision 1.203
diff -u -p -r1.203 files.i386
--- arch/i386/conf/files.i386   23 May 2011 09:54:20 -  1.203
+++ arch/i386/conf/files.i386   17 Jun 2011 10:28:40 -
@@ -24,7 +24,7 @@ file  arch/i386/i386/est.c!small_kernel
 file   arch/i386/i386/gdt.c
 file   arch/i386/i386/in_cksum.s   inet
 file   arch/i386/i386/machdep.c
-file   arch/i386/i386/hibernate_machdep.c
+file   arch/i386/i386/hibernate_machdep.c  acpi
 file   arch/i386/i386/via.c
 file   arch/i386/i386/amd64errata.c!small_kernel
 file   arch/i386/i386/kgdb_machdep.c   kgdb