cwm: modifier for AltGr
Hi,
the diff below adds support for using AltGr(the right Alt on
some keyboards) as 'm' modifier with bind-key and bind-mouse.
so ie. "bind-key Cm-Return terminal" is available for us w/AltGr
to match default binding. the lack of being able to bind w/AltGr
did hurt my cwm usage with other bindings too, so giving this to
us with such a broken keyboard layout feels only right, imo..:]
just a 'ping', in case i've sent this before.
-Artturi
diff --git a/app/cwm/conf.c b/app/cwm/conf.c
index 29b205364..83af9f7e2 100644
--- a/app/cwm/conf.c
+++ b/app/cwm/conf.c
@@ -201,6 +201,7 @@ static const struct {
{ 'M', Mod1Mask },
{ '4', Mod4Mask },
{ 'S', ShiftMask },
+ { 'm', Mod5Mask },
};
static const struct {
const char *key;
diff --git a/app/cwm/cwmrc.5 b/app/cwm/cwmrc.5
index fec9008f3..61d9809ab 100644
--- a/app/cwm/cwmrc.5
+++ b/app/cwm/cwmrc.5
@@ -84,6 +84,8 @@ Meta key.
Shift key.
.It Ic 4
Mod4 (windows) key.
+.It Ic m
+Mod5 (AltGr) key.
.El
.Pp
The
@@ -101,18 +103,10 @@ The modifier keys come first, followed by a
.Sq - ,
then the button number.
.Pp
-The following modifiers are recognised:
-.Pp
-.Bl -tag -width Ds -offset indent -compact
-.It Ic C
-Control key.
-.It Ic M
-Meta key.
-.It Ic S
-Shift key.
-.It Ic 4
-Mod4 (windows) key.
-.El
+The same modifiers are recognised as for
+.Ar key
+in
+.Nm bind-key .
.Pp
The following buttons are recognised:
.Pp
diff --git a/app/cwm/xevents.c b/app/cwm/xevents.c
index 9b504bc72..acfd94bc8 100644
--- a/app/cwm/xevents.c
+++ b/app/cwm/xevents.c
@@ -69,7 +69,7 @@ void (*xev_handlers[LASTEvent])(XEvent *) = {
};
static KeySym modkeys[] = { XK_Alt_L, XK_Alt_R, XK_Super_L, XK_Super_R,
- XK_Control_L, XK_Control_R };
+ XK_Control_L, XK_Control_R, XK_ISO_Level3_Shift };
static void
xev_handle_maprequest(XEvent *ee)
acme-client: prevent duplicate definitions of global variables
Every source file that includes extern.h will have its own definition
of these variables. Since many compilers allocate the variables with
.comm, they end up getting merged by the linker without error.
However, ISO C requires exactly one definition of objects with
external linkage.
gcc 10 will enable -fno-common by default, which will put
zero-initialized data in .bss, causing linking errors when multiple
definitions are present.
---
usr.sbin/acme-client/extern.h | 4 ++--
usr.sbin/acme-client/main.c | 5 +++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/usr.sbin/acme-client/extern.h b/usr.sbin/acme-client/extern.h
index e6b7af0d05b..f280b3e279e 100644
--- a/usr.sbin/acme-client/extern.h
+++ b/usr.sbin/acme-client/extern.h
@@ -277,12 +277,12 @@ char *json_fmt_signed(const char *, const
char *, const char *);
/*
* Should we print debugging messages?
*/
-int verbose;
+extern int verbose;
/*
* What component is the process within (COMP__MAX for none)?
*/
-enum comp proccomp;
+extern enum comp proccomp;
__END_DECLS
diff --git a/usr.sbin/acme-client/main.c b/usr.sbin/acme-client/main.c
index 7cbeeb7de03..1f59e6c755d 100644
--- a/usr.sbin/acme-client/main.c
+++ b/usr.sbin/acme-client/main.c
@@ -32,6 +32,9 @@
#define WWW_DIR "/var/www/acme"
#define CONF_FILE "/etc/acme-client.conf"
+int verbose;
+enum comp proccomp;
+
int
main(int argc, char *argv[])
{
@@ -46,8 +49,6 @@ main(int argc, char *argv[])
int c, rc, revocate = 0;
int popts = 0;
pid_t pids[COMP__MAX];
- extern intverbose;
- extern enum comp proccomp;
size_ti, altsz, ne;
struct acme_conf*conf = NULL;
--
2.25.0
rdomain.4: Use -rdomain to delete rdomain
Small nit but this properly reflects the "delete" semantic, much better than the implicit "reassign". ifconfig(8) also nicely mentions IPv4 and IPv6 addresses being purged in the `-rdomain' part, should the reader consult this manual afterwards. OK? Index: rdomain.4 === RCS file: /cvs/src/share/man/man4/rdomain.4,v retrieving revision 1.12 diff -u -p -r1.12 rdomain.4 --- rdomain.4 9 Sep 2018 10:13:21 - 1.12 +++ rdomain.4 1 Feb 2020 00:13:17 - @@ -125,7 +125,7 @@ match out on rdomain 4 to !$internal_net .Pp Delete rdomain 4 again: .Bd -literal -offset indent -# ifconfig em0 rdomain 0 +# ifconfig em0 -rdomain # ifconfig lo4 destroy .Ed .Sh SEE ALSO
Re: em(4) diff to test
On Thu, Jan 30, 2020 at 09:15:35AM +0100, Martin Pieuchot wrote:
> On 21/01/20(Tue) 12:31, Martin Pieuchot wrote:
> > On 20/01/20(Mon) 16:42, Martin Pieuchot wrote:
> > > Diff below is a refactoring of the actual em(4) code and defines that
> > > will allows me to present a shorter diff to interrupt multiple CPUs and
> > > make use of multiple queues.
> > >
> > > It contains the following items:
> > >
> > > - Abstract the allocation/freeing of TX/RX ring into em_dma_malloc().
> > > This will ease the introduction of multiple rings.
> > >
> > > - Split the 82576 variant out of 82575. The distinction is necessary
> > > when it comes to setting multiple queues.
> > >
I see in the diff where this is being done, but is the multi-queue part not
in this diff? Just looks like you separated things, and left it at that?
> > > - Change multiple TX/RX related macro to take an index argument
> > > corresponding to a ring. Currently only the index 0 and 1 are used.
> > >
> > > - Gather and print more stats counters
> > >
> > > - Switch to using a function, like FreeBSD, to translate 82542
> > > registers and get rid of a set of defines.
> > >
> > > It has been tested one the models below, I'd like to be sure there isn't
> > > any fallout with this part before continuing the effort.
> >
> > New diff that works with 82576, previous breakage reported by Hrvoje
> > Popovski. So far the following models have been tested, I'm looking for
> > more tests :o)
>
> So far this has been tested on the following, I'm confident enough and
> would like to move forward, ok?
>
> em2 at pci0 dev 4 function 0 "Intel 82540EM" rev 0x02: apic 9 int 14
> em1 at pci3 dev 1 function 0 "Intel 82545GM" rev 0x04: apic 4 int 0
> em0 at pci3 dev 1 function 0 "Intel 82546GB" rev 0x03: apic 3 int 0
> em3 at pci2 dev 0 function 0 "Intel 82571EB" rev 0x06: apic 0 int 16
> em0 at pci1 dev 0 function 0 "Intel 82572EI" rev 0x06: apic 0 int 16
> em2 at pci5 dev 0 function 0 "Intel 82573E" rev 0x03: msi
> em3 at pci6 dev 0 function 0 "Intel 82573L" rev 0x00: msi
> em0 at pci3 dev 0 function 0 "Intel 82574L" rev 0x00: msi
> em0 at pci0 dev 2 function 0 "Intel 82575GB" rev 0x02: msi
> em0 at pci1 dev 0 function 0 "Intel 82576" rev 0x01: msi
> em0 at pci0 dev 25 function 0 "Intel 82577LM" rev 0x06: msi
> em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x04: msi
> em0 at pci1 dev 0 function 0 "Intel 82583V" rev 0x00: msi
> em0 at pci1 dev 0 function 0 "Intel I210" rev 0x03: msi
> em0 at pci1 dev 0 function 0 "Intel I211" rev 0x03: msi
> em0 at pci0 dev 25 function 0 "Intel I217-LM" rev 0x04: msi
> em0 at pci0 dev 25 function 0 "Intel I218-V" rev 0x03: msi
> em0 at pci0 dev 25 function 0 Intel I218-LM rev 0x04: msi
You can add this to the "works as intended" list (t490):
em0 at pci0 dev 31 function 6 "Intel I219-LM" rev 0x30: msi
Diff reads ok to me. So ok mlarkin@ if you are still looking for oks and didn't
commit it already.
-ml
> em0 at pci0 dev 31 function 6 "Intel I219-V" rev 0x21: msi
> em0 at pci7 dev 0 function 0 "Intel I350" rev 0x01: msi
>
>
> Index: pci/if_em.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_em.c,v
> retrieving revision 1.343
> diff -u -p -r1.343 if_em.c
> --- pci/if_em.c 20 Jan 2020 23:45:02 - 1.343
> +++ pci/if_em.c 21 Jan 2020 11:27:14 -
> @@ -260,6 +260,7 @@ void em_disable_aspm(struct em_softc *);
> void em_txeof(struct em_softc *);
> int em_allocate_receive_structures(struct em_softc *);
> int em_allocate_transmit_structures(struct em_softc *);
> +int em_allocate_desc_rings(struct em_softc *);
> int em_rxfill(struct em_softc *);
> void em_rxrefill(void *);
> int em_rxeof(struct em_softc *);
> @@ -344,11 +345,6 @@ em_defer_attach(struct device *self)
>
> em_free_pci_resources(sc);
>
> - sc->sc_rx_desc_ring = NULL;
> - em_dma_free(sc, &sc->sc_rx_dma);
> - sc->sc_tx_desc_ring = NULL;
> - em_dma_free(sc, &sc->sc_tx_dma);
> -
> return;
> }
>
> @@ -464,6 +460,7 @@ em_attach(struct device *parent, struct
> case em_82572:
> case em_82574:
> case em_82575:
> + case em_82576:
> case em_82580:
> case em_i210:
> case em_i350:
> @@ -494,23 +491,11 @@ em_attach(struct device *parent, struct
> sc->hw.min_frame_size =
> ETHER_MIN_LEN + ETHER_CRC_LEN;
>
> - /* Allocate Transmit Descriptor ring */
> - if (em_dma_malloc(sc, sc->sc_tx_slots * sizeof(struct em_tx_desc),
> - &sc->sc_tx_dma) != 0) {
> - printf("%s: Unable to allocate tx_desc memory\n",
> -DEVNAME(sc));
> - goto err_tx_desc;
> - }
> - sc->sc_tx_desc_ring
Re: refer to pointers as non-null
Hi Ted, Ted Unangst wrote on Fri, Jan 31, 2020 at 05:33:05AM -0500: > Noticed this in wait.2, though I imagine other occurences abound. > > I believe non-null is clearer when refering to a pointer than non-zero, which > is a bit 80s, and less likely to be mistaken for the value pointed to. This > same page also refers to non-zero values, fwiw. Makes sense to. In general, we use .Dv NULL to refer to null pointers, so i'd prefer area, if .Pf non- Dv NULL , is filled in with termination information about the or area, unless it is .Dv NULL , is filled in with termination information about the Unless .Fa rusage is .Dv NULL , a summary of the resources used by the terminated But i don't object to your version either if you strongly resent using .Dv NULL . Yours, Ingo > Index: wait.2 > === > RCS file: /home/cvs/src/lib/libc/sys/wait.2,v > retrieving revision 1.30 > diff -u -p -r1.30 wait.2 > --- wait.21 May 2017 00:08:31 - 1.30 > +++ wait.231 Jan 2020 10:28:42 - > @@ -70,7 +70,7 @@ On return from a successful > .Fn wait > call, the > .Fa status > -area, if non-zero, is filled in with termination information about the > +area, if non-null, is filled in with termination information about the > process that exited (see below). > .Pp > The > @@ -137,7 +137,7 @@ signal also have their status reported. > .Pp > If > .Fa rusage > -is non-zero, a summary of the resources used by the terminated > +is non-null, a summary of the resources used by the terminated > process and all its > children is returned (this information is currently not available > for stopped processes).
Re: [patch] /bin/cp: reduce scope variable
Hi, ngc...@gmail.com wrote on Fri, Jan 31, 2020 at 10:14:52PM +0900: > Reduce scope of a few variables. No, this contradicts OpenBSD coding style. We want local variables declared up front in functions such that you can see at one glance which variables exist. > While here, remove an extraneous space. While avoiding trailing whitespace is good, it's not worth a commit (nor sending patches around). Yours, Ingo
[patch] /bin/cp: reduce scope variable
Hi,
Reduce scope of a few variables. While here, remove an extraneous
space.
Regards,
diff --git a/bin/cp/utils.c b/bin/cp/utils.c
index a2f480c3393..3e2f94e4fa4 100644
--- a/bin/cp/utils.c
+++ b/bin/cp/utils.c
@@ -55,10 +55,7 @@ copy_file(FTSENT *entp, int exists)
static char *buf;
static char *zeroes;
struct stat to_stat, *fs;
- int from_fd, rcount, rval, to_fd, wcount;
-#ifdef VM_AND_BUFFER_CACHE_SYNCHRONIZED
- char *p;
-#endif
+ int from_fd, rval, to_fd;
if (!buf) {
buf = malloc(MAXBSIZE);
@@ -96,7 +93,7 @@ copy_file(FTSENT *entp, int exists)
if (!copy_overwrite()) {
(void)close(from_fd);
return 2;
- }
+ }
to_fd = open(to.p_path, O_WRONLY | O_TRUNC, 0);
} else
to_fd = open(to.p_path, O_WRONLY | O_TRUNC | O_CREAT,
@@ -118,6 +115,7 @@ copy_file(FTSENT *entp, int exists)
#ifdef VM_AND_BUFFER_CACHE_SYNCHRONIZED
/* XXX broken for 0-size mmap */
if (fs->st_size <= 8 * 1048576) {
+ char *p;
if ((p = mmap(NULL, (size_t)fs->st_size, PROT_READ,
MAP_FILE|MAP_SHARED, from_fd, (off_t)0)) ==
MAP_FAILED) {
warn("mmap: %s", entp->fts_path);
@@ -138,6 +136,7 @@ copy_file(FTSENT *entp, int exists)
#endif
{
int skipholes = 0;
+ int rcount, wcount;
struct stat tosb;
if (!fstat(to_fd, &tosb) && S_ISREG(tosb.st_mode))
skipholes = 1;
@@ -255,9 +254,8 @@ copy_special(struct stat *from_stat, int exists)
int
copy_overwrite(void)
{
- int ch, checkch;
-
if (iflag) {
+ int ch, checkch;
(void)fprintf(stderr, "overwrite %s? ", to.p_path);
checkch = ch = getchar();
while (ch != '\n' && ch != EOF)
--
Jerome Pinot
Re: refer to pointers as non-null
On Fri, Jan 31, 2020 at 05:33:05AM -0500, Ted Unangst wrote: > Noticed this in wait.2, though I imagine other occurences abound. > > I believe non-null is clearer when refering to a pointer than non-zero, which > is a bit 80s, and less likely to be mistaken for the value pointed to. This > same page also refers to non-zero values, fwiw. Agreed, OK kn
Re: refer to pointers as non-null
On Fri, Jan 31, 2020 at 05:33:05AM -0500, Ted Unangst wrote: > Noticed this in wait.2, though I imagine other occurences abound. > > I believe non-null is clearer when refering to a pointer than non-zero, which > is a bit 80s, and less likely to be mistaken for the value pointed to. This > same page also refers to non-zero values, fwiw. > > > Index: wait.2 > === > RCS file: /home/cvs/src/lib/libc/sys/wait.2,v > retrieving revision 1.30 > diff -u -p -r1.30 wait.2 > --- wait.21 May 2017 00:08:31 - 1.30 > +++ wait.231 Jan 2020 10:28:42 - > @@ -70,7 +70,7 @@ On return from a successful > .Fn wait > call, the > .Fa status > -area, if non-zero, is filled in with termination information about the > +area, if non-null, is filled in with termination information about the > process that exited (see below). > .Pp > The > @@ -137,7 +137,7 @@ signal also have their status reported. > .Pp > If > .Fa rusage > -is non-zero, a summary of the resources used by the terminated > +is non-null, a summary of the resources used by the terminated > process and all its > children is returned (this information is currently not available > for stopped processes). diff looks right, things got confused maybe because that wait(2) returns pid_t, but it's refering to status pointer.
refer to pointers as non-null
Noticed this in wait.2, though I imagine other occurences abound. I believe non-null is clearer when refering to a pointer than non-zero, which is a bit 80s, and less likely to be mistaken for the value pointed to. This same page also refers to non-zero values, fwiw. Index: wait.2 === RCS file: /home/cvs/src/lib/libc/sys/wait.2,v retrieving revision 1.30 diff -u -p -r1.30 wait.2 --- wait.2 1 May 2017 00:08:31 - 1.30 +++ wait.2 31 Jan 2020 10:28:42 - @@ -70,7 +70,7 @@ On return from a successful .Fn wait call, the .Fa status -area, if non-zero, is filled in with termination information about the +area, if non-null, is filled in with termination information about the process that exited (see below). .Pp The @@ -137,7 +137,7 @@ signal also have their status reported. .Pp If .Fa rusage -is non-zero, a summary of the resources used by the terminated +is non-null, a summary of the resources used by the terminated process and all its children is returned (this information is currently not available for stopped processes).
