ping icmp ident collisions
The only thing ping uses to determine whether a received icmp echo reply packet
is a
response to one of its requests is the 16 bit icmp ident field. If you ping
enough
stuff at the same time, eventually you'll have two concurrent pings using the
same ident,
and they will both see each other's replies. Since we do tricky MAC stuff on
the ping
payload, this results in signature mismatches that look like this:
PING 172.23.94.210 (172.23.94.210): 56 data bytes
64 bytes from 172.23.94.210: icmp_seq=0 ttl=253 time=0.820 ms
64 bytes from 172.23.94.210: icmp_seq=1 ttl=253 time=0.419 ms
64 bytes from 172.23.94.210: icmp_seq=2 ttl=253 time=0.369 ms
signature mismatch!
64 bytes from 172.23.94.210: icmp_seq=3 ttl=253 time=0.273 ms
--- 172.23.94.210 ping statistics ---
4 packets transmitted, 5 packets received, -- somebody's duplicating packets!
round-trip min/avg/max/std-dev = 0.273/0.376/0.820/0.265 ms
ping is counting the packet with the signature mismatch as a reply it received,
and it
prints a misleading message about duplicated packets because it got more
replies than
the number of requests it sent.
I think it would be more helpful not to count signature mismatch packets as
replies.
If you're actually getting corrupted replies, I'd say that's more like packet
loss
than normal operation. If you're getting extra replies due to ident
collisions, this
will result in ping sending and receiving the expected number of packets.
Printing the source address and sequence number on signature mismatches would
also help.
I would have figured this out much quicker had ping told me the mismatch
packets were
from a completely different source. For example:
PING 172.23.94.210 (172.23.94.210): 56 data bytes
64 bytes from 172.23.94.210: icmp_seq=0 ttl=253 time=2.645 ms
64 bytes from 172.23.94.210: icmp_seq=1 ttl=253 time=1.360 ms
64 bytes from 172.23.94.210: icmp_seq=2 ttl=253 time=0.506 ms
64 bytes from 172.23.94.210: icmp_seq=3 ttl=253 time=0.615 ms
signature mismatch from 10.138.79.45: icmp_seq=0
64 bytes from 172.23.94.210: icmp_seq=4 ttl=253 time=0.431 ms
--- 172.23.94.210 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.431/1.111/2.645/0.835 ms
ok?
Index: ping.c
===
RCS file: /cvs/src/sbin/ping/ping.c,v
retrieving revision 1.245
diff -u -p -r1.245 ping.c
--- ping.c 12 Jul 2021 15:09:19 - 1.245
+++ ping.c 18 Feb 2022 01:52:22 -
@@ -1302,7 +1302,10 @@ pr_pack(u_char *buf, int cc, struct msgh
if (timingsafe_memcmp(mac, ,
sizeof(mac)) != 0) {
- printf("signature mismatch!\n");
+ printf("signature mismatch from %s: "
+ "icmp_seq=%u\n", pr_addr(from, fromlen),
+ ntohs(seq));
+ --nreceived;
return;
}
timinginfo=1;
Re: new manual: zonefile.5
On Thu, Feb 17, 2022 at 07:31:47PM GMT, Evan Silberman wrote: > Jason McIntyre wrote: > > as a start, i advise you to run your page through mandoc's inbuilt > > checker > > Yep, done. I've addressed all the ones I think I can properly address. > Date still blank, $OpenBSD$ still absent. It also complains that > .Sh FILES is not in its conventional location but I think that's because > I have nonstandard sections after .Sh DESCRIPTION. Those could be > subsections but mdoc(7) allows for nonstandard sections when it aids > legibility, which I think it does here. > Hi Evan, No, this is because FILES comes before EXAMPLES. > .\" > .\" Copyright (c) 2022 Evan Silberman Also, I don't think this is necessarily wrong, but there's usually a blank line between the Copyright line and the license text. Also, you can simply add: .\" $OpenBSD$ ^ BTW, I never know whether to use a space character or a tab there - I've seen both being used. and: .Dd $Mdocdate$ Regards, Raf > .\" Permission to use, copy, modify, and distribute this software for any > .\" purpose with or without fee is hereby granted, provided that the above > .\" copyright notice and this permission notice appear in all copies. > .\" > .\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > .\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > .\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > .\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > .\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > .\" > .Dd > .Dt ZONEFILE 5 > .Os > .Sh NAME > .Nm zonefile > .Nd DNS authoritative zone definition file format > .Sh DESCRIPTION > A > .Nm > is a standardized textual representation of records in the Domain Name System. > Zone files are used to define the records served by authoritative nameservers > such as > .Xr nsd 8 . > .Pp > Zone files are line-oriented; that is, each line of the file is generally a > seperate entry. > An entry can be split onto multiple lines by surrounding data fields with > parentheses. > Any newline characters within parentheses are ignored and the data within > treated as a continuation of the preceding entry. > .Pp > Domain names in a zone file consist of labels separated by periods > .Pq referred to as Dq dots . > A > .Tg label > .Sy label > is any string of bytes. > A domain name ending in a dot is called > .Tg absolute > .Sy absolute > or > .Sy fully-qualified ; > a domain name not ending in a dot is called > .Tg relative > .Sy relative > and is processed as if it were followed by a dot and the current origin domain > name, as indicated by the > .Ic $ORIGIN > and > .Ic $INCLUDE > directives (see below). > .Pp > While a label may be any arbitrary string of characters, most domain names in > a zone file will be Internet host names. > A > .Tg host > .Sy host name > is a domain name whose labels consist only of ASCII letters, digits, and > hyphens > .Pq Dq - , > and do not begin or end with a hyphen. > .Pp > A semicolon > .Pq Dq ; > is used to begin a comment. > Text from the semicolon to the end of the line is ignored. > .Pq > A backslash > .Pq Dq \ > followed by a non-digit character quotes the following character and any > special meaning it has is ignored. > Thus, a label may include periods, semicolons, or parentheses by quoting them. > .Sh DIRECTIVES > Directives in a zone file begin with a dollar sign, and affect the processing > of the zone file. > There are only three directives commonly supported by authoritative name > server > daemons: > .Bl -tag -width Ds > .It Ic $ORIGIN Ar origin > Set the absolute name > .Ar origin > as the origin domain for relative names in following resource record entries. > The origin remains the same until another > .Ic $ORIGIN > is reached. > Note that the origin is applied to relative names in both the > .Ar name > field of a resource record and in any fields of the record > .Ar data > that are domain names. > .It Ic $INCLUDE Ar file Op Ar origin > Include and process the contents of > .Ar file > before processing the remaining entries in this file. > If an > .Ar origin > is given, it will be set as the origin when processing records in > .Ar file . > The > .Ic $INCLUDE > directive never changes the current origin of the including file, regardless > of any > .Ic $ORIGIN > or > .Ic $INCLUDE > directives in the included > .Ar file . > .It Ic $TTL Ar ttl > Use > .Ar ttl > as the time-to-live value for all resource records with a blank > .Ar ttl > field. > .El > .Sh RESOURCE RECORDS > A resource record has the general form: > .Bd -ragged -offset indent > .Ar name > .Ar ttl > .Ar class > .Ar type > .Ar data > .Ed > .Pp > The > .Ar name > field is a domain name, as described above. > If it ends with a dot, it is used
Re: new manual: zonefile.5
On Thu, Feb 17, 2022 at 11:31:47AM -0800, Evan Silberman wrote: > Jason McIntyre wrote: > > as a start, i advise you to run your page through mandoc's inbuilt > > checker > > Yep, done. I've addressed all the ones I think I can properly address. > Date still blank, $OpenBSD$ still absent. It also complains that > .Sh FILES is not in its conventional location but I think that's because > I have nonstandard sections after .Sh DESCRIPTION. Those could be > subsections but mdoc(7) allows for nonstandard sections when it aids > legibility, which I think it does here. > you can check the section order in mdoc(7). FILES comes before EXAMPLES. the rest is not needed for now, but we would normally have an $Mdocdate$ tag that expands to the date when committing, and an $OpenBSD$ one for cvs revision. i'm going to wait for any other feedback before actually reviewing the content. jmc > .\" > .\" Copyright (c) 2022 Evan Silberman > .\" Permission to use, copy, modify, and distribute this software for any > .\" purpose with or without fee is hereby granted, provided that the above > .\" copyright notice and this permission notice appear in all copies. > .\" > .\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > .\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > .\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > .\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > .\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > .\" > .Dd > .Dt ZONEFILE 5 > .Os > .Sh NAME > .Nm zonefile > .Nd DNS authoritative zone definition file format > .Sh DESCRIPTION > A > .Nm > is a standardized textual representation of records in the Domain Name System. > Zone files are used to define the records served by authoritative nameservers > such as > .Xr nsd 8 . > .Pp > Zone files are line-oriented; that is, each line of the file is generally a > seperate entry. > An entry can be split onto multiple lines by surrounding data fields with > parentheses. > Any newline characters within parentheses are ignored and the data within > treated as a continuation of the preceding entry. > .Pp > Domain names in a zone file consist of labels separated by periods > .Pq referred to as Dq dots . > A > .Tg label > .Sy label > is any string of bytes. > A domain name ending in a dot is called > .Tg absolute > .Sy absolute > or > .Sy fully-qualified ; > a domain name not ending in a dot is called > .Tg relative > .Sy relative > and is processed as if it were followed by a dot and the current origin domain > name, as indicated by the > .Ic $ORIGIN > and > .Ic $INCLUDE > directives (see below). > .Pp > While a label may be any arbitrary string of characters, most domain names in > a zone file will be Internet host names. > A > .Tg host > .Sy host name > is a domain name whose labels consist only of ASCII letters, digits, and > hyphens > .Pq Dq - , > and do not begin or end with a hyphen. > .Pp > A semicolon > .Pq Dq ; > is used to begin a comment. > Text from the semicolon to the end of the line is ignored. > .Pq > A backslash > .Pq Dq \ > followed by a non-digit character quotes the following character and any > special meaning it has is ignored. > Thus, a label may include periods, semicolons, or parentheses by quoting them. > .Sh DIRECTIVES > Directives in a zone file begin with a dollar sign, and affect the processing > of the zone file. > There are only three directives commonly supported by authoritative name > server > daemons: > .Bl -tag -width Ds > .It Ic $ORIGIN Ar origin > Set the absolute name > .Ar origin > as the origin domain for relative names in following resource record entries. > The origin remains the same until another > .Ic $ORIGIN > is reached. > Note that the origin is applied to relative names in both the > .Ar name > field of a resource record and in any fields of the record > .Ar data > that are domain names. > .It Ic $INCLUDE Ar file Op Ar origin > Include and process the contents of > .Ar file > before processing the remaining entries in this file. > If an > .Ar origin > is given, it will be set as the origin when processing records in > .Ar file . > The > .Ic $INCLUDE > directive never changes the current origin of the including file, regardless > of any > .Ic $ORIGIN > or > .Ic $INCLUDE > directives in the included > .Ar file . > .It Ic $TTL Ar ttl > Use > .Ar ttl > as the time-to-live value for all resource records with a blank > .Ar ttl > field. > .El > .Sh RESOURCE RECORDS > A resource record has the general form: > .Bd -ragged -offset indent > .Ar name > .Ar ttl > .Ar class > .Ar type > .Ar data > .Ed > .Pp > The > .Ar name > field is a domain name, as described above. > If it ends with a dot, it is used as-is. > If its last label is not followed by a dot, a dot
Re: new manual: zonefile.5
Jason McIntyre wrote: > as a start, i advise you to run your page through mandoc's inbuilt > checker Yep, done. I've addressed all the ones I think I can properly address. Date still blank, $OpenBSD$ still absent. It also complains that .Sh FILES is not in its conventional location but I think that's because I have nonstandard sections after .Sh DESCRIPTION. Those could be subsections but mdoc(7) allows for nonstandard sections when it aids legibility, which I think it does here. .\" .\" Copyright (c) 2022 Evan Silberman .\" Permission to use, copy, modify, and distribute this software for any .\" purpose with or without fee is hereby granted, provided that the above .\" copyright notice and this permission notice appear in all copies. .\" .\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES .\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF .\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR .\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES .\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. .\" .Dd .Dt ZONEFILE 5 .Os .Sh NAME .Nm zonefile .Nd DNS authoritative zone definition file format .Sh DESCRIPTION A .Nm is a standardized textual representation of records in the Domain Name System. Zone files are used to define the records served by authoritative nameservers such as .Xr nsd 8 . .Pp Zone files are line-oriented; that is, each line of the file is generally a seperate entry. An entry can be split onto multiple lines by surrounding data fields with parentheses. Any newline characters within parentheses are ignored and the data within treated as a continuation of the preceding entry. .Pp Domain names in a zone file consist of labels separated by periods .Pq referred to as Dq dots . A .Tg label .Sy label is any string of bytes. A domain name ending in a dot is called .Tg absolute .Sy absolute or .Sy fully-qualified ; a domain name not ending in a dot is called .Tg relative .Sy relative and is processed as if it were followed by a dot and the current origin domain name, as indicated by the .Ic $ORIGIN and .Ic $INCLUDE directives (see below). .Pp While a label may be any arbitrary string of characters, most domain names in a zone file will be Internet host names. A .Tg host .Sy host name is a domain name whose labels consist only of ASCII letters, digits, and hyphens .Pq Dq - , and do not begin or end with a hyphen. .Pp A semicolon .Pq Dq ; is used to begin a comment. Text from the semicolon to the end of the line is ignored. .Pq A backslash .Pq Dq \ followed by a non-digit character quotes the following character and any special meaning it has is ignored. Thus, a label may include periods, semicolons, or parentheses by quoting them. .Sh DIRECTIVES Directives in a zone file begin with a dollar sign, and affect the processing of the zone file. There are only three directives commonly supported by authoritative name server daemons: .Bl -tag -width Ds .It Ic $ORIGIN Ar origin Set the absolute name .Ar origin as the origin domain for relative names in following resource record entries. The origin remains the same until another .Ic $ORIGIN is reached. Note that the origin is applied to relative names in both the .Ar name field of a resource record and in any fields of the record .Ar data that are domain names. .It Ic $INCLUDE Ar file Op Ar origin Include and process the contents of .Ar file before processing the remaining entries in this file. If an .Ar origin is given, it will be set as the origin when processing records in .Ar file . The .Ic $INCLUDE directive never changes the current origin of the including file, regardless of any .Ic $ORIGIN or .Ic $INCLUDE directives in the included .Ar file . .It Ic $TTL Ar ttl Use .Ar ttl as the time-to-live value for all resource records with a blank .Ar ttl field. .El .Sh RESOURCE RECORDS A resource record has the general form: .Bd -ragged -offset indent .Ar name .Ar ttl .Ar class .Ar type .Ar data .Ed .Pp The .Ar name field is a domain name, as described above. If it ends with a dot, it is used as-is. If its last label is not followed by a dot, a dot and the current origin are appended. A lone .Tg @ .Dq @ given as the .Ar name is a shorthand for the current origin. If the .Ar name is left blank, by beginning the resource record's line with a space character, the last stated .Ar name in the file will be reused. .Pp The .Ar ttl , or .Dq time-to-live , is a number giving the maximum time, in seconds, for which clients should save and reuse the record before querying for it again. .Pp The .Ar class is a string identifying the DNS namespace the record belongs to. In practice, essentially all DNS records use the class .Dq IN , for .Dq Internet . The only other assigned values for .Ar class are .Dq CH , for .Dq Chaosnet
Re: new manual: zonefile.5
On Thu, Feb 17, 2022 at 09:01:58AM -0800, Evan Silberman wrote: > > Inline below. Since I mistakenly believed my first email didn't go and > just resent it gzipped just in case, I'm now spamming a little bit and I > apologize; I'll chill out now and await more feedback. > hi. as a start, i advise you to run your page through mandoc's inbuilt checker: $ mandoc -Tlint zonefile.5 if any of the issues it flags are unclear, feel free to mail me offlist. then repost your cleaned page. i should say that i'm personally not sure about this page. isn;t this general dns stuff? by that i mean, does openbsd seek to document such aspects? jmc > .\" > .\" Copyright (c) 2022 Evan Silberman > .\" Permission to use, copy, modify, and distribute this software for any > .\" purpose with or without fee is hereby granted, provided that the above > .\" copyright notice and this permission notice appear in all copies. > .\" > .\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > .\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > .\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > .\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > .\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > .\" > .Dd > .Dt ZONEFILE 5 > .Os > .Sh NAME > .Nm zonefile > .Nd DNS authoritative zone definition file format > .Sh DESCRIPTION > A > .Nm > is a standardized textual representation of records in the Domain Name System. > Zone files are used to define the records served by authoritative nameservers > such as > .Xr nsd 8 . > .Pp > Zone files are line-oriented; that is, each line of the file is generally a > seperate entry. > An entry can be split onto multiple lines by surrounding data fields with > parentheses. > Any newline characters within parentheses are ignored and the data within > treated as a continuation of the preceding entry. > .Pp > Domain names in a zone file consist of labels separated by periods > .Pq referred to as Dq dots . > A > .Tg label > .Sy label > is any string of bytes. > A domain name ending in a dot is called > .Tg absolute > .Sy absolute > or > .Sy fully-qualified ; > a domain name not ending in a dot is called > .Tg relative > .Sy relative > and is processed as if it were followed by a dot and the current origin domain > name, as indicated by the > .Ic $ORIGIN > and > .Ic $INCLUDE > directives (see below). > .Pp > While a label may be any arbitrary string of characters, most domain names in > a zone file will be Internet host names. > A > .Tg host > .Sy host name > is a domain name whose labels consist only of ASCII letters, digits, and > hyphens > .Pq Dq - , > and do not begin or end with a hyphen. > .Pp > A semicolon > .Pq Dq ; > is used to begin a comment. > Text from the semicolon to the end of the line is ignored. > .Pq > A backslash > .Pq Dq \ > followed by a non-digit character quotes the following character and any > special meaning it has is ignored. > Thus, a label may include periods, semicolons, or parentheses by quoting them. > .Sh DIRECTIVES > Directives in a zone file begin with a dollar sign, and affect the processing > of the zone file. There are only three directives commonly supported by > authoritative name server daemons: > .Bl -tag -width Ds > .It Ic $ORIGIN Ar origin > Set the absolute name > .Ar origin > as the origin domain for relative names in following resource record entries. > The origin remains the same until another > .Ic $ORIGIN > is reached. > Note that the origin is applied to relative names in both the > .Ar name > field of a resource record and in any fields of the record > .Ar data > that are domain names. > .It Ic $INCLUDE Ar file Op Ar origin > Include and process the contents of > .Ar file > before processing the remaining entries in this file. If an > .Ar origin > is given, it will be set as the origin when processing records in > .Ar file . > The > .Ic $INCLUDE > directive never changes the current origin of the including file, regardless > of any > .Ic $ORIGIN > or > .Ic $INCLUDE > directives in the included > .Ar file . > .It Ic $TTL Ar ttl > Use > .Ar ttl > as the time-to-live value for all resource records with a blank > .Ar ttl > field. > .El > .Sh RESOURCE RECORDS > .Pp > A resource record has the general form: > .Bd -ragged -offset indent > .Ar name > .Ar ttl > .Ar class > .Ar type > .Ar data > .Ed > .Pp > The > .Ar name > field is a domain name, as described above. > If it ends with a dot, it is used as-is. > If its last label is not followed by a dot, a dot and the current origin are > appended. > A lone > .Tg @ > .Dq @ > given as the > .Ar name > is a shorthand for the current origin. > If the > .Ar name > is left blank, by beginning the resource record's line with a space character, >
Re: Driver for PolarFire SoC MSS GPIO controller
Mark Kettenis wrote: > > From: "Theo de Raadt" > > Date: Thu, 17 Feb 2022 09:23:14 -0700 > > > > I am terrified by existance of the userland gpio interface, basically > > the concept that users should be able to change some pin is more than > > suspect, it is crazy. It completely violates the Unix principle of > > mapping hardware support to narrow device catagories on a functional > > basis, which only the right user can use. > > > > The pins a user will change are usually undocumented. They could be > > wired to a bomb. > > > > If these drivers only exposed pins which had *known function*, or which > > are known to be otherwise unused (a pin on a header), that would be fine. > > But that's not how it plays out usually. > > So on these arm/arm64/riscv64 SoCs the situation is a bit different. > The pins are documented, we have a description of their function (the > device tree) and for many boards we even have board schematics. And > many boards are designed for users to play with these GPIOs. Are they documented in terms of this pin should be exposed for user control vs this pin is system-features only Well, yes and no. > And the > pins still need to be configured at securelevel 0 before they actually > can be used from userland. There was a lot of tooth gnashing when we did that, mostly by people who don't deserve the security-layers of Unix..
Re: new manual: zonefile.5
On 2022/02/17 11:16, Dave Voutila wrote: > > Evan Silberman writes: > > > OpenBSD is distributed with an authoritative name server daemon, nsd(8), > > but that distribution doesn't document the format of zone files in > > manual section 5. I thought hey, you should be able to read about zone > > files in the manual. So I took a stab at writing zonefile.5, attached. > > > > I did my best to address nearly all important details of zonefiles as > > standardized, as well as a useful subset of the RR type zoo. Included is > > a description of SRV records, which might not be useful/relevant enough > > for most administrators. Excluded is a description of CAA records, which > > are probably increasingly useful to cautious administrators but which I > > haven't used and seem to have more complexity than I want to boil down > > for a manual. > > > > I am interested in feedback in general, and also specifically on the > > following: > > > > - have I included more detail than OpenBSD might want to be responsible > > for documenting? > > Have you offered similar documentation to the upstream nsd project from > NLnet Labs? https://github.com/NLnetLabs/nsd > > > - have I excluded any RR types that many people will want to read about? > > - have I used mdoc(7) properly? (I use Ic to mark up RR types and Ar to > > mark up the fields of RDATA. Makes sense to me and renders nicely but > > I can understand wanting to dispute this idea.) > > - have I described an RR type or some clarification that's in an RFC I > > didn't reference? > > > > I'm happy to respond to feedback and resubmit complete drafts, but if > > this is promising enough for OpenBSD developers to commit, I'm happy to > > send diffs in response to feedback as well. > > > > I don't work on nsd(8), but getting this into the upstream project and > maintained there would probably make the most sense. I will admit that > since the file isn't inlined in the email, I didn't inspect it so won't > speak to its quality at the moment. They use man formatting not mdoc unfortunately. Could be converted but it's not as *nice* :) (It's equally relevant to BIND and Knot, and at least partially to PowerDNS, all of which seem to use RST as their "base" format for docs). > > If nothing else, this was fun to work on. I've only had a quick read but I like it so far. At least NSD, BIND, knot currently defer to the RFCs for this (mainly 1035 but then you have to pick through a couple of dozen 'updated by' to figure out which extra parts apply) and they're not so informative about real world use, this seems a nice place to mention "gotchas".
Re: Driver for PolarFire SoC MSS GPIO controller
> From: "Theo de Raadt" > Date: Thu, 17 Feb 2022 09:23:14 -0700 > > I am terrified by existance of the userland gpio interface, basically > the concept that users should be able to change some pin is more than > suspect, it is crazy. It completely violates the Unix principle of > mapping hardware support to narrow device catagories on a functional > basis, which only the right user can use. > > The pins a user will change are usually undocumented. They could be > wired to a bomb. > > If these drivers only exposed pins which had *known function*, or which > are known to be otherwise unused (a pin on a header), that would be fine. > But that's not how it plays out usually. So on these arm/arm64/riscv64 SoCs the situation is a bit different. The pins are documented, we have a description of their function (the device tree) and for many boards we even have board schematics. And many boards are designed for users to play with these GPIOs. And the pins still need to be configured at securelevel 0 before they actually can be used from userland. So I think with the changes in place that I asked visa@ to make, we strike a reasonable balance between safety and usability of this board.
Re: new manual: zonefile.5
Oh I guess my first mail made it through after all, dunno what my confusion was. Dave Voutila wrote: > > Evan Silberman writes: > > > OpenBSD is distributed with an authoritative name server daemon, nsd(8), > > but that distribution doesn't document the format of zone files in > > manual section 5. I thought hey, you should be able to read about zone > > files in the manual. So I took a stab at writing zonefile.5, attached. > > > > I did my best to address nearly all important details of zonefiles as > > standardized, as well as a useful subset of the RR type zoo. Included is > > a description of SRV records, which might not be useful/relevant enough > > for most administrators. Excluded is a description of CAA records, which > > are probably increasingly useful to cautious administrators but which I > > haven't used and seem to have more complexity than I want to boil down > > for a manual. > > > > I am interested in feedback in general, and also specifically on the > > following: > > > > - have I included more detail than OpenBSD might want to be responsible > > for documenting? > > Have you offered similar documentation to the upstream nsd project from > NLnet Labs? https://github.com/NLnetLabs/nsd I thought about it, and maybe I'll go that way if carrying this in OpenBSD doesn't get support, but I have more enthusiasm for and familiarity with contributing to OpenBSD and I spend a limited amount of time doing stuff with computers for fun these days so I'm maximizing my enjoyment by submitting here. > I don't work on nsd(8), but getting this into the upstream project and > maintained there would probably make the most sense. I will admit that > since the file isn't inlined in the email, I didn't inspect it so won't > speak to its quality at the moment. Inline below. Since I mistakenly believed my first email didn't go and just resent it gzipped just in case, I'm now spamming a little bit and I apologize; I'll chill out now and await more feedback. .\" .\" Copyright (c) 2022 Evan Silberman .\" Permission to use, copy, modify, and distribute this software for any .\" purpose with or without fee is hereby granted, provided that the above .\" copyright notice and this permission notice appear in all copies. .\" .\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES .\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF .\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR .\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES .\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. .\" .Dd .Dt ZONEFILE 5 .Os .Sh NAME .Nm zonefile .Nd DNS authoritative zone definition file format .Sh DESCRIPTION A .Nm is a standardized textual representation of records in the Domain Name System. Zone files are used to define the records served by authoritative nameservers such as .Xr nsd 8 . .Pp Zone files are line-oriented; that is, each line of the file is generally a seperate entry. An entry can be split onto multiple lines by surrounding data fields with parentheses. Any newline characters within parentheses are ignored and the data within treated as a continuation of the preceding entry. .Pp Domain names in a zone file consist of labels separated by periods .Pq referred to as Dq dots . A .Tg label .Sy label is any string of bytes. A domain name ending in a dot is called .Tg absolute .Sy absolute or .Sy fully-qualified ; a domain name not ending in a dot is called .Tg relative .Sy relative and is processed as if it were followed by a dot and the current origin domain name, as indicated by the .Ic $ORIGIN and .Ic $INCLUDE directives (see below). .Pp While a label may be any arbitrary string of characters, most domain names in a zone file will be Internet host names. A .Tg host .Sy host name is a domain name whose labels consist only of ASCII letters, digits, and hyphens .Pq Dq - , and do not begin or end with a hyphen. .Pp A semicolon .Pq Dq ; is used to begin a comment. Text from the semicolon to the end of the line is ignored. .Pq A backslash .Pq Dq \ followed by a non-digit character quotes the following character and any special meaning it has is ignored. Thus, a label may include periods, semicolons, or parentheses by quoting them. .Sh DIRECTIVES Directives in a zone file begin with a dollar sign, and affect the processing of the zone file. There are only three directives commonly supported by authoritative name server daemons: .Bl -tag -width Ds .It Ic $ORIGIN Ar origin Set the absolute name .Ar origin as the origin domain for relative names in following resource record entries. The origin remains the same until another .Ic $ORIGIN is reached. Note that the origin is applied to relative names in both the .Ar name field of a resource record and in any fields of the
Re: Driver for PolarFire SoC MSS GPIO controller
> Date: Thu, 17 Feb 2022 16:16:30 + > From: Visa Hankala > > On Thu, Feb 17, 2022 at 03:38:05PM +0100, Mark Kettenis wrote: > > > Date: Thu, 17 Feb 2022 13:52:39 + > > > From: Visa Hankala > > > > > > This patch adds a driver for the PolarFire SoC MSS GPIO controller. > > > > > > The driver provides a gpio(4) interface, so the patch also enables > > > gpioctl(8) on riscv64. The MAKEDEV script already creates gpio nodes. > > > > > > OK? > > > > So on arm64 I've been trying to build in protection against userland > > access to GPIOs used by kernel drivers. See for example bcmgpio(4) or > > sxipio(4). I think it would be good if we did the same thing on > > riscv64. > > Sure, here is a revised diff. Now the driver tracks which pins get > configured. The pins that were claimed during autoconfiguration are > skipped when setting up gpio(4). Yes I think that's better. ok kettenis@ > Index: share/man/man4/gpio.4 > === > RCS file: src/share/man/man4/gpio.4,v > retrieving revision 1.27 > diff -u -p -r1.27 gpio.4 > --- share/man/man4/gpio.4 16 May 2020 16:37:49 - 1.27 > +++ share/man/man4/gpio.4 17 Feb 2022 15:45:40 - > @@ -27,6 +27,7 @@ > .Cd "gpio* at glxpcib?" Pq i386 > .Cd "gpio* at gscpcib?" Pq i386 > .Cd "gpio* at isagpio?" > +.Cd "gpio* at mpfgpio?" Pq riscv64 > .Cd "gpio* at nsclpcsio?" > .Cd "gpio* at omgpio?" Pq armv7 > .Cd "gpio* at pcagpio?" > Index: share/man/man4/man4.riscv64/Makefile > === > RCS file: src/share/man/man4/man4.riscv64/Makefile,v > retrieving revision 1.5 > diff -u -p -r1.5 Makefile > --- share/man/man4/man4.riscv64/Makefile 16 Feb 2022 13:07:36 - > 1.5 > +++ share/man/man4/man4.riscv64/Makefile 17 Feb 2022 15:45:40 - > @@ -1,6 +1,6 @@ > #$OpenBSD: Makefile,v 1.5 2022/02/16 13:07:36 visa Exp $ > > -MAN= intro.4 mpfclock.4 mpfiic.4 plic.4 sfcc.4 sfclock.4 sfuart.4 > +MAN= intro.4 mpfclock.4 mpfgpio.4 mpfiic.4 plic.4 sfcc.4 sfclock.4 sfuart.4 > > MANSUBDIR=riscv64 > > Index: share/man/man4/man4.riscv64/mpfgpio.4 > === > RCS file: share/man/man4/man4.riscv64/mpfgpio.4 > diff -N share/man/man4/man4.riscv64/mpfgpio.4 > --- /dev/null 1 Jan 1970 00:00:00 - > +++ share/man/man4/man4.riscv64/mpfgpio.4 17 Feb 2022 15:45:40 - > @@ -0,0 +1,55 @@ > +.\" $OpenBSD$ > +.\" > +.\" Copyright (c) 2022 Visa Hankala > +.\" > +.\" Permission to use, copy, modify, and distribute this software for any > +.\" purpose with or without fee is hereby granted, provided that the above > +.\" copyright notice and this permission notice appear in all copies. > +.\" > +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > +.\" > +.Dd $Mdocdate$ > +.Dt MPFGPIO 4 riscv64 > +.Os > +.Sh NAME > +.Nm mpfgpio > +.Nd Microchip PolarFire SoC MSS GPIO controller > +.Sh SYNOPSIS > +.Cd "mpfgpio* at fdt?" > +.Cd "gpio* at mpfgpio?" > +.Sh DESCRIPTION > +The > +.Nm > +driver provides support for the Microchip PolarFire SoC MSS GPIO controller. > +.Pp > +The PolarFire SoC MSS has three GPIO units: > +.Dv GPIO_0 , > +.Dv GPIO_1 > +and > +.Dv GPIO_2 . > +.Dv GPIO_0 > +and > +.Dv GPIO_1 > +control up to 14 and 24 IOs, respectively. > +These IOs are routed through IOMUXes. > +.Dv GPIO_2 > +controls up to 32 IOs through the FPGA fabric. > +.Pp > +The IOs can be configured as either inputs or outputs, > +and accessed using > +.Xr gpioctl 8 . > +.Sh SEE ALSO > +.Xr gpio 4 , > +.Xr intro 4 , > +.Xr gpioctl 8 > +.Sh HISTORY > +The > +.Nm > +driver first appeared in > +.Ox 7.1 . > Index: sys/arch/riscv64/conf/GENERIC > === > RCS file: src/sys/arch/riscv64/conf/GENERIC,v > retrieving revision 1.34 > diff -u -p -r1.34 GENERIC > --- sys/arch/riscv64/conf/GENERIC 16 Feb 2022 13:07:36 - 1.34 > +++ sys/arch/riscv64/conf/GENERIC 17 Feb 2022 15:45:40 - > @@ -48,6 +48,8 @@ com*at fdt? > cdsdhc* at fdt? > sdmmc* at cdsdhc? > mpfclock*at fdt? early 1 > +mpfgpio* at fdt? > +gpio*at mpfgpio? > mpfiic* at fdt? > iic* at mpfiic? > > Index: sys/arch/riscv64/conf/RAMDISK > === > RCS file: src/sys/arch/riscv64/conf/RAMDISK,v > retrieving revision 1.30 > diff -u -p
Re: Driver for PolarFire SoC MSS GPIO controller
On Thu, Feb 17, 2022 at 09:23:14AM -0700, Theo de Raadt wrote: > I am terrified by existance of the userland gpio interface, basically > the concept that users should be able to change some pin is more than > suspect, it is crazy. It completely violates the Unix principle of > mapping hardware support to narrow device catagories on a functional > basis, which only the right user can use. > > The pins a user will change are usually undocumented. They could be > wired to a bomb. > > If these drivers only exposed pins which had *known function*, or which > are known to be otherwise unused (a pin on a header), that would be fine. > But that's not how it plays out usually. I agree that the userland gpio interface has its flaws. Ignorant or malicious changing of pins can cause unwanted effects, even physical damage. I think "finished" hardware with proper software does not need the userland gpio interface. The mpfgpio(4) driver provides the interface to allow tinkering. The hardware is for DIY purposes.
Re: new manual: zonefile.5
Evan Silberman writes: > OpenBSD is distributed with an authoritative name server daemon, nsd(8), > but that distribution doesn't document the format of zone files in > manual section 5. I thought hey, you should be able to read about zone > files in the manual. So I took a stab at writing zonefile.5, attached. > > I did my best to address nearly all important details of zonefiles as > standardized, as well as a useful subset of the RR type zoo. Included is > a description of SRV records, which might not be useful/relevant enough > for most administrators. Excluded is a description of CAA records, which > are probably increasingly useful to cautious administrators but which I > haven't used and seem to have more complexity than I want to boil down > for a manual. > > I am interested in feedback in general, and also specifically on the > following: > > - have I included more detail than OpenBSD might want to be responsible > for documenting? Have you offered similar documentation to the upstream nsd project from NLnet Labs? https://github.com/NLnetLabs/nsd > - have I excluded any RR types that many people will want to read about? > - have I used mdoc(7) properly? (I use Ic to mark up RR types and Ar to > mark up the fields of RDATA. Makes sense to me and renders nicely but > I can understand wanting to dispute this idea.) > - have I described an RR type or some clarification that's in an RFC I > didn't reference? > > I'm happy to respond to feedback and resubmit complete drafts, but if > this is promising enough for OpenBSD developers to commit, I'm happy to > send diffs in response to feedback as well. > I don't work on nsd(8), but getting this into the upstream project and maintained there would probably make the most sense. I will admit that since the file isn't inlined in the email, I didn't inspect it so won't speak to its quality at the moment. > If nothing else, this was fun to work on. >
Re: Driver for PolarFire SoC MSS GPIO controller
I am terrified by existance of the userland gpio interface, basically the concept that users should be able to change some pin is more than suspect, it is crazy. It completely violates the Unix principle of mapping hardware support to narrow device catagories on a functional basis, which only the right user can use. The pins a user will change are usually undocumented. They could be wired to a bomb. If these drivers only exposed pins which had *known function*, or which are known to be otherwise unused (a pin on a header), that would be fine. But that's not how it plays out usually.
Re: Driver for PolarFire SoC MSS GPIO controller
On Thu, Feb 17, 2022 at 03:38:05PM +0100, Mark Kettenis wrote: > > Date: Thu, 17 Feb 2022 13:52:39 + > > From: Visa Hankala > > > > This patch adds a driver for the PolarFire SoC MSS GPIO controller. > > > > The driver provides a gpio(4) interface, so the patch also enables > > gpioctl(8) on riscv64. The MAKEDEV script already creates gpio nodes. > > > > OK? > > So on arm64 I've been trying to build in protection against userland > access to GPIOs used by kernel drivers. See for example bcmgpio(4) or > sxipio(4). I think it would be good if we did the same thing on > riscv64. Sure, here is a revised diff. Now the driver tracks which pins get configured. The pins that were claimed during autoconfiguration are skipped when setting up gpio(4). Index: share/man/man4/gpio.4 === RCS file: src/share/man/man4/gpio.4,v retrieving revision 1.27 diff -u -p -r1.27 gpio.4 --- share/man/man4/gpio.4 16 May 2020 16:37:49 - 1.27 +++ share/man/man4/gpio.4 17 Feb 2022 15:45:40 - @@ -27,6 +27,7 @@ .Cd "gpio* at glxpcib?" Pq i386 .Cd "gpio* at gscpcib?" Pq i386 .Cd "gpio* at isagpio?" +.Cd "gpio* at mpfgpio?" Pq riscv64 .Cd "gpio* at nsclpcsio?" .Cd "gpio* at omgpio?" Pq armv7 .Cd "gpio* at pcagpio?" Index: share/man/man4/man4.riscv64/Makefile === RCS file: src/share/man/man4/man4.riscv64/Makefile,v retrieving revision 1.5 diff -u -p -r1.5 Makefile --- share/man/man4/man4.riscv64/Makefile16 Feb 2022 13:07:36 - 1.5 +++ share/man/man4/man4.riscv64/Makefile17 Feb 2022 15:45:40 - @@ -1,6 +1,6 @@ # $OpenBSD: Makefile,v 1.5 2022/02/16 13:07:36 visa Exp $ -MAN= intro.4 mpfclock.4 mpfiic.4 plic.4 sfcc.4 sfclock.4 sfuart.4 +MAN= intro.4 mpfclock.4 mpfgpio.4 mpfiic.4 plic.4 sfcc.4 sfclock.4 sfuart.4 MANSUBDIR=riscv64 Index: share/man/man4/man4.riscv64/mpfgpio.4 === RCS file: share/man/man4/man4.riscv64/mpfgpio.4 diff -N share/man/man4/man4.riscv64/mpfgpio.4 --- /dev/null 1 Jan 1970 00:00:00 - +++ share/man/man4/man4.riscv64/mpfgpio.4 17 Feb 2022 15:45:40 - @@ -0,0 +1,55 @@ +.\"$OpenBSD$ +.\" +.\" Copyright (c) 2022 Visa Hankala +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +.\" +.Dd $Mdocdate$ +.Dt MPFGPIO 4 riscv64 +.Os +.Sh NAME +.Nm mpfgpio +.Nd Microchip PolarFire SoC MSS GPIO controller +.Sh SYNOPSIS +.Cd "mpfgpio* at fdt?" +.Cd "gpio* at mpfgpio?" +.Sh DESCRIPTION +The +.Nm +driver provides support for the Microchip PolarFire SoC MSS GPIO controller. +.Pp +The PolarFire SoC MSS has three GPIO units: +.Dv GPIO_0 , +.Dv GPIO_1 +and +.Dv GPIO_2 . +.Dv GPIO_0 +and +.Dv GPIO_1 +control up to 14 and 24 IOs, respectively. +These IOs are routed through IOMUXes. +.Dv GPIO_2 +controls up to 32 IOs through the FPGA fabric. +.Pp +The IOs can be configured as either inputs or outputs, +and accessed using +.Xr gpioctl 8 . +.Sh SEE ALSO +.Xr gpio 4 , +.Xr intro 4 , +.Xr gpioctl 8 +.Sh HISTORY +The +.Nm +driver first appeared in +.Ox 7.1 . Index: sys/arch/riscv64/conf/GENERIC === RCS file: src/sys/arch/riscv64/conf/GENERIC,v retrieving revision 1.34 diff -u -p -r1.34 GENERIC --- sys/arch/riscv64/conf/GENERIC 16 Feb 2022 13:07:36 - 1.34 +++ sys/arch/riscv64/conf/GENERIC 17 Feb 2022 15:45:40 - @@ -48,6 +48,8 @@ com* at fdt? cdsdhc*at fdt? sdmmc* at cdsdhc? mpfclock* at fdt? early 1 +mpfgpio* at fdt? +gpio* at mpfgpio? mpfiic*at fdt? iic* at mpfiic? Index: sys/arch/riscv64/conf/RAMDISK === RCS file: src/sys/arch/riscv64/conf/RAMDISK,v retrieving revision 1.30 diff -u -p -r1.30 RAMDISK --- sys/arch/riscv64/conf/RAMDISK 16 Feb 2022 13:07:36 - 1.30 +++ sys/arch/riscv64/conf/RAMDISK 17 Feb 2022 15:45:40 - @@ -39,6 +39,8 @@ com* at fdt? cdsdhc*at fdt? sdmmc* at cdsdhc? mpfclock* at fdt? early 1 +mpfgpio* at fdt? +gpio* at mpfgpio? mpfiic*
new manual: zonefile.5
OpenBSD is distributed with an authoritative name server daemon, nsd(8), but that distribution doesn't document the format of zone files in manual section 5. I thought hey, you should be able to read about zone files in the manual. So I took a stab at writing zonefile.5, attached. I did my best to address nearly all important details of zonefiles as standardized, as well as a useful subset of the RR type zoo. Included is a description of SRV records, which might not be useful/relevant enough for most administrators. Excluded is a description of CAA records, which are probably increasingly useful to cautious administrators but which I haven't used and seem to have more complexity than I want to boil down for a manual. I am interested in feedback in general, and also specifically on the following: - have I included more detail than OpenBSD might want to be responsible for documenting? - have I excluded any RR types that many people will want to read about? - have I used mdoc(7) properly? (I use Ic to mark up RR types and Ar to mark up the fields of RDATA. Makes sense to me and renders nicely but I can understand wanting to dispute this idea.) - have I described an RR type or some clarification that's in an RFC I didn't reference? I'm happy to respond to feedback and resubmit complete drafts, but if this is promising enough for OpenBSD developers to commit, I'm happy to send diffs in response to feedback as well. If nothing else, this was fun to work on. Regards, Evan Silberman .\" .\" Copyright (c) 2022 Evan Silberman .\" Permission to use, copy, modify, and distribute this software for any .\" purpose with or without fee is hereby granted, provided that the above .\" copyright notice and this permission notice appear in all copies. .\" .\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES .\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF .\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR .\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES .\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. .\" .Dd .Dt ZONEFILE 5 .Os .Sh NAME .Nm zonefile .Nd DNS authoritative zone definition file format .Sh DESCRIPTION A .Nm is a standardized textual representation of records in the Domain Name System. Zone files are used to define the records served by authoritative nameservers such as .Xr nsd 8 . .Pp Zone files are line-oriented; that is, each line of the file is generally a seperate entry. An entry can be split onto multiple lines by surrounding data fields with parentheses. Any newline characters within parentheses are ignored and the data within treated as a continuation of the preceding entry. .Pp Domain names in a zone file consist of labels separated by periods .Pq referred to as Dq dots . A .Tg label .Sy label is any string of bytes. A domain name ending in a dot is called .Tg absolute .Sy absolute or .Sy fully-qualified ; a domain name not ending in a dot is called .Tg relative .Sy relative and is processed as if it were followed by a dot and the current origin domain name, as indicated by the .Ic $ORIGIN and .Ic $INCLUDE directives (see below). .Pp While a label may be any arbitrary string of characters, most domain names in a zone file will be Internet host names. A .Tg host .Sy host name is a domain name whose labels consist only of ASCII letters, digits, and hyphens .Pq Dq - , and do not begin or end with a hyphen. .Pp A semicolon .Pq Dq ; is used to begin a comment. Text from the semicolon to the end of the line is ignored. .Pq A backslash .Pq Dq \ followed by a non-digit character quotes the following character and any special meaning it has is ignored. Thus, a label may include periods, semicolons, or parentheses by quoting them. .Sh DIRECTIVES Directives in a zone file begin with a dollar sign, and affect the processing of the zone file. There are only three directives commonly supported by authoritative name server daemons: .Bl -tag -width Ds .It Ic $ORIGIN Ar origin Set the absolute name .Ar origin as the origin domain for relative names in following resource record entries. The origin remains the same until another .Ic $ORIGIN is reached. Note that the origin is applied to relative names in both the .Ar name field of a resource record and in any fields of the record .Ar data that are domain names. .It Ic $INCLUDE Ar file Op Ar origin Include and process the contents of .Ar file before processing the remaining entries in this file. If an .Ar origin is given, it will be set as the origin when processing records in .Ar file . The .Ic $INCLUDE directive never changes the current origin of the including file, regardless of any .Ic $ORIGIN or .Ic $INCLUDE directives in the included .Ar file . .It Ic $TTL Ar ttl Use .Ar ttl as the
Re: Driver for PolarFire SoC MSS GPIO controller
> Date: Thu, 17 Feb 2022 13:52:39 + > From: Visa Hankala > > This patch adds a driver for the PolarFire SoC MSS GPIO controller. > > The driver provides a gpio(4) interface, so the patch also enables > gpioctl(8) on riscv64. The MAKEDEV script already creates gpio nodes. > > OK? So on arm64 I've been trying to build in protection against userland access to GPIOs used by kernel drivers. See for example bcmgpio(4) or sxipio(4). I think it would be good if we did the same thing on riscv64. > Index: share/man/man4/gpio.4 > === > RCS file: src/share/man/man4/gpio.4,v > retrieving revision 1.27 > diff -u -p -r1.27 gpio.4 > --- share/man/man4/gpio.4 16 May 2020 16:37:49 - 1.27 > +++ share/man/man4/gpio.4 17 Feb 2022 13:45:09 - > @@ -27,6 +27,7 @@ > .Cd "gpio* at glxpcib?" Pq i386 > .Cd "gpio* at gscpcib?" Pq i386 > .Cd "gpio* at isagpio?" > +.Cd "gpio* at mpfgpio?" Pq riscv64 > .Cd "gpio* at nsclpcsio?" > .Cd "gpio* at omgpio?" Pq armv7 > .Cd "gpio* at pcagpio?" > Index: share/man/man4/man4.riscv64/Makefile > === > RCS file: src/share/man/man4/man4.riscv64/Makefile,v > retrieving revision 1.5 > diff -u -p -r1.5 Makefile > --- share/man/man4/man4.riscv64/Makefile 16 Feb 2022 13:07:36 - > 1.5 > +++ share/man/man4/man4.riscv64/Makefile 17 Feb 2022 13:45:09 - > @@ -1,6 +1,6 @@ > #$OpenBSD: Makefile,v 1.5 2022/02/16 13:07:36 visa Exp $ > > -MAN= intro.4 mpfclock.4 mpfiic.4 plic.4 sfcc.4 sfclock.4 sfuart.4 > +MAN= intro.4 mpfclock.4 mpfgpio.4 mpfiic.4 plic.4 sfcc.4 sfclock.4 sfuart.4 > > MANSUBDIR=riscv64 > > Index: share/man/man4/man4.riscv64/mpfgpio.4 > === > RCS file: share/man/man4/man4.riscv64/mpfgpio.4 > diff -N share/man/man4/man4.riscv64/mpfgpio.4 > --- /dev/null 1 Jan 1970 00:00:00 - > +++ share/man/man4/man4.riscv64/mpfgpio.4 17 Feb 2022 13:45:09 - > @@ -0,0 +1,55 @@ > +.\" $OpenBSD$ > +.\" > +.\" Copyright (c) 2022 Visa Hankala > +.\" > +.\" Permission to use, copy, modify, and distribute this software for any > +.\" purpose with or without fee is hereby granted, provided that the above > +.\" copyright notice and this permission notice appear in all copies. > +.\" > +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > +.\" > +.Dd $Mdocdate$ > +.Dt MPFGPIO 4 riscv64 > +.Os > +.Sh NAME > +.Nm mpfgpio > +.Nd Microchip PolarFire SoC MSS GPIO controller > +.Sh SYNOPSIS > +.Cd "mpfgpio* at fdt?" > +.Cd "gpio* at mpfgpio?" > +.Sh DESCRIPTION > +The > +.Nm > +driver provides support for the Microchip PolarFire SoC MSS GPIO controller. > +.Pp > +The PolarFire SoC MSS has three GPIO units: > +.Dv GPIO_0 , > +.Dv GPIO_1 > +and > +.Dv GPIO_2 . > +.Dv GPIO_0 > +and > +.Dv GPIO_1 > +control up to 14 and 24 IOs, respectively. > +These IOs are routed through IOMUXes. > +.Dv GPIO_2 > +controls up to 32 IOs through the FPGA fabric. > +.Pp > +The IOs can be configured as either inputs or outputs, > +and accessed using > +.Xr gpioctl 8 . > +.Sh SEE ALSO > +.Xr gpio 4 , > +.Xr intro 4 , > +.Xr gpioctl 8 > +.Sh HISTORY > +The > +.Nm > +driver first appeared in > +.Ox 7.1 . > Index: sys/arch/riscv64/conf/GENERIC > === > RCS file: src/sys/arch/riscv64/conf/GENERIC,v > retrieving revision 1.34 > diff -u -p -r1.34 GENERIC > --- sys/arch/riscv64/conf/GENERIC 16 Feb 2022 13:07:36 - 1.34 > +++ sys/arch/riscv64/conf/GENERIC 17 Feb 2022 13:45:10 - > @@ -48,6 +48,8 @@ com*at fdt? > cdsdhc* at fdt? > sdmmc* at cdsdhc? > mpfclock*at fdt? early 1 > +mpfgpio* at fdt? > +gpio*at mpfgpio? > mpfiic* at fdt? > iic* at mpfiic? > > Index: sys/arch/riscv64/conf/RAMDISK > === > RCS file: src/sys/arch/riscv64/conf/RAMDISK,v > retrieving revision 1.30 > diff -u -p -r1.30 RAMDISK > --- sys/arch/riscv64/conf/RAMDISK 16 Feb 2022 13:07:36 - 1.30 > +++ sys/arch/riscv64/conf/RAMDISK 17 Feb 2022 13:45:10 - > @@ -39,6 +39,8 @@ com*at fdt? > cdsdhc* at fdt? > sdmmc* at cdsdhc? > mpfclock*at fdt? early 1 > +mpfgpio* at fdt? > +gpio*at mpfgpio? > mpfiic* at fdt? > iic*
Driver for PolarFire SoC MSS GPIO controller
This patch adds a driver for the PolarFire SoC MSS GPIO controller. The driver provides a gpio(4) interface, so the patch also enables gpioctl(8) on riscv64. The MAKEDEV script already creates gpio nodes. OK? Index: share/man/man4/gpio.4 === RCS file: src/share/man/man4/gpio.4,v retrieving revision 1.27 diff -u -p -r1.27 gpio.4 --- share/man/man4/gpio.4 16 May 2020 16:37:49 - 1.27 +++ share/man/man4/gpio.4 17 Feb 2022 13:45:09 - @@ -27,6 +27,7 @@ .Cd "gpio* at glxpcib?" Pq i386 .Cd "gpio* at gscpcib?" Pq i386 .Cd "gpio* at isagpio?" +.Cd "gpio* at mpfgpio?" Pq riscv64 .Cd "gpio* at nsclpcsio?" .Cd "gpio* at omgpio?" Pq armv7 .Cd "gpio* at pcagpio?" Index: share/man/man4/man4.riscv64/Makefile === RCS file: src/share/man/man4/man4.riscv64/Makefile,v retrieving revision 1.5 diff -u -p -r1.5 Makefile --- share/man/man4/man4.riscv64/Makefile16 Feb 2022 13:07:36 - 1.5 +++ share/man/man4/man4.riscv64/Makefile17 Feb 2022 13:45:09 - @@ -1,6 +1,6 @@ # $OpenBSD: Makefile,v 1.5 2022/02/16 13:07:36 visa Exp $ -MAN= intro.4 mpfclock.4 mpfiic.4 plic.4 sfcc.4 sfclock.4 sfuart.4 +MAN= intro.4 mpfclock.4 mpfgpio.4 mpfiic.4 plic.4 sfcc.4 sfclock.4 sfuart.4 MANSUBDIR=riscv64 Index: share/man/man4/man4.riscv64/mpfgpio.4 === RCS file: share/man/man4/man4.riscv64/mpfgpio.4 diff -N share/man/man4/man4.riscv64/mpfgpio.4 --- /dev/null 1 Jan 1970 00:00:00 - +++ share/man/man4/man4.riscv64/mpfgpio.4 17 Feb 2022 13:45:09 - @@ -0,0 +1,55 @@ +.\"$OpenBSD$ +.\" +.\" Copyright (c) 2022 Visa Hankala +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +.\" +.Dd $Mdocdate$ +.Dt MPFGPIO 4 riscv64 +.Os +.Sh NAME +.Nm mpfgpio +.Nd Microchip PolarFire SoC MSS GPIO controller +.Sh SYNOPSIS +.Cd "mpfgpio* at fdt?" +.Cd "gpio* at mpfgpio?" +.Sh DESCRIPTION +The +.Nm +driver provides support for the Microchip PolarFire SoC MSS GPIO controller. +.Pp +The PolarFire SoC MSS has three GPIO units: +.Dv GPIO_0 , +.Dv GPIO_1 +and +.Dv GPIO_2 . +.Dv GPIO_0 +and +.Dv GPIO_1 +control up to 14 and 24 IOs, respectively. +These IOs are routed through IOMUXes. +.Dv GPIO_2 +controls up to 32 IOs through the FPGA fabric. +.Pp +The IOs can be configured as either inputs or outputs, +and accessed using +.Xr gpioctl 8 . +.Sh SEE ALSO +.Xr gpio 4 , +.Xr intro 4 , +.Xr gpioctl 8 +.Sh HISTORY +The +.Nm +driver first appeared in +.Ox 7.1 . Index: sys/arch/riscv64/conf/GENERIC === RCS file: src/sys/arch/riscv64/conf/GENERIC,v retrieving revision 1.34 diff -u -p -r1.34 GENERIC --- sys/arch/riscv64/conf/GENERIC 16 Feb 2022 13:07:36 - 1.34 +++ sys/arch/riscv64/conf/GENERIC 17 Feb 2022 13:45:10 - @@ -48,6 +48,8 @@ com* at fdt? cdsdhc*at fdt? sdmmc* at cdsdhc? mpfclock* at fdt? early 1 +mpfgpio* at fdt? +gpio* at mpfgpio? mpfiic*at fdt? iic* at mpfiic? Index: sys/arch/riscv64/conf/RAMDISK === RCS file: src/sys/arch/riscv64/conf/RAMDISK,v retrieving revision 1.30 diff -u -p -r1.30 RAMDISK --- sys/arch/riscv64/conf/RAMDISK 16 Feb 2022 13:07:36 - 1.30 +++ sys/arch/riscv64/conf/RAMDISK 17 Feb 2022 13:45:10 - @@ -39,6 +39,8 @@ com* at fdt? cdsdhc*at fdt? sdmmc* at cdsdhc? mpfclock* at fdt? early 1 +mpfgpio* at fdt? +gpio* at mpfgpio? mpfiic*at fdt? iic* at mpfiic? Index: sys/arch/riscv64/conf/files.riscv64 === RCS file: src/sys/arch/riscv64/conf/files.riscv64,v retrieving revision 1.19 diff -u -p -r1.19 files.riscv64 --- sys/arch/riscv64/conf/files.riscv64 16 Feb 2022 13:07:36 - 1.19 +++ sys/arch/riscv64/conf/files.riscv64 17 Feb 2022 13:45:10 - @@ -89,6 +89,11 @@ device mpfclock attach mpfclock at fdt file arch/riscv64/dev/mpfclock.c mpfclock +# PolarFire SoC MSS
