Re: [patch] mailwrapper: remove broken fallback code

2015-12-08 Thread Sunil Nimmagadda
> If /etc/mailer.conf doesn't exist, mailwrapper tries to run sendmail,
> giving a confusing error message:
> 
> mailwrapper: cannot exec /usr/libexec/sendmail/sendmail: No such
> file or directory
> 
> This patch removes this fallback code. I believe this is cleaner than
> updating the fallback since we would have to put two paths in: one for
> sendmail/send-mail/mailq and one for makemap/newaliases.

I am not sure about removing the fallback code but if we decide to
keep it, this diff should fix the fallback case.

Index: mailwrapper.c
===
RCS file: /cvs/src/usr.sbin/mailwrapper/mailwrapper.c,v
retrieving revision 1.20
diff -u -p -r1.20 mailwrapper.c
--- mailwrapper.c   12 Oct 2015 22:01:08 -  1.20
+++ mailwrapper.c   8 Dec 2015 09:36:18 -
@@ -41,7 +41,7 @@
 #include 
 
 #define _PATH_MAILERCONF   "/etc/mailer.conf"
-#define _PATH_DEFAULTMTA   "/usr/libexec/sendmail/sendmail"
+#define _PATH_DEFAULTMTA   "/usr/sbin/smtpctl"
 
 struct arglist {
size_t argc, maxc;



Re: Does grep need a version?

2015-12-08 Thread Daniel Dickman
you're missing at least the removal of the flag in the standards section of the 
man page.

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

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



Re: [PATCH] doas authentication type

2015-12-08 Thread David Gwynne
I would like this. It has my OK for what it is worth here.
On 8 Dec 2015 11:41 am, "Stuart Henderson"  wrote:

> On 2015/11/25 00:14, Stuart Henderson wrote:
> > On 2015/11/24 11:24, Richard Johnson wrote:
> > > We use 2-factor authn for sudo & doas, as well as for most logins.
> > > Presently, we transport Yubikey and other HOTP strings across RADIUS
> to an
> > > otpd authserver
> >
> > Interesting...is that a fork of the TRI-D otpd? I found the googlecode
> > one and a github export but nothing that seems currently active and
> > nothing that supports Yubikey. (I'm on the lookout for things which
> > handles central Yubikey auth, none of the programs that I've found so
> > far are very appealing).
> >
> > > This is on systems with 1200+ user accounts, about 30 active daily.
> Users
> > > expect that if they can log in as username:radius or username:skey,
> they
> > > should be able to sudo -a radius or sudo -a skey.
> > >
> > > Moving away from Kerberos means possible increasing use of sudo or
> doas by
> > > regular users to run transfer commands to data archives.  For this, it
> would
> > > be useful if doas supported "-a skey".  Then I could just use doas; the
> > > command is otherwise plain enough.
> > >
> > > But that's not a lot of users across the entire OpenBSD installed base.
> > >
> > > Installing sudo from ports is still an option. I need to debug the -a
> > > failure there now. ;)
> > >
> > >
> > > Richard
> > >
> >
> > Personally my take on this is that as long as it's just done as -a
> > then it's small and simple to implement (pass a string from args to
> > auth_userokay), and there's no other way to provide access to this which
> > is an important, though lesser-known, part of bsd_auth. We already trust
> > auth_userokay with network-supplied strings for this (e.g. as part of
> > the username from ssh) so this doesn't seem to add any real exposure
> > risk.
> >
>
> Here's an updated version of Renaud's diff against -current after the
> change
> to auth_userchallenge.
>
> Index: doas.c
> ===
> RCS file: /cvs/src/usr.bin/doas/doas.c,v
> retrieving revision 1.46
> diff -u -p -r1.46 doas.c
> --- doas.c  3 Dec 2015 08:12:15 -   1.46
> +++ doas.c  8 Dec 2015 01:26:19 -
> @@ -37,7 +37,8 @@
>  static void __dead
>  usage(void)
>  {
> -   fprintf(stderr, "usage: doas [-ns] [-C config] [-u user] command
> [args]\n");
> +   fprintf(stderr, "usage: doas [-ns] [-a style] [-C config] [-u
> user]"
> +   " command [args]\n");
> exit(1);
>  }
>
> @@ -323,6 +324,7 @@ main(int argc, char **argv, char **envp)
> int nflag = 0;
> char cwdpath[PATH_MAX];
> const char *cwd;
> +   char *login_style = NULL;
>
> if (pledge("stdio rpath getpw tty proc exec id", NULL) == -1)
> err(1, "pledge");
> @@ -331,8 +333,11 @@ main(int argc, char **argv, char **envp)
>
> uid = getuid();
>
> -   while ((ch = getopt(argc, argv, "C:nsu:")) != -1) {
> +   while ((ch = getopt(argc, argv, "a:C:nsu:")) != -1) {
> switch (ch) {
> +   case 'a':
> +   login_style = optarg;
> +   break;
> case 'C':
> confpath = optarg;
> break;
> @@ -412,7 +417,7 @@ main(int argc, char **argv, char **envp)
> if (nflag)
> errx(1, "Authorization required");
>
> -   if (!(as = auth_userchallenge(myname, NULL, "auth-doas",
> +   if (!(as = auth_userchallenge(myname, login_style,
> "auth-doas",
> )))
> err(1, "auth challenge failed");
> if (!challenge) {
> Index: doas.1
> ===
> RCS file: /cvs/src/usr.bin/doas/doas.1,v
> retrieving revision 1.14
> diff -u -p -r1.14 doas.1
> --- doas.1  27 Jul 2015 17:57:06 -  1.14
> +++ doas.1  8 Dec 2015 01:26:19 -
> @@ -22,6 +22,7 @@
>  .Sh SYNOPSIS
>  .Nm doas
>  .Op Fl ns
> +.Op Fl a Ar style
>  .Op Fl C Ar config
>  .Op Fl u Ar user
>  .Ar command
> @@ -40,6 +41,19 @@ is specified.
>  .Pp
>  The options are as follows:
>  .Bl -tag -width tenletters
> ++.It Fl a Ar style
> ++The
> ++.Fl a
> ++(authentication style) option causes
> ++.Nm
> ++to use the specified authentication style when validating the user,
> ++as allowed by
> ++.Pa /etc/login.conf .
> ++The system administrator may specify a list of doas-specific
> ++authentication methods by adding an
> ++.Sq auth-doas
> ++entry in
> ++.Pa /etc/login.conf .
>  .It Fl C Ar config
>  Parse and check the configuration file
>  .Ar config ,
>
>


pledge spamlogd(8)

2015-12-08 Thread Ricardo Mestre
Hi tech@

This is the last spamd* utility that I still didn't touch, but it seems to be
fairly easy to pledge.

After privdrop, and before the program loop (pcap_loop(3) in this case) check if
syncsend is used (daemon was started with -Y argument), then pledge for rpath,
wpath and flock in order to update the DB (/var/db/spamd) and inet to
sendmsg(2) to the sync'ed host(s). If syncsend is NULL then it just needs to
update the DB, and therefore doesn't need inet.

For the interested, I caught the 2 codepaths like this

1) pcap_loop(3) -> pcap_read -> logpkt_handler -> dbupdate -> sync_addr ->
sync_send -> sendmsg(2)

2) pcap_loop -> pcap_read -> logpkt_handler -> dbupdate

Index: spamlogd.c
===
RCS file: /cvs/src/libexec/spamlogd/spamlogd.c,v
retrieving revision 1.25
diff -u -p -u -r1.25 spamlogd.c
--- spamlogd.c  21 Jan 2015 21:50:33 -  1.25
+++ spamlogd.c  8 Dec 2015 09:05:17 -
@@ -374,6 +374,14 @@ main(int argc, char **argv)
openlog_r("spamlogd", LOG_PID | LOG_NDELAY, LOG_DAEMON, );
}
 
+   if (syncsend) {
+   if (pledge("stdio rpath wpath inet flock", NULL) == -1)
+   err(1, "pledge");
+   } else {
+   if (pledge("stdio rpath wpath flock", NULL) == -1)
+   err(1, "pledge");
+   }
+
pcap_loop(hpcap, -1, phandler, NULL);
 
logmsg(LOG_NOTICE, "exiting");



Re: Does grep need a version?

2015-12-08 Thread Stuart Henderson
On 2015/12/08 13:22, Marc Espie wrote:
> Keep the version, whatever it is.
> 
> The "check of ports" is annoying, because some of these checks may be in
> scripts and happen at runtime for ports.
> 
> The way it usually happens is:
> something breaks -> porters don't have time to check too closely -> someone
> moves the ports to using gnu grep instead.
> 
> 
> I had rather we had as much stuff as possible working with the base system.
> 
> Having --version is not a problem. Not having it will probably break things,
> and we will probably notice six months from now.

yes, I agree 100%. Besides ports, who knows what checks sysadmins may
have in local scripts to identify the type of grep on a system and use
the right flags?



Re: ugenctl for attaching USB devices to ugen instead of their specific driver

2015-12-08 Thread Xiaofan Chen
On Mon, Dec 7, 2015 at 10:43 PM, Stuart Henderson  wrote:
> On 2015/12/07 22:11, Xiaofan Chen wrote:
>> Not so sure if there is a port of hidapi under OpenBSD.
>> Ref: http://www.signal11.us/oss/hidapi/
>
> It isn't ported to OpenBSD, and it's one of those projects where they
> don't provide any infrastructure to build a library and suggest that
> people copy it to their source tree and add to their own Makefiles..
>

Maybe you are looking at an old version. Now it is not like that.
  https://github.com/signal11/hidapi

Since it is working under FreeBSD with the libusb backend, it is
probably not so difficult to port to OpenBSD as well.

-- 
Xiaofan



Re: Does grep need a version?

2015-12-08 Thread Ted Unangst
Michael McConville wrote:
> It's been 0.9 since the original import in 2003...

note we also have --mmap for the sole purpose of compat. i'd say keep it.

anything that *does* check the version will get a number it doesn't like and
then do something "sensible".



Re: Does grep need a version?

2015-12-08 Thread Marc Espie
Keep the version, whatever it is.

The "check of ports" is annoying, because some of these checks may be in
scripts and happen at runtime for ports.

The way it usually happens is:
something breaks -> porters don't have time to check too closely -> someone
moves the ports to using gnu grep instead.


I had rather we had as much stuff as possible working with the base system.

Having --version is not a problem. Not having it will probably break things,
and we will probably notice six months from now.



Re: [patch] Convert modulus to arc4random_uniform

2015-12-08 Thread Jérémie Courrèges-Anglas
Matthew Martin  writes:

> On Mon, Dec 07, 2015 at 09:33:47AM +0100, Theo Buehler wrote:
>> I think some of these are ok, but I'm unsure about some of the others.
>> Here are some of my concerns:
>> 
>> - since arc4random_uniform can potentially loop indefinitely, it
>>   might interfere with predictable timing of some routines.  I can't
>>   tell if this is harmless in all cases below.  This applies in
>>   particular to the proposed changes in the kernel.
>
> I hadn't considered timing problems. I'll look at it again tonight, but
> someone more familiar with the code should certainly look at it before
> committing.
>
>> - changing random() to arc4random() in games might have undesired
>>   side-effects like interfering with the reproducibility of tests or
>>   games.  I think this might apply to awk for the same reason as in the
>>   shells.  
>
> The patch for awk was wrong.

If there's a concern about upstream for nsd/sqlite/libevent, then note
that awk has an upstream too.

[...]

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



ifq serialisation, was Re: taskctx and revisiting if_start serialisation

2015-12-08 Thread David Gwynne
On Sun, Dec 06, 2015 at 02:00:16PM +1000, David Gwynne wrote:
> the current code for serialising if_start calls for mpsafe nics does what it 
> says.

as per mpi@s suggestion, this makes the ifq code responsible for
the task serialisation.

all the machinery is there, but it provides a minimal step toward
coordination of the oactive flag. the only concession is if a driver
wants to clear oactive and run its start routine again it can call
ifq_restart() to have it serialised with the stacks calls to the
start routine.

if there's a desire for a driver to run all of its txeof serialised
with its start routine, we'll figure out the best way to provide
that when the problem really occurs.

if_start_barrier is now called ifq_barrier too.i

Index: dev/pci/if_myx.c
===
RCS file: /cvs/src/sys/dev/pci/if_myx.c,v
retrieving revision 1.90
diff -u -p -r1.90 if_myx.c
--- dev/pci/if_myx.c3 Dec 2015 12:45:56 -   1.90
+++ dev/pci/if_myx.c8 Dec 2015 11:31:09 -
@@ -1208,7 +1208,7 @@ myx_up(struct myx_softc *sc)
ifq_clr_oactive(>if_snd);
SET(ifp->if_flags, IFF_RUNNING);
myx_iff(sc);
-   myx_start(ifp);
+   if_start(ifp);
 
return;
 
@@ -1330,6 +1330,8 @@ myx_down(struct myx_softc *sc)
int  s;
int  ring;
 
+   CLR(ifp->if_flags, IFF_RUNNING);
+
bus_dmamap_sync(sc->sc_dmat, map, 0, map->dm_mapsize,
BUS_DMASYNC_POSTREAD|BUS_DMASYNC_POSTWRITE);
sc->sc_linkdown = sts->ms_linkdown;
@@ -1362,8 +1364,7 @@ myx_down(struct myx_softc *sc)
}
 
ifq_clr_oactive(>if_snd);
-   CLR(ifp->if_flags, IFF_RUNNING);
-   if_start_barrier(ifp);
+   ifq_barrier(>if_snd);
 
for (ring = 0; ring < 2; ring++) {
struct myx_rx_ring *mrr = >sc_rx_ring[ring];
@@ -1702,9 +1703,8 @@ myx_txeof(struct myx_softc *sc, u_int32_
sc->sc_tx_ring_cons = idx;
sc->sc_tx_cons = cons;
 
-   ifq_clr_oactive(>if_snd);
-   if (!ifq_empty(>if_snd))
-   if_start(ifp);
+   if (ifq_is_oactive(>if_snd))
+   ifq_restart(>if_snd);
 }
 
 void
Index: dev/pci/if_bnx.c
===
RCS file: /cvs/src/sys/dev/pci/if_bnx.c,v
retrieving revision 1.118
diff -u -p -r1.118 if_bnx.c
--- dev/pci/if_bnx.c5 Dec 2015 16:23:37 -   1.118
+++ dev/pci/if_bnx.c8 Dec 2015 11:31:09 -
@@ -871,6 +871,7 @@ bnx_attachhook(void *xsc)
ifp = >arpcom.ac_if;
ifp->if_softc = sc;
ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST;
+   ifp->if_xflags = IFXF_MPSAFE;
ifp->if_ioctl = bnx_ioctl;
ifp->if_start = bnx_start;
ifp->if_watchdog = bnx_watchdog;
@@ -4573,20 +4574,14 @@ bnx_tx_intr(struct bnx_softc *sc)
 
used = atomic_sub_int_nv(>used_tx_bd, freed);
 
+   sc->tx_cons = sw_tx_cons;
+
/* Clear the TX timeout timer. */
if (used == 0)
ifp->if_timer = 0;
 
-   /* Clear the tx hardware queue full flag. */
-   if (used < sc->max_tx_bd) {
-   DBRUNIF(ifq_is_oactive(>if_snd),
-   printf("%s: Open TX chain! %d/%d (used/total)\n",
-   sc->bnx_dev.dv_xname, used,
-   sc->max_tx_bd));
-   ifq_clr_oactive(>if_snd);
-   }
-
-   sc->tx_cons = sw_tx_cons;
+   if (ifq_is_oactive(>if_snd))
+   ifq_restart(>if_snd);
 }
 
 //
@@ -4880,10 +4875,8 @@ bnx_start(struct ifnet *ifp)
int used;
u_int16_t   tx_prod, tx_chain_prod;
 
-   /* If there's no link or the transmit queue is empty then just exit. */
-   if (!sc->bnx_link || IFQ_IS_EMPTY(>if_snd)) {
-   DBPRINT(sc, BNX_INFO_SEND,
-   "%s(): No link or transmit queue empty.\n", __FUNCTION__);
+   if (!sc->bnx_link) {
+   ifq_purge(>if_snd);
goto bnx_start_exit;
}
 
Index: net/if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.423
diff -u -p -r1.423 if.c
--- net/if.c8 Dec 2015 10:06:12 -   1.423
+++ net/if.c8 Dec 2015 11:31:09 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: if.c,v 1.423 2015/12/08 10:06:12 dlg Exp $*/
+/* $OpenBSD: if.c,v 1.422 2015/12/05 10:07:55 tedu Exp $   */
 /* $NetBSD: if.c,v 1.35 1996/05/07 05:26:04 thorpej Exp $  */
 
 /*
@@ -153,7 +153,6 @@ voidif_input_process(void *);
 void   ifa_print_all(void);
 #endif
 
-void   if_start_mpsafe(struct ifnet *ifp);
 void   if_start_locked(struct ifnet *ifp);
 
 /*
@@ -512,7 +511,7 @@ if_attach_common(struct ifnet *ifp)
TAILQ_INIT(>if_addrlist);
TAILQ_INIT(>if_maddrlist);
 
-   ifq_init(>if_snd);
+   

Re: [PATCH] doas authentication type

2015-12-08 Thread Ted Unangst
Stuart Henderson wrote:
> > 
> > Personally my take on this is that as long as it's just done as -a
> > then it's small and simple to implement (pass a string from args to
> > auth_userokay), and there's no other way to provide access to this which
> > is an important, though lesser-known, part of bsd_auth. We already trust
> > auth_userokay with network-supplied strings for this (e.g. as part of
> > the username from ssh) so this doesn't seem to add any real exposure
> > risk.
> > 
> 
> Here's an updated version of Renaud's diff against -current after the change
> to auth_userchallenge.

I suppose it's time to bend to user demand. ok.

But all these auth changes are burning up your reserve line budget. :)

>  .Bl -tag -width tenletters
> ++.It Fl a Ar style
> ++The
> ++.Fl a
> ++(authentication style) option causes

And only one set of plus here please. :)



Re: ksh(1): utf8 in emacs editing mode

2015-12-08 Thread Ted Unangst
Sebastien Marie wrote:
> While testing ksh, I found the following problem, that I will try to
> describe. But I dunno if it is just a case no-managed by your patch. It
> looks like a problem in "inserting a UTF-8 char inside the line (opposed
> to 'at end of line')".

This is what Ingo meant by column counting. The cursor may not appear in the
correct place at all times. Note that the diff is a substantial improvment
over the current situation, which would allow inserting the a` *inside* the e`
character.

fwiw, I like this diff. it's very surprisingly compact. ok.



Re: ugenctl for attaching USB devices to ugen instead of their specific driver

2015-12-08 Thread Stuart Henderson
On 2015/12/08 20:55, Xiaofan Chen wrote:
> On Mon, Dec 7, 2015 at 10:43 PM, Stuart Henderson  wrote:
> > On 2015/12/07 22:11, Xiaofan Chen wrote:
> >> Not so sure if there is a port of hidapi under OpenBSD.
> >> Ref: http://www.signal11.us/oss/hidapi/
> >
> > It isn't ported to OpenBSD, and it's one of those projects where they
> > don't provide any infrastructure to build a library and suggest that
> > people copy it to their source tree and add to their own Makefiles..
> >
> 
> Maybe you are looking at an old version. Now it is not like that.
>   https://github.com/signal11/hidapi
> 
> Since it is working under FreeBSD with the libusb backend, it is
> probably not so difficult to port to OpenBSD as well.

I'm looking at 0.7.0, which is the last actual release on
https://github.com/signal11/hidapi/releases.

This isn't another of those projects that expects everyone to use
some random version of development code is it?




Re: [patch] mailwrapper: remove broken fallback code

2015-12-08 Thread Joerg Jung

> On 08 Dec 2015, at 10:39, Sunil Nimmagadda  wrote:
> 
>> If /etc/mailer.conf doesn't exist, mailwrapper tries to run sendmail,
>> giving a confusing error message:
>> 
>> mailwrapper: cannot exec /usr/libexec/sendmail/sendmail: No such
>> file or directory
>> 
>> This patch removes this fallback code. I believe this is cleaner than
>> updating the fallback since we would have to put two paths in: one for
>> sendmail/send-mail/mailq and one for makemap/newaliases.
> 
> I am not sure about removing the fallback code but if we decide to
> keep it, this diff should fix the fallback case.

ok jung@ for the fix below.

I’m also unsure about the fallback code. It was introduced with -r1.4 more than 
16 yrs ago. However, I fail to understand what’s the point of it? I mean why 
running mailwrapper without a config file, that does not make much sense 
and defeats it's purpose, right? AFAIU, the mailer.conf is a must-have,
so the proposed removal of the fallback code makes sense to me.

> Index: mailwrapper.c
> ===
> RCS file: /cvs/src/usr.sbin/mailwrapper/mailwrapper.c,v
> retrieving revision 1.20
> diff -u -p -r1.20 mailwrapper.c
> --- mailwrapper.c 12 Oct 2015 22:01:08 -  1.20
> +++ mailwrapper.c 8 Dec 2015 09:36:18 -
> @@ -41,7 +41,7 @@
> #include 
> 
> #define _PATH_MAILERCONF  "/etc/mailer.conf"
> -#define _PATH_DEFAULTMTA "/usr/libexec/sendmail/sendmail"
> +#define _PATH_DEFAULTMTA "/usr/sbin/smtpctl"
> 
> struct arglist {
>   size_t argc, maxc;
> 



Re: [patch] mailwrapper: remove broken fallback code

2015-12-08 Thread Serguey Parkhomovsky
On Tue, Dec 08, 2015 at 10:39:56AM +0100, Sunil Nimmagadda wrote:
> > If /etc/mailer.conf doesn't exist, mailwrapper tries to run sendmail,
> > giving a confusing error message:
> > 
> > mailwrapper: cannot exec /usr/libexec/sendmail/sendmail: No such
> > file or directory
> > 
> > This patch removes this fallback code. I believe this is cleaner than
> > updating the fallback since we would have to put two paths in: one for
> > sendmail/send-mail/mailq and one for makemap/newaliases.
> 
> I am not sure about removing the fallback code but if we decide to
> keep it, this diff should fix the fallback case.

Good catch; I didn't realize you could also call newaliases/makemap
through /usr/sbin/smtpctl.

If we choose to keep the fallback code, we should probably fix the
manpage for mailwrapper as well. I've attached a revised version of your
patch that documents the fallback behavior.

Index: mailwrapper.8
===
RCS file: /cvs/src/usr.sbin/mailwrapper/mailwrapper.8,v
retrieving revision 1.12
diff -u -p -r1.12 mailwrapper.8
--- mailwrapper.8   27 Mar 2014 22:34:42 -  1.12
+++ mailwrapper.8   8 Dec 2015 16:32:01 -
@@ -120,9 +120,11 @@ is typically set up as a symlink to
 which is not usually invoked on its own.
 .Sh DIAGNOSTICS
 .Nm
-will return an error value and print a diagnostic if its configuration
-file is missing or malformed, or does not contain a mapping for the
-name under which
+will invoke
+.Xr smtpd 8
+if its configuration file is missing.
+It will return an error value and print a diagnostic if its configuration
+file is malformed, or does not contain a mapping for the name under which
 .Nm
 was invoked.
 .Sh SEE ALSO
Index: mailwrapper.c
===
RCS file: /cvs/src/usr.sbin/mailwrapper/mailwrapper.c,v
retrieving revision 1.20
diff -u -p -r1.20 mailwrapper.c
--- mailwrapper.c   12 Oct 2015 22:01:08 -  1.20
+++ mailwrapper.c   8 Dec 2015 16:32:01 -
@@ -41,7 +41,7 @@
 #include 
 
 #define _PATH_MAILERCONF   "/etc/mailer.conf"
-#define _PATH_DEFAULTMTA   "/usr/libexec/sendmail/sendmail"
+#define _PATH_DEFAULTMTA   "/usr/sbin/smtpctl"
 
 struct arglist {
size_t argc, maxc;



Use off_t for lineno in csplit

2015-12-08 Thread Michael McConville
I thought I'd look for other examples after the grep fix.

ok?


Index: csplit.c
===
RCS file: /cvs/src/usr.bin/csplit/csplit.c,v
retrieving revision 1.8
diff -u -p -r1.8 csplit.c
--- csplit.c11 Oct 2015 17:43:03 -  1.8
+++ csplit.c8 Dec 2015 17:57:50 -
@@ -80,7 +80,7 @@ intkflag; /* Keep output if error oc
 /*
  * Other miscellaneous globals (XXX too many)
  */
-longlineno;/* Current line number in input file */
+off_t   lineno;/* Current line number in input file */
 longreps;  /* Number of repetitions for this pattern */
 longnfiles;/* Number of files output so far */
 longmaxfiles;  /* Maximum number of files we can create */
@@ -439,7 +439,7 @@ do_rexp(const char *expr)
 void
 do_lineno(const char *expr)
 {
-   long lastline, tgtline;
+   off_t lastline, tgtline;
char *ep, *p;
FILE *ofp;
 
@@ -455,7 +455,8 @@ do_lineno(const char *expr)
ofp = newfile();
while (lineno + 1 != lastline) {
if ((p = get_line()) == NULL)
-   errx(1, "%ld: out of range", lastline);
+   errx(1, "%lld: out of range",
+   (long long)lastline);
if (fputs(p, ofp) != 0)
break;
}



Re: ksh(1): utf8 in emacs editing mode

2015-12-08 Thread Ingo Schwarze
Hi Sebastien,

Sebastien Marie wrote on Tue, Dec 08, 2015 at 07:06:57AM +0100:
> On Tue, Dec 08, 2015 at 01:19:35AM +0100, Ingo Schwarze wrote:

>> i'd like to propose a simplified version of this patch Frederic Nowak
>> posted a few weeks ago for commit.  Our experience is probably
>> not yet sufficient to develop a full-blown solution for all UTF-8
>> problems in ksh(1), but this is very non-intrusive and makes the
>> following commands better without breaking anything:
>> 
>>  * Ctrl-b, Ctrl-xd, Esc-[D, Esc-OD (backward-char)
>>  * Ctrl-f, Ctrl-xc, Esc-[C, Esc-OC (forward-char)
>>  * Ctrl-h, Ctrl-? (delete-char-backward)
>>  * Esc-[3~ (delete-char-forward)
>>  * Ctrl-k (kill-to-eol)

> While testing ksh, I found the following problem, that I will try to
> describe.  But I dunno if it is just a case no-managed by your patch.

Yes, i noticed that, but decided against trying to handle it in the
same patch.  I looks like that problem can be seperated from making
the above commands work better.

Maybe Frederic's original patch already handles that, too, maybe not.
In cut(1), it was OK to drop in a large patch doing three things at
once, even though that made review harder; allowing us to move faster.
By contrast, in a shell, i'd prefer moving as slowly as possible and
treading as carefully as possible.

Once this is in, let's look at the next step.  :-)

(But i'll wait a day or so for more OKs or objections before
 committing based on OK tedu@ semarie@)

> It looks like a problem in "inserting a UTF-8 char inside the line
> (opposed to 'at end of line')".

True.

> Else your patch is pretty readable, and it would be a good first step.

Thanks for checking!

Yours,
  Ingo



kevent ktrace

2015-12-08 Thread Ted Unangst
allow some inspection of the kevent structs.


Index: kern/kern_event.c
===
RCS file: /cvs/src/sys/kern/kern_event.c,v
retrieving revision 1.67
diff -u -p -r1.67 kern_event.c
--- kern/kern_event.c   5 Dec 2015 10:11:53 -   1.67
+++ kern/kern_event.c   8 Dec 2015 17:41:29 -
@@ -508,6 +508,10 @@ sys_kevent(struct proc *p, void *v, regi
goto done;
for (i = 0; i < n; i++) {
kevp = >kq_kev[i];
+#ifdef KTRACE
+   if (KTRPOINT(p, KTR_STRUCT))
+   ktrevent(p, kevp);
+#endif
kevp->flags &= ~EV_SYSFLAGS;
error = kqueue_register(kq, kevp, p);
if (error) {
@@ -793,6 +797,13 @@ start:
count--;
if (nkev == KQ_NEVENTS) {
splx(s);
+#ifdef KTRACE
+   if (KTRPOINT(p, KTR_STRUCT)) {
+   int i;
+   for (i = 0; i < nkev; i++)
+   ktrevent(p, >kq_kev[i]);
+   }
+#endif
error = copyout(>kq_kev, ulistp,
sizeof(struct kevent) * nkev);
ulistp += nkev;
@@ -806,9 +817,17 @@ start:
TAILQ_REMOVE(>kq_head, , kn_tqe);
splx(s);
 done:
-   if (nkev != 0)
+   if (nkev != 0) {
+#ifdef KTRACE
+   if (KTRPOINT(p, KTR_STRUCT)) {
+   int i;
+   for (i = 0; i < nkev; i++)
+   ktrevent(p, >kq_kev[i]);
+   }
+#endif
error = copyout(>kq_kev, ulistp,
sizeof(struct kevent) * nkev);
+   }
*retval = maxevents - count;
return (error);
 }
Index: sys/ktrace.h
===
RCS file: /cvs/src/sys/sys/ktrace.h,v
retrieving revision 1.26
diff -u -p -r1.26 ktrace.h
--- sys/ktrace.h25 Oct 2015 20:39:54 -  1.26
+++ sys/ktrace.h8 Dec 2015 17:41:06 -
@@ -251,5 +251,7 @@ voidktrstruct(struct proc *, const c
ktrstruct(p, "iovec", s, (count) * sizeof(struct iovec))
 #define ktrcmsghdr(p, c, len) \
ktrstruct(p, "cmsghdr", c, len)
+#define ktrevent(p, kev) \
+   ktrstruct(p, "kevent", kev, sizeof(struct kevent))
 
 #endif /* !_KERNEL */



Re: __progname in base

2015-12-08 Thread Theo Buehler
On Sat, Nov 07, 2015 at 12:20:42PM +0100, Tobias Stoeckmann wrote:
> Based on Todd's patch for at and cron, I did a grep through our base
> tree to see if there are more occurrences of self-made __progname
> handling.

A few more of those:

Index: caesar/caesar.c
===
RCS file: /var/cvs/src/games/caesar/caesar.c,v
retrieving revision 1.17
diff -u -p -r1.17 caesar.c
--- caesar/caesar.c 14 Oct 2015 08:12:12 -  1.17
+++ caesar/caesar.c 8 Dec 2015 17:40:00 -
@@ -69,7 +69,8 @@ int
 main(int argc, char *argv[])
 {
int ch, i, nread;
-   char *inbuf, *p, **av;
+   extern char *__progname;
+   char *inbuf;
int obs[26], try, winner;
double dot, winnerdot;
 
@@ -77,11 +78,7 @@ main(int argc, char *argv[])
err(1, "pledge");
 
/* check to see if we were called as rot13 */
-   av = argv;
-   p = strrchr(*av, '/');
-   if (p++ == NULL)
-   p = *av;
-   if (strcmp(p,"rot13") == 0)
+   if (strcmp(__progname, "rot13") == 0)
printit(13);
 
if (argc > 1) {
Index: hack/hack.end.c
===
RCS file: /var/cvs/src/games/hack/hack.end.c,v
retrieving revision 1.13
diff -u -p -r1.13 hack.end.c
--- hack/hack.end.c 24 Oct 2015 18:26:13 -  1.13
+++ hack/hack.end.c 8 Dec 2015 17:53:00 -
@@ -613,7 +613,7 @@ charcat(char *s, char c)
 void
 prscore(int argc, char **argv)
 {
-   extern char *hname;
+   extern char *__progname;
char **players;
int playerct;
int rank;
@@ -699,7 +699,7 @@ prscore(int argc, char **argv)
  if(playerct > 1) printf("any of ");
  for(i=0; i

Re: patch 3/4 add generic keyboard backlight support

2015-12-08 Thread Joerg Jung
On Tue, Dec 08, 2015 at 10:48:47PM +0100, Mark Kettenis wrote:
> > Date: Mon, 7 Dec 2015 23:44:13 +0100
> > From: Joerg Jung 
> > 
> > Hi,
> > 
> > here comes the third part of the series for generic keyboard backlight
> > support.
> > 
> > Please find below a diff which adds they key(code)s for keyboard
> > backlight control, as found on all recent Intel based Apple Laptop
> > Keyboards.  While here, also add keys for display brightness control
> > found on Apple Keyboards as well.
> > 
> > This is based on a similar diff from Sven-Volker Nowarra and is a NOOP
> > for now, as these keys are not used yet. Using them is target for a
> > later diff.
> > 
> > I'm not familar with keycodes, most of the diff below is 'educated
> > guess', so please, hints are welcome!
> > 
> > Comments, OK?
> 
> Heh, I just looked into this during n2k15 to make the display
> brihtness keys work.

Did you got it working? :)

> I don't think you should add codes to pckbc/wskbdmap_mfii.c unless you
> have some evidence there really are PC-style keyboards that produce
> these codes.

Ok, understood. In my defence: as written above 'educated guess' meant,
I just copy here, using the same approach as the (already 
working) audio keys.
 
> I think you should choose different codes for USB.  Take a look at the
> "HID Usage Tables" document.  There you'll find that 131-134 are
> already assigned.  For my brightness diff I used codes in the reserved
> range that startx at 232 (0xe8).

Ok, makes sense.

> There are already keysyms defined for display brightness in "Group 4".

Yes, I have seen them.

> Using symbols in that group has some consequences though.  Currently
> the code that handles them assumes they are only generated in
> combination with certain modifies keys.

Yes, that is what I guessed and the reason why added them in the
previous group.

Modifier keys means  or , but does not include the famous
 key, right?

Now I'm a bit more confused: where and how should I add the backlight or
brightness keys to be able to access them in wskbd.c later?


> > Index: pckbc/wskbdmap_mfii.c
> > ===
> > RCS file: /cvs/src/sys/dev/pckbc/wskbdmap_mfii.c,v
> > retrieving revision 1.43
> > diff -u -p -r1.43 wskbdmap_mfii.c
> > --- pckbc/wskbdmap_mfii.c   14 Apr 2013 19:32:52 -  1.43
> > +++ pckbc/wskbdmap_mfii.c   7 Dec 2015 22:22:27 -
> > @@ -149,6 +149,10 @@ static const keysym_t pckbd_keydesc_us[]
> >  KC(170),   KS_Print_Screen,
> >  KC(174),   KS_AudioLower,
> >  KC(176),   KS_AudioRaise,
> > +KC(177),   KS_BrightnessDown,
> > +KC(178),   KS_BrightnessUp,
> > +KC(179),   KS_KbdBacklightDown,
> > +KC(180),   KS_KbdBacklightUp,
> >  KC(181),   KS_KP_Divide,
> >  KC(183),   KS_Print_Screen,
> >  KC(184), KS_Cmd2,  KS_Alt_R,   KS_Multi_key,
> > Index: wscons/wsksymdef.h
> > ===
> > RCS file: /cvs/src/sys/dev/wscons/wsksymdef.h,v
> > retrieving revision 1.36
> > diff -u -p -r1.36 wsksymdef.h
> > --- wscons/wsksymdef.h  26 Jan 2014 17:48:08 -  1.36
> > +++ wscons/wsksymdef.h  7 Dec 2015 22:22:27 -
> > @@ -633,6 +633,10 @@
> >  #define KS_AudioMute   0xf3d1
> >  #define KS_AudioLower  0xf3d2
> >  #define KS_AudioRaise  0xf3d3
> > +#define KS_BrightnessDown  0xf3d4
> > +#define KS_BrightnessUp0xf3d5
> > +#define KS_KbdBacklightDown0xf3d6
> > +#define KS_KbdBacklightUp  0xf3d7
> >  
> >  /*
> >   * Group 4 (command)
> > Index: usb/makemap.awk
> > ===
> > RCS file: /cvs/src/sys/dev/usb/makemap.awk,v
> > retrieving revision 1.14
> > diff -u -p -r1.14 makemap.awk
> > --- usb/makemap.awk 20 Nov 2013 17:27:32 -  1.14
> > +++ usb/makemap.awk 7 Dec 2015 22:22:27 -
> > @@ -153,6 +153,10 @@ BEGIN {
> > conv[170] = 70
> > conv[174] = 129
> > conv[176] = 128
> > +   conv[177] = 131
> > +   conv[178] = 132
> > +   conv[179] = 133
> > +   conv[180] = 134
> > conv[181] = 84
> > conv[184] = 230
> > # 198 is #if 0 in the PS/2 map...
> > Index: usb/ukbd.c
> > ===
> > RCS file: /cvs/src/sys/dev/usb/ukbd.c,v
> > retrieving revision 1.71
> > diff -u -p -r1.71 ukbd.c
> > --- usb/ukbd.c  14 Mar 2015 03:38:50 -  1.71
> > +++ usb/ukbd.c  7 Dec 2015 22:22:27 -
> > @@ -469,13 +469,15 @@ ukbd_apple_munge(void *vsc, uint8_t *ibu
> > static const struct ukbd_translation apple_fn_trans[] = {
> > { 40, 73 }, /* return -> insert */
> > { 42, 76 }, /* backspace -> delete */
> > +   { 58, 131 },

Re: [PATCH] ukbd.c cleanup and mba iso support

2015-12-08 Thread Joerg Jung
On Tue, Dec 08, 2015 at 10:12:38PM +0100, Joerg Jung wrote:
> On Thu, Aug 06, 2015 at 09:58:56PM +0200, Joerg Jung wrote:
> > On Wed, Feb 18, 2015 at 10:33:57PM -0800, William Orr wrote:
> > > 
> > > Any interest?
> > 
> > I'm interested in this. Your diff looks reasonable, so I applied it and 
> > it compiled fine, but the less and grave keys are still wrong exchanged
> > on my MacBookAir4,2. Looks like usbdevs says I have a 
> > USB_PRODUCT_APPLE_WELLSPRING6_ISO:
> > 
> >port 2 addr 7: full speed, power 40 mA, config 1, Apple Internal
> >   Keyboard / Trackpad(0x024d), Apple Inc.(0x05ac), rev 2.09   
> > 
> > So I guess some more case's are required in the diff below?
> >  
> > > On 2/4/15 9:37 AM, William Orr wrote:
> > > > 
> > > > This implements some of Alexey's comments as well as munging the grave 
> > > > key for
> > > > macbook airs. Tested on a mba with a WELLSPRING ANSI keyboard.
> 
> Please find below an updated diff which also includes a case for the ISO
> keyboard found in my older MacbookAir4,2.
> 
> This newer diff also includes some minor KNF and whitespace cleanup.
> 
> I would really like to commit this, as this fixes a real bug (exchanged
> grave/less key). So no longer fiddling with xmodmap required.

Slightly updated diff below, sorting the switch cases in the same order
as found in usbdevs.
 
OK, anyone?


Index: sys/dev/usb/ukbd.c
===
RCS file: /cvs/src/sys/dev/usb/ukbd.c,v
retrieving revision 1.71
diff -u -p -r1.71 ukbd.c
--- sys/dev/usb/ukbd.c  14 Mar 2015 03:38:50 -  1.71
+++ sys/dev/usb/ukbd.c  8 Dec 2015 22:40:12 -
@@ -158,13 +158,13 @@ const struct wskbd_accessops ukbd_access
ukbd_ioctl,
 };
 
-int ukbd_match(struct device *, void *, void *); 
-void ukbd_attach(struct device *, struct device *, void *); 
-int ukbd_detach(struct device *, int); 
-
-struct cfdriver ukbd_cd = { 
-   NULL, "ukbd", DV_DULL 
-}; 
+intukbd_match(struct device *, void *, void *);
+void   ukbd_attach(struct device *, struct device *, void *);
+intukbd_detach(struct device *, int);
+
+struct cfdriver ukbd_cd = {
+   NULL, "ukbd", DV_DULL
+};
 
 const struct cfattach ukbd_ca = {
sizeof(struct ukbd_softc), ukbd_match, ukbd_attach, ukbd_detach
@@ -181,6 +181,9 @@ voidukbd_gdium_munge(void *, uint8_t *,
 void   ukbd_apple_munge(void *, uint8_t *, u_int);
 void   ukbd_apple_mba_munge(void *, uint8_t *, u_int);
 void   ukbd_apple_iso_munge(void *, uint8_t *, u_int);
+void   ukbd_apple_iso_mba_munge(void *, uint8_t *, u_int);
+void   ukbd_apple_translate(void *, uint8_t *, u_int,
+   const struct ukbd_translation *, u_int);
 uint8_tukbd_translate(const struct ukbd_translation *, size_t, 
uint8_t);
 
 int
@@ -241,17 +244,20 @@ ukbd_attach(struct device *parent, struc
switch (uha->uaa->product) {
case USB_PRODUCT_APPLE_FOUNTAIN_ISO:
case USB_PRODUCT_APPLE_GEYSER_ISO:
+   case USB_PRODUCT_APPLE_WELLSPRING6_ISO:
sc->sc_munge = ukbd_apple_iso_munge;
break;
-   case USB_PRODUCT_APPLE_WELLSPRING4A_ANSI:
-   case USB_PRODUCT_APPLE_WELLSPRING4A_ISO:
-   case USB_PRODUCT_APPLE_WELLSPRING4A_JIS:
-   case USB_PRODUCT_APPLE_WELLSPRING4_ANSI:
+   case USB_PRODUCT_APPLE_WELLSPRING_ISO:
case USB_PRODUCT_APPLE_WELLSPRING4_ISO:
-   case USB_PRODUCT_APPLE_WELLSPRING4_JIS:
+   case USB_PRODUCT_APPLE_WELLSPRING4A_ISO:
+   sc->sc_munge = ukbd_apple_iso_mba_munge;
+   break;
case USB_PRODUCT_APPLE_WELLSPRING_ANSI:
-   case USB_PRODUCT_APPLE_WELLSPRING_ISO:
case USB_PRODUCT_APPLE_WELLSPRING_JIS:
+   case USB_PRODUCT_APPLE_WELLSPRING4_ANSI:
+   case USB_PRODUCT_APPLE_WELLSPRING4_JIS:
+   case USB_PRODUCT_APPLE_WELLSPRING4A_ANSI:
+   case USB_PRODUCT_APPLE_WELLSPRING4A_JIS:
sc->sc_munge = ukbd_apple_mba_munge;
break;
default:
@@ -431,15 +437,14 @@ ukbd_cnpollc(void *v, int on)
 }
 
 void
-ukbd_cnbell(void *v, u_int pitch, u_int period, u_int volume) 
+ukbd_cnbell(void *v, u_int pitch, u_int period, u_int volume)
 {
hidkbd_bell(pitch, period, volume, 1);
-}  
+}
 
 int
 ukbd_cnattach(void)
 {
-
/*
 * XXX USB requires too many parts of the kernel to be running
   

Re: IPsec: remove DES support

2015-12-08 Thread Mike Belopuhov
On 2 December 2015 at 23:36, Christian Weisgerber  wrote:
> Quoth ipsec.conf(5):
> Use of DES as an encryption algorithm is considered to be insecure since
> brute force attacks are practical due its short key length.
>
> The attached patch removes support for DES-CBC encryption in ESP
> and in IKE main and quick mode from the kernel, iked(8), ipsecctl(8),
> and isakmpd(8).
>
> Note this is plain DES, *not* 3DES.
>
> RFC2409 (November 1998) says that DES support is a "MUST" for IKEv1,
> but I think we _must_ ignore this.
>
>
> Next I intend to remove DES from the kernel crypto framework.
>
>

Hi,

I thought I've OK'ed this diff, but looks like I didn't.  OK mikeb



[patch] eliminate -Wsign-compare warning in imsg.c with clang on FreeBSD

2015-12-08 Thread Craig Rodrigues
Index: imsg.c
===
RCS file: /cvs/src/lib/libutil/imsg.c,v
retrieving revision 1.12
diff -u -r1.12 imsg.c
--- imsg.c5 Dec 2015 13:06:52 -1.12
+++ imsg.c9 Dec 2015 05:04:05 -
@@ -72,7 +72,7 @@

 again:
 if (getdtablecount() + imsg_fd_overhead +
-(CMSG_SPACE(sizeof(int))-CMSG_SPACE(0))/sizeof(int)
+(int)((CMSG_SPACE(sizeof(int))-CMSG_SPACE(0))/sizeof(int))
 >= getdtablesize()) {
 errno = EAGAIN;
 free(ifd);



This patch eliminates this warning when compiled with clang on FreeBSD:

/opt2/branches/head2/lib/libopenbsd/imsg.c:78:6: warning: comparison of
integers of different signs: 'unsigned long' and 'int' [-Wsign-compare]
>= getdtablesize()) {
^  ~~~
1 warning generated.


See previous discussion: http://marc.info/?l=openbsd-tech=144766546202667

I'm submitting this patch to OpenBSD to facilitate sharing of code between
the projects.
--
Craig


University of Toronto Mirror upcoming outages

2015-12-08 Thread Nick Holland
Hi,

A heads-up for users of the University of Toronto mirror
(openbsd.cs.toronto.edu):

The University will be doing some power systems maintenance this week
and next, and anticipate two planned outages:

* Thursday,  December 10 11:00p EST to Friday December 11, 7:00am EST
* Wednesday, December 16 11:00p EST to Thursday December 17, 7:00am EST

The mirror will be unavailable during these periods.

Thanks!

Nick.



OPENBSD performance // intel NIC interrupts // interrupt moderation

2015-12-08 Thread Jeff Drago



 Hello - first post here , hopefully it is the right forum.
I recently setup a bgp box on top of OPENBSD 5.5 Generic.MP, with 6 INTEL EM 
nics.The problem is that when I get 700Mbits in one interface, the CPU is 
peaking at 88% (interrupt).
I read about interrupt moderation and I dont know how to play with that in my 
box. is it the case to update the NIC driver?
here is the reference that the NIC supports int 
moderation:http://download.intel.com/design/network/applnots/ap450.pdf

Not sure how to turn that on or off in OpenBSD. Any help is greatly appreciated.
Here is the spec for the box (NETMAP 
L-800)http://www.serveru.us/en/images/ServerU/Folder-Brochure_en.pdf 
Tks,Jeffrey


  

Re: [PATCH] ukbd.c cleanup and mba iso support

2015-12-08 Thread Joerg Jung
Hi,

...back on this topic.

On Thu, Aug 06, 2015 at 09:58:56PM +0200, Joerg Jung wrote:
> On Wed, Feb 18, 2015 at 10:33:57PM -0800, William Orr wrote:
> > 
> > Any interest?
> 
> I'm interested in this. Your diff looks reasonable, so I applied it and 
> it compiled fine, but the less and grave keys are still wrong exchanged
> on my MacBookAir4,2. Looks like usbdevs says I have a 
> USB_PRODUCT_APPLE_WELLSPRING6_ISO:
> 
>port 2 addr 7: full speed, power 40 mA, config 1, Apple Internal
>   Keyboard / Trackpad(0x024d), Apple Inc.(0x05ac), rev 2.09   
> 
> So I guess some more case's are required in the diff below?
>  
> > On 2/4/15 9:37 AM, William Orr wrote:
> > > 
> > > This implements some of Alexey's comments as well as munging the grave 
> > > key for
> > > macbook airs. Tested on a mba with a WELLSPRING ANSI keyboard.

Please find below an updated diff which also includes a case for the ISO
keyboard found in my older MacbookAir4,2.

This newer diff also includes some minor KNF and whitespace cleanup.

I would really like to commit this, as this fixes a real bug (exchanged
grave/less key). So no longer fiddling with xmodmap required.

OK, anyone?

Thanks,
Regards,
Joerg


Index: sys/dev/usb/ukbd.c
===
RCS file: /cvs/src/sys/dev/usb/ukbd.c,v
retrieving revision 1.71
diff -u -p -r1.71 ukbd.c
--- sys/dev/usb/ukbd.c  14 Mar 2015 03:38:50 -  1.71
+++ sys/dev/usb/ukbd.c  8 Dec 2015 20:39:31 -
@@ -158,13 +158,13 @@ const struct wskbd_accessops ukbd_access
ukbd_ioctl,
 };
 
-int ukbd_match(struct device *, void *, void *); 
-void ukbd_attach(struct device *, struct device *, void *); 
-int ukbd_detach(struct device *, int); 
-
-struct cfdriver ukbd_cd = { 
-   NULL, "ukbd", DV_DULL 
-}; 
+intukbd_match(struct device *, void *, void *);
+void   ukbd_attach(struct device *, struct device *, void *);
+intukbd_detach(struct device *, int);
+
+struct cfdriver ukbd_cd = {
+   NULL, "ukbd", DV_DULL
+};
 
 const struct cfattach ukbd_ca = {
sizeof(struct ukbd_softc), ukbd_match, ukbd_attach, ukbd_detach
@@ -181,6 +181,9 @@ voidukbd_gdium_munge(void *, uint8_t *,
 void   ukbd_apple_munge(void *, uint8_t *, u_int);
 void   ukbd_apple_mba_munge(void *, uint8_t *, u_int);
 void   ukbd_apple_iso_munge(void *, uint8_t *, u_int);
+void   ukbd_apple_iso_mba_munge(void *, uint8_t *, u_int);
+void   ukbd_apple_translate(void *, uint8_t *, u_int,
+   const struct ukbd_translation *, u_int);
 uint8_tukbd_translate(const struct ukbd_translation *, size_t, 
uint8_t);
 
 int
@@ -243,14 +246,17 @@ ukbd_attach(struct device *parent, struc
case USB_PRODUCT_APPLE_GEYSER_ISO:
sc->sc_munge = ukbd_apple_iso_munge;
break;
-   case USB_PRODUCT_APPLE_WELLSPRING4A_ANSI:
+   case USB_PRODUCT_APPLE_WELLSPRING6_ISO:
case USB_PRODUCT_APPLE_WELLSPRING4A_ISO:
+   case USB_PRODUCT_APPLE_WELLSPRING4_ISO:
+   case USB_PRODUCT_APPLE_WELLSPRING_ISO:
+   sc->sc_munge = ukbd_apple_iso_mba_munge;
+   break;
+   case USB_PRODUCT_APPLE_WELLSPRING4A_ANSI:
case USB_PRODUCT_APPLE_WELLSPRING4A_JIS:
case USB_PRODUCT_APPLE_WELLSPRING4_ANSI:
-   case USB_PRODUCT_APPLE_WELLSPRING4_ISO:
case USB_PRODUCT_APPLE_WELLSPRING4_JIS:
case USB_PRODUCT_APPLE_WELLSPRING_ANSI:
-   case USB_PRODUCT_APPLE_WELLSPRING_ISO:
case USB_PRODUCT_APPLE_WELLSPRING_JIS:
sc->sc_munge = ukbd_apple_mba_munge;
break;
@@ -431,15 +437,14 @@ ukbd_cnpollc(void *v, int on)
 }
 
 void
-ukbd_cnbell(void *v, u_int pitch, u_int period, u_int volume) 
+ukbd_cnbell(void *v, u_int pitch, u_int period, u_int volume)
 {
hidkbd_bell(pitch, period, volume, 1);
-}  
+}
 
 int
 ukbd_cnattach(void)
 {
-
/*
 * XXX USB requires too many parts of the kernel to be running
 * XXX in order to work, so we can't do much for the console
@@ -460,12 +465,28 @@ ukbd_translate(const struct ukbd_transla
 }
 
 void
-ukbd_apple_munge(void *vsc, uint8_t *ibuf, u_int ilen)
+ukbd_apple_translate(void *vsc, uint8_t *ibuf, u_int ilen,
+const struct ukbd_translation* trans, u_int tlen)
 {
struct ukbd_softc *sc = vsc;
struct hidkbd *kbd = >sc_kbd;
uint8_t *pos, *spos, *epos, xlat;
 
+   spos = ibuf + kbd->sc_keycodeloc.pos / 8;
+   epos = spos + kbd->sc_nkeycode;
+
+   for (pos = spos; 

UTF-8 support for fmt(1)

2015-12-08 Thread Ingo Schwarze
Hi,

here is UTF-8 support for fmt(1).
This does not include the -c case; the patch is already large enough.

Because tedu@ said he didn't see value in splitting the cut(1) diff,
i dare sending it as one big patch.  If anybody wants to have it
split into steps for easier review and a safer transition, please
just say so.  But i don't think changing this program is particularly
dangerous.

The main changes are in three areas:

1. get_line():
This function can no longer expand tabs up front because their width
depends on the display width of characters earlier on the line.
This change causes minor growth in indent_length().

While here, always NUL-terminate the input buffer.  It's safer and
simplifies the code, also reducing the number of arguments for two
functions.

Also delete the contorted spaces_pending logic in get_line(), simply
trim trailing whitespace at the end, and delete the pointless XMALLOC
macro.

2. process_stream():
It used to iterate bytes, now it iterates characters.  The code
becomes a bit longer, but using mbtowc(3), wcwidth(3), and iswblank(3)
directly, it's quite readable in this case.

3. output_word():
Needs both the length of the word in bytes and the width in output
positions now.  The hand-rolled output_buffer complicated matters
for no gain.  Just let stdio do its work.  Simplifies new_paragraph,
too.  Also simplify calling of output_indent() by doing the 0 check
inside.


All told, the patch shortens the code by four lines.  Not bad
for adding functionality, right?  :-)

OK?
  Ingo


Index: fmt.c
===
RCS file: /cvs/src/usr.bin/fmt/fmt.c,v
retrieving revision 1.33
diff -u -p -r1.33 fmt.c
--- fmt.c   9 Oct 2015 01:37:07 -   1.33
+++ fmt.c   8 Dec 2015 21:15:15 -
@@ -176,6 +176,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 /* Something that, we hope, will never be a genuine line length,
  * indentation etc.
@@ -222,7 +224,6 @@ static int grok_mail_headers = 0;   /* tr
 static int format_troff = 0;   /* Format troff? */
 
 static int n_errors = 0;   /* Number of failed files. */
-static char *output_buffer = NULL; /* Output line will be built 
here */
 static size_t x;   /* Horizontal position in 
output line */
 static size_t x0;  /* Ditto, ignoring leading 
whitespace */
 static size_t pending_spaces;  /* Spaces to add before next 
word */
@@ -232,17 +233,16 @@ static int output_in_paragraph = 0;   /* 
 
 static voidprocess_named_file(const char *);
 static voidprocess_stream(FILE *, const char *);
-static size_t  indent_length(const char *, size_t);
+static size_t  indent_length(const char *);
 static int might_be_header(const char *);
-static voidnew_paragraph(size_t, size_t);
-static voidoutput_word(size_t, size_t, const char *, size_t, size_t);
+static voidnew_paragraph(size_t);
+static voidoutput_word(size_t, size_t, const char *, int, int, int);
 static voidoutput_indent(size_t);
 static voidcenter_stream(FILE *, const char *);
-static char*get_line(FILE *, size_t *);
+static char*get_line(FILE *);
 static void*xrealloc(void *, size_t);
 void   usage(void);
 
-#define XMALLOC(x) xrealloc(0, x)
 #define ERRS(x) (x >= 127 ? 127 : ++x)
 
 /* Here is perhaps the right place to mention that this code is
@@ -332,7 +332,6 @@ main(int argc, char *argv[])
goal_length = 65;
if (max_length == 0)
max_length = goal_length+10;
-   output_buffer = XMALLOC(max_length+1);  /* really needn't be longer */
 
/* 2. Process files. */
 
@@ -381,25 +380,31 @@ typedef enum {
 static void
 process_stream(FILE *stream, const char *name)
 {
-   size_t n;
+   const char *wordp, *cp;
+   wchar_t wc;
size_t np;
size_t last_indent = SILLY; /* how many spaces in last indent? */
size_t para_line_number = 0;/* how many lines already read in this 
para? */
size_t first_indent = SILLY;/* indentation of line 0 of paragraph */
+   int wcl;/* number of bytes in wide character */
+   int wcw;/* display width of wide character */
+   int word_length;/* number of bytes in word */
+   int word_width; /* display width of word */
+   int space_width;/* display width of space after word */
+   int line_width; /* display width of line */
HdrType prev_header_type = hdr_ParagraphStart;
HdrType header_type;
 
/* ^-- header_type of previous line; -1 at para start */
const char *line;
-   size_t length;
 
if (centerP) {
center_stream(stream, name);
return;
}
 
-   while ((line = get_line(stream, )) != NULL) {

Re: OPENBSD performance // intel NIC interrupts // interrupt moderation

2015-12-08 Thread Michael McConville
Jeff Drago wrote:
>  Hello - first post here , hopefully it is the right forum.
> 
> I recently setup a bgp box on top of OPENBSD 5.5 Generic.MP, with 6
> INTEL EM nics.The problem is that when I get 700Mbits in one
> interface, the CPU is peaking at 88% (interrupt).
> 
> I read about interrupt moderation and I dont know how to play with
> that in my box. is it the case to update the NIC driver? here is the
> reference that the NIC supports int
> moderation:http://download.intel.com/design/network/applnots/ap450.pdf
> 
> Not sure how to turn that on or off in OpenBSD. Any help is greatly
> appreciated. Here is the spec for the box (NETMAP
> L-800)http://www.serveru.us/en/images/ServerU/Folder-Brochure_en.pdf 

5.5 is no longer supported. Upgrade sequentially (5.5 -> 5.6, 5.6 ->
5.7, 5.7 -> 5.8) and see if that fixes it. I've seen a huge network
performance improvement over that series of upgrades.

Also, if the problem persists, please include a dmesg with your next
email.

Thanks,
Michael



Re: patch 3/4 add generic keyboard backlight support

2015-12-08 Thread Mark Kettenis
> Date: Mon, 7 Dec 2015 23:44:13 +0100
> From: Joerg Jung 
> 
> Hi,
> 
> here comes the third part of the series for generic keyboard backlight
> support.
> 
> Please find below a diff which adds they key(code)s for keyboard
> backlight control, as found on all recent Intel based Apple Laptop
> Keyboards.  While here, also add keys for display brightness control
> found on Apple Keyboards as well.
> 
> This is based on a similar diff from Sven-Volker Nowarra and is a NOOP
> for now, as these keys are not used yet. Using them is target for a
> later diff.
> 
> I'm not familar with keycodes, most of the diff below is 'educated
> guess', so please, hints are welcome!
> 
> Comments, OK?

Heh, I just looked into this during n2k15 to make the display
brihtness keys work.

I don't think you should add codes to pckbc/wskbdmap_mfii.c unless you
have some evidence there really are PC-style keyboards that produce
these codes.

I think you should choose different codes for USB.  Take a look at the
"HID Usage Tables" document.  There you'll find that 131-134 are
already assigned.  For my brightness diff I used codes in the reserved
range that startx at 232 (0xe8).

There are already keysyms defined for display brightness in "Group 4".
Using symbols in that group has some consequences though.  Currently
the code that handles them assumes they are only generated in
combination with certain modifies keys.


> Index: pckbc/wskbdmap_mfii.c
> ===
> RCS file: /cvs/src/sys/dev/pckbc/wskbdmap_mfii.c,v
> retrieving revision 1.43
> diff -u -p -r1.43 wskbdmap_mfii.c
> --- pckbc/wskbdmap_mfii.c 14 Apr 2013 19:32:52 -  1.43
> +++ pckbc/wskbdmap_mfii.c 7 Dec 2015 22:22:27 -
> @@ -149,6 +149,10 @@ static const keysym_t pckbd_keydesc_us[]
>  KC(170), KS_Print_Screen,
>  KC(174), KS_AudioLower,
>  KC(176), KS_AudioRaise,
> +KC(177), KS_BrightnessDown,
> +KC(178), KS_BrightnessUp,
> +KC(179), KS_KbdBacklightDown,
> +KC(180), KS_KbdBacklightUp,
>  KC(181), KS_KP_Divide,
>  KC(183), KS_Print_Screen,
>  KC(184), KS_Cmd2,KS_Alt_R,   KS_Multi_key,
> Index: wscons/wsksymdef.h
> ===
> RCS file: /cvs/src/sys/dev/wscons/wsksymdef.h,v
> retrieving revision 1.36
> diff -u -p -r1.36 wsksymdef.h
> --- wscons/wsksymdef.h26 Jan 2014 17:48:08 -  1.36
> +++ wscons/wsksymdef.h7 Dec 2015 22:22:27 -
> @@ -633,6 +633,10 @@
>  #define KS_AudioMute 0xf3d1
>  #define KS_AudioLower0xf3d2
>  #define KS_AudioRaise0xf3d3
> +#define KS_BrightnessDown0xf3d4
> +#define KS_BrightnessUp  0xf3d5
> +#define KS_KbdBacklightDown  0xf3d6
> +#define KS_KbdBacklightUp0xf3d7
>  
>  /*
>   * Group 4 (command)
> Index: usb/makemap.awk
> ===
> RCS file: /cvs/src/sys/dev/usb/makemap.awk,v
> retrieving revision 1.14
> diff -u -p -r1.14 makemap.awk
> --- usb/makemap.awk   20 Nov 2013 17:27:32 -  1.14
> +++ usb/makemap.awk   7 Dec 2015 22:22:27 -
> @@ -153,6 +153,10 @@ BEGIN {
>   conv[170] = 70
>   conv[174] = 129
>   conv[176] = 128
> + conv[177] = 131
> + conv[178] = 132
> + conv[179] = 133
> + conv[180] = 134
>   conv[181] = 84
>   conv[184] = 230
>   # 198 is #if 0 in the PS/2 map...
> Index: usb/ukbd.c
> ===
> RCS file: /cvs/src/sys/dev/usb/ukbd.c,v
> retrieving revision 1.71
> diff -u -p -r1.71 ukbd.c
> --- usb/ukbd.c14 Mar 2015 03:38:50 -  1.71
> +++ usb/ukbd.c7 Dec 2015 22:22:27 -
> @@ -469,13 +469,15 @@ ukbd_apple_munge(void *vsc, uint8_t *ibu
>   static const struct ukbd_translation apple_fn_trans[] = {
>   { 40, 73 }, /* return -> insert */
>   { 42, 76 }, /* backspace -> delete */
> + { 58, 131 },/* F1 -> screen brightness down */
> + { 59, 132 },/* F2 -> screen brightness up */
>  #ifdef notyet
> - { 58, 0 },  /* F1 -> screen brightness down */
> - { 59, 0 },  /* F2 -> screen brightness up */
>   { 60, 0 },  /* F3 */
>   { 61, 0 },  /* F4 */
> - { 62, 0 },  /* F5 -> keyboard backlight down */
> - { 63, 0 },  /* F6 -> keyboard backlight up */
> +#endif
> + { 62, 133 },/* F5 -> keyboard backlight down */
> + { 63, 134 },/* F6 -> keyboard backlight up */
> +#ifdef notyet
>   { 64, 0 },  /* F7 -> audio back */
>   { 65, 0 },  /* F8 -> audio pause/play */
>   { 66, 0 },  /* F9 ->