Re: ospfd: depend on interface (new feature)

2018-02-03 Thread Sebastian Benoit
Remi Locherer(remi.loche...@relo.ch) on 2018.02.04 00:42:22 +0100:
> Hi
> 
> This adds a new feature to ospfd: depend on interface.
> 
> A ospfd.conf using it looks like this:
> 
> --%<--
> redistribute default depend on carp0
> area 0.0.0.0 {
>   interface em2 { depend on carp0 }
>   [...]
> }
> --%<--
> 
> This router would send out the default route and the em2 network with
> default metrics as long as carp0 is master. When carp0 becomes backup these
> routes are advertised with metric 65535.
> 
> "depend on" can also be used with other interface types than carp.
> 
> This diff was started by benno@ at p2k17 (redistribute and config parser).
> I added the interface part. jca@ contributed several improvements.
> 
> Comments, OKs?

fwiw ok benno@

> Remi
> 
> 
> Index: ospfd.c
> ===
> RCS file: /cvs/src/usr.sbin/ospfd/ospfd.c,v
> retrieving revision 1.94
> diff -u -p -r1.94 ospfd.c
> --- ospfd.c   24 Jan 2017 04:24:25 -  1.94
> +++ ospfd.c   21 Jan 2018 14:01:42 -
> @@ -29,6 +29,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -512,18 +513,30 @@ imsg_compose_event(struct imsgev *iev, u
>  int
>  ospf_redistribute(struct kroute *kr, u_int32_t *metric)
>  {
> + struct in_addr   addr;
> + struct kif  *kif;
>   struct redistribute *r;
> - u_int8_t is_default = 0;
> + int  is_default = 0, depend_ok = 1;
> +
> + bzero(, sizeof(addr));
>  
>   /* only allow 0.0.0.0/0 via REDIST_DEFAULT */
>   if (kr->prefix.s_addr == INADDR_ANY && kr->prefixlen == 0)
>   is_default = 1;
>  
>   SIMPLEQ_FOREACH(r, _conf->redist_list, entry) {
> + if (r->dependon[0] != '\0') {
> + if ((kif = kif_findname(r->dependon, addr, NULL)))
> + depend_ok = ifstate_is_up(kif);
> + else
> + depend_ok = 0;
> + } else 
> + depend_ok = 1;
> +
>   switch (r->type & ~REDIST_NO) {
>   case REDIST_LABEL:
>   if (kr->rtlabel == r->label) {
> - *metric = r->metric;
> + *metric = (depend_ok) ? r->metric : MAX_METRIC;
>   return (r->type & REDIST_NO ? 0 : 1);
>   }
>   break;
> @@ -538,7 +551,7 @@ ospf_redistribute(struct kroute *kr, u_i
>   if (kr->flags & F_DYNAMIC)
>   continue;
>   if (kr->flags & F_STATIC) {
> - *metric = r->metric;
> + *metric = (depend_ok) ? r->metric : MAX_METRIC;
>   return (r->type & REDIST_NO ? 0 : 1);
>   }
>   break;
> @@ -548,7 +561,7 @@ ospf_redistribute(struct kroute *kr, u_i
>   if (kr->flags & F_DYNAMIC)
>   continue;
>   if (kr->flags & F_CONNECTED) {
> - *metric = r->metric;
> + *metric = (depend_ok) ? r->metric : MAX_METRIC;
>   return (r->type & REDIST_NO ? 0 : 1);
>   }
>   break;
> @@ -559,7 +572,8 @@ ospf_redistribute(struct kroute *kr, u_i
>   if (r->addr.s_addr == INADDR_ANY &&
>   r->mask.s_addr == INADDR_ANY) {
>   if (is_default) {
> - *metric = r->metric;
> + *metric = (depend_ok) ? r->metric :
> + MAX_METRIC;
>   return (r->type & REDIST_NO ? 0 : 1);
>   } else
>   return (0);
> @@ -568,13 +582,13 @@ ospf_redistribute(struct kroute *kr, u_i
>   if ((kr->prefix.s_addr & r->mask.s_addr) ==
>   (r->addr.s_addr & r->mask.s_addr) &&
>   kr->prefixlen >= mask2prefixlen(r->mask.s_addr)) {
> - *metric = r->metric;
> + *metric = (depend_ok) ? r->metric : MAX_METRIC;
>   return (r->type & REDIST_NO ? 0 : 1);
>   }
>   break;
>   case REDIST_DEFAULT:
>   if (is_default) {
> - *metric = r->metric;
> + *metric = (depend_ok) ? r->metric : MAX_METRIC;
>   return (r->type & REDIST_NO ? 0 : 1);
>   }
>   break;
> @@ -841,6 +855,10 @@ merge_interfaces(struct area *a, struct 
>   if 

Re: ospfd: depend on interface (new feature)

2018-02-03 Thread Claudio Jeker
On Sun, Feb 04, 2018 at 12:42:22AM +0100, Remi Locherer wrote:
> Hi
> 
> This adds a new feature to ospfd: depend on interface.
> 
> A ospfd.conf using it looks like this:
> 
> --%<--
> redistribute default depend on carp0
> area 0.0.0.0 {
>   interface em2 { depend on carp0 }
>   [...]
> }
> --%<--
> 
> This router would send out the default route and the em2 network with
> default metrics as long as carp0 is master. When carp0 becomes backup these
> routes are advertised with metric 65535.
> 
> "depend on" can also be used with other interface types than carp.
> 
> This diff was started by benno@ at p2k17 (redistribute and config parser).
> I added the interface part. jca@ contributed several improvements.
> 
> Comments, OKs?
> 
> Remi
> 
> 
> Index: ospfd.c
> ===
> RCS file: /cvs/src/usr.sbin/ospfd/ospfd.c,v
> retrieving revision 1.94
> diff -u -p -r1.94 ospfd.c
> --- ospfd.c   24 Jan 2017 04:24:25 -  1.94
> +++ ospfd.c   21 Jan 2018 14:01:42 -
> @@ -29,6 +29,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -512,18 +513,30 @@ imsg_compose_event(struct imsgev *iev, u
>  int
>  ospf_redistribute(struct kroute *kr, u_int32_t *metric)
>  {
> + struct in_addr   addr;
> + struct kif  *kif;
>   struct redistribute *r;
> - u_int8_t is_default = 0;
> + int  is_default = 0, depend_ok = 1;
> +
> + bzero(, sizeof(addr));
>  
>   /* only allow 0.0.0.0/0 via REDIST_DEFAULT */
>   if (kr->prefix.s_addr == INADDR_ANY && kr->prefixlen == 0)
>   is_default = 1;
>  
>   SIMPLEQ_FOREACH(r, _conf->redist_list, entry) {
> + if (r->dependon[0] != '\0') {
> + if ((kif = kif_findname(r->dependon, addr, NULL)))
> + depend_ok = ifstate_is_up(kif);
> + else
> + depend_ok = 0;
> + } else 
> + depend_ok = 1;
> +
>   switch (r->type & ~REDIST_NO) {
>   case REDIST_LABEL:
>   if (kr->rtlabel == r->label) {
> - *metric = r->metric;
> + *metric = (depend_ok) ? r->metric : MAX_METRIC;
  ^ ^
Please remove the () around depend_ok here. The () are not needed. 
There is many more of these.
>   return (r->type & REDIST_NO ? 0 : 1);
>   }
>   break;
> @@ -538,7 +551,7 @@ ospf_redistribute(struct kroute *kr, u_i
>   if (kr->flags & F_DYNAMIC)
>   continue;
>   if (kr->flags & F_STATIC) {
> - *metric = r->metric;
> + *metric = (depend_ok) ? r->metric : MAX_METRIC;
>   return (r->type & REDIST_NO ? 0 : 1);
>   }
>   break;
> @@ -548,7 +561,7 @@ ospf_redistribute(struct kroute *kr, u_i
>   if (kr->flags & F_DYNAMIC)
>   continue;
>   if (kr->flags & F_CONNECTED) {
> - *metric = r->metric;
> + *metric = (depend_ok) ? r->metric : MAX_METRIC;
>   return (r->type & REDIST_NO ? 0 : 1);
>   }
>   break;
> @@ -559,7 +572,8 @@ ospf_redistribute(struct kroute *kr, u_i
>   if (r->addr.s_addr == INADDR_ANY &&
>   r->mask.s_addr == INADDR_ANY) {
>   if (is_default) {
> - *metric = r->metric;
> + *metric = (depend_ok) ? r->metric :
> + MAX_METRIC;
>   return (r->type & REDIST_NO ? 0 : 1);
>   } else
>   return (0);
> @@ -568,13 +582,13 @@ ospf_redistribute(struct kroute *kr, u_i
>   if ((kr->prefix.s_addr & r->mask.s_addr) ==
>   (r->addr.s_addr & r->mask.s_addr) &&
>   kr->prefixlen >= mask2prefixlen(r->mask.s_addr)) {
> - *metric = r->metric;
> + *metric = (depend_ok) ? r->metric : MAX_METRIC;
>   return (r->type & REDIST_NO ? 0 : 1);
>   }
>   break;
>   case REDIST_DEFAULT:
>   if (is_default) {
> - *metric = r->metric;
> + *metric = (depend_ok) ? r->metric : MAX_METRIC;
>   return (r->type & REDIST_NO ? 0 : 1);
>   

Re: Fix for vi(1) manpage Visual command

2018-02-03 Thread Anthony J. Bentley
Ingo Schwarze writes:
> > and the USD docs to update. so a man page fix will not suffice.
>
> I wouldn't bother.  They are not installed, and the base system
> doesn't even provide tools to process them.  If we ever decide
> to do anything with them, they will require a full check of accuracy
> anyway.

I am not interested in updating the USD docs, but we *should* continue
to migrate information from them to the manpage. Many user-facing parts
of vi are not adequately documented right now except in there.




Re: ospfd: depend on interface (new feature)

2018-02-03 Thread Kapetanakis Giannis

On 04/02/18 01:42, Remi Locherer wrote:

Hi

This adds a new feature to ospfd: depend on interface.

A ospfd.conf using it looks like this:

--%<--
redistribute default depend on carp0
area 0.0.0.0 {
interface em2 { depend on carp0 }
[...]
}
--%<--

This router would send out the default route and the em2 network with
default metrics as long as carp0 is master. When carp0 becomes backup these
routes are advertised with metric 65535.

"depend on" can also be used with other interface types than carp.

This diff was started by benno@ at p2k17 (redistribute and config parser).
I added the interface part. jca@ contributed several improvements.

Comments, OKs?

Remi


If I understand this right, someone could use this combined with pfsync,
to wait for states full sync before switching routes from backup to master?

nice :)

G




Re: [PATCH] libexec/ld.so/dlfcn.c - fix column alignment

2018-02-03 Thread Raf Czlonka
Ping.

On Mon, Jan 01, 2018 at 06:17:53PM GMT, Raf Czlonka wrote:
> On Mon, Jan 01, 2018 at 08:56:18AM GMT, Mark Kettenis wrote:
> > > Date: Mon, 1 Jan 2018 07:49:54 +0100 (CET)
> > > From: Mark Kettenis 
> > > 
> > > > Date: Mon, 1 Jan 2018 04:20:35 +
> > > > From: Raf Czlonka 
> > > > 
> > > > Hi all,
> > > > 
> > > > With the recent rtld -> ld.so name change in the 1.100 revision[0],
> > > > said objtypename has been increased by one character, thus causing
> > > > everything past the 'Type' column to become mis-aligned, i.e.:
> > > > 
> > > > $ ldd /usr/bin/ldd
> > > > 
> > > > /usr/bin/ldd:
> > > > StartEnd  Type Open Ref GrpRef Name
> > > > 105b6710 105b67303000 exe  10   0  
> > > > /usr/bin/ldd
> > > > 105d9e966000 105d9ec46000 rlib 01   0  
> > > > /usr/lib/libc.so.92.2
> > > > 105dca30 105dca30 ld.so 01   0  
> > > > /usr/libexec/ld.so
> > > > 
> > > > How about simply changing the ld.so five-character name to ldso
> > > > four-character one and keep current column alignment?
> > > > 
> > > > Alternatively, expand the 'Type' column and all remaining objtypenames
> > > > by one character (mostly space) in order to fix the alignment.
> > > > 
> > > > I'm only including the diff for the latter as doing the former is
> > > > trivial - I still prefer the former solution, BTW.
> > > > 
> > > > While there, how about dropping the leading tab character so that
> > > > majority of the outputs generated fit within 80 columns?
> > > 
> > > I'd prefer to simply revert the change.  It serves no purpose other
> > > than to eat another column.  And if there is any doubt this is ld.so,
> > > the full name is printed next to it on the same line!
> > 
> > Or we could change it to "ldso" instead.
> 
> Hi Mark,
> 
> Yes, please - as per above, and quoting myself from a private email,
> this would have been my preferred solution as removing a single
> character - the dot (.) - is simply the least amount of effort to
> fix the alignment while still maintaining the ldso objtypename
> unambiguously clear and descriptive.
> 
> Additionally, the 'Type' column header would look better separated
> from the other headers - bar Start and End - by a single space.
> 
> Kind regards,
> 
> Raf



Re: Fix for vi(1) manpage Visual command

2018-02-03 Thread Raf Czlonka
On Sun, Feb 04, 2018 at 12:05:47AM GMT, trondd wrote:
> On Sat, February 3, 2018 4:28 pm, Ingo Schwarze wrote:
> >
> >> a good way to do it without adding verbiage would be to not document it!
> >> if it really is a crappy quirk, let's just leave it out then.
> >
> > I actually like that idea, it makes the long list of EX COMMANDS
> > a bit simpler, making the relevant stuff easier to find.
> >
> > Of course, we still have to say how to get out of split screen
> > mode when you stumble into it unintentionally - which esily
> > happens because the colon requires the shift key on many keyboards,
> > so accidentally hitting ":N" instead of ":n" is not uncommon.
> >
> > If people like the idea, i'll also fix up :exusage (unless people
> > want :exusage deleted, which i would of course prefer).
> >
> > OK?
> >   Ingo
> >
> 
> Well this is kind of a bummer.  I agree the documentation is inconsistent
> and confusing, but once I got past reading the man page, I was so excited
> to discover that I could get split screens in base vi without having to
> install vim with its extra baggage.  I'm sad that a feature I use
> constantly will now become undocumented (if not removed) and hidden from
> other's who might find it valuable.
> 
> Not to discourage your work.  I'm not the one maintaining vi, and I can go
> crawling back to ports for nvi if I need to.
> 
> Tim.

I have to second Tim here - I like base vi/ex the way it is.

Very recently, I found a file where I had saved the output of both
:visuage and :exusage - this was from a time when I had noticed as
small alignment issue in :viusage.  I actually learnt a handful
of commands form both of these and would be sad to see either of
them go.  Personally, I don't treat them as *documentation* sensu
stricto, but more like a quick command guide - an index.

All that being said, I'm obviously in no position to make requests
- merely £0.02 from a base vi user and one who found :{ex,vi}usage
actually useful in the past.

Raf



Re: Fix for vi(1) manpage Visual command

2018-02-03 Thread trondd
On Sat, February 3, 2018 4:28 pm, Ingo Schwarze wrote:
>
>> a good way to do it without adding verbiage would be to not document it!
>> if it really is a crappy quirk, let's just leave it out then.
>
> I actually like that idea, it makes the long list of EX COMMANDS
> a bit simpler, making the relevant stuff easier to find.
>
> Of course, we still have to say how to get out of split screen
> mode when you stumble into it unintentionally - which esily
> happens because the colon requires the shift key on many keyboards,
> so accidentally hitting ":N" instead of ":n" is not uncommon.
>
> If people like the idea, i'll also fix up :exusage (unless people
> want :exusage deleted, which i would of course prefer).
>
> OK?
>   Ingo
>

Well this is kind of a bummer.  I agree the documentation is inconsistent
and confusing, but once I got past reading the man page, I was so excited
to discover that I could get split screens in base vi without having to
install vim with its extra baggage.  I'm sad that a feature I use
constantly will now become undocumented (if not removed) and hidden from
other's who might find it valuable.

Not to discourage your work.  I'm not the one maintaining vi, and I can go
crawling back to ports for nvi if I need to.

Tim.




ospfd: depend on interface (new feature)

2018-02-03 Thread Remi Locherer
Hi

This adds a new feature to ospfd: depend on interface.

A ospfd.conf using it looks like this:

--%<--
redistribute default depend on carp0
area 0.0.0.0 {
interface em2 { depend on carp0 }
[...]
}
--%<--

This router would send out the default route and the em2 network with
default metrics as long as carp0 is master. When carp0 becomes backup these
routes are advertised with metric 65535.

"depend on" can also be used with other interface types than carp.

This diff was started by benno@ at p2k17 (redistribute and config parser).
I added the interface part. jca@ contributed several improvements.

Comments, OKs?

Remi


Index: ospfd.c
===
RCS file: /cvs/src/usr.sbin/ospfd/ospfd.c,v
retrieving revision 1.94
diff -u -p -r1.94 ospfd.c
--- ospfd.c 24 Jan 2017 04:24:25 -  1.94
+++ ospfd.c 21 Jan 2018 14:01:42 -
@@ -29,6 +29,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -512,18 +513,30 @@ imsg_compose_event(struct imsgev *iev, u
 int
 ospf_redistribute(struct kroute *kr, u_int32_t *metric)
 {
+   struct in_addr   addr;
+   struct kif  *kif;
struct redistribute *r;
-   u_int8_t is_default = 0;
+   int  is_default = 0, depend_ok = 1;
+
+   bzero(, sizeof(addr));
 
/* only allow 0.0.0.0/0 via REDIST_DEFAULT */
if (kr->prefix.s_addr == INADDR_ANY && kr->prefixlen == 0)
is_default = 1;
 
SIMPLEQ_FOREACH(r, _conf->redist_list, entry) {
+   if (r->dependon[0] != '\0') {
+   if ((kif = kif_findname(r->dependon, addr, NULL)))
+   depend_ok = ifstate_is_up(kif);
+   else
+   depend_ok = 0;
+   } else 
+   depend_ok = 1;
+
switch (r->type & ~REDIST_NO) {
case REDIST_LABEL:
if (kr->rtlabel == r->label) {
-   *metric = r->metric;
+   *metric = (depend_ok) ? r->metric : MAX_METRIC;
return (r->type & REDIST_NO ? 0 : 1);
}
break;
@@ -538,7 +551,7 @@ ospf_redistribute(struct kroute *kr, u_i
if (kr->flags & F_DYNAMIC)
continue;
if (kr->flags & F_STATIC) {
-   *metric = r->metric;
+   *metric = (depend_ok) ? r->metric : MAX_METRIC;
return (r->type & REDIST_NO ? 0 : 1);
}
break;
@@ -548,7 +561,7 @@ ospf_redistribute(struct kroute *kr, u_i
if (kr->flags & F_DYNAMIC)
continue;
if (kr->flags & F_CONNECTED) {
-   *metric = r->metric;
+   *metric = (depend_ok) ? r->metric : MAX_METRIC;
return (r->type & REDIST_NO ? 0 : 1);
}
break;
@@ -559,7 +572,8 @@ ospf_redistribute(struct kroute *kr, u_i
if (r->addr.s_addr == INADDR_ANY &&
r->mask.s_addr == INADDR_ANY) {
if (is_default) {
-   *metric = r->metric;
+   *metric = (depend_ok) ? r->metric :
+   MAX_METRIC;
return (r->type & REDIST_NO ? 0 : 1);
} else
return (0);
@@ -568,13 +582,13 @@ ospf_redistribute(struct kroute *kr, u_i
if ((kr->prefix.s_addr & r->mask.s_addr) ==
(r->addr.s_addr & r->mask.s_addr) &&
kr->prefixlen >= mask2prefixlen(r->mask.s_addr)) {
-   *metric = r->metric;
+   *metric = (depend_ok) ? r->metric : MAX_METRIC;
return (r->type & REDIST_NO ? 0 : 1);
}
break;
case REDIST_DEFAULT:
if (is_default) {
-   *metric = r->metric;
+   *metric = (depend_ok) ? r->metric : MAX_METRIC;
return (r->type & REDIST_NO ? 0 : 1);
}
break;
@@ -841,6 +855,10 @@ merge_interfaces(struct area *a, struct 
if (ospfd_process == PROC_OSPF_ENGINE)
if_fsm(i, IF_EVT_UP);
}
+
+   strlcpy(i->dependon, xi->dependon,
+   

Re: athn(4) USB open firmware support

2018-02-03 Thread Stefan Sperling
On Fri, Nov 17, 2017 at 12:28:35AM +0100, Stefan Sperling wrote:
> This diff switches athn(4) USB devices to open source firmware.
> 
> I only have an AR9271 device which I can test with:
> athn0 at uhub1 port 2 configuration 1 interface 0 "ATHEROS USB2.0 WLAN" rev 
> 2.00/1.08 addr 3
> athn0: AR9271 rev 1 (1T1R), ROM rev 13, address xx:xx:xx:xx:xx:xx
> 
> The diff switches AR7010 devices over as well because this new code
> will *not* support the old binary-only firmware anyway.
> But it is possible that AR7010 devices don't work yet with this diff.
> Can anybody help and test such a device? And if anyone would like to
> donate an AR7010 device for me to develop with, that would be appreciated.

I have received an AR7010 device from Stuart Henderson and now have
this device working as well. It actually didn't work properly even
with the old firmware due to existing bugs in the driver.

This new diff also makes use of the open firmware's Tx rate reports.
Tx rate scaling is always done in firmware on these devices and there
seems to be no way around that. What the driver can do is show which
Tx rate the firmware has most recently chosen in 'ifconfig athn0' output.
We could tweak the Tx rate scaling algo in firmware code of course :-)

I have also briefly tested hostap with both AR9271 and AR7010 and it
now seems to work well enough to justify removing the BUGS section from
the athn(4) page. I still wouldn't recommend using such a device as
primary AP because it can only support up to 8 clients, and association
to AR9271 was a bit flaky in my testing.

> The new firmware package 'athn-firmware-1.1p3', which contains the open
> firmware files, is required. Specifically, the diff needs these files
> from the new firmware package:
> 
>   /etc/firmware/athn-open-ar7010
>   /etc/firmware/athn-open-ar9271

This new firmware has been in fw_update for some time now so we can
commit this change without disrupting users tracking -current.

We should keep the old firmware file around for a while, just in case
this change needs to be reverted for some reason.

ok?

Index: if_athn_usb.c
===
RCS file: /cvs/src/sys/dev/usb/if_athn_usb.c,v
retrieving revision 1.48
diff -u -p -r1.48 if_athn_usb.c
--- if_athn_usb.c   26 Oct 2017 15:00:28 -  1.48
+++ if_athn_usb.c   3 Feb 2018 22:08:54 -
@@ -159,6 +159,7 @@ voidathn_usb_delete_key_cb(struct athn
 void   athn_usb_bcneof(struct usbd_xfer *, void *,
usbd_status);
 void   athn_usb_swba(struct athn_usb_softc *);
+void   athn_usb_tx_status(void *, struct ieee80211_node *);
 void   athn_usb_rx_wmi_ctrl(struct athn_usb_softc *, uint8_t *, int);
 void   athn_usb_intr(struct usbd_xfer *, void *,
usbd_status);
@@ -629,12 +630,9 @@ athn_usb_load_firmware(struct athn_usb_s
/* Determine which firmware image to load. */
if (usc->flags & ATHN_USB_FLAG_AR7010) {
dd = usbd_get_device_descriptor(usc->sc_udev);
-   if (UGETW(dd->bcdDevice) == 0x0202)
-   name = "athn-ar7010-11";
-   else
-   name = "athn-ar7010";
+   name = "athn-open-ar7010";
} else
-   name = "athn-ar9271";
+   name = "athn-open-ar9271";
/* Read firmware image from the filesystem. */
if ((error = loadfirmware(name, , )) != 0) {
printf("%s: failed loadfirmware of file %s (error %d)\n",
@@ -1033,7 +1031,6 @@ athn_usb_newstate_cb(struct athn_usb_sof
 
s = splnet();
ostate = ic->ic_state;
-   DPRINTF(("newstate %d -> %d\n", ostate, cmd->state));
 
if (ostate == IEEE80211_S_RUN) {
sta_index = ((struct athn_node *)ic->ic_bss)->sta_index;
@@ -1053,13 +1050,21 @@ athn_usb_newstate_cb(struct athn_usb_sof
case IEEE80211_S_SCAN:
/* Make the LED blink while scanning. */
athn_set_led(sc, !sc->led_state);
-   (void)athn_usb_switch_chan(sc, ic->ic_bss->ni_chan, NULL);
+   error = athn_usb_switch_chan(sc, ic->ic_bss->ni_chan, NULL);
+   if (error)
+   printf("%s: could not switch to channel %d\n",
+   usc->usb_dev.dv_xname,
+   ieee80211_chan2ieee(ic, ic->ic_bss->ni_chan));
if (!usbd_is_dying(usc->sc_udev))
timeout_add_msec(>scan_to, 200);
break;
case IEEE80211_S_AUTH:
athn_set_led(sc, 0);
error = athn_usb_switch_chan(sc, ic->ic_bss->ni_chan, NULL);
+   if (error)
+   printf("%s: could not switch to channel %d\n",
+   usc->usb_dev.dv_xname,
+   ieee80211_chan2ieee(ic, ic->ic_bss->ni_chan));
break;
case 

Re: Fix for vi(1) manpage Visual command

2018-02-03 Thread Jason McIntyre
On Sat, Feb 03, 2018 at 10:28:20PM +0100, Ingo Schwarze wrote:
> 
> > a good way to do it without adding verbiage would be to not document it!
> > if it really is a crappy quirk, let's just leave it out then.
> 
> I actually like that idea, it makes the long list of EX COMMANDS
> a bit simpler, making the relevant stuff easier to find.
> 
> Of course, we still have to say how to get out of split screen
> mode when you stumble into it unintentionally - which esily
> happens because the colon requires the shift key on many keyboards,
> so accidentally hitting ":N" instead of ":n" is not uncommon.
> 
> If people like the idea, i'll also fix up :exusage (unless people
> want :exusage deleted, which i would of course prefer).
> 
> OK?
>   Ingo
> 

pretty much ok me. but:

> 
> Index: vi.1
> ===
> RCS file: /cvs/src/usr.bin/vi/docs/USD.doc/vi.man/vi.1,v
> retrieving revision 1.74
> diff -u -p -r1.74 vi.1
> --- vi.1  22 Aug 2017 20:27:18 -  1.74
> +++ vi.1  3 Feb 2018 21:14:48 -
> @@ -1737,11 +1737,6 @@ The input text is appended after the spe
>  .It Cm ar Ns Op Cm gs
>  Display the argument list.
>  .Pp
> -.It Cm bg
> -.Nm vi
> -only.
> -Background the current screen.
> -.Pp
>  .It Xo
>  .Op Ar range
>  .Cm c Ns Op Cm hange Ns
> @@ -1788,24 +1783,16 @@ Delete the lines from the file.
>  .It Xo
>  .Cm di Ns Op Cm splay
>  .Cm b Ns Oo Cm uffers Oc |
> -.Cm s Ns Oo Cm creens Oc |
>  .Cm t Ns Op Cm ags
>  .Xc
> -Display buffers, screens or tags.
> +Display buffers or tags.
>  .Pp
>  .It Xo
> -.Op Cm Ee Ns
> -.Op Cm dit Ns
> +.Cm e Ns Op Cm dit Ns | Ns Cm x Ns
>  .Op Cm !\&
>  .Op Ar +cmd
>  .Op Ar file
>  .Xc
> -.It Xo
> -.Op Cm Ee Ns
> -.Cm x Ns Op Cm !\&
> -.Op Ar +cmd
> -.Op Ar file
> -.Xc
>  Edit a different file.
>  .Pp
>  .It Xo
> @@ -1823,15 +1810,6 @@ command.
>  Display and optionally change the file name.
>  .Pp
>  .It Xo
> -.Op Cm Ff Ns
> -.Cm g
> -.Op Ar name
> -.Xc
> -.Nm vi
> -mode only.
> -Foreground the specified screen.
> -.Pp
> -.It Xo
>  .Op Ar range
>  .Cm g Ns Op Cm lobal
>  .No / Ns Ar pattern Ns /
> @@ -1880,9 +1858,9 @@ Display the lines unambiguously.
>  .Cm map Ns Op Cm !\&
>  .Op Ar lhs rhs
>  .Xc
> -Define or display maps (for
>  .Nm vi
> -only).
> +only.
> +Define or display maps.
>  .Pp
>  .It Xo
>  .Op Ar line
> @@ -1912,8 +1890,7 @@ Write the abbreviations, editor options 
>  .Ar file .
>  .Pp
>  .It Xo
> -.Op Cm Nn Ns
> -.Op Cm ext Ns
> +.Cm n Ns Op Cm ext Ns
>  .Op Cm !\&
>  .Op Ar file ...
>  .Xc
> @@ -1933,11 +1910,7 @@ Save the file in a form that can later b
>  .Fl r
>  option.
>  .Pp
> -.It Xo
> -.Op Cm \ Ns
> -.Cm rev Ns Op Cm ious Ns
> -.Op Cm !\&
> -.Xc
> +.It Cm prev Ns Oo Cm ious Oc Ns Op Cm !\&
>  Edit the previous file from the argument list.
>  .Pp
>  .It Xo
> @@ -1960,6 +1933,8 @@ Append buffer contents to the current li
>  .Op Cm !\&
>  .Xc
>  End the editing session.
> +This command can also be used to get out of the intentionally
> +undocumented, non-standard split-screen mode.

as-is, i'd add a comma after "non-standard".

but i wonder if we'd be better just saying "... get out of split-screen
mode." and running for cover? the comment might draw less attention to
itself that way.

your call. ok either way, with exusage fix-up or removal.

jmc

>  .Pp
>  .It Xo
>  .Op Ar line
> @@ -1978,15 +1953,6 @@ Recover
>  if it was previously saved.
>  .Pp
>  .It Xo
> -.Cm res Ns Op Cm ize
> -.Op Cm + Ns | Ns Cm - Ns
> -.Ar size
> -.Xc
> -.Nm vi
> -mode only.
> -Grow or shrink the current screen.
> -.Pp
> -.It Xo
>  .Cm rew Ns Op Cm ind Ns
>  .Op Cm !\&
>  .Xc
> @@ -2132,8 +2098,7 @@ character is usually
>  .Aq control-Z .
>  .Pp
>  .It Xo
> -.Op Cm Tt Ns
> -.Cm a Ns Op Cm g Ns
> +.Cm ta Ns Op Cm g Ns
>  .Op Cm !\&
>  .Ar tagstring
>  .Xc
> @@ -2195,19 +2160,18 @@ editor.
>  .Op Ar flags
>  .Xc
>  .Nm ex
> -mode only.
> +only.
>  Enter
>  .Nm vi .
>  .Pp
>  .It Xo
> -.Op Cm Vi Ns
> -.Cm i Ns Op Cm sual Ns
> +.Cm vi Ns Op Cm sual Ns
>  .Op Cm !\&
>  .Op Ar +cmd
>  .Op Ar file
>  .Xc
>  .Nm vi
> -mode only.
> +only.
>  Edit a new file.
>  .Pp
>  .It Xo
> @@ -2231,19 +2195,23 @@ command.
>  .Op Cm !\&
>  .Op Ar file
>  .Xc
> +Write the file.
> +.Pp
>  .It Xo
>  .Op Ar range
>  .Cm wn Ns Op Cm !\&
>  .Op >>
>  .Op Ar file
>  .Xc
> +Write the file and edit the next file from the argument list.
> +.Pp
>  .It Xo
>  .Op Ar range
>  .Cm wq Ns Op Cm !\&
>  .Op >>
>  .Op Ar file
>  .Xc
> -Write the file.
> +Write the file and exit the editor.
>  .Pp
>  .It Xo
>  .Op Ar range



Re: Fix for vi(1) manpage Visual command

2018-02-03 Thread Ingo Schwarze
Hi Jason,

Jason McIntyre wrote on Sat, Feb 03, 2018 at 08:52:16PM +:

> hmm. not that i entirely agree with this sentiment but fair enough,
> i will look at updating the USD docs.

Thanks.  Don't waste your time on that until after commit, of course.

> a good way to do it without adding verbiage would be to not document it!
> if it really is a crappy quirk, let's just leave it out then.

I actually like that idea, it makes the long list of EX COMMANDS
a bit simpler, making the relevant stuff easier to find.

Of course, we still have to say how to get out of split screen
mode when you stumble into it unintentionally - which esily
happens because the colon requires the shift key on many keyboards,
so accidentally hitting ":N" instead of ":n" is not uncommon.

If people like the idea, i'll also fix up :exusage (unless people
want :exusage deleted, which i would of course prefer).

OK?
  Ingo


Index: vi.1
===
RCS file: /cvs/src/usr.bin/vi/docs/USD.doc/vi.man/vi.1,v
retrieving revision 1.74
diff -u -p -r1.74 vi.1
--- vi.122 Aug 2017 20:27:18 -  1.74
+++ vi.13 Feb 2018 21:14:48 -
@@ -1737,11 +1737,6 @@ The input text is appended after the spe
 .It Cm ar Ns Op Cm gs
 Display the argument list.
 .Pp
-.It Cm bg
-.Nm vi
-only.
-Background the current screen.
-.Pp
 .It Xo
 .Op Ar range
 .Cm c Ns Op Cm hange Ns
@@ -1788,24 +1783,16 @@ Delete the lines from the file.
 .It Xo
 .Cm di Ns Op Cm splay
 .Cm b Ns Oo Cm uffers Oc |
-.Cm s Ns Oo Cm creens Oc |
 .Cm t Ns Op Cm ags
 .Xc
-Display buffers, screens or tags.
+Display buffers or tags.
 .Pp
 .It Xo
-.Op Cm Ee Ns
-.Op Cm dit Ns
+.Cm e Ns Op Cm dit Ns | Ns Cm x Ns
 .Op Cm !\&
 .Op Ar +cmd
 .Op Ar file
 .Xc
-.It Xo
-.Op Cm Ee Ns
-.Cm x Ns Op Cm !\&
-.Op Ar +cmd
-.Op Ar file
-.Xc
 Edit a different file.
 .Pp
 .It Xo
@@ -1823,15 +1810,6 @@ command.
 Display and optionally change the file name.
 .Pp
 .It Xo
-.Op Cm Ff Ns
-.Cm g
-.Op Ar name
-.Xc
-.Nm vi
-mode only.
-Foreground the specified screen.
-.Pp
-.It Xo
 .Op Ar range
 .Cm g Ns Op Cm lobal
 .No / Ns Ar pattern Ns /
@@ -1880,9 +1858,9 @@ Display the lines unambiguously.
 .Cm map Ns Op Cm !\&
 .Op Ar lhs rhs
 .Xc
-Define or display maps (for
 .Nm vi
-only).
+only.
+Define or display maps.
 .Pp
 .It Xo
 .Op Ar line
@@ -1912,8 +1890,7 @@ Write the abbreviations, editor options 
 .Ar file .
 .Pp
 .It Xo
-.Op Cm Nn Ns
-.Op Cm ext Ns
+.Cm n Ns Op Cm ext Ns
 .Op Cm !\&
 .Op Ar file ...
 .Xc
@@ -1933,11 +1910,7 @@ Save the file in a form that can later b
 .Fl r
 option.
 .Pp
-.It Xo
-.Op Cm \ Ns
-.Cm rev Ns Op Cm ious Ns
-.Op Cm !\&
-.Xc
+.It Cm prev Ns Oo Cm ious Oc Ns Op Cm !\&
 Edit the previous file from the argument list.
 .Pp
 .It Xo
@@ -1960,6 +1933,8 @@ Append buffer contents to the current li
 .Op Cm !\&
 .Xc
 End the editing session.
+This command can also be used to get out of the intentionally
+undocumented, non-standard split-screen mode.
 .Pp
 .It Xo
 .Op Ar line
@@ -1978,15 +1953,6 @@ Recover
 if it was previously saved.
 .Pp
 .It Xo
-.Cm res Ns Op Cm ize
-.Op Cm + Ns | Ns Cm - Ns
-.Ar size
-.Xc
-.Nm vi
-mode only.
-Grow or shrink the current screen.
-.Pp
-.It Xo
 .Cm rew Ns Op Cm ind Ns
 .Op Cm !\&
 .Xc
@@ -2132,8 +2098,7 @@ character is usually
 .Aq control-Z .
 .Pp
 .It Xo
-.Op Cm Tt Ns
-.Cm a Ns Op Cm g Ns
+.Cm ta Ns Op Cm g Ns
 .Op Cm !\&
 .Ar tagstring
 .Xc
@@ -2195,19 +2160,18 @@ editor.
 .Op Ar flags
 .Xc
 .Nm ex
-mode only.
+only.
 Enter
 .Nm vi .
 .Pp
 .It Xo
-.Op Cm Vi Ns
-.Cm i Ns Op Cm sual Ns
+.Cm vi Ns Op Cm sual Ns
 .Op Cm !\&
 .Op Ar +cmd
 .Op Ar file
 .Xc
 .Nm vi
-mode only.
+only.
 Edit a new file.
 .Pp
 .It Xo
@@ -2231,19 +2195,23 @@ command.
 .Op Cm !\&
 .Op Ar file
 .Xc
+Write the file.
+.Pp
 .It Xo
 .Op Ar range
 .Cm wn Ns Op Cm !\&
 .Op >>
 .Op Ar file
 .Xc
+Write the file and edit the next file from the argument list.
+.Pp
 .It Xo
 .Op Ar range
 .Cm wq Ns Op Cm !\&
 .Op >>
 .Op Ar file
 .Xc
-Write the file.
+Write the file and exit the editor.
 .Pp
 .It Xo
 .Op Ar range



Re: Fix for vi(1) manpage Visual command

2018-02-03 Thread Jason McIntyre
On Sat, Feb 03, 2018 at 09:28:11PM +0100, Ingo Schwarze wrote:
> Hi Jason,
> 
> Jason McIntyre wrote on Sat, Feb 03, 2018 at 07:23:59PM +:
> > On Sat, Feb 03, 2018 at 08:10:14PM +0100, Ingo Schwarze wrote:
> >> Jason McIntyre wrote on Sat, Feb 03, 2018 at 05:41:01PM +:
> 
> >>> can of worms, there's still stuff like :exusage
> 
> >> I think that can remain as it is.  It isn't very precise anyway,
> >> with very short half-line descriptions only and not saying how
> >> the ex commands can be abbreviated.  So at least the usage of []
> >> isn't inconsistent in there.
> 
> > i think it's worth taking the time to fix. if it gets deleted, that's
> > another thing, but until then why mislead people? it will be simpler
> > and clearer just to list lowercase variants.
> 
> See below for a patch to do that.
> 

i'll take your word for it that it does what you say ;)

> Note that the man page and :exusage are already out of sync in multiple
> respects, mostly in the sense of using gratuitiously different
> wordings.  I didn't try to fix that in this patch, to not expand
> the scope of the patch beyond what is reasonable, and did not check
> whether anything unrelated in there is actually wrong.
> 

agreed

> >>> and the USD docs to update. so a man page fix will not suffice.
> 
> >> I wouldn't bother.  They are not installed, and the base system
> >> doesn't even provide tools to process them.  If we ever decide
> >> to do anything with them, they will require a full check of accuracy
> >> anyway.
> 
> > actually a fair bit of time has been spent on vi's USD docs. it would be
> > a shame to let that slip. i'm not saying they're 100% in sync, but why
> > worsen it? we could have (another) discussion about removing them but
> > until then, i think it's worth trying to keep this up to date. if
> > nothing else, it will make someone else's job easier in the future if
> > they try to check it.
> 
> Even if we consider maintaining the USD docs worthwhile, i don't think
> that ought to delay fixing the manual page.
> 

hmm. not that i entirely agree with this sentiment but fair enough, i will
look at updating the USD docs.

> > diff reads ok, but one comment:
> [...]
> >> +For
> >> +.Cm e ,
> >> +.Cm fg ,
> >> +.Cm n ,
> >> +.Cm prev ,
> >> +.Cm ta ,
> >> +and
> >> +.Cm vi ,
> >> +if the first letter of the command is capitalized, the current screen is
> >> +split and the new file is displayed in addition to the current screen.
> >> +This feature is only available in
> >> +.Nm vi ,
> >> +not in
> >> +.Nm ex .
> 
> > it would be better, i think, to emphasise the behaviour rather than the
> > commands. so i'd do it the other way round:
> > 
> > It is possible to start a command in a new screen by ...
> > This applies to the commands ..., in vi mode only.
> > 
> > like that? again, no biggie.
> 
> Actually, i don't like that.  That makes it sound as if it were a
> general principle applicable to most commands, while it is actually
> a non-standard, non-portable, poorly designed and barely working
> quirk implemented only for a handful of commands.  So i think
> emphasizing the limitations rather than the benefits serves the
> users better.  I'd rather discourage it even more, if i could see
> a good way to do so without additional verbiage.
> 

a good way to do it without adding verbiage would be to not document it!
if it really is a crappy quirk, let's just leave it out then.
i presumed it was all meant to be there...

> Yours,
>   Ingo
> 
> 
> Index: ex/ex_cmd.c
> ===
> RCS file: /cvs/src/usr.bin/vi/ex/ex_cmd.c,v
> retrieving revision 1.10
> diff -u -p -r1.10 ex_cmd.c
> --- ex/ex_cmd.c   19 Nov 2015 07:53:31 -  1.10
> +++ ex/ex_cmd.c   3 Feb 2018 20:10:59 -
> @@ -111,7 +111,7 @@ EXCMDLIST const cmds[] = {
>   {"bg",  ex_bg,  E_VIONLY,
>   "",
>   "bg",
> - "put a foreground screen into the background"},
> + "put the current screen into the background"},
>  /* C_CHANGE */
>   {"change",  ex_change,  E_ADDR2|E_ADDR_ZERODEF,
>   "!ca",
> @@ -150,12 +150,12 @@ EXCMDLIST const cmds[] = {
>  /* C_EDIT */
>   {"edit",ex_edit,E_NEWSCREEN,
>   "f1o",
> - "[Ee][dit][!] [+cmd] [file]",
> + "e[dit][!] [+cmd] [file]",
>   "begin editing another file"},
>  /* C_EX */
>   {"ex",  ex_edit,E_NEWSCREEN,
>   "f1o",
> - "[Ee]x[!] [+cmd] [file]",
> + "ex[!] [+cmd] [file]",
>   "begin editing another file"},
>  /* C_EXUSAGE */
>   {"exusage", ex_usage,   0,
> @@ -170,7 +170,7 @@ EXCMDLIST const cmds[] = {
>  /* C_FG */
>   {"fg",  ex_fg,  E_NEWSCREEN|E_VIONLY,
>   "f1o",
> - "[Ff]g [file]",
> + "fg [file]",
>   "bring a backgrounded screen into the foreground"},
>  /* C_GLOBAL */
>   {"global",  

Re: Fix for vi(1) manpage Visual command

2018-02-03 Thread Ingo Schwarze
Hi Jason,

Jason McIntyre wrote on Sat, Feb 03, 2018 at 07:23:59PM +:
> On Sat, Feb 03, 2018 at 08:10:14PM +0100, Ingo Schwarze wrote:
>> Jason McIntyre wrote on Sat, Feb 03, 2018 at 05:41:01PM +:

>>> can of worms, there's still stuff like :exusage

>> I think that can remain as it is.  It isn't very precise anyway,
>> with very short half-line descriptions only and not saying how
>> the ex commands can be abbreviated.  So at least the usage of []
>> isn't inconsistent in there.

> i think it's worth taking the time to fix. if it gets deleted, that's
> another thing, but until then why mislead people? it will be simpler
> and clearer just to list lowercase variants.

See below for a patch to do that.

Note that the man page and :exusage are already out of sync in multiple
respects, mostly in the sense of using gratuitiously different
wordings.  I didn't try to fix that in this patch, to not expand
the scope of the patch beyond what is reasonable, and did not check
whether anything unrelated in there is actually wrong.

>>> and the USD docs to update. so a man page fix will not suffice.

>> I wouldn't bother.  They are not installed, and the base system
>> doesn't even provide tools to process them.  If we ever decide
>> to do anything with them, they will require a full check of accuracy
>> anyway.

> actually a fair bit of time has been spent on vi's USD docs. it would be
> a shame to let that slip. i'm not saying they're 100% in sync, but why
> worsen it? we could have (another) discussion about removing them but
> until then, i think it's worth trying to keep this up to date. if
> nothing else, it will make someone else's job easier in the future if
> they try to check it.

Even if we consider maintaining the USD docs worthwhile, i don't think
that ought to delay fixing the manual page.

> diff reads ok, but one comment:
[...]
>> +For
>> +.Cm e ,
>> +.Cm fg ,
>> +.Cm n ,
>> +.Cm prev ,
>> +.Cm ta ,
>> +and
>> +.Cm vi ,
>> +if the first letter of the command is capitalized, the current screen is
>> +split and the new file is displayed in addition to the current screen.
>> +This feature is only available in
>> +.Nm vi ,
>> +not in
>> +.Nm ex .

> it would be better, i think, to emphasise the behaviour rather than the
> commands. so i'd do it the other way round:
> 
>   It is possible to start a command in a new screen by ...
>   This applies to the commands ..., in vi mode only.
> 
> like that? again, no biggie.

Actually, i don't like that.  That makes it sound as if it were a
general principle applicable to most commands, while it is actually
a non-standard, non-portable, poorly designed and barely working
quirk implemented only for a handful of commands.  So i think
emphasizing the limitations rather than the benefits serves the
users better.  I'd rather discourage it even more, if i could see
a good way to do so without additional verbiage.

Yours,
  Ingo


Index: ex/ex_cmd.c
===
RCS file: /cvs/src/usr.bin/vi/ex/ex_cmd.c,v
retrieving revision 1.10
diff -u -p -r1.10 ex_cmd.c
--- ex/ex_cmd.c 19 Nov 2015 07:53:31 -  1.10
+++ ex/ex_cmd.c 3 Feb 2018 20:10:59 -
@@ -111,7 +111,7 @@ EXCMDLIST const cmds[] = {
{"bg",  ex_bg,  E_VIONLY,
"",
"bg",
-   "put a foreground screen into the background"},
+   "put the current screen into the background"},
 /* C_CHANGE */
{"change",  ex_change,  E_ADDR2|E_ADDR_ZERODEF,
"!ca",
@@ -150,12 +150,12 @@ EXCMDLIST const cmds[] = {
 /* C_EDIT */
{"edit",ex_edit,E_NEWSCREEN,
"f1o",
-   "[Ee][dit][!] [+cmd] [file]",
+   "e[dit][!] [+cmd] [file]",
"begin editing another file"},
 /* C_EX */
{"ex",  ex_edit,E_NEWSCREEN,
"f1o",
-   "[Ee]x[!] [+cmd] [file]",
+   "ex[!] [+cmd] [file]",
"begin editing another file"},
 /* C_EXUSAGE */
{"exusage", ex_usage,   0,
@@ -170,7 +170,7 @@ EXCMDLIST const cmds[] = {
 /* C_FG */
{"fg",  ex_fg,  E_NEWSCREEN|E_VIONLY,
"f1o",
-   "[Ff]g [file]",
+   "fg [file]",
"bring a backgrounded screen into the foreground"},
 /* C_GLOBAL */
{"global",  ex_global,  E_ADDR2_ALL,
@@ -225,7 +225,7 @@ EXCMDLIST const cmds[] = {
 /* C_NEXT */
{"next",ex_next,E_NEWSCREEN,
"!fN",
-   "[Nn][ext][!] [+cmd] [file ...]",
+   "n[ext][!] [+cmd] [file ...]",
"edit (and optionally specify) the next file"},
 /* C_NUMBER */
{"number",  ex_number,  E_ADDR2|E_CLRFLAG,
@@ -250,7 +250,7 @@ EXCMDLIST const cmds[] = {
 /* C_PREVIOUS */
{"previous",ex_prev,E_NEWSCREEN,
"!",
-   "[Pp]rev[ious][!]",
+   "prev[ious][!]",
"edit the previous file in 

shutdown(8): fprintf(stderr -> warnx

2018-02-03 Thread Scott Cheloha
ok?

--
Scott Cheloha

Index: sbin/shutdown/shutdown.c
===
RCS file: /cvs/src/sbin/shutdown/shutdown.c,v
retrieving revision 1.46
diff -u -p -r1.46 shutdown.c
--- sbin/shutdown/shutdown.c3 Apr 2017 20:59:19 -   1.46
+++ sbin/shutdown/shutdown.c3 Feb 2018 19:31:12 -
@@ -151,18 +151,15 @@ main(int argc, char *argv[])
usage();
 
if (dofast && nosync) {
-   (void)fprintf(stderr,
-   "shutdown: incompatible switches -f and -n.\n");
+   warnx("incompatible switches -f and -n.");
usage();
}
if (doreboot && dohalt) {
-   (void)fprintf(stderr,
-   "shutdown: incompatible switches -h and -r.\n");
+   warnx("incompatible switches -h and -r.");
usage();
}
if (doreboot && dopower) {
-   (void)fprintf(stderr,
-   "shutdown: incompatible switches -p and -r.\n");
+   warnx("incompatible switches -p and -r.");
usage();
}
getoffset(*argv++);



Re: Fix for vi(1) manpage Visual command

2018-02-03 Thread Jason McIntyre
On Sat, Feb 03, 2018 at 08:10:14PM +0100, Ingo Schwarze wrote:
> Hi Jason,
> 
> Jason McIntyre wrote on Sat, Feb 03, 2018 at 05:41:01PM +:
> 
> > personally i still think it would be simpler to only list these commands
> > once, but note which subset can take a capital letter (and what that
> > means).
> 
> I seems you are right, amybe i should believe you the first time
> you say something.  See below for an updated patch.
> 
> > can of worms, there's still stuff like :exusage
> 
> I think that can remain as it is.  It isn't very precise anyway,
> with very short half-line descriptions only and not saying how
> the ex commands can be abbreviated.  So at least the usage of []
> isn't inconsistent in there.
> 

i think it's worth taking the time to fix. if it gets deleted, that's
another thing, but until then why mislead people? it will be simpler and
clearer just to list lowercase variants.

> In principle, :exusage ought to be deleted.  It's not the job of a
> program to contain documentation.  Documentation belongs in the
> manual page, and there it is indeed.  But that's a different matter.
> 
> > and the USD docs to update. so a man page fix will not suffice.
> 
> I wouldn't bother.  They are not installed, and the base system
> doesn't even provide tools to process them.  If we ever decide
> to do anything with them, they will require a full check of accuracy
> anyway.
> 

actually a fair bit of time has been spent on vi's USD docs. it would be
a shame to let that slip. i'm not saying they're 100% in sync, but why
worsen it? we could have (another) discussion about removing them but
until then, i think it's worth trying to keep this up to date. if
nothing else, it will make someone else's job easier in the future if
they try to check it.

> Yours,
>   Ingo
> 

diff reads ok, but one comment:

> 
> Index: vi.1
> ===
> RCS file: /cvs/src/usr.bin/vi/docs/USD.doc/vi.man/vi.1,v
> retrieving revision 1.74
> diff -u -p -r1.74 vi.1
> --- vi.1  22 Aug 2017 20:27:18 -  1.74
> +++ vi.1  3 Feb 2018 19:04:16 -
> @@ -1794,18 +1794,11 @@ Delete the lines from the file.
>  Display buffers, screens or tags.
>  .Pp
>  .It Xo
> -.Op Cm Ee Ns
> -.Op Cm dit Ns
> +.Cm e Ns Op Cm dit Ns | Ns Cm x Ns
>  .Op Cm !\&
>  .Op Ar +cmd
>  .Op Ar file
>  .Xc
> -.It Xo
> -.Op Cm Ee Ns
> -.Cm x Ns Op Cm !\&
> -.Op Ar +cmd
> -.Op Ar file
> -.Xc
>  Edit a different file.
>  .Pp
>  .It Xo
> @@ -1822,14 +1815,10 @@ command.
>  .Xc
>  Display and optionally change the file name.
>  .Pp
> -.It Xo
> -.Op Cm Ff Ns
> -.Cm g
> -.Op Ar name
> -.Xc
> +.It Cm fg Op Ar name
>  .Nm vi
> -mode only.
> -Foreground the specified screen.
> +only.
> +Background the current screen and foreground the specified screen instead.
>  .Pp
>  .It Xo
>  .Op Ar range
> @@ -1880,9 +1869,9 @@ Display the lines unambiguously.
>  .Cm map Ns Op Cm !\&
>  .Op Ar lhs rhs
>  .Xc
> -Define or display maps (for
>  .Nm vi
> -only).
> +only.
> +Define or display maps.
>  .Pp
>  .It Xo
>  .Op Ar line
> @@ -1912,8 +1901,7 @@ Write the abbreviations, editor options 
>  .Ar file .
>  .Pp
>  .It Xo
> -.Op Cm Nn Ns
> -.Op Cm ext Ns
> +.Cm n Ns Op Cm ext Ns
>  .Op Cm !\&
>  .Op Ar file ...
>  .Xc
> @@ -1933,11 +1921,7 @@ Save the file in a form that can later b
>  .Fl r
>  option.
>  .Pp
> -.It Xo
> -.Op Cm \ Ns
> -.Cm rev Ns Op Cm ious Ns
> -.Op Cm !\&
> -.Xc
> +.It Cm prev Ns Oo Cm ious Oc Ns Op Cm !\&
>  Edit the previous file from the argument list.
>  .Pp
>  .It Xo
> @@ -1959,7 +1943,7 @@ Append buffer contents to the current li
>  .Cm q Ns Op Cm uit Ns
>  .Op Cm !\&
>  .Xc
> -End the editing session.
> +End editing the file and close the current screen.
>  .Pp
>  .It Xo
>  .Op Ar line
> @@ -1980,10 +1964,10 @@ if it was previously saved.
>  .It Xo
>  .Cm res Ns Op Cm ize
>  .Op Cm + Ns | Ns Cm - Ns
> -.Ar size
> +.Ar lines
>  .Xc
>  .Nm vi
> -mode only.
> +only.
>  Grow or shrink the current screen.
>  .Pp
>  .It Xo
> @@ -2132,8 +2116,7 @@ character is usually
>  .Aq control-Z .
>  .Pp
>  .It Xo
> -.Op Cm Tt Ns
> -.Cm a Ns Op Cm g Ns
> +.Cm ta Ns Op Cm g Ns
>  .Op Cm !\&
>  .Ar tagstring
>  .Xc
> @@ -2195,19 +2178,18 @@ editor.
>  .Op Ar flags
>  .Xc
>  .Nm ex
> -mode only.
> +only.
>  Enter
>  .Nm vi .
>  .Pp
>  .It Xo
> -.Op Cm Vi Ns
> -.Cm i Ns Op Cm sual Ns
> +.Cm vi Ns Op Cm sual Ns
>  .Op Cm !\&
>  .Op Ar +cmd
>  .Op Ar file
>  .Xc
>  .Nm vi
> -mode only.
> +only.
>  Edit a new file.
>  .Pp
>  .It Xo
> @@ -2231,19 +2213,23 @@ command.
>  .Op Cm !\&
>  .Op Ar file
>  .Xc
> +Write the file.
> +.Pp
>  .It Xo
>  .Op Ar range
>  .Cm wn Ns Op Cm !\&
>  .Op >>
>  .Op Ar file
>  .Xc
> +Write the file and edit the next file from the argument list.
> +.Pp
>  .It Xo
>  .Op Ar range
>  .Cm wq Ns Op Cm !\&
>  .Op >>
>  .Op Ar file
>  .Xc
> -Write the file.
> +Write the file and close the current screen.
>  .Pp
>  .It Xo
>  .Op Ar range
> @@ -2251,8 +2237,7 @@ Write the file.
>  .Op Cm !\&
>  .Op 

Re: Fix for vi(1) manpage Visual command

2018-02-03 Thread Ingo Schwarze
Hi Jason,

Jason McIntyre wrote on Sat, Feb 03, 2018 at 05:41:01PM +:

> personally i still think it would be simpler to only list these commands
> once, but note which subset can take a capital letter (and what that
> means).

I seems you are right, amybe i should believe you the first time
you say something.  See below for an updated patch.

> can of worms, there's still stuff like :exusage

I think that can remain as it is.  It isn't very precise anyway,
with very short half-line descriptions only and not saying how
the ex commands can be abbreviated.  So at least the usage of []
isn't inconsistent in there.

In principle, :exusage ought to be deleted.  It's not the job of a
program to contain documentation.  Documentation belongs in the
manual page, and there it is indeed.  But that's a different matter.

> and the USD docs to update. so a man page fix will not suffice.

I wouldn't bother.  They are not installed, and the base system
doesn't even provide tools to process them.  If we ever decide
to do anything with them, they will require a full check of accuracy
anyway.

Yours,
  Ingo


Index: vi.1
===
RCS file: /cvs/src/usr.bin/vi/docs/USD.doc/vi.man/vi.1,v
retrieving revision 1.74
diff -u -p -r1.74 vi.1
--- vi.122 Aug 2017 20:27:18 -  1.74
+++ vi.13 Feb 2018 19:04:16 -
@@ -1794,18 +1794,11 @@ Delete the lines from the file.
 Display buffers, screens or tags.
 .Pp
 .It Xo
-.Op Cm Ee Ns
-.Op Cm dit Ns
+.Cm e Ns Op Cm dit Ns | Ns Cm x Ns
 .Op Cm !\&
 .Op Ar +cmd
 .Op Ar file
 .Xc
-.It Xo
-.Op Cm Ee Ns
-.Cm x Ns Op Cm !\&
-.Op Ar +cmd
-.Op Ar file
-.Xc
 Edit a different file.
 .Pp
 .It Xo
@@ -1822,14 +1815,10 @@ command.
 .Xc
 Display and optionally change the file name.
 .Pp
-.It Xo
-.Op Cm Ff Ns
-.Cm g
-.Op Ar name
-.Xc
+.It Cm fg Op Ar name
 .Nm vi
-mode only.
-Foreground the specified screen.
+only.
+Background the current screen and foreground the specified screen instead.
 .Pp
 .It Xo
 .Op Ar range
@@ -1880,9 +1869,9 @@ Display the lines unambiguously.
 .Cm map Ns Op Cm !\&
 .Op Ar lhs rhs
 .Xc
-Define or display maps (for
 .Nm vi
-only).
+only.
+Define or display maps.
 .Pp
 .It Xo
 .Op Ar line
@@ -1912,8 +1901,7 @@ Write the abbreviations, editor options 
 .Ar file .
 .Pp
 .It Xo
-.Op Cm Nn Ns
-.Op Cm ext Ns
+.Cm n Ns Op Cm ext Ns
 .Op Cm !\&
 .Op Ar file ...
 .Xc
@@ -1933,11 +1921,7 @@ Save the file in a form that can later b
 .Fl r
 option.
 .Pp
-.It Xo
-.Op Cm \ Ns
-.Cm rev Ns Op Cm ious Ns
-.Op Cm !\&
-.Xc
+.It Cm prev Ns Oo Cm ious Oc Ns Op Cm !\&
 Edit the previous file from the argument list.
 .Pp
 .It Xo
@@ -1959,7 +1943,7 @@ Append buffer contents to the current li
 .Cm q Ns Op Cm uit Ns
 .Op Cm !\&
 .Xc
-End the editing session.
+End editing the file and close the current screen.
 .Pp
 .It Xo
 .Op Ar line
@@ -1980,10 +1964,10 @@ if it was previously saved.
 .It Xo
 .Cm res Ns Op Cm ize
 .Op Cm + Ns | Ns Cm - Ns
-.Ar size
+.Ar lines
 .Xc
 .Nm vi
-mode only.
+only.
 Grow or shrink the current screen.
 .Pp
 .It Xo
@@ -2132,8 +2116,7 @@ character is usually
 .Aq control-Z .
 .Pp
 .It Xo
-.Op Cm Tt Ns
-.Cm a Ns Op Cm g Ns
+.Cm ta Ns Op Cm g Ns
 .Op Cm !\&
 .Ar tagstring
 .Xc
@@ -2195,19 +2178,18 @@ editor.
 .Op Ar flags
 .Xc
 .Nm ex
-mode only.
+only.
 Enter
 .Nm vi .
 .Pp
 .It Xo
-.Op Cm Vi Ns
-.Cm i Ns Op Cm sual Ns
+.Cm vi Ns Op Cm sual Ns
 .Op Cm !\&
 .Op Ar +cmd
 .Op Ar file
 .Xc
 .Nm vi
-mode only.
+only.
 Edit a new file.
 .Pp
 .It Xo
@@ -2231,19 +2213,23 @@ command.
 .Op Cm !\&
 .Op Ar file
 .Xc
+Write the file.
+.Pp
 .It Xo
 .Op Ar range
 .Cm wn Ns Op Cm !\&
 .Op >>
 .Op Ar file
 .Xc
+Write the file and edit the next file from the argument list.
+.Pp
 .It Xo
 .Op Ar range
 .Cm wq Ns Op Cm !\&
 .Op >>
 .Op Ar file
 .Xc
-Write the file.
+Write the file and close the current screen.
 .Pp
 .It Xo
 .Op Ar range
@@ -2251,8 +2237,7 @@ Write the file.
 .Op Cm !\&
 .Op Ar file
 .Xc
-Exit the editor,
-writing the file if it has been modified.
+Write the file if it has been modified and close the current screen.
 .Pp
 .It Xo
 .Op Ar range
@@ -2271,6 +2256,21 @@ Copy the specified lines to a buffer.
 .Xc
 Adjust the window.
 .El
+.Pp
+For
+.Cm e ,
+.Cm fg ,
+.Cm n ,
+.Cm prev ,
+.Cm ta ,
+and
+.Cm vi ,
+if the first letter of the command is capitalized, the current screen is
+split and the new file is displayed in addition to the current screen.
+This feature is only available in
+.Nm vi ,
+not in
+.Nm ex .
 .Sh SET OPTIONS
 There are a large number of options that may be set
 .Pq or unset



Re: Fix for vi(1) manpage Visual command

2018-02-03 Thread Jason McIntyre
On Sat, Feb 03, 2018 at 05:26:34PM +0100, Ingo Schwarze wrote:
> Hi Jason, hi Anthony,
> 

evening.

> Jason McIntyre wrote on Sat, Feb 03, 2018 at 02:52:26PM +:
> 
> > ok, but it does not currently say that. hence the original post:
> > [Vi]i[sual]
> > that seems an obvious mistake, as noted in the original post.
> 
> That section of the manual is full of lies in multiple respects.
> I never used split screens, so i never noticed in the past.
> 
> > so we could quick-fix that. but now we see that [Vv] itself is
> > problematic, as also noted. i'd be inclined to say we should just list
> > them as lowercase commands, and note separately what happens if the
> > command begins uppercase.
> 
> I think the lowercase and uppercase versions are sufficiently different
> to document them separately.
> 
> > there again, why does the EX COMMANDS section list commands that are
> > "vi only"?
> 
> Historical misdesign.  Originally, Bill Joy wrote ex(1) for 1BSD in 1977.
> Then he wrote vi(1) for 2BSD in 1979.  He completely botched the design
> in so far as he kept the concept of "ex commands" and introduced an
> additional, completely different concept of "vi commands".  Both
> provide distinct, but significantly redundant functionality.
> 
> So in vi(1), you can append text to a line using the vi "a" command,
> or you can append a new line using the vi "o" command, or you can
> append a new line using the ex "a" command, which has completely
> different syntax and semantics.
> 
> Given that concept of ex commands in vi, even though it originally
> emerged as a backward compatibility concept, at some point, ex
> commands appeared that can only be used in vi, but not in ex:  KISS!
> 
> That said, here is a patch to fix most of the lies in one go.
> 
> OK?
>   Ingo
> 
> P.S.
> Note that the concept of screens is not very well thought out.
> For example, it interacts very erratically with the concept of
> next and previous files from the command line.  I wouldn't mind
> completely zapping the concept of split screens from vi(1), it
> isn't required by POSIX.  Then again, i won't get myself killed
> over the proposal to scrap the feature if anybody wants to keep it.
> 

thanks for the explanation.

personally i still think it would be simpler to only list these commands
once, but note which subset can take a capital letter (and what that
means). but both ways would fix it and i'm not that fussed. so if you
really prefer to list them twice, fine.

having said that, can of worms, can of worms, there's still stuff like
:exusage and the USD docs to update. so a man page fix will not suffice.

jmc

> 
> Index: vi.1
> ===
> RCS file: /cvs/src/usr.bin/vi/docs/USD.doc/vi.man/vi.1,v
> retrieving revision 1.74
> diff -u -p -r1.74 vi.1
> --- vi.1  22 Aug 2017 20:27:18 -  1.74
> +++ vi.1  3 Feb 2018 15:54:16 -
> @@ -1794,19 +1794,22 @@ Delete the lines from the file.
>  Display buffers, screens or tags.
>  .Pp
>  .It Xo
> -.Op Cm Ee Ns
> -.Op Cm dit Ns
> +.Cm e Ns Op Cm dit Ns | Ns Cm x Ns
>  .Op Cm !\&
>  .Op Ar +cmd
>  .Op Ar file
>  .Xc
> +Edit a different file.
> +.Pp
>  .It Xo
> -.Op Cm Ee Ns
> -.Cm x Ns Op Cm !\&
> +.Cm E Ns Op Cm dit Ns | Ns Cm x Ns
> +.Op Cm !\&
>  .Op Ar +cmd
>  .Op Ar file
>  .Xc
> -Edit a different file.
> +.Nm vi
> +only.
> +Split the screen and edit a different file.
>  .Pp
>  .It Xo
>  .Cm exu Ns Op Cm sage
> @@ -1822,14 +1825,15 @@ command.
>  .Xc
>  Display and optionally change the file name.
>  .Pp
> -.It Xo
> -.Op Cm Ff Ns
> -.Cm g
> -.Op Ar name
> -.Xc
> +.It Cm fg Op Ar name
> +.Nm vi
> +only.
> +Background the current screen and foreground the specified screen instead.
> +.Pp
> +.It Cm Fg Op Ar name
>  .Nm vi
> -mode only.
> -Foreground the specified screen.
> +only.
> +Split the screen and foreground the specified screen.
>  .Pp
>  .It Xo
>  .Op Ar range
> @@ -1880,9 +1884,9 @@ Display the lines unambiguously.
>  .Cm map Ns Op Cm !\&
>  .Op Ar lhs rhs
>  .Xc
> -Define or display maps (for
>  .Nm vi
> -only).
> +only.
> +Define or display maps.
>  .Pp
>  .It Xo
>  .Op Ar line
> @@ -1912,12 +1916,20 @@ Write the abbreviations, editor options 
>  .Ar file .
>  .Pp
>  .It Xo
> -.Op Cm Nn Ns
> -.Op Cm ext Ns
> +.Cm n Ns Op Cm ext Ns
>  .Op Cm !\&
>  .Op Ar file ...
>  .Xc
>  Edit the next file from the argument list.
> +.Pp
> +.It Xo
> +.Cm N Ns Op Cm ext Ns
> +.Op Cm !\&
> +.Op Ar file ...
> +.Xc
> +.Nm vi
> +only.
> +Split the screen and edit the next file from the argument list.
>  .\" .Pp
>  .\" .It Xo
>  .\" .Op Ar line
> @@ -1933,13 +1945,14 @@ Save the file in a form that can later b
>  .Fl r
>  option.
>  .Pp
> -.It Xo
> -.Op Cm \ Ns
> -.Cm rev Ns Op Cm ious Ns
> -.Op Cm !\&
> -.Xc
> +.It Cm prev Ns Oo Cm ious Oc Ns Op Cm !\&
>  Edit the previous file from the argument list.
>  .Pp
> +.It Cm Prev Ns Oo Cm ious Oc Ns Op Cm !\&
> +.Nm vi
> +only.
> +Split the screen and edit the previous file from the 

Re: sleep(1): better error messages

2018-02-03 Thread Ingo Schwarze
Hi Scott,

Scott Cheloha wrote on Sat, Feb 03, 2018 at 10:08:46AM -0600:

> This adds strtonum(3)-style error messages to sleep(1).  They're
> more informative than the usage statement and they're idiomatic
> for numeric input.
> 
> Exiting with EINVAL is really unusual.  It went into r1.9.  Unless
> I'm missing something I think we can just exit with 1, which is
> consistent with what other utilities do.

I consider this an improvement.  POSIX neither restricts the error
message format nor mandates specific non-zero EXIT STATUS values.
I can't see how it might break anyone's scripts either, unless those
are poorly written and rely on undocumented features.

In general, don't abuse errno(2) constants for the EXIT STATUS,
and don't use EXIT STATUS values other than 1 unless the utility
is unusually complicated, which sleep(1) certainly isn't.

OK schwarze@
  Ingo


> Index: bin/sleep/sleep.c
> ===
> RCS file: /cvs/src/bin/sleep/sleep.c,v
> retrieving revision 1.25
> diff -u -p -r1.25 sleep.c
> --- bin/sleep/sleep.c 2 Feb 2018 16:46:37 -   1.25
> +++ bin/sleep/sleep.c 2 Feb 2018 17:20:58 -
> @@ -31,7 +31,6 @@
>   */
>  
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -73,10 +72,10 @@ main(int argc, char *argv[])
>   cp = *argv;
>   while ((*cp != '\0') && (*cp != '.')) {
>   if (!isdigit((unsigned char)*cp))
> - usage();
> + errx(1, "seconds is invalid: %s", *argv);
>   t = (secs * 10) + (*cp++ - '0');
>   if (t / 10 != secs) /* oflow */
> - return (EINVAL);
> + errx(1, "seconds is too large: %s", *argv);
>   secs = t;
>   }
>  
> @@ -87,7 +86,7 @@ main(int argc, char *argv[])
>   if (*cp == '\0')
>   break;
>   if (!isdigit((unsigned char)*cp))
> - usage();
> + errx(1, "seconds is invalid: %s", *argv);
>   nsecs += (*cp++ - '0') * i;
>   }
>  
> @@ -98,7 +97,7 @@ main(int argc, char *argv[])
>*/
>   while (*cp != '\0') {
>   if (!isdigit((unsigned char)*cp++))
> - usage();
> + errx(1, "seconds is invalid: %s", *argv);
>   }
>   }
>  
> 



gem receive watchdog

2018-02-03 Thread Alexander Bluhm
Hi,

I have seen some network hangs with my gem(4) interface on sparc64.
Receiving packets stopped sometimes, ifconfig down/up made it work
again.

In the tick timeout handler refill the receive ring if it is empty.
The logic is taken from hme(4).  Also splnet() should protect the
register access and ifp counters.

As this did not help, I looked into gem_rx_watchdog().  There is a
workaround for a hardware bug.  It resets the hardware when there
is no progress.  I my case the fifo pointers advanced a bit, but
finally got stuck anyway.  So I restart the receive watchdog timeout
again.

Since this fix the interface keeps running.

ok?

bluhm

Index: dev/ic/gem.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/dev/ic/gem.c,v
retrieving revision 1.122
diff -u -p -r1.122 gem.c
--- dev/ic/gem.c8 Jun 2017 01:34:00 -   1.122
+++ dev/ic/gem.c3 Feb 2018 16:49:36 -
@@ -423,6 +423,7 @@ gem_tick(void *arg)
int s;
u_int32_t v;
 
+   s = splnet();
/* unload collisions counters */
v = bus_space_read_4(t, mac, GEM_MAC_EXCESS_COLL_CNT) +
bus_space_read_4(t, mac, GEM_MAC_LATE_COLL_CNT);
@@ -448,7 +449,15 @@ gem_tick(void *arg)
bus_space_write_4(t, mac, GEM_MAC_RX_CRC_ERR_CNT, 0);
bus_space_write_4(t, mac, GEM_MAC_RX_CODE_VIOL, 0);
 
-   s = splnet();
+   /*
+* If buffer allocation fails, the receive ring may become
+* empty. There is no receive interrupt to recover from that.
+*/
+   if (if_rxr_inuse(>sc_rx_ring) == 0) {
+   gem_fill_rx_ring(sc);
+   bus_space_write_4(t, mac, GEM_RX_KICK, sc->sc_rx_prod);
+   }
+
mii_tick(>sc_mii);
splx(s);
 
@@ -1200,17 +1209,26 @@ gem_rx_watchdog(void *arg)
rx_fifo_wr_ptr = bus_space_read_4(t, h, GEM_RX_FIFO_WR_PTR);
rx_fifo_rd_ptr = bus_space_read_4(t, h, GEM_RX_FIFO_RD_PTR);
state = bus_space_read_4(t, h, GEM_MAC_MAC_STATE);
-   if ((state & GEM_MAC_STATE_OVERFLOW) == GEM_MAC_STATE_OVERFLOW &&
-   ((rx_fifo_wr_ptr == rx_fifo_rd_ptr) ||
-((sc->sc_rx_fifo_wr_ptr == rx_fifo_wr_ptr) &&
- (sc->sc_rx_fifo_rd_ptr == rx_fifo_rd_ptr {
-   /*
-* The RX state machine is still in overflow state and
-* the RX FIFO write and read pointers seem to be
-* stuck.  Whack the chip over the head to get things
-* going again.
-*/
-   gem_init(ifp);
+   if ((state & GEM_MAC_STATE_OVERFLOW) == GEM_MAC_STATE_OVERFLOW) {
+   if ((rx_fifo_wr_ptr == rx_fifo_rd_ptr) ||
+((sc->sc_rx_fifo_wr_ptr == rx_fifo_wr_ptr) &&
+ (sc->sc_rx_fifo_rd_ptr == rx_fifo_rd_ptr))) {
+   /*
+* The RX state machine is still in overflow state and
+* the RX FIFO write and read pointers seem to be
+* stuck.  Whack the chip over the head to get things
+* going again.
+*/
+   gem_init(ifp);
+   } else {
+   /*
+* We made some progress, but is not certain that the
+* overflow condition has been resolved.  Check again.
+*/
+   sc->sc_rx_fifo_wr_ptr = rx_fifo_wr_ptr;
+   sc->sc_rx_fifo_rd_ptr = rx_fifo_rd_ptr;
+   timeout_add_msec(>sc_rx_watchdog, 400);
+   }
}
 }
 



Re: Fix for vi(1) manpage Visual command

2018-02-03 Thread Ingo Schwarze
Hi Jason, hi Anthony,

Jason McIntyre wrote on Sat, Feb 03, 2018 at 02:52:26PM +:

> ok, but it does not currently say that. hence the original post:
>   [Vi]i[sual]
> that seems an obvious mistake, as noted in the original post.

That section of the manual is full of lies in multiple respects.
I never used split screens, so i never noticed in the past.

> so we could quick-fix that. but now we see that [Vv] itself is
> problematic, as also noted. i'd be inclined to say we should just list
> them as lowercase commands, and note separately what happens if the
> command begins uppercase.

I think the lowercase and uppercase versions are sufficiently different
to document them separately.

> there again, why does the EX COMMANDS section list commands that are
> "vi only"?

Historical misdesign.  Originally, Bill Joy wrote ex(1) for 1BSD in 1977.
Then he wrote vi(1) for 2BSD in 1979.  He completely botched the design
in so far as he kept the concept of "ex commands" and introduced an
additional, completely different concept of "vi commands".  Both
provide distinct, but significantly redundant functionality.

So in vi(1), you can append text to a line using the vi "a" command,
or you can append a new line using the vi "o" command, or you can
append a new line using the ex "a" command, which has completely
different syntax and semantics.

Given that concept of ex commands in vi, even though it originally
emerged as a backward compatibility concept, at some point, ex
commands appeared that can only be used in vi, but not in ex:  KISS!

That said, here is a patch to fix most of the lies in one go.

OK?
  Ingo

P.S.
Note that the concept of screens is not very well thought out.
For example, it interacts very erratically with the concept of
next and previous files from the command line.  I wouldn't mind
completely zapping the concept of split screens from vi(1), it
isn't required by POSIX.  Then again, i won't get myself killed
over the proposal to scrap the feature if anybody wants to keep it.


Index: vi.1
===
RCS file: /cvs/src/usr.bin/vi/docs/USD.doc/vi.man/vi.1,v
retrieving revision 1.74
diff -u -p -r1.74 vi.1
--- vi.122 Aug 2017 20:27:18 -  1.74
+++ vi.13 Feb 2018 15:54:16 -
@@ -1794,19 +1794,22 @@ Delete the lines from the file.
 Display buffers, screens or tags.
 .Pp
 .It Xo
-.Op Cm Ee Ns
-.Op Cm dit Ns
+.Cm e Ns Op Cm dit Ns | Ns Cm x Ns
 .Op Cm !\&
 .Op Ar +cmd
 .Op Ar file
 .Xc
+Edit a different file.
+.Pp
 .It Xo
-.Op Cm Ee Ns
-.Cm x Ns Op Cm !\&
+.Cm E Ns Op Cm dit Ns | Ns Cm x Ns
+.Op Cm !\&
 .Op Ar +cmd
 .Op Ar file
 .Xc
-Edit a different file.
+.Nm vi
+only.
+Split the screen and edit a different file.
 .Pp
 .It Xo
 .Cm exu Ns Op Cm sage
@@ -1822,14 +1825,15 @@ command.
 .Xc
 Display and optionally change the file name.
 .Pp
-.It Xo
-.Op Cm Ff Ns
-.Cm g
-.Op Ar name
-.Xc
+.It Cm fg Op Ar name
+.Nm vi
+only.
+Background the current screen and foreground the specified screen instead.
+.Pp
+.It Cm Fg Op Ar name
 .Nm vi
-mode only.
-Foreground the specified screen.
+only.
+Split the screen and foreground the specified screen.
 .Pp
 .It Xo
 .Op Ar range
@@ -1880,9 +1884,9 @@ Display the lines unambiguously.
 .Cm map Ns Op Cm !\&
 .Op Ar lhs rhs
 .Xc
-Define or display maps (for
 .Nm vi
-only).
+only.
+Define or display maps.
 .Pp
 .It Xo
 .Op Ar line
@@ -1912,12 +1916,20 @@ Write the abbreviations, editor options 
 .Ar file .
 .Pp
 .It Xo
-.Op Cm Nn Ns
-.Op Cm ext Ns
+.Cm n Ns Op Cm ext Ns
 .Op Cm !\&
 .Op Ar file ...
 .Xc
 Edit the next file from the argument list.
+.Pp
+.It Xo
+.Cm N Ns Op Cm ext Ns
+.Op Cm !\&
+.Op Ar file ...
+.Xc
+.Nm vi
+only.
+Split the screen and edit the next file from the argument list.
 .\" .Pp
 .\" .It Xo
 .\" .Op Ar line
@@ -1933,13 +1945,14 @@ Save the file in a form that can later b
 .Fl r
 option.
 .Pp
-.It Xo
-.Op Cm \ Ns
-.Cm rev Ns Op Cm ious Ns
-.Op Cm !\&
-.Xc
+.It Cm prev Ns Oo Cm ious Oc Ns Op Cm !\&
 Edit the previous file from the argument list.
 .Pp
+.It Cm Prev Ns Oo Cm ious Oc Ns Op Cm !\&
+.Nm vi
+only.
+Split the screen and edit the previous file from the argument list.
+.Pp
 .It Xo
 .Op Ar range
 .Cm p Ns Op Cm rint
@@ -1959,7 +1972,7 @@ Append buffer contents to the current li
 .Cm q Ns Op Cm uit Ns
 .Op Cm !\&
 .Xc
-End the editing session.
+End editing the file and close the current screen.
 .Pp
 .It Xo
 .Op Ar line
@@ -1980,10 +1993,10 @@ if it was previously saved.
 .It Xo
 .Cm res Ns Op Cm ize
 .Op Cm + Ns | Ns Cm - Ns
-.Ar size
+.Ar lines
 .Xc
 .Nm vi
-mode only.
+only.
 Grow or shrink the current screen.
 .Pp
 .It Xo
@@ -2132,14 +2145,22 @@ character is usually
 .Aq control-Z .
 .Pp
 .It Xo
-.Op Cm Tt Ns
-.Cm a Ns Op Cm g Ns
+.Cm ta Ns Op Cm g Ns
 .Op Cm !\&
 .Ar tagstring
 .Xc
 Edit the file containing the specified tag.
 .Pp
 .It Xo
+.Cm \ Ns Op Cm g Ns
+.Op Cm !\&
+.Ar tagstring
+.Xc
+.Nm vi
+only.
+Split the screen and edit the file containing the 

sleep(1): better error messages

2018-02-03 Thread Scott Cheloha
Hi,

This adds strtonum(3)-style error messages to sleep(1).  They're
more informative than the usage statement and they're idiomatic
for numeric input.

Exiting with EINVAL is really unusual.  It went into r1.9.  Unless
I'm missing something I think we can just exit with 1, which is
consistent with what other utilities do.

ok?

--
Scott Cheloha

Index: bin/sleep/sleep.c
===
RCS file: /cvs/src/bin/sleep/sleep.c,v
retrieving revision 1.25
diff -u -p -r1.25 sleep.c
--- bin/sleep/sleep.c   2 Feb 2018 16:46:37 -   1.25
+++ bin/sleep/sleep.c   2 Feb 2018 17:20:58 -
@@ -31,7 +31,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -73,10 +72,10 @@ main(int argc, char *argv[])
cp = *argv;
while ((*cp != '\0') && (*cp != '.')) {
if (!isdigit((unsigned char)*cp))
-   usage();
+   errx(1, "seconds is invalid: %s", *argv);
t = (secs * 10) + (*cp++ - '0');
if (t / 10 != secs) /* oflow */
-   return (EINVAL);
+   errx(1, "seconds is too large: %s", *argv);
secs = t;
}
 
@@ -87,7 +86,7 @@ main(int argc, char *argv[])
if (*cp == '\0')
break;
if (!isdigit((unsigned char)*cp))
-   usage();
+   errx(1, "seconds is invalid: %s", *argv);
nsecs += (*cp++ - '0') * i;
}
 
@@ -98,7 +97,7 @@ main(int argc, char *argv[])
 */
while (*cp != '\0') {
if (!isdigit((unsigned char)*cp++))
-   usage();
+   errx(1, "seconds is invalid: %s", *argv);
}
}
 



Re: Fix for vi(1) manpage Visual command

2018-02-03 Thread Jason McIntyre
On Sat, Feb 03, 2018 at 03:00:15AM -0700, Anthony J. Bentley wrote:
> Jason McIntyre writes:
> > On Fri, Feb 02, 2018 at 08:17:11PM -0700, Anthony J. Bentley wrote:
> > > trondd writes:
> > > > The manpage for vi(1) has a small error for the :Visual/:visual 
> > > > command. 
> >  The
> > > > 'V' can be capital or lowercase, followed by an 'i' and optionally 
> > > > 'sual'
> > . Bu
> > > > t
> > > > the manpage shows the command as [Vi]i[sual] instead of [Vv]i[sual].
> > > 
> > > This reveals a problem with the manpage. Everywhere else [] refers to
> > > optional parts of a command, but in the EX COMMANDS section, [] does
> > > double duty both to mark multiple valid characters as in glob(7) and to
> > > signify optional parts of the command.
> > > 
> > > Even in EX COMMANDS [] means "optional" only except for a few commands:
> > > [Ee][dit], [Ee]x, [Ff]g, [Nn][ext], [Pp]rev[ious], [Tt]a[g], and now
> > > [Vv]i[sual].
> > > 
> > > For readability I think these should be separate lines. Doubly so
> > > because the capitalized commands actually behave differently as
> > > explained in the reference documentation, and NOT explained in the
> > > manpage...
> > > 
> > > This does leave open the question of how the usage strings in ex_cmd.c
> > > should change, and whether the code there should be rearchitected so
> > > that, e.g., "edit" and "Edit" can have different usage strings.
> > > 
> > > -- 
> > > Anthony J. Bentley
> > > 
> >
> > morning.
> >
> > can you explain how uppercase and lowercase variants differ? it could be
> > that the simplest fix is not to list the uppercase variant (e.g. Visual)
> > and just explain in a separate paragraph those few commands that have
> > the variant.
> >
> > but that depends on what the difference is.
> 
> For each of them the capitalized variant opens the result in a new
> screen instead of the current screen. (Fg foregrounds to a new screen
> instead of swapping with the current screen, Tag opens the tag in a
> new screen, etc.) Thus the capitalized variants are only available in
> vi, not ex.
> 
> Of these, "visual" is different from the others in that in ex mode and
> vi mode they are actually separate commands. Hence the current
> documentation:
> 
>  [line] vi[sual] [type] [count] [flags]
>  ex mode only.  Enter vi.
> 
>  [Vv]i[sual][!] [+cmd] [file]
>  vi mode only.  Edit a new file.
> 

ok, but it does not currently say that. hence the original post:

[Vi]i[sual]

that seems an obvious mistake, as noted in the original post.

so we could quick-fix that. but now we see that [Vv] itself is
problematic, as also noted. i'd be inclined to say we should just list
them as lowercase commands, and note separately what happens if the
command begins uppercase.

there again, why does the EX COMMANDS section list commands that are
"vi only"?

jmc



Re: Fix for vi(1) manpage Visual command

2018-02-03 Thread Anthony J. Bentley
Jason McIntyre writes:
> On Fri, Feb 02, 2018 at 08:17:11PM -0700, Anthony J. Bentley wrote:
> > trondd writes:
> > > The manpage for vi(1) has a small error for the :Visual/:visual command. 
>  The
> > > 'V' can be capital or lowercase, followed by an 'i' and optionally 'sual'
> . Bu
> > > t
> > > the manpage shows the command as [Vi]i[sual] instead of [Vv]i[sual].
> > 
> > This reveals a problem with the manpage. Everywhere else [] refers to
> > optional parts of a command, but in the EX COMMANDS section, [] does
> > double duty both to mark multiple valid characters as in glob(7) and to
> > signify optional parts of the command.
> > 
> > Even in EX COMMANDS [] means "optional" only except for a few commands:
> > [Ee][dit], [Ee]x, [Ff]g, [Nn][ext], [Pp]rev[ious], [Tt]a[g], and now
> > [Vv]i[sual].
> > 
> > For readability I think these should be separate lines. Doubly so
> > because the capitalized commands actually behave differently as
> > explained in the reference documentation, and NOT explained in the
> > manpage...
> > 
> > This does leave open the question of how the usage strings in ex_cmd.c
> > should change, and whether the code there should be rearchitected so
> > that, e.g., "edit" and "Edit" can have different usage strings.
> > 
> > -- 
> > Anthony J. Bentley
> > 
>
> morning.
>
> can you explain how uppercase and lowercase variants differ? it could be
> that the simplest fix is not to list the uppercase variant (e.g. Visual)
> and just explain in a separate paragraph those few commands that have
> the variant.
>
> but that depends on what the difference is.

For each of them the capitalized variant opens the result in a new
screen instead of the current screen. (Fg foregrounds to a new screen
instead of swapping with the current screen, Tag opens the tag in a
new screen, etc.) Thus the capitalized variants are only available in
vi, not ex.

Of these, "visual" is different from the others in that in ex mode and
vi mode they are actually separate commands. Hence the current
documentation:

 [line] vi[sual] [type] [count] [flags]
 ex mode only.  Enter vi.

 [Vv]i[sual][!] [+cmd] [file]
 vi mode only.  Edit a new file.