Re: Patch for install64.octeon : EdgeRouter 6 info
That looks much better to me, though it does get machine-specific
I feel like it would be more clear if the examples uniformly used your
new variable
convention, as some do and some do not. This allows us to eliminate one example
too. (I assume the ER Lite does OK if you specify numcores=1 ? )
I left in the ER Lite machine-specific example about resetting the USB
controller.
I only booted my new ER6 from USB a few times before switching to MMC,
but it did not seem to have any issues detecting the USB controller or devices.
(It WAS picky about what USB sticks it would work correctly with.)
This is a diff from -current's /usr/src/distrib/notes/octeon/install
me@box> diff -u install install.ori
--- install Thu Dec 20 19:17:00 2018
+++ install.ori Thu Dec 20 19:04:07 2018
@@ -56,8 +56,8 @@
${bootcmd} is run by U-Boot when ${autoload} is enabled. Now create a new
${bootcmd} which will load an ELF file called 'bsd' from the first active FAT
-partition on the first CF card. The FAT partition has been created by the
-installer.
+partition on the first CF card or USB device. The FAT partition has
been created
+by the installer.
# setenv bootcmd 'fatload ide 0:1 ${loadaddr} bsd;bootoctlinux
rootdev=/dev/octcf0'
# setenv bootdelay 5
@@ -71,24 +71,19 @@
Protected 1 sectors
#
-In the following bootcmd examples, replace:
- with the disklabel(8) UID (DUID) of your root disk.
- with ``mmc'', ``sata'' or ``usb'' as appropriate.
- with the number of CPU cores your machine has.
+If you have installed onto USB use the following bootcmd instead:
-If you have installed onto eMMC, SATA or USB, use the following
-bootcmd instead:
+ fatload usb 0 ${loadaddr} bsd; bootoctlinux rootdev=sd0
- fatload 0 ${loadaddr} bsd; bootoctlinux rootdev=sd0 numcores=
+On multi-core systems, the numcores parameter enables the secondary CPUs.
+Use the total number of cores on your system as the value of the parameter.
-For stable root disk selection, you can specify the disk by disklabel(8) UID:
+ fatload usb 0 ${loadaddr} bsd; bootoctlinux rootdev=sd0 numcores=2
- fatload 0 ${loadaddr} bsd; bootoctlinux rootdev=
numcores=
-
On the EdgeRouter Lite, bootcmd may also reset the USB controller for
more reliable USB device detection:
- usb reset; fatload usb 0 ${loadaddr} bsd; bootoctlinux rootdev=sd0
numcores=
+ usb reset; fatload usb 0 ${loadaddr} bsd; bootoctlinux rootdev=sd0 numcores=2
OpenBSDCongratulations
On Tue, Dec 18, 2018 at 11:40 AM Visa Hankala wrote:
>
> On Mon, Dec 17, 2018 at 11:22:40PM -0500, Chris McGee wrote:
> > Hi:
> >
> > I would like to add some info for Edgerouter 6
> > (and presumably ER4, and maybe also ER12?) to install64.octeon.
> > The document is great but it won't get a new user booting on the new
> > 4-core machines with MMC drives.
> >
> > I tried to make it as brief as possible while pointing the user in the right
> > direction, so for example it mentions that you're going to need to drop
> > bsd.mp into the msdos kernel loader partition but doesn't explain how
> > to do that. Seemed to be the right level of detail for this document.
> >
> > Here is a diff with my additions. Diff is from
> > /OpenBSD/6.4/INSTALL.octeon.
> >
> > me@box> diff INSTALL.octeon INSTALL.octeon.er6
> > 690a691,692
> > > For the EdgeRouter Lite:
> > >
> > 702a705,710
> > > For the EdgeRouter 6, installing to the internal MMC drive:
> > >
> > > # setenv bootcmd 'fatload mmc 0 ${loadaddr} bsd;bootoctlinux
> > > coremask=0xf rootdev=/dev/sd0'
> > > # setenv bootdelay 5
> > > # saveenv
> > >
> > 707c715
> > < On multi-core systems, the numcores parameter enables the secondary CPUs.
> > ---
> > > On multi-core systems, the numcores parameter enables multiple cores.
> > 708a717,719
> > > Note that this boot command does not actually put a multiprocessor kernel
> > > in
> > > place; you will also need to copy the bsd.mp kernel to the octeon MS-DOS
> > > partition (disklabel i by default) on your boot drive for multicore
> > > support.
> > 709a721
> > > Example booting from USB on the Edgerouter Lite:
> > 711a724,726
> > > Example booting from USB on the EdgeRouter 6:
> > > fatload usb 0 ${loadaddr} bsd; bootoctlinux rootdev=sd0 numcores=4
> > >
> > 716a732,736
> > > If you installed from a USB stick to the MMC on an EdgeRouter 4/6/8:
> > > The machine assigns sd0 to USB first if present, then to MMC if present.
> > > If you leave the USB install stick in, the machine will try to boot it.
> > > Removing the USB device will cause sd0 to be assigned to mmc0 next boot,
> > > allowing the machine to boot your newly-installed OpenBSD drive.
>
> Good points. However, I would like to keep the text general and avoid
> listing machine specifics if possible. Does the patch below make the
> text any clearer?
>
> In principle, the installer could show an example bootoctlinux command
> with the correct parameters for the system.
>
> Future snapshots built after today
Re: mandoc -T html default style
Hi Theo, Theo de Raadt wrote on Thu, Dec 20, 2018 at 03:58:31PM -0700: > Ingo Schwarze wrote: >> 1. Install /var/www/htdocs/mandoc.css by default. > I object to adding something to that directory. > > I think it should be empty so that users have nothing else surprising > in it when they start using it. I see the point, and it makes sense to me. So in case people want a sensible default for "-O style=" as suggested, where should the file go? Maybe /usr/share/misc/mandoc.css ? Yours, Ingo
Re: mandoc -T html default style
> 1. Install /var/www/htdocs/mandoc.css by default. I object to adding something to that directory. I think it should be empty so that users have nothing else surprising in it when they start using it. Speaking of which I think the bgplg parts should not be in there by default, either. Web servers are exclusively designed for distributing manual pages.
Re: mandoc -T html default style
Hi Ted, hi Raphael,
Ted Unangst wrote on Thu, Dec 20, 2018 at 11:36:06AM -0500:
> Raphael Graf wrote:
>> The diff inserts some space above the footer.
>> This improves readability and makes it similar to the other output formats.
>>
>> Here is an example found in the wild, demonstrating the problem:
>> https://webassembly.github.io/wabt/doc/wasm-objdump.1.html
How did that page get generated? By some Github automatic or
half-automatic infrastructure, and if so, how exactly? Or did the
maintainers of "webassembly" simply generate that file by hand?
Also, is that URI linked to from anywhere? It tried clicking around
the "webassembly" website, but failed to find any link to the URI
you cite.
> So I think one answer to this problem is "use the provided mandoc.css".
Absolutely.
Or if it doesn't meet your needs exactly, edit it, then use your
edited version.
Or if it doesn't meet your needs at all, write your own, using
mandoc.css as documenation of the available classes.
> However, that's not the default.
> But perhaps it, or a variant of it, should be.
I certainly love sensible defaults and hate the lack of them,
but in the past, i considered sensible defaults impossible
for "-O style=" because it is kind of hard to guess the file
system layout on the user's system, so we don't know which
absolute path to use in the line
.
Let's try again.
What do you think about the following plan:
1. Let's install /var/www/htdocs/mandoc.css by default.
2. When calling "mandoc -T html" without specifying "-O style=",
fall back to "-O style=/var/www/htdocs/mandoc.css" by default.
That might be sensible because it is adequate for local
viewing of the file, which is likely intended with files
generated in such a manual way.
If the user then goes ahead and copies these files onto a
webserver, they of course cannot work because the document root
must be stripped from the "-O style=" argument in that case.
Also, if the user copies these files onto a non-OpenBSD system,
they stop working there, too.
3. To build HTML without any whatsoever,
require "-O style=" to be explicitly specified with an empty path.
4. Document all that in the mandoc(1) manual page below "HTML Output".
5. In man.cgi(8), we already use the equivalent
of "-O style=/mandoc.css" by default, unless CSS_DIR is
configured in cgi.h. That won't change.
> I guess one objection to always using mandoc.css is that it's
> another file that may get lost.
That's not really a counter-argument because nothing becomes worse.
Currently, by default, you never have a good stylesheet, and if you
configure one, it can already get lost, maybe even more easily
because it is not installed by default. With the above plan, you
get a working stylesheet by default for some simple cases, and you
can still build HTML files with a different one or even without any
if you want to.
By the way, not that man.conf(5) already supports the
output style /path/to/my.css
directive.
> And perhaps it's a touch too large to inline?
Not a very convincing counter-argument either. If you use an
external stylesheet, which is almost always by far the most sensible
thing to do, nothing gets inlined in the first place. With the
above plan, in the unusual case that the user explicitly request
that no external stylesheet be used, inlining the whole thing is
still better than inlining something stunted, like we do now, i
think. Look at arbitrary websites nowdays: almost all serve
ridiculous amounts of boilerplate styling stuff. The size of
mandoc.css is really not a problem by comparision, and much less
for a corner case that isn't recommended anyway.
> But we can trim it down some to where I think it can be reasonably inlined in
> every html and I don't think there will be many complaints about bloat.
>
> This is only a start. I noticed there's a lot of redundant definitions, and by
> inverting the selector property grouping we can trim many lines off the file.
> I don't think this impedes readability of maintenance. On the contrary,
> (personally) I find it easier to see all the italic tags in one place versus
> scanning a list of mostly identical looking elements. But that may just be the
> way I look at it.
>
> A few more operations like this, and elimination of the emtpy { } sets and I
> think we can consider inlining this as a default style instead of the current
> minimal one. Maybe we embed this minimized version but provide the full file
> complete with empty blocks for local customization?
Right, the full version has the dupes and empties to help customization,
so i do not want to delete those from the full version.
I'm not opposed to inlining the version you suggest instead of the
current minimal stylesheet, and the additional maintenance effort
seems tolerable. It isn't zero though, there is a risk of both
versions getting out of sync.
So should i go ahead and do the following?
1. Install
pf.4 pfctl.8: s/drivers/groups/
All interface drivers have their interface group, but users can create
extra, driver independent groups as well.
# ifconfig lo0 group foo
# pfctl -sI -ifoo
foo
lo0
Feedback? OK?
Index: share/man/man4/pf.4
===
RCS file: /cvs/src/share/man/man4/pf.4,v
retrieving revision 1.89
diff -u -p -r1.89 pf.4
--- share/man/man4/pf.4 12 Oct 2017 14:39:24 - 1.89
+++ share/man/man4/pf.4 20 Dec 2018 20:34:10 -
@@ -916,7 +916,7 @@ will be set to the length of the buffer
.It Dv DIOCCLRSRCNODES
Clear the tree of source tracking nodes.
.It Dv DIOCIGETIFACES Fa "struct pfioc_iface *io"
-Get the list of interfaces and interface drivers known to
+Get the list of interfaces and interface groups known to
.Nm .
All the ioctls that manipulate interfaces
use the same structure described below:
@@ -933,7 +933,7 @@ struct pfioc_iface {
.Pp
If not empty,
.Va pfiio_name
-can be used to restrict the search to a specific interface or driver.
+can be used to restrict the search to a specific interface or group.
.Va pfiio_buffer[pfiio_size]
is the user-supplied buffer for returning the data.
On entry,
Index: sbin/pfctl/pfctl.8
===
RCS file: /cvs/src/sbin/pfctl/pfctl.8,v
retrieving revision 1.172
diff -u -p -r1.172 pfctl.8
--- sbin/pfctl/pfctl.8 18 Sep 2018 12:55:19 - 1.172
+++ sbin/pfctl/pfctl.8 20 Dec 2018 20:23:51 -
@@ -392,7 +392,7 @@ Show the list of tables.
.It Fl s Cm osfp
Show the list of operating system fingerprints.
.It Fl s Cm Interfaces
-Show the list of interfaces and interface drivers available to PF.
+Show the list of interfaces and interface groups available to PF.
When used together with
.Fl v ,
it additionally lists which interfaces have skip rules activated.
Re: mandoc -T html default style
Raphael Graf wrote:
> The diff inserts some space above the footer.
> This improves readability and makes it similar to the other output formats.
>
> Here is an example found in the wild, demonstrating the problem:
> https://webassembly.github.io/wabt/doc/wasm-objdump.1.html
So I think one answer to this problem is "use the provided mandoc.css".
However, that's not the default. But perhaps it, or a variant of it, should
be.
I guess one objection to always using mandoc.css is that it's another file
that may get lost. And perhaps it's a touch too large to inline?
But we can trim it down some to where I think it can be reasonably inlined in
every html and I don't think there will be many complaints about bloat.
This is only a start. I noticed there's a lot of redundant definitions, and by
inverting the selector property grouping we can trim many lines off the file.
I don't think this impedes readability of maintenance. On the contrary,
(personally) I find it easier to see all the italic tags in one place versus
scanning a list of mostly identical looking elements. But that may just be the
way I look at it.
A few more operations like this, and elimination of the emtpy { } sets and I
think we can consider inlining this as a default style instead of the current
minimal one. Maybe we embed this minimized version but provide the full file
complete with empty blocks for local customization?
Index: mandoc.css
===
RCS file: /cvs/src/usr.bin/mandoc/mandoc.css,v
retrieving revision 1.29
diff -u -p -r1.29 mandoc.css
--- mandoc.css 4 Dec 2018 06:11:44 - 1.29
+++ mandoc.css 20 Dec 2018 16:27:46 -
@@ -171,27 +171,13 @@ td.foot-os { text-align: right; }
/* Semantic markup for command line utilities. */
-table.Nm { }
-code.Nm { font-style: normal;
- font-weight: bold;
- font-family: inherit; }
-.Fl { font-style: normal;
- font-weight: bold;
- font-family: inherit; }
-.Cm { font-style: normal;
- font-weight: bold;
- font-family: inherit; }
-.Ar { font-style: italic;
- font-weight: normal; }
+code.Nm, .Fl, .Cm, .Ic, .Ev { font-style: normal; }
+.Ar, .Pa { font-style: italic; }
+code.Nm, .Fl, .Cm, .Ic { font-weight: bold; }
+.Ar, .Ev, .Pa { font-weight: normal; }
+code.Nm, .Fl, .Cm, .Ic { font-family: inherit; }
+.Ev { font-family: monospace; }
.Op { display: inline; }
-.Ic { font-style: normal;
- font-weight: bold;
- font-family: inherit; }
-.Ev { font-style: normal;
- font-weight: normal;
- font-family: monospace; }
-.Pa { font-style: italic;
- font-weight: normal; }
/* Semantic markup for function libraries. */
mandoc -T html default style
The diff inserts some space above the footer.
This improves readability and makes it similar to the other output formats.
Here is an example found in the wild, demonstrating the problem:
https://webassembly.github.io/wabt/doc/wasm-objdump.1.html
Index: html.c
===
RCS file: /cvs/src/usr.bin/mandoc/html.c,v
retrieving revision 1.117
diff -u -p -u -p -r1.117 html.c
--- html.c 15 Dec 2018 23:33:20 - 1.117
+++ html.c 20 Dec 2018 13:38:14 -
@@ -183,6 +183,8 @@ print_gen_head(struct html *h)
t = print_otag(h, TAG_STYLE, "");
print_text(h, "table.head, table.foot { width: 100%; }");
print_endline(h);
+ print_text(h, "table.foot { margin-top: 3em; }");
+ print_endline(h);
print_text(h, "td.head-rtitle, td.foot-os { text-align: right; }");
print_endline(h);
print_text(h, "td.head-vol { text-align: center; }");
Re: pcap_dispatch() returning zero
No really, it reads 20 packets and returns zero.
On Dec 08 13:56:09, h...@stare.cz wrote:
> The return value of pcap_dispatch() is described in pcap.3 as follows:
>
> The number of packets read is returned.
> Zero is returned when EOF is reached in a savefile.
> A return of -1 indicates an error in which case ...
>
> It will also return zero on the last short read (as "EOF is reached").
> So if you read the packets in chunks of 100, like
>
> while ((r = pcap_dispatch(src, 100, callback, NULL)) > 0) {
> /* ... */
> }
> if (r == 0) {
> /* EOF */
> } else if (r == -1) {
> /* ERROR */
> }
>
> and the file contains 120 packets, you will have
> r == 100 the first time (reading 100 packets) and
> r == 0 the second time (reading 20 packets).
>
> It seems there is no way for the caller to know
> how many packets were actually there in the last short read
> besides counting the packets himself in the callback().
>
> Is that intended? It seems more natural, and less surprising,
> to have it return the actual number of packets. That would make
> the sequence above 100, then 20, then 0 (like read(2) does).
>
> Anyway, should this be explicitly mentioned in the manpage?
>
> Jan
>
>
> Index: pcap.3
> ===
> RCS file: /cvs/src/lib/libpcap/pcap.3,v
> retrieving revision 1.48
> diff -u -p -r1.48 pcap.3
> --- pcap.33 Jun 2018 10:45:15 - 1.48
> +++ pcap.38 Dec 2018 12:53:59 -
> @@ -345,7 +345,11 @@ and a
> .Fa u_char
> pointer to the packet data.
> The number of packets read is returned.
> -Zero is returned when EOF is reached in a savefile.
> +Zero is returned when EOF is reached in a savefile;
> +this includes a short read near the end of savefile,
> +when less than
> +.Fa cnt
> +packets are available.
> A return of \-1 indicates an error in which case
> .Fn pcap_perror
> or
>
Re: undocumented nfs mount option "intr"
On Thu, Dec 20, 2018 at 09:31:45AM +0100, Landry Breuil wrote: > On Thu, Dec 20, 2018 at 09:26:33AM +0100, Solene Rapenne wrote: > > Hi > > > > fstab(5) has an example for a nfs mountpoint using the "intr" option. > > > > That option isn't documented in mount(8) or mount_nfs(8) and in fact, I've > > not > > been able to find it anywhere. What is it doing? > > I think it's the fstab shortcut for -i option in mount_nfs(8). > Looking at mntopt mopts[] in mount_nfs.c there are way more nfs specifc options that are only documented as getopt flags and not as -o flags. -Otto
Re: undocumented nfs mount option "intr"
On Thu, Dec 20, 2018 at 09:26:33AM +0100, Solene Rapenne wrote: > Hi > > fstab(5) has an example for a nfs mountpoint using the "intr" option. > > That option isn't documented in mount(8) or mount_nfs(8) and in fact, I've not > been able to find it anywhere. What is it doing? I think it's the fstab shortcut for -i option in mount_nfs(8).
undocumented nfs mount option "intr"
Hi fstab(5) has an example for a nfs mountpoint using the "intr" option. That option isn't documented in mount(8) or mount_nfs(8) and in fact, I've not been able to find it anywhere. What is it doing?
