In Sun we always got hammered for this especially among the 3rd party coops as 
the man pages never really had an real world examples, and if they were there 
they were poor, I would keep as many examples as you can as most learn from 
seeing-in-action, instead of being told how.

I could explain process class priority configuration until my mind is numb but 
in the end without seeing the commands that would actually be used it is really 
making your life far harder.

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, 25 October 2020 17:44, Theo de Raadt <dera...@openbsd.org> wrote:

> Jason McIntyre j...@kerhand.co.uk wrote:
>
> > On Sun, Oct 25, 2020 at 10:16:54AM -0600, Theo de Raadt wrote:
> >
> > > Jason McIntyre j...@kerhand.co.uk wrote:
> > >
> > > > whereas /etc/netstart is actually doing:
> > > >
> > > > -   configure non-physical: (1)
> > > >     aggr trunk svlan vlan carp pppoe
> > > >
> > > > -   routing (2)
> > > > -   rest of non-physical: (3)
> > > >     tun tap gif etherip gre egre mobileip pflow wg
> > > >
> > > >
> > > > we could try to keep this list up to date, but it may be easier to just
> > > > generally describe what netstart is doing.
> > >
> > > I think we goes wrong by trying to maintain these as lists, and part of
> > > where this goes wrong is weak definition of the reasons for the
> > > ordering. (Meaning, the developers who tweak netstart to handle the
> > > concerns I'm about to describe, don't tend to think about the manual
> > > page).
> > > The (1) list of non-physical can probably be called "link-layer control
> > > interfaces". Or let's find a name for this. These devices mutate the
> > > presentation of other devices. That's why their configuration needs to
> > > be done before the physical device.
> > > (2) The physical device is then brought up, including IP addressing. The
> > > things in (1) need to be done beforehands, or the physical device is
> > > participating in the wrong layer of network.
> > > the (3) list of non-physical devices are layer-2 or layer-3 and operate
> > > on devices which are already configured with some some sort of
> > > "addressing" configured.
> > > It would be nice to have our networking people come up with nice names
> > > for group (1) and (2); words which succinctly describe the
> > > classification like I've done above. We need to increase understanding
> > > of this order, rather than just abstractly listing names of devices with
> > > complicated behaviours.
> > > Once that is done, I still think it is problematic for us to list all
> > > devices in each catagory:
> > > a) new subsystems will be forgotten
> > > b) the order of instantiation will sometimes be listed wrong -- for some
> > > of these the order is highly significant.
> > > We can try to list as many as possible, but people who want the precise
> > > list (and order) should look in the netstart code. The lists will get
> > > long and wrong. If we find we cannot maintain the lists correctly
> > > because it is duplicated information, man page wording like "such as"
> > > could be used, also something which leads people to consider the script
> > > source as authoritative, ie. have them go read the script
> >
> > ok, here is a start.
> > i have left the description as "non-physical", because i think that is
> > clear. we could easily amend it. ifconfig.8 create talks about "network
> > pseudo-devices" - that could be a possibility.
>
> You've deleted all the interface names, so now there are no examples.
> I disagree strongly. That creates a hurdle and people won't learn how
> our network pieces are configured into a multi-layer stack.


Reply via email to