Document how unveil(2) permissions correspond to various pledge(2) promises.
unveil considers the operation that happens at namei(9) time, but pledge has a
deeper integration into subsystems, therefore pledge can be more precise.
This change is the result of various experiments. For example the "unix" promise
allows creating files when calling bind(2) on an AF_UNIX socket, we found
requiring the "cpath" promise along with "unix" either required extensive
changes or made the promise set too broad. Similiar applies to connect(2) and
"wpath". Instead document that the unveil permissions "c", "w" and "r"
correspond to a larger set of pledge promises.
ok deraadt
make dwpcie_rk3568_link_up less pedantic about what it considers "up".
ie, only report whether the pcie link is up, don't look at the state
of the up link too. this matches linux behaviour fwiw.
after a warm boot (ie, reboot), the re(4) in my rk3528 based radxa
e20c didnt attach because the pcie link was in a power saving state
instead of the ready state this code was expecting.
jmatthew@ and i have also tested this on a bunch of rk356x boards too.
ok jmatthew@ kettenis@