On Mon, 29 Jul 2019 01:12:44 +0200, Ingo Schwarze wrote:
> My feeling is csh(1) is the odd one out here. The amount of
> cross references from csh(1) to section 2 looks excessive.
Agreed. I noticed this but it wasn't within the scope of the diff
I was writing :-)
> For the umask builtin
On Mon, Jul 29, 2019 at 01:12:44AM +0200, Ingo Schwarze wrote:
> Hi Philip,
>
> Philip Guenther wrote on Thu, Jul 25, 2019 at 07:21:48PM -0900:
>
> > Hmm: sh(1) and ksh(1) have *nothing* from sections 2 or 3 in their SEE
> > ALSO. That doesn't seem like a wrong choice,
>
> Indeed. Jason
Hi Philip,
Philip Guenther wrote on Thu, Jul 25, 2019 at 07:21:48PM -0900:
> Hmm: sh(1) and ksh(1) have *nothing* from sections 2 or 3 in their SEE
> ALSO. That doesn't seem like a wrong choice,
Indeed. Jason generally discourages linking from section 1 to
sections 2 and 3, arguing that
On Sun, Jul 28, 2019 at 08:13:07PM +0200, Klemens Nanni wrote:
> I looked at vmd which does the same and works. The only difference I
> see is ldomctl having a local util.[ch] - could this be an issue? I'm
> out of clues here at the moment.
So of all 33 tools in /usr/src/*bin/ that have an
Rebased diff after kettenis' iodevice manual commit.
Index: Makefile
===
RCS file: /cvs/src/usr.sbin/ldomctl/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- Makefile28 Jul 2019 15:30:45 - 1.9
+++
Stop parsing units manually and let ldom.conf(5) support more units than
'K', 'M' and 'G'.
vm.conf(5) already does so, but through a little wrapper that rounds up;
I've ommitted these additions for the sake of simplicity, but they may
be worth it.
The following diff does that, but on my T5240's
> Date: Sat, 27 Jul 2019 19:35:42 +0200
> From: Klemens Nanni
Please go ahead.
> On Sat, Jul 27, 2019 at 10:43:23AM -0600, Theo de Raadt wrote:
> > Mark Kettenis wrote:
> > > I realuze that eeprom(8) calls these fields, but they're usually just
> > > called variables.
> >
> > makes sense.
>
Normally I'm not very enthusiastic about nic virtual functions, but this
seemed like it might be interesting to work on, because Intel documented
the virtual function interface (it turns out this is only mostly true),
they're claiming future nics will use the same vf interface (this is true
for
