Re: wscons: precision scrolling
On 3/13/19 4:49 PM, Martin Pieuchot wrote:
> On 13/03/19(Wed) 00:41, Ulf Brosziewski wrote:
>> The standard method of scrolling in X is tailored to mouse wheels and
>> proceeds in coarse steps. Wheel events are mapped to button events, and on
>> receiving such an event, an application moves the view of its data by some
>> fixed distance - usually the height of a line of text, or of a couple of
>> lines.
>>
>> Version 2.1 of the X Input Protocol has introduced a more precise
>> alternative. It defines additional types of motion events. In essence,
>> their values represent fractions of a complete scroll unit, and newer
>> applications may move their views by distances that are proportional to the
>> event values. For applications that don't support this, X generates the
>> standard button events whenever the values add up to the complete unit.
>>
>> synaptics(4) supports the newer method since long.
>>
>> The diffs below add the feature to ws and wstpad. The kernel part defines
>> two new event types in wsconsio.h, and it adapts the scrolling functions of
>> the touchpad input driver. The xenocara part adds the new "axes" and event
>> handlers to ws.
>>
>> There is a little twist to the implementation. While synaptics(4)
>> initializes the scroll axes with the scroll distance in device units, the
>> constant 4096 is used in the new ws code, and event values represent the
>> fraction (motion_delta / scroll_unit) in [*.12] fixed-point format. That
>> way, no queries for the device- and configuration-dependent scroll unit
>> are necessary.
>>
>> The X Input Protocol calls the method "smooth scrolling", but it seems
>> that nowadays, this term is used exclusively for the rendering technique
>> that displays a little animation when the document position changes, so
>> "precision scrolling" might be a better choice.
>>
>> Tests, comments, and OKs would be welcome.
>
> I like it. Implementation is nice. I find the *_EV defines confusing.
> Why not use the WSCONS_* defines directly, it would make easier for the
> reader to find which code generates which event in a single grep. But
> that's not new ;)
Some of the WSCONS_EVENT_* names are very long, and too many capital
letters in a C function can make me nervous ;-) Initially, I thought
that more *_EV definitions would become macros.
>
> Do you know if it would make sense to get rid of the standard scrolling
> method? Could we generate such events for all input devices? Does
> other X drivers do that already or plan to do it?
>
I wouldn't know of any obstacle, at least, but I haven't checked that.
Whether the kernel sends a DELTA_Z event or a VSCROLL event with a
multiple of the base unit shouldn't make a difference in the outcome.
It might even be possible to apply an acceleration scheme to wheel
input (I believe Mac OS does that), but I have no idea whether that
would be useful. Anyway, first we should make sure that the mechanism
is sound; I'm a bit puzzled by Joshua's report and hope there will be
more tests.
>> Index: dev/wscons/wsconsio.h
>> ===
>> RCS file: /cvs/src/sys/dev/wscons/wsconsio.h,v
>> retrieving revision 1.90
>> diff -u -p -r1.90 wsconsio.h
>> --- dev/wscons/wsconsio.h10 Nov 2018 14:27:51 - 1.90
>> +++ dev/wscons/wsconsio.h12 Mar 2019 21:55:11 -
>> @@ -112,6 +112,12 @@ struct wscons_event {
>> #define WSCONS_EVENT_TOUCH_RESET25 /* (no value) */
>>
>> /*
>> + * Precision Scrolling
>> + */
>> +#define WSCONS_EVENT_HSCROLL26 /* dx * 4096 /
>> scroll_unit */
>> +#define WSCONS_EVENT_VSCROLL27 /* dy * 4096 /
>> scroll_unit */
>> +
>> +/*
>> * Keyboard ioctls (0 - 31)
>> */
>>
>> Index: dev/wscons/wsmouse.c
>> ===
>> RCS file: /cvs/src/sys/dev/wscons/wsmouse.c,v
>> retrieving revision 1.51
>> diff -u -p -r1.51 wsmouse.c
>> --- dev/wscons/wsmouse.c 19 Feb 2019 07:01:02 - 1.51
>> +++ dev/wscons/wsmouse.c 12 Mar 2019 21:55:11 -
>> @@ -1034,10 +1034,18 @@ wsmouse_motion_sync(struct wsmouseinput
>> wsmouse_evq_put(evq, DELTA_X_EV(input), dx);
>> if (dy)
>> wsmouse_evq_put(evq, DELTA_Y_EV(input), dy);
>> -if (motion->dz)
>> -wsmouse_evq_put(evq, DELTA_Z_EV, motion->dz);
>> -if (motion->dw)
>> -wsmouse_evq_put(evq, DELTA_W_EV, motion->dw);
>> +if (motion->dz) {
>> +if (IS_TOUCHPAD(input))
>> +wsmouse_evq_put(evq, VSCROLL_EV, motion->dz);
>> +else
>> +wsmouse_evq_put(evq, DELTA_Z_EV, motion->dz);
>> +}
>> +if (motion->dw) {
>> +if (IS_TOUCHPAD(input))
>> +wsmouse_evq_put(evq, HSCROLL_EV, motion->dw);
>> +
Re: wscons: precision scrolling
On 3/13/19 5:27 PM, joshua stein wrote: > On Wed, 13 Mar 2019 at 00:41:12 +0100, Ulf Brosziewski wrote: >> The standard method of scrolling in X is tailored to mouse wheels and >> proceeds in coarse steps. Wheel events are mapped to button events, and on >> receiving such an event, an application moves the view of its data by some >> fixed distance - usually the height of a line of text, or of a couple of >> lines. >> >> Version 2.1 of the X Input Protocol has introduced a more precise >> alternative. It defines additional types of motion events. In essence, >> their values represent fractions of a complete scroll unit, and newer >> applications may move their views by distances that are proportional to the >> event values. For applications that don't support this, X generates the >> standard button events whenever the values add up to the complete unit. >> >> synaptics(4) supports the newer method since long. >> >> The diffs below add the feature to ws and wstpad. The kernel part defines >> two new event types in wsconsio.h, and it adapts the scrolling functions of >> the touchpad input driver. The xenocara part adds the new "axes" and event >> handlers to ws. >> >> There is a little twist to the implementation. While synaptics(4) >> initializes the scroll axes with the scroll distance in device units, the >> constant 4096 is used in the new ws code, and event values represent the >> fraction (motion_delta / scroll_unit) in [*.12] fixed-point format. That >> way, no queries for the device- and configuration-dependent scroll unit >> are necessary. >> >> The X Input Protocol calls the method "smooth scrolling", but it seems >> that nowadays, this term is used exclusively for the rendering technique >> that displays a little animation when the document position changes, so >> "precision scrolling" might be a better choice. >> >> Tests, comments, and OKs would be welcome. > > Well done! It works on my touchpad and retains the old "chunky" > style scrolling from the mouse wheel on my external mouse. > > My only quibble is that this new style scrolling seems much too fast > by default with the default X and wscons mouse acceleration > settings. > > Much too fast? I'm a bit surprised. In my tests, the new method was generally somewhat slower than the old one (and I haven't changed the "scroll units"). How did you test it? Which hardware and which applications did you use?
Re: 63 bit certificate ID is libressl affected?
Hi Tom, Tom Smyth wrote on Wed, Mar 13, 2019 at 08:32:20PM +: > Just saw the following article and i was wondering if libressl > Might be affected by the bug also > Top bit being set to 0 always making an effective 63 bits rather than 64 > bits If i understand the article you quote correctly, is is about a minor bug in some CA softwares (i.e. softwares used to operate certificate authorities). As far as i am aware, LibreSSL does *not* include any software that can be used to operate a certificate authority. The "openssl ca" subcommand of openssl(1) definitely does not count. The openssl(1) utility is a *testing tool* and must not be used for any kind of production purposes. So i don't see how LibreSSL could possibly be affected. If you still think it might be, please consider stating more precisely which part of LibreSSL (i.e. which library function) you fear might be broken in precisely which way. > https://www.theregister.co.uk/2019/03/13/tls_cert_revoke_ejbca_config/ My impression is that the most important sentence from that article is the following: While the serial number security issue is largely theoretical - 63 bits leaves plenty of space to fend off collision attacks, even if it's not compliant with the spec [...] That means this is unlikely to be a security issue in the first place but looks more like a minor bug where some software is gratutiosly violating a specification. Sure, specifications should not be set aside without a good reason, and certainly not accidentally, and bugs ought to be fixed, but i fail to see any indication that this bug might be more important than other run-of-the-mill bugs. Please take this with a grain of salt: while i did occasionally work on LibreSSL documentation in the past, my knowledge and experience in matters of cryptography and PKI is very limited. But i thought quick feedback might help to discourage people from panicking. Also, if you want to continue this discussion, i suggest moving to misc@. You didn't include a patch! ;-) Yours, Ingo
63 bit certificate ID is libressl affected?
Hello all, Just saw the flllowing article and i was wondering if libressl Might be affected by the bug also Top bit being set to 0 always making an effective 63 bits rather than 64 bits https://www.theregister.co.uk/2019/03/13/tls_cert_revoke_ejbca_config/ Hope this helps Tom -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 The information contained in this E-mail is intended only for the confidential use of the named recipient. If the reader of this message is not the intended recipient or the person responsible for delivering it to the recipient, you are hereby notified that you have received this communication in error and that any review, dissemination or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately by telephone at the number above and erase the message You are requested to carry out your own virus check before opening any attachment.
Re: Option for alternative escape character with cu(1)
On Wed, Mar 13, 2019 at 07:47:08AM -0600, Todd C. Miller wrote:
> On Wed, 13 Mar 2019 14:35:06 +0200, Artturi Alm wrote:
>
> > i don't have issues with tilde when using locally, but i mostly ssh to
> > reach cu, and too many times i've forgotten to configure ssh/use -e,
> > with this cu(1) becomes safer/easier to use for us with non-english
> > keyboard.
> > ~tilde is certainly annoying when it's three key presses alone,
> > and then you mostly get only one shot at trying..
>
> The cu from Taylor UUCP uses -E for this (it uses -e to specify
> even parity). If we are going to support this, I think it makes
> sense to be as compatible as possible with other systems.
>
> - todd
Sure, makes sense to me, thanks.
On Wed, Mar 13, 2019 at 02:36:03PM +, Nicholas Marriott wrote:
> Why only % rather than have -e take an argument like ssh?
>
I'm lazy, and wanted to avoid breaking the "line" in usage().. :]
i had also missed escaping the alternative escape character in
do_command(), diff with these things fixed below.
-Artturi
diff --git a/usr.bin/cu/command.c b/usr.bin/cu/command.c
index c07fe73aeca..e225fb544be 100644
--- a/usr.bin/cu/command.c
+++ b/usr.bin/cu/command.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include "cu.h"
@@ -223,6 +224,8 @@ start_record(void)
void
do_command(char c)
{
+ char esc[4 + 1];
+
if (restricted && strchr("CRX$>", c) != NULL) {
cu_warnx("~%c command is not allowed in restricted mode", c);
return;
@@ -266,20 +269,26 @@ do_command(char c)
sleep(1);
ioctl(line_fd, TIOCCBRK, NULL);
break;
- case '~':
- bufferevent_write(line_ev, "~", 1);
+ default:
+ if (c != escape_char)
+ break;
+ esc[0] = escape_char;
+ esc[1] = '\0';
+ bufferevent_write(line_ev, esc, 1);
break;
case '?':
+ vis(esc, escape_char, VIS_WHITE | VIS_NOSLASH, 0);
printf("\r\n"
- "~# send break\r\n"
- "~$ pipe local command to remote host\r\n"
- "~> send file to remote host\r\n"
- "~C connect program to remote host\r\n"
- "~D de-assert DTR line briefly\r\n"
- "~R start recording to file\r\n"
- "~S set speed\r\n"
- "~X send file with XMODEM\r\n"
- "~? get this summary\r\n"
+ "%s# send break\r\n"
+ "%s$ pipe local command to remote host\r\n"
+ "%s> send file to remote host\r\n"
+ "%sC connect program to remote host\r\n"
+ "%sD de-assert DTR line briefly\r\n"
+ "%sR start recording to file\r\n"
+ "%sS set speed\r\n"
+ "%sX send file with XMODEM\r\n"
+ "%s? get this summary\r\n",
+ esc, esc, esc, esc, esc, esc, esc, esc, esc
);
break;
}
diff --git a/usr.bin/cu/cu.1 b/usr.bin/cu/cu.1
index 104a6ea7893..d52e0b94e5f 100644
--- a/usr.bin/cu/cu.1
+++ b/usr.bin/cu/cu.1
@@ -38,6 +38,7 @@
.Op Fl dr
.Op Fl l Ar line
.Op Fl s Ar speed | Fl Ar speed
+.Op Fl E Ar escape_char
.Nm
.Op Ar host
.Sh DESCRIPTION
@@ -92,6 +93,8 @@ and
.It Fl s Ar speed | Fl Ar speed
Set the speed of the connection.
The default is 9600.
+.It Fl E Ar escape_char
+Specify a escape character to use instead of the default tilde.
.El
.Pp
If
diff --git a/usr.bin/cu/cu.c b/usr.bin/cu/cu.c
index 03a2df4181f..f269f4a74f3 100644
--- a/usr.bin/cu/cu.c
+++ b/usr.bin/cu/cu.c
@@ -41,6 +41,7 @@ FILE *record_file;
struct termios saved_tio;
struct bufferevent *input_ev;
struct bufferevent *output_ev;
+int escape_char = -1;
int is_direct = -1;
int restricted = 0;
const char *line_path = NULL;
@@ -53,7 +54,7 @@ struct event sighup_ev;
enum {
STATE_NONE,
STATE_NEWLINE,
- STATE_TILDE
+ STATE_ESCAPE
} last_state = STATE_NEWLINE;
__dead voidusage(void);
@@ -67,8 +68,8 @@ void try_remote(const char *, const char *, const
char *);
__dead void
usage(void)
{
- fprintf(stderr, "usage: %s [-dr] [-l line] [-s speed | -speed]\n",
- __progname);
+ fprintf(stderr, "usage: %s [-dr] [-l line] [-s speed | -speed]"
+ " [-E escape_char]\n", __progname);
fprintf(stderr, " %s [host]\n", __progname);
exit(1);
}
@@ -101,7 +102,7 @@ main(int argc, char **argv)
errx(1, "speed asprintf");
}
- while ((opt = getopt(argc, argv, "drl:s:")) != -1) {
+ while ((opt = getopt(argc,
npppd(8): remove dead code
There is some code that dates back to 2010 and cannot compile if -DUSE_NPPPD_ARP. So I guess we can safely remove. Denis Index: npppd/npppd.c === RCS file: /cvs/src/usr.sbin/npppd/npppd/npppd.c,v retrieving revision 1.49 diff -u -p -r1.49 npppd.c --- npppd/npppd.c 30 Dec 2018 23:09:58 - 1.49 +++ npppd/npppd.c 13 Mar 2019 18:22:52 - @@ -69,10 +69,6 @@ #include "l2tp_local.h"/* XXX sa_cookie */ -#ifdef USE_NPPPD_ARP -#include "npppd_arp.h" -#endif - #ifdef USE_NPPPD_PIPEX #ifdef USE_NPPPD_PPPOE #include "pppoe_local.h" @@ -389,11 +385,6 @@ npppd_init(npppd *_this, const char *con fprintf(pidfp, "%u\n", _this->pid); fclose(pidfp); pidfp = NULL; -#ifdef USE_NPPPD_ARP - arp_set_strictintfnetwork(npppd_config_str_equali(_this, "arpd.strictintfnetwork", "true", ARPD_STRICTINTFNETWORK_DEFAULT)); - if (npppd_config_str_equali(_this, "arpd.enabled", "true", ARPD_DEFAULT) == 1) - arp_sock_init(); -#endif if ((status = npppd_modules_reload(_this)) != 0) return status; @@ -433,9 +424,6 @@ npppd_stop(npppd *_this) #ifdef USE_NPPPD_PPPOE pppoed_stop(&_this->pppoed); #endif -#ifdef USE_NPPPD_ARP -arp_sock_fini(); -#endif close(_this->ctl_sock.cs_fd); control_cleanup(&_this->ctl_sock); @@ -1936,13 +1924,6 @@ npppd_reload0(npppd *_this) int i; npppd_reload_config(_this); -#ifdef USE_NPPPD_ARP - arp_set_strictintfnetwork(npppd_config_str_equali(_this, "arpd.strictintfnetwork", "true", ARPD_STRICTINTFNETWORK_DEFAULT)); - if (npppd_config_str_equali(_this, "arpd.enabled", "true", ARPD_DEFAULT) == 1) - arp_sock_init(); - else - arp_sock_fini(); -#endif npppd_modules_reload(_this); npppd_ifaces_load_config(_this); npppd_update_pool_reference(_this);
less(1) UTF-8 cleanup: pappend()
Hi Todd,
Todd C. Miller wrote on Tue, Mar 12, 2019 at 09:14:43AM -0600:
> This looks like an improvement to me. OK millert@
Thanks for checking the do_append() patch, i committed it.
The next step is to clean up pappend(), which reads one byte of
a multibyte character per call and outputs the multibyte character
once it is complete. As long as the character is not yet complete,
the bytes are cached in the static buffer mbc_buf; the current
number of bytes already cached is mbc_buf_index, the byte position
of the start byte is mbc_pos.
The static variable mbc_buf_len stores the number of bytes expected
in the current character according to the start byte. When using
standard functions, this information is irrelevant, so i'm deleting
the variable, which simplifies global state.
The proper tool to distinguish valid, incomplete, and invalid
multibyte characters is mbrtowc(3). The simpler and generally more
recommended function mbtowc(3) which i used in earlier patches
cannot be used for this purpose because it does not distinguish
incomplete from invalid sequences. The single call to mbrtowc(3)
replaces one call of each of the following functions and macros
that we want to get rid of: IS_ASCII_OCTET(), IS_UTF8_LEAD(),
utf_len(), IS_UTF8_TRAIL(), and is_utf8_well_formed().
Some additional observations:
* A goto is replaced by a proper loop.
* In case of an invalid start byte, calling store_prchar() directly
is simpler than the detour via flush_mbc_buf().
* When the line overflows, rather than first storing the number of
bytes to back up in mbc_buf_index, then moving it to r at the
end of the function, it is simpler to store it into r right away.
* The patch replaces 11 lines of code with 10 lines of comments. :-)
Tests done:
* ASCII CR bytes are correctly shown encoded as ^M after ASCII bytes,
after valid UTF-8 characters, and when interrupting incomplete
UTF-8 characters.
* Incomplete UTF-8 characters are correctly shown in encoded form
when interrupted by ASCII characters, by valid UTF-8 characters,
or by invalid bytes.
* Width 2 Unicode characters correctly wrap to the next line when
their left half would be in the last column of the screen.
* Encoded representations of invalid bytes and of valid, but
non-printable UTF-8 characters correctly wrap to the next line
in their entirety unless all their output bytes still fit on the
current screen output line.
* All tests were also performed with LC_CTYPE=C.
OK?
Ingo
Index: line.c
===
RCS file: /cvs/src/usr.bin/less/line.c,v
retrieving revision 1.28
diff -u -p -r1.28 line.c
--- line.c 13 Mar 2019 11:22:56 - 1.28
+++ line.c 13 Mar 2019 16:07:35 -
@@ -64,7 +64,6 @@ extern off_t start_attnpos;
extern off_t end_attnpos;
static char mbc_buf[MAX_UTF_CHAR_LEN];
-static int mbc_buf_len = 0;
static int mbc_buf_index = 0;
static off_t mbc_pos;
@@ -129,7 +128,6 @@ prewind(void)
column = 0;
cshift = 0;
overstrike = 0;
- mbc_buf_len = 0;
is_null_line = 0;
pendc = '\0';
lmargin = 0;
@@ -683,6 +681,9 @@ flush_mbc_buf(off_t pos)
int
pappend(char c, off_t pos)
{
+ mbstate_t mbs;
+ size_t sz;
+ wchar_t ch;
int r;
if (pendc) {
@@ -696,13 +697,12 @@ pappend(char c, off_t pos)
}
if (c == '\r' && bs_mode == BS_SPECIAL) {
- if (mbc_buf_len > 0) /* utf_mode must be on. */ {
+ if (mbc_buf_index > 0) /* utf_mode must be on. */ {
/* Flush incomplete (truncated) sequence. */
r = flush_mbc_buf(mbc_pos);
- mbc_buf_index = r + 1;
- mbc_buf_len = 0;
+ mbc_buf_index = 0;
if (r)
- return (mbc_buf_index);
+ return (r + 1);
}
/*
@@ -718,40 +718,43 @@ pappend(char c, off_t pos)
if (!utf_mode) {
r = do_append((LWCHAR) c, NULL, pos);
} else {
- /* Perform strict validation in all possible cases. */
- if (mbc_buf_len == 0) {
-retry:
- mbc_buf_index = 1;
- *mbc_buf = c;
- if (IS_ASCII_OCTET(c)) {
- r = do_append((LWCHAR) c, NULL, pos);
- } else if (IS_UTF8_LEAD(c)) {
- mbc_buf_len = utf_len(c);
+ for (;;) {
+ if (mbc_buf_index == 0)
mbc_pos = pos;
- return (0);
- } else {
- /* UTF8_INVALID or stray UTF8_TRAIL */
- r = flush_mbc_buf(pos);
- }
- } else if
Re: wscons: precision scrolling
On Wed, 13 Mar 2019 at 00:41:12 +0100, Ulf Brosziewski wrote: > The standard method of scrolling in X is tailored to mouse wheels and > proceeds in coarse steps. Wheel events are mapped to button events, and on > receiving such an event, an application moves the view of its data by some > fixed distance - usually the height of a line of text, or of a couple of > lines. > > Version 2.1 of the X Input Protocol has introduced a more precise > alternative. It defines additional types of motion events. In essence, > their values represent fractions of a complete scroll unit, and newer > applications may move their views by distances that are proportional to the > event values. For applications that don't support this, X generates the > standard button events whenever the values add up to the complete unit. > > synaptics(4) supports the newer method since long. > > The diffs below add the feature to ws and wstpad. The kernel part defines > two new event types in wsconsio.h, and it adapts the scrolling functions of > the touchpad input driver. The xenocara part adds the new "axes" and event > handlers to ws. > > There is a little twist to the implementation. While synaptics(4) > initializes the scroll axes with the scroll distance in device units, the > constant 4096 is used in the new ws code, and event values represent the > fraction (motion_delta / scroll_unit) in [*.12] fixed-point format. That > way, no queries for the device- and configuration-dependent scroll unit > are necessary. > > The X Input Protocol calls the method "smooth scrolling", but it seems > that nowadays, this term is used exclusively for the rendering technique > that displays a little animation when the document position changes, so > "precision scrolling" might be a better choice. > > Tests, comments, and OKs would be welcome. Well done! It works on my touchpad and retains the old "chunky" style scrolling from the mouse wheel on my external mouse. My only quibble is that this new style scrolling seems much too fast by default with the default X and wscons mouse acceleration settings.
Re: wscons: precision scrolling
On 13/03/19(Wed) 00:41, Ulf Brosziewski wrote:
> The standard method of scrolling in X is tailored to mouse wheels and
> proceeds in coarse steps. Wheel events are mapped to button events, and on
> receiving such an event, an application moves the view of its data by some
> fixed distance - usually the height of a line of text, or of a couple of
> lines.
>
> Version 2.1 of the X Input Protocol has introduced a more precise
> alternative. It defines additional types of motion events. In essence,
> their values represent fractions of a complete scroll unit, and newer
> applications may move their views by distances that are proportional to the
> event values. For applications that don't support this, X generates the
> standard button events whenever the values add up to the complete unit.
>
> synaptics(4) supports the newer method since long.
>
> The diffs below add the feature to ws and wstpad. The kernel part defines
> two new event types in wsconsio.h, and it adapts the scrolling functions of
> the touchpad input driver. The xenocara part adds the new "axes" and event
> handlers to ws.
>
> There is a little twist to the implementation. While synaptics(4)
> initializes the scroll axes with the scroll distance in device units, the
> constant 4096 is used in the new ws code, and event values represent the
> fraction (motion_delta / scroll_unit) in [*.12] fixed-point format. That
> way, no queries for the device- and configuration-dependent scroll unit
> are necessary.
>
> The X Input Protocol calls the method "smooth scrolling", but it seems
> that nowadays, this term is used exclusively for the rendering technique
> that displays a little animation when the document position changes, so
> "precision scrolling" might be a better choice.
>
> Tests, comments, and OKs would be welcome.
I like it. Implementation is nice. I find the *_EV defines confusing.
Why not use the WSCONS_* defines directly, it would make easier for the
reader to find which code generates which event in a single grep. But
that's not new ;)
Do you know if it would make sense to get rid of the standard scrolling
method? Could we generate such events for all input devices? Does
other X drivers do that already or plan to do it?
> Index: dev/wscons/wsconsio.h
> ===
> RCS file: /cvs/src/sys/dev/wscons/wsconsio.h,v
> retrieving revision 1.90
> diff -u -p -r1.90 wsconsio.h
> --- dev/wscons/wsconsio.h 10 Nov 2018 14:27:51 - 1.90
> +++ dev/wscons/wsconsio.h 12 Mar 2019 21:55:11 -
> @@ -112,6 +112,12 @@ struct wscons_event {
> #define WSCONS_EVENT_TOUCH_RESET25 /* (no value) */
>
> /*
> + * Precision Scrolling
> + */
> +#define WSCONS_EVENT_HSCROLL 26 /* dx * 4096 / scroll_unit */
> +#define WSCONS_EVENT_VSCROLL 27 /* dy * 4096 / scroll_unit */
> +
> +/*
> * Keyboard ioctls (0 - 31)
> */
>
> Index: dev/wscons/wsmouse.c
> ===
> RCS file: /cvs/src/sys/dev/wscons/wsmouse.c,v
> retrieving revision 1.51
> diff -u -p -r1.51 wsmouse.c
> --- dev/wscons/wsmouse.c 19 Feb 2019 07:01:02 - 1.51
> +++ dev/wscons/wsmouse.c 12 Mar 2019 21:55:11 -
> @@ -1034,10 +1034,18 @@ wsmouse_motion_sync(struct wsmouseinput
> wsmouse_evq_put(evq, DELTA_X_EV(input), dx);
> if (dy)
> wsmouse_evq_put(evq, DELTA_Y_EV(input), dy);
> - if (motion->dz)
> - wsmouse_evq_put(evq, DELTA_Z_EV, motion->dz);
> - if (motion->dw)
> - wsmouse_evq_put(evq, DELTA_W_EV, motion->dw);
> + if (motion->dz) {
> + if (IS_TOUCHPAD(input))
> + wsmouse_evq_put(evq, VSCROLL_EV, motion->dz);
> + else
> + wsmouse_evq_put(evq, DELTA_Z_EV, motion->dz);
> + }
> + if (motion->dw) {
> + if (IS_TOUCHPAD(input))
> + wsmouse_evq_put(evq, HSCROLL_EV, motion->dw);
> + else
> + wsmouse_evq_put(evq, DELTA_W_EV, motion->dw);
> + }
> }
> if (motion->sync & SYNC_POSITION) {
> if (motion->sync & SYNC_X) {
> Index: dev/wscons/wsmouseinput.h
> ===
> RCS file: /cvs/src/sys/dev/wscons/wsmouseinput.h,v
> retrieving revision 1.12
> diff -u -p -r1.12 wsmouseinput.h
> --- dev/wscons/wsmouseinput.h 10 Nov 2018 14:27:51 - 1.12
> +++ dev/wscons/wsmouseinput.h 12 Mar 2019 21:55:12 -
> @@ -210,6 +210,8 @@ int wstpad_set_param(struct wsmouseinput
> WSCONS_EVENT_MOUSE_ABSOLUTE_X : WSCONS_EVENT_MOUSE_ABSOLUTE_Y)
> #define DELTA_Z_EV WSCONS_EVENT_MOUSE_DELTA_Z
> #define DELTA_W_EV WSCONS_EVENT_MOUSE_DELTA_W
> +#define VSCROLL_EV
Re: Option for alternative escape character with cu(1)
Why only % rather than have -e take an argument like ssh?
On Wed, Mar 13, 2019 at 02:35:06PM +0200, Artturi Alm wrote:
> Hi,
>
> i don't have issues with tilde when using locally, but i mostly ssh to
> reach cu, and too many times i've forgotten to configure ssh/use -e,
> with this cu(1) becomes safer/easier to use for us with non-english
> keyboard.
> ~tilde is certainly annoying when it's three key presses alone,
> and then you mostly get only one shot at trying..
>
> is this bloat?
>
> -Artturi
>
>
> diff --git a/usr.bin/cu/command.c b/usr.bin/cu/command.c
> index c07fe73aeca..d97db3b56de 100644
> --- a/usr.bin/cu/command.c
> +++ b/usr.bin/cu/command.c
> @@ -223,6 +223,8 @@ start_record(void)
> void
> do_command(char c)
> {
> + char esc = alt_esc ? '%' : '~';
> +
> if (restricted && strchr("CRX$>", c) != NULL) {
> cu_warnx("~%c command is not allowed in restricted mode", c);
> return;
> @@ -271,15 +273,16 @@ do_command(char c)
> break;
> case '?':
> printf("\r\n"
> - "~# send break\r\n"
> - "~$ pipe local command to remote host\r\n"
> - "~> send file to remote host\r\n"
> - "~C connect program to remote host\r\n"
> - "~D de-assert DTR line briefly\r\n"
> - "~R start recording to file\r\n"
> - "~S set speed\r\n"
> - "~X send file with XMODEM\r\n"
> - "~? get this summary\r\n"
> + "%c# send break\r\n"
> + "%c$ pipe local command to remote host\r\n"
> + "%c> send file to remote host\r\n"
> + "%cC connect program to remote host\r\n"
> + "%cD de-assert DTR line briefly\r\n"
> + "%cR start recording to file\r\n"
> + "%cS set speed\r\n"
> + "%cX send file with XMODEM\r\n"
> + "%c? get this summary\r\n",
> + esc, esc, esc, esc, esc, esc, esc, esc, esc
> );
> break;
> }
> diff --git a/usr.bin/cu/cu.1 b/usr.bin/cu/cu.1
> index 104a6ea7893..1d609e14947 100644
> --- a/usr.bin/cu/cu.1
> +++ b/usr.bin/cu/cu.1
> @@ -35,7 +35,7 @@
> .Nd serial terminal emulator
> .Sh SYNOPSIS
> .Nm
> -.Op Fl dr
> +.Op Fl der
> .Op Fl l Ar line
> .Op Fl s Ar speed | Fl Ar speed
> .Nm
> @@ -55,6 +55,10 @@ The options are as follows:
> Specify that the line is directly connected and
> .Nm
> should not allow the driver to block waiting for a carrier to be detected.
> +.It Fl e
> +Use a percent sign
> +.Pq Ql %
> +as the escape character instead of tilde.
> .It Fl l Ar line
> Specify the line to use.
> Either of the forms like
> diff --git a/usr.bin/cu/cu.c b/usr.bin/cu/cu.c
> index 03a2df4181f..b66f4698605 100644
> --- a/usr.bin/cu/cu.c
> +++ b/usr.bin/cu/cu.c
> @@ -41,6 +41,7 @@ FILE*record_file;
> struct termiossaved_tio;
> struct bufferevent *input_ev;
> struct bufferevent *output_ev;
> +int alt_esc = 0;
> int is_direct = -1;
> int restricted = 0;
> const char *line_path = NULL;
> @@ -53,7 +54,7 @@ struct event sighup_ev;
> enum {
> STATE_NONE,
> STATE_NEWLINE,
> - STATE_TILDE
> + STATE_ESCAPE
> } last_state = STATE_NEWLINE;
>
> __dead void usage(void);
> @@ -67,7 +68,7 @@ voidtry_remote(const char *, const char *,
> const char *);
> __dead void
> usage(void)
> {
> - fprintf(stderr, "usage: %s [-dr] [-l line] [-s speed | -speed]\n",
> + fprintf(stderr, "usage: %s [-der] [-l line] [-s speed | -speed]\n",
> __progname);
> fprintf(stderr, " %s [host]\n", __progname);
> exit(1);
> @@ -101,11 +102,14 @@ main(int argc, char **argv)
> errx(1, "speed asprintf");
> }
>
> - while ((opt = getopt(argc, argv, "drl:s:")) != -1) {
> + while ((opt = getopt(argc, argv, "derl:s:")) != -1) {
> switch (opt) {
> case 'd':
> is_direct = 1;
> break;
> + case 'e':
> + alt_esc = 1;
> + break;
> case 'r':
> if (pledge("stdio rpath wpath tty", NULL) == -1)
> err(1, "pledge");
> @@ -308,14 +312,14 @@ stream_read(struct bufferevent *bufev, void *data)
> last_state = STATE_NEWLINE;
> break;
> case STATE_NEWLINE:
> - if (state_change && *ptr == '~') {
> - last_state = STATE_TILDE;
> + if (state_change && *ptr == "~%"[alt_esc]) {
> + last_state = STATE_ESCAPE;
>
Re: Option for alternative escape character with cu(1)
On Wed, 13 Mar 2019 14:35:06 +0200, Artturi Alm wrote: > i don't have issues with tilde when using locally, but i mostly ssh to > reach cu, and too many times i've forgotten to configure ssh/use -e, > with this cu(1) becomes safer/easier to use for us with non-english > keyboard. > ~tilde is certainly annoying when it's three key presses alone, > and then you mostly get only one shot at trying.. The cu from Taylor UUCP uses -E for this (it uses -e to specify even parity). If we are going to support this, I think it makes sense to be as compatible as possible with other systems. - todd
Option for alternative escape character with cu(1)
Hi,
i don't have issues with tilde when using locally, but i mostly ssh to
reach cu, and too many times i've forgotten to configure ssh/use -e,
with this cu(1) becomes safer/easier to use for us with non-english
keyboard.
~tilde is certainly annoying when it's three key presses alone,
and then you mostly get only one shot at trying..
is this bloat?
-Artturi
diff --git a/usr.bin/cu/command.c b/usr.bin/cu/command.c
index c07fe73aeca..d97db3b56de 100644
--- a/usr.bin/cu/command.c
+++ b/usr.bin/cu/command.c
@@ -223,6 +223,8 @@ start_record(void)
void
do_command(char c)
{
+ char esc = alt_esc ? '%' : '~';
+
if (restricted && strchr("CRX$>", c) != NULL) {
cu_warnx("~%c command is not allowed in restricted mode", c);
return;
@@ -271,15 +273,16 @@ do_command(char c)
break;
case '?':
printf("\r\n"
- "~# send break\r\n"
- "~$ pipe local command to remote host\r\n"
- "~> send file to remote host\r\n"
- "~C connect program to remote host\r\n"
- "~D de-assert DTR line briefly\r\n"
- "~R start recording to file\r\n"
- "~S set speed\r\n"
- "~X send file with XMODEM\r\n"
- "~? get this summary\r\n"
+ "%c# send break\r\n"
+ "%c$ pipe local command to remote host\r\n"
+ "%c> send file to remote host\r\n"
+ "%cC connect program to remote host\r\n"
+ "%cD de-assert DTR line briefly\r\n"
+ "%cR start recording to file\r\n"
+ "%cS set speed\r\n"
+ "%cX send file with XMODEM\r\n"
+ "%c? get this summary\r\n",
+ esc, esc, esc, esc, esc, esc, esc, esc, esc
);
break;
}
diff --git a/usr.bin/cu/cu.1 b/usr.bin/cu/cu.1
index 104a6ea7893..1d609e14947 100644
--- a/usr.bin/cu/cu.1
+++ b/usr.bin/cu/cu.1
@@ -35,7 +35,7 @@
.Nd serial terminal emulator
.Sh SYNOPSIS
.Nm
-.Op Fl dr
+.Op Fl der
.Op Fl l Ar line
.Op Fl s Ar speed | Fl Ar speed
.Nm
@@ -55,6 +55,10 @@ The options are as follows:
Specify that the line is directly connected and
.Nm
should not allow the driver to block waiting for a carrier to be detected.
+.It Fl e
+Use a percent sign
+.Pq Ql %
+as the escape character instead of tilde.
.It Fl l Ar line
Specify the line to use.
Either of the forms like
diff --git a/usr.bin/cu/cu.c b/usr.bin/cu/cu.c
index 03a2df4181f..b66f4698605 100644
--- a/usr.bin/cu/cu.c
+++ b/usr.bin/cu/cu.c
@@ -41,6 +41,7 @@ FILE *record_file;
struct termios saved_tio;
struct bufferevent *input_ev;
struct bufferevent *output_ev;
+int alt_esc = 0;
int is_direct = -1;
int restricted = 0;
const char *line_path = NULL;
@@ -53,7 +54,7 @@ struct event sighup_ev;
enum {
STATE_NONE,
STATE_NEWLINE,
- STATE_TILDE
+ STATE_ESCAPE
} last_state = STATE_NEWLINE;
__dead voidusage(void);
@@ -67,7 +68,7 @@ void try_remote(const char *, const char *, const
char *);
__dead void
usage(void)
{
- fprintf(stderr, "usage: %s [-dr] [-l line] [-s speed | -speed]\n",
+ fprintf(stderr, "usage: %s [-der] [-l line] [-s speed | -speed]\n",
__progname);
fprintf(stderr, " %s [host]\n", __progname);
exit(1);
@@ -101,11 +102,14 @@ main(int argc, char **argv)
errx(1, "speed asprintf");
}
- while ((opt = getopt(argc, argv, "drl:s:")) != -1) {
+ while ((opt = getopt(argc, argv, "derl:s:")) != -1) {
switch (opt) {
case 'd':
is_direct = 1;
break;
+ case 'e':
+ alt_esc = 1;
+ break;
case 'r':
if (pledge("stdio rpath wpath tty", NULL) == -1)
err(1, "pledge");
@@ -308,14 +312,14 @@ stream_read(struct bufferevent *bufev, void *data)
last_state = STATE_NEWLINE;
break;
case STATE_NEWLINE:
- if (state_change && *ptr == '~') {
- last_state = STATE_TILDE;
+ if (state_change && *ptr == "~%"[alt_esc]) {
+ last_state = STATE_ESCAPE;
continue;
}
if (*ptr != '\r')
last_state = STATE_NONE;
break;
- case STATE_TILDE:
+ case STATE_ESCAPE:
Re: small detail on faq current upgrade guide.
On 3/13/19 7:03 AM, Janne Johansson wrote: > Since some confusion was noticed about this sentence, this might make > it clearer: ... > -Upgrading to -current by compiling your own source code is not supported. > +Upgrading to -current from a release by compiling your own source > code is not supported. Last I heard, upgrading from /anything/ to current by source code is not supported. If you want current, install a snapshot. Compiling is for making or testing code AFTER you have upgraded to the most recent snapshot. So, I think this is going the wrong direction. Nick.
small detail on faq current upgrade guide.
Since some confusion was noticed about this sentence, this might make it clearer: $ cvs -q diff -u current.html Index: current.html === RCS file: /cvs/www/faq/current.html,v retrieving revision 1.982 diff -u -p -u -r1.982 current.html --- current.html19 Feb 2019 05:38:00 - 1.982 +++ current.html13 Mar 2019 10:45:02 - @@ -45,7 +45,7 @@ Any installed packages should then be upgraded after booting into the new system. -Upgrading to -current by compiling your own source code is not supported. +Upgrading to -current from a release by compiling your own source code is not supported. Most of these changes will have to be performed as root. And since gmail in all its wisdom probably html-mangled the diff, its also available here: http://c66.it.su.se:8080/obsd/faq-upgr.diff in all it's simplicity. /jj -- May the most significant bit of your life be positive.
Re: extend BPF filter drop to allow not capturing packets
On Wed, Mar 13, 2019 at 11:32:36AM +0100, Mike Belopuhov wrote:
>
> David Gwynne writes:
>
> > On Tue, Mar 05, 2019 at 12:03:05PM +1000, David Gwynne wrote:
> >> this extends the fildrop mechanism so you can drop the packets with bpf
> >> using the existing fildrop method, but with an extra tweak so you can
> >> avoid the cost of copying packets to userland.
> >>
> >> i wanted to quickly drop some packets in the rx interrupt path to try
> >> and prioritise some traffic getting processed by the system. the initial
> >> version was going to use weird custom DLTs and extra bpf interface
> >> pointers and stuff, but most of the glue is already in place with
> >> the fildrop functionality.
> >>
> >> this also adds a bit to tcpdump so you can set a fildrop action. it
> >> means tcpdump can be used as a quick and dirty firewall.
> >
> > there's a bit more discussion about this that i should have included in
> > my original email.
> >
> > firstly, the functionality it offers. this effectively offers a firewall
> > with the ability to filter arbitrary packets. this has significant
> > overlap with the functionality that pf offers, but there are a couple of
> > important differences. pf only handles IP traffic, but we don't
> > really have a good story when it comes to filtering non-ip. we could
> > implement something like pf for the next protocol that people need to
> > manage, but what is that next protocol? pf like implies a highly
> > optimised but constrained set of filters that deeply understands the
> > protocol it is handling. is that next protol ieee1905p? cdp? ipx?
> > macsec? where should that protocol be filtered in the stack?
> >
> > im arguing that bpf with fildrop has the benefit of already existing,
> > it's in place, and it already has the ability to be configured with
> > arbitrary policy. considering we've got this far without handling
> > non-ip, spending more time on it seems unjustified.
> >
> > secondly, the performance aspects of this diff.
> >
> > bpf allows for arbitrarily complicated filters, so it is entirely
> > possible to slow your box down a lot by writing really complicated
> > filters. this is in comparison to pf where each rule has a limit
> > on how much work it will do, which is also mitigated by the ruleset
> > optimiser and skip steps. i don't have a good answer to that except to
> > say you can already add such filters to bpf, they just don't do anything
> > except copy packets at the moment.
> >
> > another interesting performance consideration is that bpf runs a lot
> > earlier than pf, so filtering packets with bpf can avoid a lot of work
> > in the stack. if you want to pass IP statefully, pf is a much better
> > hammer, but to drop packets up front bpf is interesting.
> >
> > for example, thanks to hrvoje popovski i now have a setup where im
> > pushing ~7 million packets per second through a box to do performance
> > measurements. those packets are udp from random ips to port 7 on
> > another set of random ips. if i have the following rule in pf.conf:
> >
> > block in quick proto udp to port 7
> >
> > i can rx and drop about 550kpps. if im sshed in using another
> > interface, the system is super sluggish over that shell.
> >
> > if i use this diff and run the following;
> >
> > # tcpdump -B drop -i ix1 udp and port 7
> >
> > i'm dropping about 1.2 million pps, and the box is responsive when sshed
> > in using another interface.
> >
> > so, to summarise, bpf can already be used to drop packets, this is just
> > a tweak to make it faster, and a tweak so tcpdump can be used to set up
> > that filtering.
> >
>
> I think this is a great development. Diff looks good as well.
I agree. OK claudio@
> >> Index: sys/net/bpf.c
> >> ===
> >> RCS file: /cvs/src/sys/net/bpf.c,v
> >> retrieving revision 1.170
> >> diff -u -p -r1.170 bpf.c
> >> --- sys/net/bpf.c 13 Jul 2018 08:51:15 - 1.170
> >> +++ sys/net/bpf.c 4 Mar 2019 22:30:32 -
> >> @@ -926,9 +926,20 @@ bpfioctl(dev_t dev, u_long cmd, caddr_t
> >>*(u_int *)addr = d->bd_fildrop;
> >>break;
> >>
> >> - case BIOCSFILDROP: /* set "filter-drop" flag */
> >> - d->bd_fildrop = *(u_int *)addr ? 1 : 0;
> >> + case BIOCSFILDROP: {/* set "filter-drop" flag */
> >> + unsigned int fildrop = *(u_int *)addr;
> >> + switch (fildrop) {
> >> + case BPF_FILDROP_PASS:
> >> + case BPF_FILDROP_CAPTURE:
> >> + case BPF_FILDROP_DROP:
> >> + d->bd_fildrop = fildrop;
> >> + break;
> >> + default:
> >> + error = EINVAL;
> >> + break;
> >> + }
> >>break;
> >> + }
> >>
> >>case BIOCGDIRFILT: /* get direction filter */
> >>*(u_int *)addr = d->bd_dirfilt;
> >> @@ -1261,23 +1272,26 @@ _bpf_mtap(caddr_t arg, const struct mbuf
> >>pktlen += m0->m_len;
Re: extend BPF filter drop to allow not capturing packets
David Gwynne writes:
> On Tue, Mar 05, 2019 at 12:03:05PM +1000, David Gwynne wrote:
>> this extends the fildrop mechanism so you can drop the packets with bpf
>> using the existing fildrop method, but with an extra tweak so you can
>> avoid the cost of copying packets to userland.
>>
>> i wanted to quickly drop some packets in the rx interrupt path to try
>> and prioritise some traffic getting processed by the system. the initial
>> version was going to use weird custom DLTs and extra bpf interface
>> pointers and stuff, but most of the glue is already in place with
>> the fildrop functionality.
>>
>> this also adds a bit to tcpdump so you can set a fildrop action. it
>> means tcpdump can be used as a quick and dirty firewall.
>
> there's a bit more discussion about this that i should have included in
> my original email.
>
> firstly, the functionality it offers. this effectively offers a firewall
> with the ability to filter arbitrary packets. this has significant
> overlap with the functionality that pf offers, but there are a couple of
> important differences. pf only handles IP traffic, but we don't
> really have a good story when it comes to filtering non-ip. we could
> implement something like pf for the next protocol that people need to
> manage, but what is that next protocol? pf like implies a highly
> optimised but constrained set of filters that deeply understands the
> protocol it is handling. is that next protol ieee1905p? cdp? ipx?
> macsec? where should that protocol be filtered in the stack?
>
> im arguing that bpf with fildrop has the benefit of already existing,
> it's in place, and it already has the ability to be configured with
> arbitrary policy. considering we've got this far without handling
> non-ip, spending more time on it seems unjustified.
>
> secondly, the performance aspects of this diff.
>
> bpf allows for arbitrarily complicated filters, so it is entirely
> possible to slow your box down a lot by writing really complicated
> filters. this is in comparison to pf where each rule has a limit
> on how much work it will do, which is also mitigated by the ruleset
> optimiser and skip steps. i don't have a good answer to that except to
> say you can already add such filters to bpf, they just don't do anything
> except copy packets at the moment.
>
> another interesting performance consideration is that bpf runs a lot
> earlier than pf, so filtering packets with bpf can avoid a lot of work
> in the stack. if you want to pass IP statefully, pf is a much better
> hammer, but to drop packets up front bpf is interesting.
>
> for example, thanks to hrvoje popovski i now have a setup where im
> pushing ~7 million packets per second through a box to do performance
> measurements. those packets are udp from random ips to port 7 on
> another set of random ips. if i have the following rule in pf.conf:
>
> block in quick proto udp to port 7
>
> i can rx and drop about 550kpps. if im sshed in using another
> interface, the system is super sluggish over that shell.
>
> if i use this diff and run the following;
>
> # tcpdump -B drop -i ix1 udp and port 7
>
> i'm dropping about 1.2 million pps, and the box is responsive when sshed
> in using another interface.
>
> so, to summarise, bpf can already be used to drop packets, this is just
> a tweak to make it faster, and a tweak so tcpdump can be used to set up
> that filtering.
>
I think this is a great development. Diff looks good as well.
>> Index: sys/net/bpf.c
>> ===
>> RCS file: /cvs/src/sys/net/bpf.c,v
>> retrieving revision 1.170
>> diff -u -p -r1.170 bpf.c
>> --- sys/net/bpf.c13 Jul 2018 08:51:15 - 1.170
>> +++ sys/net/bpf.c4 Mar 2019 22:30:32 -
>> @@ -926,9 +926,20 @@ bpfioctl(dev_t dev, u_long cmd, caddr_t
>> *(u_int *)addr = d->bd_fildrop;
>> break;
>>
>> -case BIOCSFILDROP: /* set "filter-drop" flag */
>> -d->bd_fildrop = *(u_int *)addr ? 1 : 0;
>> +case BIOCSFILDROP: {/* set "filter-drop" flag */
>> +unsigned int fildrop = *(u_int *)addr;
>> +switch (fildrop) {
>> +case BPF_FILDROP_PASS:
>> +case BPF_FILDROP_CAPTURE:
>> +case BPF_FILDROP_DROP:
>> +d->bd_fildrop = fildrop;
>> +break;
>> +default:
>> +error = EINVAL;
>> +break;
>> +}
>> break;
>> +}
>>
>> case BIOCGDIRFILT: /* get direction filter */
>> *(u_int *)addr = d->bd_dirfilt;
>> @@ -1261,23 +1272,26 @@ _bpf_mtap(caddr_t arg, const struct mbuf
>> pktlen += m0->m_len;
>>
>> SRPL_FOREACH(d, , >bif_dlist, bd_next) {
>> +struct srp_ref bsr;
>> +struct bpf_program *bf;
>> +struct bpf_insn *fcode = NULL;
>> +
>> atomic_inc_long(>bd_rcount);
>>
>> -if
fix kvm(3) support for netstat -r
hi tech@,
netstat -r with -A/-M (which uses kvm(3)) was broken since in-kernel
routing table implementation was changed to ART-based.
this patch adds support for ART-based implementation in netstat.
kernel and src build ok.
by the way, is "netstat -r with -A on live system" really needed?
it needs kern.allowkmem=1.
Regards,
--
FUKAUMI Naoki
Index: regress/sys/net/rtable/Makefile.inc
===
RCS file: /cvs/src/regress/sys/net/rtable/Makefile.inc,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile.inc
--- regress/sys/net/rtable/Makefile.inc 27 Jul 2017 13:34:30 - 1.3
+++ regress/sys/net/rtable/Makefile.inc 13 Mar 2019 07:03:52 -
@@ -9,6 +9,6 @@ SRCS+= art.c
CFLAGS+= -DART
.endif
-CPPFLAGS+= -I${TOPDIR} -Wall
+CPPFLAGS+= -I${TOPDIR} -Wall -Wno-macro-redefined
.PATH: ${TOPDIR} ${TOPDIR}/../../../../sys/net
Index: sys/net/art.c
===
RCS file: /cvs/src/sys/net/art.c,v
retrieving revision 1.27
diff -u -p -r1.27 art.c
--- sys/net/art.c 28 Feb 2017 09:50:13 - 1.27
+++ sys/net/art.c 13 Mar 2019 07:03:53 -
@@ -37,37 +37,6 @@
#include
-#define ISLEAF(e) (((unsigned long)(e) & 1) == 0)
-#define SUBTABLE(e)((struct art_table *)((unsigned long)(e) & ~1))
-#define ASNODE(t) ((struct art_node *)((unsigned long)(t) | 1))
-
-/*
- * Allotment Table.
- */
-struct art_table {
- struct art_table*at_parent; /* Parent table */
- uint32_t at_index; /* Index in the parent table */
- uint32_t at_minfringe; /* Index that fringe begins */
- uint32_t at_level; /* Level of the table */
- uint8_t at_bits; /* Stride length of the table */
- uint8_t at_offset; /* Sum of parents' stride len */
-
- /*
-* Items stored in the heap are pointers to nodes, in the leaf
-* case, or tables otherwise. One exception is index 0 which
-* is a route counter.
-*/
- union {
- struct srp node;
- unsigned longcount;
- } *at_heap; /* Array of 2^(slen+1) items */
-};
-#defineat_refcnt at_heap[0].count/* Refcounter (1 per different
route) */
-#defineat_default at_heap[1].node /* Default route (was in parent
heap) */
-
-/* Heap size for an ART table of stride length ``slen''. */
-#define AT_HEAPSIZE(slen) ((1 << ((slen) + 1)) * sizeof(void *))
-
int art_bindex(struct art_table *, uint8_t *, int);
voidart_allot(struct art_table *at, int, struct art_node *,
struct art_node *);
Index: sys/net/art.h
===
RCS file: /cvs/src/sys/net/art.h,v
retrieving revision 1.17
diff -u -p -r1.17 art.h
--- sys/net/art.h 28 Feb 2017 09:50:13 - 1.17
+++ sys/net/art.h 13 Mar 2019 07:03:53 -
@@ -20,6 +20,7 @@
#define _NET_ART_H_
#include
+#include
#define ART_MAXLVL 32 /* We currently use 32 levels for IPv6. */
@@ -35,6 +36,37 @@ struct art_root {
uint8_t ar_off;/* Offset of the key in bytes */
unsigned int ar_rtableid; /* ID of this routing table */
};
+
+#define ISLEAF(e) (((unsigned long)(e) & 1) == 0)
+#define SUBTABLE(e)((struct art_table *)((unsigned long)(e) & ~1))
+#define ASNODE(t) ((struct art_node *)((unsigned long)(t) | 1))
+
+/*
+ * Allotment Table.
+ */
+struct art_table {
+ struct art_table*at_parent; /* Parent table */
+ uint32_t at_index; /* Index in the parent table */
+ uint32_t at_minfringe; /* Index that fringe begins */
+ uint32_t at_level; /* Level of the table */
+ uint8_t at_bits; /* Stride length of the table */
+ uint8_t at_offset; /* Sum of parents' stride len */
+
+ /*
+* Items stored in the heap are pointers to nodes, in the leaf
+* case, or tables otherwise. One exception is index 0 which
+* is a route counter.
+*/
+ union {
+ struct srp node;
+ unsigned longcount;
+ } *at_heap; /* Array of 2^(slen+1) items */
+};
+#defineat_refcnt at_heap[0].count/* Refcounter (1 per different
route) */
+#defineat_default at_heap[1].node /* Default route (was in parent
heap) */
+
+/* Heap size for an ART table of stride length ``slen''. */
+#define AT_HEAPSIZE(slen) ((1 << ((slen) + 1)) * sizeof(void *))
/*
* Forward declaration needed for the list of mpath routes
Index:
