Re: call for testing: rad(8) - a rtadvd(8) replacement
On Thu, Jul 19, 2018 at 09:47:06PM +0200, Björn Ketelaars wrote:
> On Wed 18/07/2018 08:54, Florian Obser wrote:
> > During g2k18 I commited rad(8).
> >
> > The latest amd64 and i386 snapshots should contain it with enough
> > features to replace rtadvd(8). If you are using rtadvd(8) I'd
> > appreciate if you could switch to rad(8) and report back if any
> > features are missing.
>
> Florian,
>
> Thank you for rad(8). I like the configuration format, and it seems to
> work for me as replacement for rtadvd(8). For reference purposes:
>
> $ cat /etc/rtadvd.conf
> vlan1003:\
> :mtu#1480:\
> :rdnss="2001:470:7ce4:1::1":\
> :dnssl="guest":
>
> $ cat /etc/rad.conf
> interface vlan1003 {
> dns {
> resolver 2001:470:7ce4:1::1
> search guest
> }
> }
>
> There is one thing that I'm missing, and that is the MTU option in RA
> messages (RFC 4861 Section 4.6.4). I've baked up a diff which works for
> me. My current rad.conf looks like:
>
> interface vlan1003 {
> dns {
> resolver 2001:470:7ce4:1::1
> search guest
> }
>
> mtu 1480
> }
>
> Output "tcpdump - -ttt -i vlan1003 icmp6 and 'ip6[40] = 134'":
>
> Jul 19 21:26:10.009348 fe80::a562:1f47:a75c:a5fc > ff02::1: icmp6: router
> advertisement(chlim=0, pref=medium, router_ltime=1800, reachable_time=0,
> retrans_time=0)(prefix info: LA valid_ltime=2592000, preferred_ltime=604800,
> prefix=2001:470:7ce4:1::/64)(mtu: mtu=1480)[ndp opt] (len 88, hlim 255)
>
> I'm not sure this is an option for rad(8) that is useful for anyone else
> but me. What do you think? Also, what do you think of the diff below?
I like it, I think we should have it. Out of curiosity, which clients
pay attention to the MTU option? I know that slaacd does not. If you
are sufficiently bored you might want to implement it there, too! ;)
(hint: you will need to add to the wroute pledge in the kernel)
Diff reads mostly ok but needs a few tweaks, see inline:
>
>
> diff --git engine.c engine.c
> index 5d186439dd8..4ade634a689 100644
> --- engine.c
> +++ engine.c
> @@ -355,6 +355,9 @@ engine_dispatch_main(int fd, short event, void *bula)
> SIMPLEQ_INSERT_TAIL(_iface_conf->ra_prefix_list,
> ra_prefix_conf, entry);
> break;
> + case IMSG_RECONF_RA_MTU:
> + ra_iface_conf->ra_mtu = *((uint32_t *)imsg.data);
> + break;
no need for the extra IMSG, ra_mtu is not a substructure in
ra_iface_conf, it will be copied with the rest of the ra_iface_conf in
IMSG_RECONF_RA_IFACE
> case IMSG_RECONF_RA_RDNS_LIFETIME:
> ra_iface_conf->rdns_lifetime = *((uint32_t *)imsg.data);
> break;
> diff --git frontend.c frontend.c
> index b06fa43038c..06c4cc5cb2b 100644
> --- frontend.c
> +++ frontend.c
> @@ -397,6 +397,9 @@ frontend_dispatch_main(int fd, short event, void *bula)
> SIMPLEQ_INSERT_TAIL(_iface_conf->ra_prefix_list,
> ra_prefix_conf, entry);
> break;
> + case IMSG_RECONF_RA_MTU:
> + ra_iface_conf->ra_mtu = *((uint32_t *)imsg.data);
> + break;
same here
> case IMSG_RECONF_RA_RDNS_LIFETIME:
> ra_iface_conf->rdns_lifetime = *((uint32_t *)imsg.data);
> break;
> @@ -888,6 +891,7 @@ build_packet(struct ra_iface *ra_iface)
> {
> struct nd_router_advert *ra;
> struct nd_opt_prefix_info *ndopt_pi;
> + struct nd_opt_mtu *ndopt_mtu;
> struct ra_iface_conf*ra_iface_conf;
> struct ra_options_conf *ra_options_conf;
> struct ra_prefix_conf *ra_prefix_conf;
> @@ -960,6 +964,15 @@ build_packet(struct ra_iface *ra_iface)
> p += sizeof(*ndopt_pi);
> }
>
> + if (ra_iface_conf->ra_mtu > 0) {
> + ndopt_mtu = (struct nd_opt_mtu *)p;
> + ndopt_mtu->nd_opt_mtu_type = ND_OPT_MTU;
> + ndopt_mtu->nd_opt_mtu_len = 1;
> + ndopt_mtu->nd_opt_mtu_reserved = 0;
> + ndopt_mtu->nd_opt_mtu_mtu = htonl(ra_iface_conf->ra_mtu);
> + p += sizeof(*ndopt_mtu);
> + }
> +
you need to account for the length of the mtu option, see the beginning
of build_packet(), something like
if (ra_iface_conf->ra_mtu > 0)
len += sizeof(*ndopt_mtu);
> if (ra_iface_conf->rdnss_count > 0) {
> ndopt_rdnss = (struct nd_opt_rdnss *)p;
> ndopt_rdnss->nd_opt_rdnss_type = ND_OPT_RDNSS;
> diff --git parse.y parse.y
> index 582d165c7d6..9696ac58213 100644
> --- parse.y
> +++ parse.y
> @@ -115,7 +115,7 @@ typedef struct {
> %token DEFAULT ROUTER HOP LIMIT MANAGED ADDRESS
> %token CONFIGURATION OTHER LIFETIME REACHABLE TIME
Re: pfctl: remove tiny `-T create' leftover
On Fri, Jul 20, 2018 at 01:11:29AM +0200, Klemens Nanni wrote:
> Or simply check for `show' and `test'.
>
> Index: pfctl.c
> ===
> RCS file: /cvs/src/sbin/pfctl/pfctl.c,v
> retrieving revision 1.355
> diff -u -p -r1.355 pfctl.c
> --- pfctl.c 10 Jul 2018 09:30:49 - 1.355
> +++ pfctl.c 19 Jul 2018 23:06:02 -
> @@ -2491,7 +2491,7 @@ main(int argc, char *argv[])
> argc -= optind;
> argv += optind;
> ch = *tblcmdopt;
> - mode = strchr("acdefkrz", ch) ? O_RDWR : O_RDONLY;
> + mode = strchr("st", ch) ? O_RDONLY : O_RDWR;
> } else if (argc != optind) {
> warnx("unknown command line argument: %s ...", argv[optind]);
> usage();
>
this is OK for me.
sashan
Re: [patch] make(1) remove unused tutorial
Nope. Still some useful stuff in there.
Add PCI ID for VirtualBox NVMe
This is strictly a cosmetic change, as it already gets bound to nvme(4) and works properly, but is currently identified as an unknown product. diff --git a/sys/dev/pci/pcidevs b/sys/dev/pci/pcidevs index f9ab4d1c535..e50b8d1a1a7 100644 --- a/sys/dev/pci/pcidevs +++ b/sys/dev/pci/pcidevs @@ -2912,6 +2912,7 @@ product INITIO INIC941 0x9401 INIC-941 product INITIO INIC950 0x9500 INIC-950 /* InnoTek Systemberatung GmbH */ +product INNOTEK VBNVME 0x4e56 VirtualBox NVMe product INNOTEK VBGA 0xbeef VirtualBox Graphics Adapter product INNOTEK VBGS 0xcafe VirtualBox Guest Service Change in dmesg: -nvme0 at pci0 dev 14 function 0 vendor "InnoTek", unknown product 0x4e56 rev 0x00: apic 2 int 22, NVMe 1.2 +nvme0 at pci0 dev 14 function 0 "InnoTek VirtualBox NVMe" rev 0x00: apic 2 int 22, NVMe 1.2 nvme0: ORCL-VBOX-NVME-VER12, firmware 1.0, serial VB1234-56789 scsibus1 at nvme0: 1 targets sd0 at scsibus1 targ 0 lun 0: SCSI4 0/direct fixed -Andrew
Re: pfctl: remove tiny `-T create' leftover
Or simply check for `show' and `test'.
Index: pfctl.c
===
RCS file: /cvs/src/sbin/pfctl/pfctl.c,v
retrieving revision 1.355
diff -u -p -r1.355 pfctl.c
--- pfctl.c 10 Jul 2018 09:30:49 - 1.355
+++ pfctl.c 19 Jul 2018 23:06:02 -
@@ -2491,7 +2491,7 @@ main(int argc, char *argv[])
argc -= optind;
argv += optind;
ch = *tblcmdopt;
- mode = strchr("acdefkrz", ch) ? O_RDWR : O_RDONLY;
+ mode = strchr("st", ch) ? O_RDONLY : O_RDWR;
} else if (argc != optind) {
warnx("unknown command line argument: %s ...", argv[optind]);
usage();
pfctl: remove tiny `-T create' leftover
Probably an oversight back in 2003 when this command got zapped.
OK?
Index: pfctl.c
===
RCS file: /cvs/src/sbin/pfctl/pfctl.c,v
retrieving revision 1.355
diff -u -p -r1.355 pfctl.c
--- pfctl.c 10 Jul 2018 09:30:49 - 1.355
+++ pfctl.c 19 Jul 2018 22:25:02 -
@@ -2491,7 +2491,7 @@ main(int argc, char *argv[])
argc -= optind;
argv += optind;
ch = *tblcmdopt;
- mode = strchr("acdefkrz", ch) ? O_RDWR : O_RDONLY;
+ mode = strchr("adefkrz", ch) ? O_RDWR : O_RDONLY;
} else if (argc != optind) {
warnx("unknown command line argument: %s ...", argv[optind]);
usage();
Re: Remove cruft: libm/noieee_src
> Date: Tue, 17 Jul 2018 20:41:26 +0200
> From: Christian Weisgerber
>
> Since the VAX port was discontinued, all our remaining architectures
> use IEEE floating point, as will any future ones.
>
> For this reason, I would like to remove all of libm/noieee_src,
> which is unused now. I don't quite know how to actually prove that
> it is unused, but
> * I grepped the full src tree for noieee_src as well as the names
> of all individual files and nothing references them;
> * I successfully built a release on amd64 and arm64.
>
> The proposed commit is the Makefile bit below and all of the
> noieee_src directory. I'll refrain from posting that 6400-line
> diff.
>
> OK to kill the cruft?
ok kettenis@
> Index: Makefile
> ===
> RCS file: /cvs/src/lib/libm/Makefile,v
> retrieving revision 1.118
> diff -u -r1.118 Makefile
> --- Makefile 10 Mar 2018 20:52:58 - 1.118
> +++ Makefile 16 Jul 2018 15:37:20 -
> @@ -67,7 +67,6 @@
>
> .PATH: ${.CURDIR}/man
> .PATH: ${.CURDIR}/src
> -.PATH: ${.CURDIR}/noieee_src
>
> LIB= m
> COMMON_SRCS = b_exp__D.c b_log__D.c b_tgamma.c \
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
>
>
Re: call for testing: rad(8) - a rtadvd(8) replacement
On Wed 18/07/2018 08:54, Florian Obser wrote:
> During g2k18 I commited rad(8).
>
> The latest amd64 and i386 snapshots should contain it with enough
> features to replace rtadvd(8). If you are using rtadvd(8) I'd
> appreciate if you could switch to rad(8) and report back if any
> features are missing.
Florian,
Thank you for rad(8). I like the configuration format, and it seems to
work for me as replacement for rtadvd(8). For reference purposes:
$ cat /etc/rtadvd.conf
vlan1003:\
:mtu#1480:\
:rdnss="2001:470:7ce4:1::1":\
:dnssl="guest":
$ cat /etc/rad.conf
interface vlan1003 {
dns {
resolver 2001:470:7ce4:1::1
search guest
}
}
There is one thing that I'm missing, and that is the MTU option in RA
messages (RFC 4861 Section 4.6.4). I've baked up a diff which works for
me. My current rad.conf looks like:
interface vlan1003 {
dns {
resolver 2001:470:7ce4:1::1
search guest
}
mtu 1480
}
Output "tcpdump - -ttt -i vlan1003 icmp6 and 'ip6[40] = 134'":
Jul 19 21:26:10.009348 fe80::a562:1f47:a75c:a5fc > ff02::1: icmp6: router
advertisement(chlim=0, pref=medium, router_ltime=1800, reachable_time=0,
retrans_time=0)(prefix info: LA valid_ltime=2592000, preferred_ltime=604800,
prefix=2001:470:7ce4:1::/64)(mtu: mtu=1480)[ndp opt] (len 88, hlim 255)
I'm not sure this is an option for rad(8) that is useful for anyone else
but me. What do you think? Also, what do you think of the diff below?
diff --git engine.c engine.c
index 5d186439dd8..4ade634a689 100644
--- engine.c
+++ engine.c
@@ -355,6 +355,9 @@ engine_dispatch_main(int fd, short event, void *bula)
SIMPLEQ_INSERT_TAIL(_iface_conf->ra_prefix_list,
ra_prefix_conf, entry);
break;
+ case IMSG_RECONF_RA_MTU:
+ ra_iface_conf->ra_mtu = *((uint32_t *)imsg.data);
+ break;
case IMSG_RECONF_RA_RDNS_LIFETIME:
ra_iface_conf->rdns_lifetime = *((uint32_t *)imsg.data);
break;
diff --git frontend.c frontend.c
index b06fa43038c..06c4cc5cb2b 100644
--- frontend.c
+++ frontend.c
@@ -397,6 +397,9 @@ frontend_dispatch_main(int fd, short event, void *bula)
SIMPLEQ_INSERT_TAIL(_iface_conf->ra_prefix_list,
ra_prefix_conf, entry);
break;
+ case IMSG_RECONF_RA_MTU:
+ ra_iface_conf->ra_mtu = *((uint32_t *)imsg.data);
+ break;
case IMSG_RECONF_RA_RDNS_LIFETIME:
ra_iface_conf->rdns_lifetime = *((uint32_t *)imsg.data);
break;
@@ -888,6 +891,7 @@ build_packet(struct ra_iface *ra_iface)
{
struct nd_router_advert *ra;
struct nd_opt_prefix_info *ndopt_pi;
+ struct nd_opt_mtu *ndopt_mtu;
struct ra_iface_conf*ra_iface_conf;
struct ra_options_conf *ra_options_conf;
struct ra_prefix_conf *ra_prefix_conf;
@@ -960,6 +964,15 @@ build_packet(struct ra_iface *ra_iface)
p += sizeof(*ndopt_pi);
}
+ if (ra_iface_conf->ra_mtu > 0) {
+ ndopt_mtu = (struct nd_opt_mtu *)p;
+ ndopt_mtu->nd_opt_mtu_type = ND_OPT_MTU;
+ ndopt_mtu->nd_opt_mtu_len = 1;
+ ndopt_mtu->nd_opt_mtu_reserved = 0;
+ ndopt_mtu->nd_opt_mtu_mtu = htonl(ra_iface_conf->ra_mtu);
+ p += sizeof(*ndopt_mtu);
+ }
+
if (ra_iface_conf->rdnss_count > 0) {
ndopt_rdnss = (struct nd_opt_rdnss *)p;
ndopt_rdnss->nd_opt_rdnss_type = ND_OPT_RDNSS;
diff --git parse.y parse.y
index 582d165c7d6..9696ac58213 100644
--- parse.y
+++ parse.y
@@ -115,7 +115,7 @@ typedef struct {
%token DEFAULT ROUTER HOP LIMIT MANAGED ADDRESS
%token CONFIGURATION OTHER LIFETIME REACHABLE TIME RETRANS TIMER
%token AUTO PREFIX VALID PREFERRED LIFETIME ONLINK AUTONOMOUS
-%token ADDRESS_CONFIGURATION DNS RESOLVER SEARCH
+%token ADDRESS_CONFIGURATION DNS RESOLVER SEARCH MTU
%token STRING
%token NUMBER
@@ -265,6 +265,9 @@ ra_ifaceoptsl : NO AUTO PREFIX {
} ra_prefix_block {
ra_prefix_conf = NULL;
}
+ | MTU NUMBER {
+ ra_iface_conf->ra_mtu = $2;
+ }
| DNS dns_block
| ra_opt_block
;
@@ -423,6 +426,7 @@ lookup(char *s)
{"lifetime",LIFETIME},
{"limit", LIMIT},
{"managed", MANAGED},
+ {"mtu", MTU},
{"no", NO},
{"on-link", ONLINK},
{"other",
Re: pcidevs Sandisk or WD
On Thu, Jul 19, 2018 at 08:32:45PM +0200, Mike Belopuhov wrote: > But at this point the origin of new devices is WD. I think since it's > a new addition it should go by WD to reduce potential confusion in the > future. I would tend to agree. It would look rather strange to have a Sandisk WD Black High-performance NVMe SSD in my system. I think the Sandisk brand is being phased out of this market and kept for camera memory cards and other similar products. Bryan
Re: [patch] make(1) remove unused tutorial
On Thu, Jul 19, 2018 at 09:02:07PM +0300, Leonid Bobrov wrote:
> Index: PSD.doc/Makefile
> ===
evening.
all the PSD/USD/... docs in src that remain have been previously
vouched for by other developers as having value, either as-is, or
with the hope of having pertinent details moved into the man page.
so i suspect none of them are going to be removed soon, though of
course your mail may provoke another round of hand-wringing.
rather than voting to nuke documentation wholesale, how about
volunteering to go through such papers with the proverbial (fine)
tooth comb, and mailing in diffs to update the current pages, or
verifying that there is nothing left that isn;t already covered.
that's the real work.
good luck!
jmc
> RCS file: PSD.doc/Makefile
> diff -N PSD.doc/Makefile
> --- PSD.doc/Makefile 1 Feb 2004 14:33:13 - 1.4
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,11 +0,0 @@
> -#$OpenBSD: Makefile,v 1.4 2004/02/01 14:33:13 jmc Exp $
> -#$NetBSD: Makefile,v 1.2 1995/06/14 15:20:23 christos Exp $
> -
> -DIR= psd/12.make
> -SRCS=tutorial.ms
> -MACROS= -ms
> -
> -paper.txt: ${SRCS}
> - ${ROFF} -Tascii ${SRCS} > ${.TARGET}
> -
> -.include
> Index: PSD.doc/tutorial.ms
> ===
> RCS file: PSD.doc/tutorial.ms
> diff -N PSD.doc/tutorial.ms
> --- PSD.doc/tutorial.ms 2 Nov 2007 17:27:24 - 1.13
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,3226 +0,0 @@
> -.\" $OpenBSD: tutorial.ms,v 1.13 2007/11/02 17:27:24 espie Exp $
> -.\" $NetBSD: tutorial.ms,v 1.3 1996/03/06 00:15:31 christos Exp $
> -.\" Copyright (c) 1988, 1989 by Adam de Boor
> -.\" Copyright (c) 1989 by Berkeley Softworks
> -.\" Copyright (c) 1988, 1989, 1993
> -.\" The Regents of the University of California. All rights reserved.
> -.\"
> -.\" This code is derived from software contributed to Berkeley by
> -.\" Adam de Boor.
> -.\"
> -.\" Redistribution and use in source and binary forms, with or without
> -.\" modification, are permitted provided that the following conditions
> -.\" are met:
> -.\" 1. Redistributions of source code must retain the above copyright
> -.\"notice, this list of conditions and the following disclaimer.
> -.\" 2. Redistributions in binary form must reproduce the above copyright
> -.\"notice, this list of conditions and the following disclaimer in the
> -.\"documentation and/or other materials provided with the distribution.
> -.\" 3. Neither the name of the University nor the names of its contributors
> -.\"may be used to endorse or promote products derived from this software
> -.\"without specific prior written permission.
> -.\"
> -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
> -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
> -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> CONSEQUENTIAL
> -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
> STRICT
> -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
> -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> -.\" SUCH DAMAGE.
> -.\"
> -.\" @(#)tutorial.ms 8.1 (Berkeley) 8/18/93
> -.\"
> -.EH 'PSD:12-%''Make \*- A Tutorial'
> -.OH 'Make \*- A Tutorial''PSD:12-%'
> -.\" xH is a macro to provide numbered headers that are automatically stuffed
> -.\" into a table-of-contents, properly indented, etc. If the first argument
> -.\" is numeric, it is taken as the depth for numbering (as for .NH), else
> -.\" the default (1) is assumed.
> -.\"
> -.\" @P The initial paragraph distance.
> -.\" @Q The piece of section number to increment (or 0 if none given)
> -.\" @R Section header.
> -.\" @S Indent for toc entry
> -.\" @T Argument to NH (can't use @Q b/c giving 0 to NH resets the counter)
> -.de xH
> -.NH \\$1
> -\\$2 \\$3 \\$4 \\$5 \\$6 \\$7 \\$8 \\$9
> -.nr PD .1v
> -.XS \\n%
> -.ta 0.6i
> -\\*(SN \\$2 \\$3 \\$4 \\$5 \\$6 \\$7 \\$8 \\$9
> -.XE
> -.nr PD .3v
> -..
> -.\" CW is used to place a string in fixed-width or switch to a
> -.\" fixed-width font.
> -.\" C is a typewriter font for a laserwriter. Use something else if
> -.\" you don't have one...
> -.de CW
> -.ie !\\n(.$ .ft C
> -.el \&\\$3\fC\\$1\fP\\$2
> -..
> -.\" Anything I put in a display I want to be in fixed-width
> -.am DS
> -.CW
> -..
> -.\" The stuff in .No produces a little stop sign in the left margin
> -.\" that says NOTE in it. Unfortunately, it does cause a break, but
> -.\" hey. Can't have everything. In case you're wondering how I
Re: pcidevs Sandisk or WD
On 19 July 2018 at 19:36, Stuart Henderson wrote: > > On 2018/07/19 10:00, Bryan Vyhmeister wrote: > > I am wanting to add the WD Black High-performance NVMe SSD PCI > > IDs to pcidevs and I am not sure how to proceed. WD bought Sandisk a > > while back but the vendor ID is 15b7 which is Sandisk Corp. The product > > itself is WD Black High-performance NVMe SSD and is labeled as Western > > Digital. The vendor ID of 15b7 does not exist in our pcidevs at this > > point. Should I create a diff as 15b7 being Sandisk or Western Digital? > > There are only two products listed under 15b7 that I have found (2001 > > and 5001) and this SSD I have is a new (third) one (5002). My intention > > is to add the information for 5001 and 5002 which are the original WD > > Black NVMe SSD and the new WD Black High-performance NVMe SSD. I have > > both 500GB and 1TB versions which share the same product ID as expected. > > Output from dmesg and pcidump is below. > > AFAIK typically we list under the original vendor name though I'm sure > there are exceptions to this. My vote would be for listing as Sandisk. > But at this point the origin of new devices is WD. I think since it's a new addition it should go by WD to reduce potential confusion in the future.
[patch] make(1) remove unused tutorial
Index: PSD.doc/Makefile
===
RCS file: PSD.doc/Makefile
diff -N PSD.doc/Makefile
--- PSD.doc/Makefile1 Feb 2004 14:33:13 - 1.4
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,11 +0,0 @@
-# $OpenBSD: Makefile,v 1.4 2004/02/01 14:33:13 jmc Exp $
-# $NetBSD: Makefile,v 1.2 1995/06/14 15:20:23 christos Exp $
-
-DIR= psd/12.make
-SRCS= tutorial.ms
-MACROS=-ms
-
-paper.txt: ${SRCS}
- ${ROFF} -Tascii ${SRCS} > ${.TARGET}
-
-.include
Index: PSD.doc/tutorial.ms
===
RCS file: PSD.doc/tutorial.ms
diff -N PSD.doc/tutorial.ms
--- PSD.doc/tutorial.ms 2 Nov 2007 17:27:24 - 1.13
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,3226 +0,0 @@
-.\"$OpenBSD: tutorial.ms,v 1.13 2007/11/02 17:27:24 espie Exp $
-.\"$NetBSD: tutorial.ms,v 1.3 1996/03/06 00:15:31 christos Exp $
-.\" Copyright (c) 1988, 1989 by Adam de Boor
-.\" Copyright (c) 1989 by Berkeley Softworks
-.\" Copyright (c) 1988, 1989, 1993
-.\"The Regents of the University of California. All rights reserved.
-.\"
-.\" This code is derived from software contributed to Berkeley by
-.\" Adam de Boor.
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that the following conditions
-.\" are met:
-.\" 1. Redistributions of source code must retain the above copyright
-.\"notice, this list of conditions and the following disclaimer.
-.\" 2. Redistributions in binary form must reproduce the above copyright
-.\"notice, this list of conditions and the following disclaimer in the
-.\"documentation and/or other materials provided with the distribution.
-.\" 3. Neither the name of the University nor the names of its contributors
-.\"may be used to endorse or promote products derived from this software
-.\"without specific prior written permission.
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
-.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
-.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-.\" SUCH DAMAGE.
-.\"
-.\"@(#)tutorial.ms 8.1 (Berkeley) 8/18/93
-.\"
-.EH 'PSD:12-%''Make \*- A Tutorial'
-.OH 'Make \*- A Tutorial''PSD:12-%'
-.\" xH is a macro to provide numbered headers that are automatically stuffed
-.\" into a table-of-contents, properly indented, etc. If the first argument
-.\" is numeric, it is taken as the depth for numbering (as for .NH), else
-.\" the default (1) is assumed.
-.\"
-.\" @P The initial paragraph distance.
-.\" @Q The piece of section number to increment (or 0 if none given)
-.\" @R Section header.
-.\" @S Indent for toc entry
-.\" @T Argument to NH (can't use @Q b/c giving 0 to NH resets the counter)
-.de xH
-.NH \\$1
-\\$2 \\$3 \\$4 \\$5 \\$6 \\$7 \\$8 \\$9
-.nr PD .1v
-.XS \\n%
-.ta 0.6i
-\\*(SN \\$2 \\$3 \\$4 \\$5 \\$6 \\$7 \\$8 \\$9
-.XE
-.nr PD .3v
-..
-.\" CW is used to place a string in fixed-width or switch to a
-.\" fixed-width font.
-.\" C is a typewriter font for a laserwriter. Use something else if
-.\" you don't have one...
-.de CW
-.ie !\\n(.$ .ft C
-.el \&\\$3\fC\\$1\fP\\$2
-..
-.\" Anything I put in a display I want to be in fixed-width
-.am DS
-.CW
-..
-.\" The stuff in .No produces a little stop sign in the left margin
-.\" that says NOTE in it. Unfortunately, it does cause a break, but
-.\" hey. Can't have everything. In case you're wondering how I came
-.\" up with such weird commands, they came from running grn on a
-.\" gremlin file...
-.de No
-.br
-.ne 0.5i
-.po -0.5i
-.br
-.mk
-.nr g3 \\n(.f
-.nr g4 \\n(.s
-.sp -1
-.\" .st cf
-\D's -1u'\D't 5u'
-.sp -1
-\h'50u'\D'l 71u 0u'\D'l 50u 50u'\D'l 0u 71u'\D'l -50u 50u'\D'l -71u 0u'\D'l
-50u -50u'\D'l 0u -71u'\D'l 50u -50u'
-.sp -1
-\D't 3u'
-.sp -1
-.sp 7u
-\h'53u'\D'p 14 68u 0u 46u 46u 0u 68u -46u 46u -68u 0u -47u -46u 0u -68u 47u
-46u'
-.sp -1
-.ft R
-.ps 6
-.nr g8 \\n(.d
-.ds g9 "NOTE
-.sp 74u
-\h'85u'\v'0.85n'\h-\w\\*(g9u/2u\&\\*(g9
-.sp |\\n(g8u
-.sp 166u
-\D't 3u'\D's -1u'
-.br
-.po
-.rt
-.ft \\n(g3
-.ps \\n(g4
-..
-.de Bp
-.ie !\\n(.$ .IP \(bu 2
-.el .IP "\&" 2
-..
-.po +.3i
-.TL
-Make \*- A Tutorial
-.AU
-Adam de Boor
-.AI
-Berkeley Softworks
-2150 Shattuck Ave, Penthouse
-Berkeley, CA 94704
-a...@bsw.uu.net
-\&...!uunet!bsw!adam
-.FS
-Permission to use, copy, modify,
Re: pcidevs Sandisk or WD
On 2018/07/19 10:00, Bryan Vyhmeister wrote: > I am wanting to add the WD Black High-performance NVMe SSD PCI > IDs to pcidevs and I am not sure how to proceed. WD bought Sandisk a > while back but the vendor ID is 15b7 which is Sandisk Corp. The product > itself is WD Black High-performance NVMe SSD and is labeled as Western > Digital. The vendor ID of 15b7 does not exist in our pcidevs at this > point. Should I create a diff as 15b7 being Sandisk or Western Digital? > There are only two products listed under 15b7 that I have found (2001 > and 5001) and this SSD I have is a new (third) one (5002). My intention > is to add the information for 5001 and 5002 which are the original WD > Black NVMe SSD and the new WD Black High-performance NVMe SSD. I have > both 500GB and 1TB versions which share the same product ID as expected. > Output from dmesg and pcidump is below. AFAIK typically we list under the original vendor name though I'm sure there are exceptions to this. My vote would be for listing as Sandisk. > > Bryan > > > > nvme0 at pci3 dev 0 function 0 unknown vendor 0x15b7 product 0x5002 rev 0x00: > msi, NVMe 1.3 > nvme0: WDS100T2X0C-00L350, firmware 101110WD, serial 181123456789 > > > 4:0:0: unknown unknown > 0x: Vendor ID: 15b7 Product ID: 5002 > 0x0004: Command: 0007 Status: 0010 > 0x0008: Class: 01 Subclass: 08 Interface: 02 Revision: 00 > 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00 > 0x0010: BAR mem 64bit addr: 0xe000/0x4000 > 0x0018: BAR empty () > 0x001c: BAR empty () > 0x0020: BAR mem 64bit addr: 0xe0004000/0x0100 > 0x0028: Cardbus CIS: > 0x002c: Subsystem Vendor ID: 15b7 Product ID: 5002 > 0x0030: Expansion ROM Base Address: > 0x0038: > 0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00 > 0x0080: Capability 0x01: Power Management > State: D0 > 0x0090: Capability 0x05: Message Signalled Interrupts (MSI) > 0x00b0: Capability 0x11: Extended Message Signalled Interrupts (MSI-X) > 0x00c0: Capability 0x10: PCI Express > Link Speed: 5.0 / 8.0 GT/s Link Width: x4 / x4 > 0x0100: Enhanced Capability 0x01: Advanced Error Reporting > 0x0150: Enhanced Capability 0x03: Device Serial Number > 0x01b8: Enhanced Capability 0x18: Latency Tolerance Reporting > 0x0300: Enhanced Capability 0x19: Secondary PCIe Capability > 0x0900: Enhanced Capability 0x1e: L1 PM >
Re: Fwd: new usb id for urtwn
On 2018/07/19 18:00, Mikhail wrote:
> Anyone?
>
>
> -- Forwarded message --
> From: Mikhail
> Date: Wed, Jul 11, 2018 at 6:12 PM
> Subject: Re: new usb id for urtwn
> To: Stuart Henderson
> Cc: tech@openbsd.org
>
>
> Sorry, new patch attached.
>
> On Wed, Jul 11, 2018 at 4:45 PM, Stuart Henderson
> wrote:
> > On 2018/07/11 16:27, Mikhail wrote:
> >> Ping? Ok?
> >>
> >> On Thu, 21 Jun 2018 at 18:28, Mikhail wrote:
> >>
> >> > Taken from FreeBSD:
> >> >
> >> > diff --git a/sys/dev/usb/if_urtwn.c b/sys/dev/usb/if_urtwn.c
> >> > index 0e204a196b1..d9aee16b05f 100644
> >> > --- a/sys/dev/usb/if_urtwn.c
> >> > +++ b/sys/dev/usb/if_urtwn.c
> >> > @@ -306,6 +306,7 @@ static const struct urtwn_type {
> >> > URTWN_DEV_8192CU(TRENDNET, RTL8192CU),
> >> > URTWN_DEV_8192CU(ZYXEL, RTL8192CU),
> >> > /* URTWN_RTL8188E */
> >> > + URTWN_DEV_8188EU(ABOCOM,RTL8188EU),
> >> > URTWN_DEV_8188EU(DLINK, DWA123D1),
> >> > URTWN_DEV_8188EU(DLINK, DWA125D1),
> >> > URTWN_DEV_8188EU(ELECOM,WDC150SU2M),
> >> >
> >
> > Not OK. Try compiling it...
> >
If you look at the top of the usbdevs.h and usbdevs_data.h files you'll
see "THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT." - these should
be generated by adding to the usbdevs file and running make.
I've committed a fixed version.
pcidevs Sandisk or WD
I am wanting to add the WD Black High-performance NVMe SSD PCI IDs to pcidevs and I am not sure how to proceed. WD bought Sandisk a while back but the vendor ID is 15b7 which is Sandisk Corp. The product itself is WD Black High-performance NVMe SSD and is labeled as Western Digital. The vendor ID of 15b7 does not exist in our pcidevs at this point. Should I create a diff as 15b7 being Sandisk or Western Digital? There are only two products listed under 15b7 that I have found (2001 and 5001) and this SSD I have is a new (third) one (5002). My intention is to add the information for 5001 and 5002 which are the original WD Black NVMe SSD and the new WD Black High-performance NVMe SSD. I have both 500GB and 1TB versions which share the same product ID as expected. Output from dmesg and pcidump is below. Bryan nvme0 at pci3 dev 0 function 0 unknown vendor 0x15b7 product 0x5002 rev 0x00: msi, NVMe 1.3 nvme0: WDS100T2X0C-00L350, firmware 101110WD, serial 181123456789 4:0:0: unknown unknown 0x: Vendor ID: 15b7 Product ID: 5002 0x0004: Command: 0007 Status: 0010 0x0008: Class: 01 Subclass: 08 Interface: 02 Revision: 00 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00 0x0010: BAR mem 64bit addr: 0xe000/0x4000 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR mem 64bit addr: 0xe0004000/0x0100 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 15b7 Product ID: 5002 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00 0x0080: Capability 0x01: Power Management State: D0 0x0090: Capability 0x05: Message Signalled Interrupts (MSI) 0x00b0: Capability 0x11: Extended Message Signalled Interrupts (MSI-X) 0x00c0: Capability 0x10: PCI Express Link Speed: 5.0 / 8.0 GT/s Link Width: x4 / x4 0x0100: Enhanced Capability 0x01: Advanced Error Reporting 0x0150: Enhanced Capability 0x03: Device Serial Number 0x01b8: Enhanced Capability 0x18: Latency Tolerance Reporting 0x0300: Enhanced Capability 0x19: Secondary PCIe Capability 0x0900: Enhanced Capability 0x1e: L1 PM
Fwd: new usb id for urtwn
Anyone?
-- Forwarded message --
From: Mikhail
Date: Wed, Jul 11, 2018 at 6:12 PM
Subject: Re: new usb id for urtwn
To: Stuart Henderson
Cc: tech@openbsd.org
Sorry, new patch attached.
On Wed, Jul 11, 2018 at 4:45 PM, Stuart Henderson wrote:
> On 2018/07/11 16:27, Mikhail wrote:
>> Ping? Ok?
>>
>> On Thu, 21 Jun 2018 at 18:28, Mikhail wrote:
>>
>> > Taken from FreeBSD:
>> >
>> > diff --git a/sys/dev/usb/if_urtwn.c b/sys/dev/usb/if_urtwn.c
>> > index 0e204a196b1..d9aee16b05f 100644
>> > --- a/sys/dev/usb/if_urtwn.c
>> > +++ b/sys/dev/usb/if_urtwn.c
>> > @@ -306,6 +306,7 @@ static const struct urtwn_type {
>> > URTWN_DEV_8192CU(TRENDNET, RTL8192CU),
>> > URTWN_DEV_8192CU(ZYXEL, RTL8192CU),
>> > /* URTWN_RTL8188E */
>> > + URTWN_DEV_8188EU(ABOCOM,RTL8188EU),
>> > URTWN_DEV_8188EU(DLINK, DWA123D1),
>> > URTWN_DEV_8188EU(DLINK, DWA125D1),
>> > URTWN_DEV_8188EU(ELECOM,WDC150SU2M),
>> >
>
> Not OK. Try compiling it...
>
diff --git a/sys/dev/usb/if_urtwn.c b/sys/dev/usb/if_urtwn.c
index 0e204a196b1..e6152e8fb13 100644
--- a/sys/dev/usb/if_urtwn.c
+++ b/sys/dev/usb/if_urtwn.c
@@ -306,6 +306,7 @@ static const struct urtwn_type {
URTWN_DEV_8192CU(TRENDNET, RTL8192CU),
URTWN_DEV_8192CU(ZYXEL, RTL8192CU),
/* URTWN_RTL8188E */
+ URTWN_DEV_8188EU(ABOCOM,RTL8188EU),
URTWN_DEV_8188EU(DLINK, DWA123D1),
URTWN_DEV_8188EU(DLINK, DWA125D1),
URTWN_DEV_8188EU(ELECOM, WDC150SU2M),
diff --git a/sys/dev/usb/usbdevs.h b/sys/dev/usb/usbdevs.h
index 0fc246400a5..d8688378143 100644
--- a/sys/dev/usb/usbdevs.h
+++ b/sys/dev/usb/usbdevs.h
@@ -727,6 +727,7 @@
#define USB_PRODUCT_ABOCOM_XX9 0x4104 /* XX9 */
#define USB_PRODUCT_ABOCOM_WL54 0x6001 /* WL54 */
#define USB_PRODUCT_ABOCOM_RTL8192CU 0x8178 /* RTL8192CU */
+#define USB_PRODUCT_ABOCOM_RTL8188EU 0x8179 /* RTL8188EU */
#define USB_PRODUCT_ABOCOM_RTL8188CU_1 0x8188 /* RTL8188CU */
#define USB_PRODUCT_ABOCOM_RTL8188CU_2 0x8189 /* RTL8188CU */
#define USB_PRODUCT_ABOCOM_XX10 0xabc1 /* XX10 */
match on marvell,armada-38x-uart in com_fdt
Linux >= 4.18-rc1 changed the compat string for armada uart to a
different value in b7639b0b15ddd1a4686b0142e70dfb122eefc88f.
Only compile tested for lack of hardware.
Index: com_fdt.c
===
RCS file: /cvs/src/sys/dev/fdt/com_fdt.c,v
retrieving revision 1.1
diff -u -p -r1.1 com_fdt.c
--- com_fdt.c 31 May 2018 20:03:18 - 1.1
+++ com_fdt.c 19 Jul 2018 09:07:21 -
@@ -56,6 +56,7 @@ com_fdt_init_cons(void)
if ((node = fdt_find_cons("brcm,bcm2835-aux-uart")) == NULL &&
(node = fdt_find_cons("snps,dw-apb-uart")) == NULL &&
+ (node = fdt_find_cons("marvell,armada-38x-uart")) == NULL &&
(node = fdt_find_cons("ti,omap3-uart")) == NULL &&
(node = fdt_find_cons("ti,omap4-uart")) == NULL)
return;
@@ -87,6 +88,7 @@ com_fdt_match(struct device *parent, voi
return (OF_is_compatible(faa->fa_node, "brcm,bcm2835-aux-uart") ||
OF_is_compatible(faa->fa_node, "snps,dw-apb-uart") ||
+ OF_is_compatible(faa->fa_node, "marvell,armada-38x-uart") ||
OF_is_compatible(faa->fa_node, "ti,omap3-uart") ||
OF_is_compatible(faa->fa_node, "ti,omap4-uart"));
}
@@ -121,7 +123,8 @@ com_fdt_attach(struct device *parent, st
sc->sc_reg_width = OF_getpropint(faa->fa_node, "reg-io-width", 4);
sc->sc_reg_shift = OF_getpropint(faa->fa_node, "reg-shift", 2);
- if (OF_is_compatible(faa->fa_node, "snps,dw-apb-uart"))
+ if (OF_is_compatible(faa->fa_node, "snps,dw-apb-uart") ||
+ OF_is_compatible(faa->fa_node, "marvell,armada-38x-uart"))
intr = com_fdt_intr_designware;
if (OF_is_compatible(faa->fa_node, "ti,omap3-uart") ||
Re: fix compilation failure when sr_debug is defined.
Hello,
correct version of the patch is below. The previos one was wrong.
Thanks,
Karel
Index: sys/arch/amd64/amd64/machdep.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/machdep.c,v
retrieving revision 1.248
diff -u -p -u -r1.248 machdep.c
--- sys/arch/amd64/amd64/machdep.c 12 Jul 2018 14:11:11 - 1.248
+++ sys/arch/amd64/amd64/machdep.c 19 Jul 2018 09:07:52 -
@@ -142,7 +142,9 @@ extern int db_console;
#endif
/* #define MACHDEP_DEBUG */
-
+#ifdef DPRINTF
+#undef DPRINTF
+#endif
#ifdef MACHDEP_DEBUG
#define DPRINTF(x...) do { printf(x); } while(0)
#else
