Re: pvclock(4)
On Mon, Nov 19, 2018 at 01:12:46PM +0100, Reyk Floeter wrote: > Hi, > > the attached diff is another attempt at implementing a pvclock(4) > guest driver. This improves the clock on KVM and replaces the need > for using the VM-expensive acpihpet(4). > > While pvclock(4) is available on KVM, Xen, Hyper-V (in a modified > form), it currently only attaches under KVM: > > pvbus0 at mainbus0: KVM > pvclock0 at pvbus0 Works fine on my proxmox 5.2 / KVM 2.11 dpb build cluster emulating 6x "QEMU Standard PC (Q35 + ICH9, 2009)". Before i had to restart ntpd every 5mn on each hosts, time would drift like crazy under build load. With pvclock it seems the slave clocks are stable and ntpd stays synced. kern.timecounter.tick=1 kern.timecounter.timestepwarnings=0 kern.timecounter.hardware=pvclock0 kern.timecounter.choice=i8254(0) pvclock0(1500) acpihpet0(1000) acpitimer0(1000) dummy(-100) Landry OpenBSD 6.4-current (GENERIC.MP) #0: Tue Nov 20 18:52:03 CET 2018 landry@c64.proxmox2:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4276924416 (4078MB) avail mem = 4138016768 (3946MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5970 (10 entries) bios0: vendor SeaBIOS version "rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org" date 04/01/2014 bios0: QEMU Standard PC (Q35 + ICH9, 2009) acpi0 at bios0: rev 0 acpi0: sleep states S3 S4 S5 acpi0: tables DSDT FACP APIC HPET MCFG acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Common KVM processor, 2933.90 MHz, 0f-06-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,x2APIC,HV,NXE,LONG,LAHF,MELTDOWN cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 999MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Common KVM processor, 2933.54 MHz, 0f-06-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,x2APIC,HV,NXE,LONG,LAHF,MELTDOWN cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu1: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins acpihpet0 at acpi0: 1 Hz acpimcfg0 at acpi0 acpimcfg0: addr 0xb000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1 halt!) "ACPI0006" at acpi0 not configured acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 "PNP0A06" at acpi0
Re: ksh: be even more posixly correct on local/typeset
On 11/21/18 2:19 AM, Philip Guenther wrote: > On Tue, Nov 20, 2018 at 12:47 AM Martijn van Duren < > openbsd+t...@list.imperialat.at> wrote: > >> When running a script with -o posix I usually do so to make sure that >> the script will run anywhere with a POSIX compliant shell. Currently we >> support typeset when running in posix mode, where POSIX states: >> If the command name matches the name of a utility listed in the >> following table, the results are unspecified[0]. >>> snip< >> local >>> snip< >> typeset >>> snip< >> >> When looking at the rationale[1] I found the following: >> Local variables within a function were considered and included in >> another early proposal (controlled by the special built-in local), but >> were removed because they do not fit the simple model developed for >> functions and because there was some opposition to adding yet another >> new special built-in that was not part of historical practice. >> Implementations should reserve the identifier local (as well as typeset, >> as used in the KornShell) in case this local variable mechanism is >> adopted in a future version of this standard. >> >> I know bash supports local and dash has the keyword, but ignores its >> meaning (the variables are still global), but since POSIX is pretty >> vague in how the keyword should be reserved I reckon it would help >> people who want to write portable scripts. >> >> Thoughts? Are people running -o posix in production where this could >> breakage? >> > > "set -o posix" is, IMO, about dealing with the places where ksh and posix > diverge. Using it as a hammer for strict compliance eliminates that middle > ground of "posix behavior with extensions". I would not consider that a > positive direction. > > > Philip Guenther > ACK, I'll drop this.
Re: Vim core dump
def...@posteo.de [def...@posteo.de] wrote: > Hi, all > > Could you be so kind to explain me why OpenBSD has no Dump core issue with > Vim : > https://github.com/vim/vim/issues/3619 > This is the wrong list for random discussion, but obviously, OpenBSD is so far superior it can even help to avoid OTHER people's mistakes :) Chris
Re: xenocara tarball
The FAQ is intended for the average user.
The non-average user can understand what is there, and make different
choices.
People who compile X or the src tree are not average users, and should
create additional partitions to store that stuff.
The FAQ should *NOT* be changed to accomodate the non-average user, because
by doing so you create hell for the average user who is new and doesn't
need that information.
> There is also a related problem with FAQ (and please forgive me for hijacking
> the thread!): if someone follows these instructions to the letter, correcting
> for the file hierarchy, of course, they can end up with no space in /usr.
> Specifically,
>
> a) By default, disklabel(1) allocates at most 2G to /usr when auto-install is
> selected.
> b) With all packages selected during the install, /usr occupies 830M on my
> system:
>
> thor# du -k -d 1 /usr | egrep -v 'ports|X11R6|local|obj|src|usr$|total' | \
>awk '{ t+= $2 }; END { print t }'
>
> 830910
>
> c) ports and xenocara, unpacked, collectively occupy 1G.
>
> That means that after installing all the packages + ports + xenocara, /usr is
> almost full; and during an upgrade, it can be filled completely, which
> happened to me recently.
>
> I'm happy to submit a documentation patch, but I'm not sure what's the right
> approach here - e.g., I can see how any of the following could seem a proper
> solution to some, so I would like to get some input from more experienced
> OpenBSD users:
>
> 0. Do not change anything - if a user install xenocara and ports, she should
> understand what she is doing; and if she ends up eating up all the space in
> /usr, it's a good exercise in recovering and a reminder to plan ahead.
>
> 1. Change the documentation, suggesting that users installing all sources
> (xenocara + ports) should think about space and possibly increase size of
> /usr during the install.
>
> 2. Change the documentation, suggesting other places for placing xenocara
> sources (/usr/local ?)
>
> 3. Change the defaults for disklabel(1), allocating more space to /usr in
> auto-install mode.
>
> #3 would not solve the problem for people with smaller disks, and has a
> potential to eat space for people who don't care about sources. #2 would
> probably break some other examples and people's expectations. So I would
> think either #0 or #1 is the right approach.
>
> Thoughts?
>
>
> On Sun, Nov 11, 2018, at 11:01 AM, Robert Urban wrote:
> > Hello,
> >
> > until v6.2, xenocara.tar.gz contained a hierarchy whose top node was
> > "xenocara",
> > which meant that it should be unpacked with CWD=/usr. Since v6.3 the
> > "xenocara"
> > top node is gone, which means, if one follows these FAQ instructions:
> >
> > > $ *cd /usr/src*
> > > $ *tar xzf /tmp/src.tar.gz*
> > > $ *tar xzf /tmp/sys.tar.gz*
> > > $ *cd /usr*
> > > $ *tar xzf /tmp/ports.tar.gz*
> > > $ *tar xzf /tmp/xenocara.tar.gz*
> >
> > one screws up one's /usr filesystem with a bunch of stuff that does not
> > belong
> > there, and overwrites several files in /usr/share/mk/.
> >
> > Either the FAQ is wrong, or the tarball is wrong. Does anyone think it
> > worthwhile fixing this?
> >
> > Regards,
> >
> > Robert Urban
> >
>
Re: xenocara tarball
I noticed this problem too.
There is also a related problem with FAQ (and please forgive me for hijacking
the thread!): if someone follows these instructions to the letter, correcting
for the file hierarchy, of course, they can end up with no space in /usr.
Specifically,
a) By default, disklabel(1) allocates at most 2G to /usr when auto-install is
selected.
b) With all packages selected during the install, /usr occupies 830M on my
system:
thor# du -k -d 1 /usr | egrep -v 'ports|X11R6|local|obj|src|usr$|total' | \
awk '{ t+= $2 }; END { print t }'
830910
c) ports and xenocara, unpacked, collectively occupy 1G.
That means that after installing all the packages + ports + xenocara, /usr is
almost full; and during an upgrade, it can be filled completely, which happened
to me recently.
I'm happy to submit a documentation patch, but I'm not sure what's the right
approach here - e.g., I can see how any of the following could seem a proper
solution to some, so I would like to get some input from more experienced
OpenBSD users:
0. Do not change anything - if a user install xenocara and ports, she should
understand what she is doing; and if she ends up eating up all the space in
/usr, it's a good exercise in recovering and a reminder to plan ahead.
1. Change the documentation, suggesting that users installing all sources
(xenocara + ports) should think about space and possibly increase size of /usr
during the install.
2. Change the documentation, suggesting other places for placing xenocara
sources (/usr/local ?)
3. Change the defaults for disklabel(1), allocating more space to /usr in
auto-install mode.
#3 would not solve the problem for people with smaller disks, and has a
potential to eat space for people who don't care about sources. #2 would
probably break some other examples and people's expectations. So I would think
either #0 or #1 is the right approach.
Thoughts?
On Sun, Nov 11, 2018, at 11:01 AM, Robert Urban wrote:
> Hello,
>
> until v6.2, xenocara.tar.gz contained a hierarchy whose top node was
> "xenocara",
> which meant that it should be unpacked with CWD=/usr. Since v6.3 the
> "xenocara"
> top node is gone, which means, if one follows these FAQ instructions:
>
> > $ *cd /usr/src*
> > $ *tar xzf /tmp/src.tar.gz*
> > $ *tar xzf /tmp/sys.tar.gz*
> > $ *cd /usr*
> > $ *tar xzf /tmp/ports.tar.gz*
> > $ *tar xzf /tmp/xenocara.tar.gz*
>
> one screws up one's /usr filesystem with a bunch of stuff that does not belong
> there, and overwrites several files in /usr/share/mk/.
>
> Either the FAQ is wrong, or the tarball is wrong. Does anyone think it
> worthwhile fixing this?
>
> Regards,
>
> Robert Urban
>
Re: kernel page fault in vm_teardown
Looking at src changes this is probably expected, Nov 20 snapshot is still
affected.
login: uvm_fault(0x81cbc100, 0x80b6e000, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at uvm_unmap_remove+0x212: movq0x100(%r13),%r8
ddb{7}> set $lines = 0
ddb{7}> show panic
kernel page fault
uvm_fault(0x81cbc100, 0x80b6e000, 0, 1) -> e
uvm_unmap_remove(f3660549fcbefe8b,ff03996f0b60,80b6df00,ff03996f0b50,800022286480,0)
at uvm_unmap_remove+0x212
end trace frame: 0x8000222a50c0, count: 0
ddb{7}> trace
uvm_unmap_remove(f3660549fcbefe8b,ff03996f0b60,80b6df00,ff03996f0b50,800022286480,0)
at uvm_unmap_remove+0x212
uvm_map_deallocate(c213623cf2be5b6) at uvm_map_deallocate+0x5e
vm_teardown(ff03996f0990) at vm_teardown+0xf0
vm_run(f3660549fca69a0f) at vm_run+0x226
VOP_IOCTL(703dbe68b198b2f2,ff03d3ba3c30,a50318ed4b52f246,800022280338,ff043f7ca4e0,3)
at VOP_IOCTL+0x5a
vn_ioctl(51b27f479be0b418,ff03c287f178,800022280338,20) at
vn_ioctl+0x6b
sys_ioctl(f1ce120ec2c9a54e,360,800022280338) at sys_ioctl+0x3ec
syscall(33dbf1b60169518) at syscall+0x32a
Xsyscall(0,36,0,36,118700b52d0,11870035000) at Xsyscall+0x128
end of kernel
end trace frame: 0x11a7a41b340, count: -9
On Sun, Nov 11, 2018 at 9:56 AM Greg Steuck wrote:
> Hi Mike,
>
> > Known issue. And the parameters in the list aren't right (there needs to
> be
> > something added to clang/llvm to support reading the params properly).
>
> This is happening often enough to create toil for running syzkaller with
> VMM. Is there a workaround that you know of? As things stand I end up
> monitoring this machine and rebooting on crashes. While I can automate this
> with some work, it feels deeply unsatisfying.
>
> Thanks
> Greg
>
Re: vmd: add support for local inet6 interfaces
On Tue, Nov 20, 2018 at 03:24:18PM +0100, Reyk Floeter wrote: > Hi > > On Fri, Nov 16, 2018 at 05:35:03PM +0100, Reyk Floeter wrote: > > "local interface" (-L) is an amazing feature and I use it every day; > > but it is IPv4-only and now I realized that I need IPv6 too. > > > > The attached diff implements IPv6 support for local interfaces. > > > > Updated diff with feedback from kn@ and ccardenas@ (thanks, Carlos, > for testing!) with the following changes: > > - keep the auto-generated local inet6 prefix across reloads. > - clarify the manpage describing the fd00::/8 prefix > - comments and minor things > > OK? > > Reyk > I'm good with the updated diff. ok ccardenas@ +--+ Carlos
Re: Add Colemak keyboard encoding
On Fri, 16 Nov 2018 at 07:02:42 -0700, Aaron Bieber wrote:
> On Fri, 16 Nov 2018 at 06:55:09 -0700, Aaron Bieber wrote:
> > Hi,
> >
> > This diff is based off a diff Geert Hendrickx sent to bugs@ back in 2009. I
> > have updated it to add the 'swapctrlcaps' bit and removed the xenocara diff.
> >
> > https://marc.info/?l=openbsd-bugs=124284599329729
> >
> > Not sure if this didn't land because it was sent to bugs@ or if there are
> > other
> > reasons. Please cluestick me if you know!
> >
> > OK?
> >
>
Here is a much cleaner version of the diff which adds proper man
entries and only modifies the keys that are different from KB_US.
OK?
diff --git a/share/man/man4/pckbd.4 b/share/man/man4/pckbd.4
index 45ad55d8765..0135c715bc0 100644
--- a/share/man/man4/pckbd.4
+++ b/share/man/man4/pckbd.4
@@ -162,6 +162,11 @@ British.
.It KB_US
.Pq us
English/US keyboard mapping (default).
+.It KB_US | KB_COLEMAK
+.Pq us.colemak
+English/US keyboard with
+.Dq Colemak
+layout.
.It KB_US | KB_DECLK
.Pq us.declk
English/US mapping for
@@ -180,7 +185,8 @@ variant.
This switches off the
.Dq dead accents .
.Pp
-The KB_BE, KB_FR, KB_FR | KB_DVORAK, KB_JP, KB_UK, KB_US and KB_US | KB_DVORAK
+The KB_BE, KB_FR, KB_FR | KB_DVORAK, KB_JP, KB_UK, KB_US,
+KB_US | KB_DVORAK and KB_US | KB_COLEMAK
mappings can be modified
to swap the left Control and the Caps Lock keys by the
KB_SWAPCTRLCAPS variant bit or the
diff --git a/share/man/man4/ukbd.4 b/share/man/man4/ukbd.4
index af218fa0910..211516596dd 100644
--- a/share/man/man4/ukbd.4
+++ b/share/man/man4/ukbd.4
@@ -198,6 +198,11 @@ British.
.It KB_US
.Pq us
English/US keyboard mapping (default).
+.It KB_US | KB_COLEMAK
+.Pq us.colemak
+English/US keyboard with
+.Dq Colemak
+layout.
.It KB_US | KB_DVORAK
.Pq us.dvorak
English/US keyboard with
@@ -212,8 +217,8 @@ variant.
This switches off the
.Dq dead accents .
.Pp
-The KB_BE, KB_FR, KB_FR | KB_APPLE, KB_FR | KB_DVORAK, KB_JP, KB_UK, KB_US and
-KB_US | KB_DVORAK
+The KB_BE, KB_FR, KB_FR | KB_APPLE, KB_FR | KB_DVORAK, KB_JP, KB_UK, KB_US,
+KB_US | KB_DVORAK and KB_US | KB_COLEMAK
mappings can be modified
to swap the left Control and the Caps Lock keys by the
KB_SWAPCTRLCAPS variant bit or the
diff --git a/sys/dev/pckbc/wskbdmap_mfii.c b/sys/dev/pckbc/wskbdmap_mfii.c
index d10a909eece..8708ef96e11 100644
--- a/sys/dev/pckbc/wskbdmap_mfii.c
+++ b/sys/dev/pckbc/wskbdmap_mfii.c
@@ -597,6 +597,27 @@ static const keysym_t pckbd_keydesc_us_dvorak[] = {
KC(53),KS_z,
};
+static const keysym_t pckbd_keydesc_us_colemak[] = {
+/* pos command normal shifted */
+KC(18),KS_f,
+KC(19),KS_p,
+KC(20),KS_g,
+KC(21),KS_j,
+KC(22),KS_l,
+KC(23),KS_u,
+KC(24),KS_y,
+KC(25),KS_semicolon, KS_colon,
+KC(31),KS_r,
+KC(32),KS_s,
+KC(33),KS_t,
+KC(34),KS_d,
+KC(36),KS_n,
+KC(37),KS_e,
+KC(38),KS_i, KS_I,
+KC(39),KS_o,
+KC(49),KS_k,
+};
+
static const keysym_t pckbd_keydesc_swapctrlcaps[] = {
/* pos command normal shifted */
KC(29),KS_Caps_Lock,
@@ -1129,6 +1150,7 @@ const struct wscons_keydesc pckbd_keydesctab[] = {
KBD_MAP(KB_NO | KB_NODEAD, KB_NO, pckbd_keydesc_no_nodead),
KBD_MAP(KB_US | KB_DECLK, KB_US, pckbd_keydesc_us_declk),
KBD_MAP(KB_US | KB_DVORAK, KB_US, pckbd_keydesc_us_dvorak),
+ KBD_MAP(KB_US | KB_COLEMAK, KB_US, pckbd_keydesc_us_colemak),
KBD_MAP(KB_US | KB_SWAPCTRLCAPS, KB_US, pckbd_keydesc_swapctrlcaps),
KBD_MAP(KB_US | KB_IOPENER, KB_US, pckbd_keydesc_iopener),
KBD_MAP(KB_UK | KB_SWAPCTRLCAPS, KB_UK, pckbd_keydesc_swapctrlcaps),
@@ -1139,6 +1161,8 @@ const struct wscons_keydesc pckbd_keydesctab[] = {
KBD_MAP(KB_BE | KB_SWAPCTRLCAPS, KB_BE, pckbd_keydesc_swapctrlcaps),
KBD_MAP(KB_US | KB_DVORAK | KB_SWAPCTRLCAPS,KB_US | KB_DVORAK,
pckbd_keydesc_swapctrlcaps),
+ KBD_MAP(KB_US | KB_COLEMAK | KB_SWAPCTRLCAPS, KB_US | KB_COLEMAK,
+ pckbd_keydesc_swapctrlcaps),
KBD_MAP(KB_US | KB_IOPENER | KB_SWAPCTRLCAPS, KB_US | KB_IOPENER,
pckbd_keydesc_swapctrlcaps),
KBD_MAP(KB_ES, KB_US, pckbd_keydesc_es),
diff --git a/sys/dev/usb/ukbdmap.c b/sys/dev/usb/ukbdmap.c
index 3cf1dfe18ed..3048f468b85 100644
--- a/sys/dev/usb/ukbdmap.c
+++ b/sys/dev/usb/ukbdmap.c
@@ -626,6 +626,27 @@ static const keysym_t ukbd_keydesc_us_dvorak[] = {
KC(56),KS_z,
};
+static const keysym_t ukbd_keydesc_us_colemak[] = {
+/* pos command
Re: ksh: be even more posixly correct on local/typeset
On Tue, Nov 20, 2018 at 12:47 AM Martijn van Duren < openbsd+t...@list.imperialat.at> wrote: > When running a script with -o posix I usually do so to make sure that > the script will run anywhere with a POSIX compliant shell. Currently we > support typeset when running in posix mode, where POSIX states: > If the command name matches the name of a utility listed in the > following table, the results are unspecified[0]. > >snip< > local > >snip< > typeset > >snip< > > When looking at the rationale[1] I found the following: > Local variables within a function were considered and included in > another early proposal (controlled by the special built-in local), but > were removed because they do not fit the simple model developed for > functions and because there was some opposition to adding yet another > new special built-in that was not part of historical practice. > Implementations should reserve the identifier local (as well as typeset, > as used in the KornShell) in case this local variable mechanism is > adopted in a future version of this standard. > > I know bash supports local and dash has the keyword, but ignores its > meaning (the variables are still global), but since POSIX is pretty > vague in how the keyword should be reserved I reckon it would help > people who want to write portable scripts. > > Thoughts? Are people running -o posix in production where this could > breakage? > "set -o posix" is, IMO, about dealing with the places where ksh and posix diverge. Using it as a hammer for strict compliance eliminates that middle ground of "posix behavior with extensions". I would not consider that a positive direction. Philip Guenther
Re: makemap.8 patch
On Nov 20, 2018 9:15 AM, Gilles Chehade wrote: > > On Sun, Nov 18, 2018 at 08:32:47AM -0600, Edgar Pettijohn III wrote: > > Use new syntax. > > > > Sorry was on the road. > > Comment inlined: > > > > Index: makemap.8 > > > > === > > RCS file: /cvs/src/usr.sbin/smtpd/makemap.8,v > > retrieving revision 1.29 > > diff -u -p -u -r1.29 makemap.8 > > --- makemap.8 ??13 Feb 2016 08:53:18 - ??1.29 > > +++ makemap.8 ??18 Nov 2018 14:29:33 - > > @@ -105,8 +105,11 @@ In addition to adding an entry to the pr > > ??one must add a filter rule that accepts mail for the domain > > ??map, for example: > > ??.Bd -literal -offset indent > > -table domains "/etc/mail/domains" > > -accept for domain deliver to mbox > > +table domains db:/etc/mail/domains.db > > + > > why db ? Do you need makemap for file backend? > > > +action "local" mbox > > + > > +match for domain action "local" > > ??.Ed > > ??.Sh VIRTUAL DOMAINS > > ??Virtual domains may also be kept in tables. > > @@ -140,11 +143,13 @@ In addition to adding an entry to the vi > > ??one must add a filter rule that accepts mail for virtual domains, > > ??for example: > > ??.Bd -literal -offset indent > > -table vdomains "/etc/mail/vdomains" > > -table vusers "/etc/mail/users" > > +table vdomains db:/etc/mail/vdomains.db > > +table vusers db:/etc/mail/users.db > > + > > why db ? > > > +action "local" mbox virtual > > > > -accept for domain virtual deliver to mbox > > -accept for domain example.org virtual deliver to mbox > > +match for domain action "local" > > +match for domain "example.org" action "local" > > ??.Ed > > ??.Sh FILES > > ??.Bl -tag -width "/etc/mail/aliasesXXX" -compact > > > > Documentation should stick to the file backend which is the best one for > the general case. > > The db backend is an extension of the file backend and unless you have a > very specific use case, it brings no benefit whatsoever. It ISN'T faster > than the file backend and unless you have a good rationale for using it, > there's actually no good reason to. > > The only reason we still support it is because some corner cases do make > sense, and even in those cases I'd argue there are better backends. > > > -- > Gilles Chehade @poolpOrg > > https://www.poolp.org tip me: https://paypal.me/poolpOrg
Re: add core4g thermal id to pcidevs
On Sat, Nov 10, 2018 at 04:02:15PM -0500, Daniel Dickman wrote: > Add core 4g thermal id from one of my systems. ok? > sure, ok mlarkin -ml > > Index: pcidevs > === > RCS file: /cvs/src/sys/dev/pci/pcidevs,v > retrieving revision 1.1866 > diff -u -p -u -r1.1866 pcidevs > --- pcidevs 8 Nov 2018 06:54:13 - 1.1866 > +++ pcidevs 10 Nov 2018 20:53:00 - > @@ -3092,6 +3092,7 @@ product INTEL 80960RM 0x0962 i960 RM > product INTEL 80960RN0x0964 i960 RN > product INTEL NVME 0x0953 NVMe > product INTEL CORE4G_D_ULT_GT1 0x0a02 HD Graphics > +product INTEL CORE4G_THERM 0x0a03 Core 4G Thermal > product INTEL CORE4G_HB_10x0a04 Core 4G Host > product INTEL CORE4G_M_ULT_GT1 0x0a06 HD Graphics > product INTEL CORE4G_S_ULT_GT1 0x0a0a HD Graphics >
Re: remove midiplay
On Tue, Nov 20, 2018 at 10:02:33PM +0100, Alexandre Ratchov wrote: > Midiplay requires a midi synth to produce sounds. We dropped support > for OPL2-style chips, as we've two softsynths in ports to render > midi. Both already handle .mid files, so midiplay is not very useful > anymore. > > Objections to remove it? What is the alternative for hardware synths? I used to use this to send sysex messages to reset my mt32 and play midi files back when I still had a machine with a midi interface (via a pci soundcard). > > OK? > > Index: Makefile > === > RCS file: /cvs/src/usr.bin/Makefile,v > retrieving revision 1.157 > diff -u -p -u -p -r1.157 Makefile > --- Makefile 19 Jun 2018 14:01:16 - 1.157 > +++ Makefile 20 Nov 2018 20:17:06 - > @@ -15,7 +15,7 @@ SUBDIR= apply arch at aucat audioctl awk > libtool lndir \ > locale locate lock logger login logname look lorder \ > m4 mail make mandoc mesg mg \ > - midiplay mixerctl mkdep mklocale mktemp nc netstat \ > + mixerctl mkdep mklocale mktemp nc netstat \ > newsyslog \ > nfsstat nice nm nl nohup openssl pagesize passwd paste patch pctr \ > pkg-config pkill \ > Index: midiplay/Makefile > === > RCS file: midiplay/Makefile > diff -N midiplay/Makefile > --- midiplay/Makefile 13 Feb 2010 13:45:29 - 1.2 > +++ /dev/null 1 Jan 1970 00:00:00 - > @@ -1,8 +0,0 @@ > -#$OpenBSD: Makefile,v 1.2 2010/02/13 13:45:29 ratchov Exp $ > -#$NetBSD: Makefile,v 1.1 1998/08/12 21:39:11 augustss Exp $ > -#@(#)Makefile8.1 (Berkeley) 6/6/93 > - > -PROG=midiplay > -LDADD+= -lsndio > - > -.include > Index: midiplay/midiplay.1 > === > RCS file: midiplay/midiplay.1 > diff -N midiplay/midiplay.1 > --- midiplay/midiplay.1 18 Oct 2011 07:07:25 - 1.16 > +++ /dev/null 1 Jan 1970 00:00:00 - > @@ -1,80 +0,0 @@ > -.\" $OpenBSD: midiplay.1,v 1.16 2011/10/18 07:07:25 jmc Exp $ > -.\" $NetBSD: midiplay.1,v 1.3 1998/08/13 18:26:36 augustss Exp $ > -.\" > -.\" Copyright (c) 1998 The NetBSD Foundation, Inc. > -.\" All rights reserved. > -.\" > -.\" Author: Lennart Augustsson > -.\" > -.\" Redistribution and use in source and binary forms, with or without > -.\" modification, are permitted provided that the following conditions > -.\" are met: > -.\" 1. Redistributions of source code must retain the above copyright > -.\"notice, this list of conditions and the following disclaimer. > -.\" 2. Redistributions in binary form must reproduce the above copyright > -.\"notice, this list of conditions and the following disclaimer in the > -.\"documentation and/or other materials provided with the distribution. > -.\" > -.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS > -.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT > LIMITED > -.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A > PARTICULAR > -.\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS > -.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > -.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF > -.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS > -.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN > -.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) > -.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF > THE > -.\" POSSIBILITY OF SUCH DAMAGE. > -.\" > -.Dd $Mdocdate: October 18 2011 $ > -.Dt MIDIPLAY 1 > -.Os > -.Sh NAME > -.Nm midiplay > -.Nd play MIDI files > -.Sh SYNOPSIS > -.Nm midiplay > -.Op Fl gmqvx > -.Op Fl f Ar device > -.Op Fl t Ar tempo > -.Op Ar > -.Sh DESCRIPTION > -The > -.Nm > -command plays MIDI files. > -If no file name is given it will play from standard input; > -otherwise it will play the named files. > -.Pp > -The options are as follows: > -.Bl -tag -width Ds > -.It Fl f Ar device > -Specifies the name of the > -.Xr sndio 7 > -MIDI device. > -.It Fl g > -Send a > -.Dq General MIDI On > -system exclusive message to the device. > -.It Fl m > -Show MIDI file meta events (copyright, lyrics, etc.). > -.It Fl q > -Do not play the MIDI file, just parse it. > -.It Fl t Ar tempo > -Specifies the tempo. > -Default is 100. > -.It Fl v > -Be verbose. > -If the flag is repeated, the verbosity increases. > -.It Fl x > -Play a small sample sound. > -.El > -.Sh SEE ALSO > -.Xr aucat 1 , > -.Xr midi 4 , > -.Xr sndio 7 > -.Sh HISTORY > -The > -.Nm > -command first appeared in > -.Nx 1.4 . > Index: midiplay/midiplay.c > === > RCS file: midiplay/midiplay.c > diff -N midiplay/midiplay.c > --- midiplay/midiplay.c 20 Jul 2018
remove midiplay
Midiplay requires a midi synth to produce sounds. We dropped support for OPL2-style chips, as we've two softsynths in ports to render midi. Both already handle .mid files, so midiplay is not very useful anymore. Objections to remove it? OK? Index: Makefile === RCS file: /cvs/src/usr.bin/Makefile,v retrieving revision 1.157 diff -u -p -u -p -r1.157 Makefile --- Makefile19 Jun 2018 14:01:16 - 1.157 +++ Makefile20 Nov 2018 20:17:06 - @@ -15,7 +15,7 @@ SUBDIR= apply arch at aucat audioctl awk libtool lndir \ locale locate lock logger login logname look lorder \ m4 mail make mandoc mesg mg \ - midiplay mixerctl mkdep mklocale mktemp nc netstat \ + mixerctl mkdep mklocale mktemp nc netstat \ newsyslog \ nfsstat nice nm nl nohup openssl pagesize passwd paste patch pctr \ pkg-config pkill \ Index: midiplay/Makefile === RCS file: midiplay/Makefile diff -N midiplay/Makefile --- midiplay/Makefile 13 Feb 2010 13:45:29 - 1.2 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,8 +0,0 @@ -# $OpenBSD: Makefile,v 1.2 2010/02/13 13:45:29 ratchov Exp $ -# $NetBSD: Makefile,v 1.1 1998/08/12 21:39:11 augustss Exp $ -# @(#)Makefile8.1 (Berkeley) 6/6/93 - -PROG= midiplay -LDADD+=-lsndio - -.include Index: midiplay/midiplay.1 === RCS file: midiplay/midiplay.1 diff -N midiplay/midiplay.1 --- midiplay/midiplay.1 18 Oct 2011 07:07:25 - 1.16 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,80 +0,0 @@ -.\" $OpenBSD: midiplay.1,v 1.16 2011/10/18 07:07:25 jmc Exp $ -.\" $NetBSD: midiplay.1,v 1.3 1998/08/13 18:26:36 augustss Exp $ -.\" -.\" Copyright (c) 1998 The NetBSD Foundation, Inc. -.\" All rights reserved. -.\" -.\" Author: Lennart Augustsson -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\"notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\"notice, this list of conditions and the following disclaimer in the -.\"documentation and/or other materials provided with the distribution. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS -.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED -.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR -.\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS -.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR -.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF -.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS -.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN -.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) -.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE -.\" POSSIBILITY OF SUCH DAMAGE. -.\" -.Dd $Mdocdate: October 18 2011 $ -.Dt MIDIPLAY 1 -.Os -.Sh NAME -.Nm midiplay -.Nd play MIDI files -.Sh SYNOPSIS -.Nm midiplay -.Op Fl gmqvx -.Op Fl f Ar device -.Op Fl t Ar tempo -.Op Ar -.Sh DESCRIPTION -The -.Nm -command plays MIDI files. -If no file name is given it will play from standard input; -otherwise it will play the named files. -.Pp -The options are as follows: -.Bl -tag -width Ds -.It Fl f Ar device -Specifies the name of the -.Xr sndio 7 -MIDI device. -.It Fl g -Send a -.Dq General MIDI On -system exclusive message to the device. -.It Fl m -Show MIDI file meta events (copyright, lyrics, etc.). -.It Fl q -Do not play the MIDI file, just parse it. -.It Fl t Ar tempo -Specifies the tempo. -Default is 100. -.It Fl v -Be verbose. -If the flag is repeated, the verbosity increases. -.It Fl x -Play a small sample sound. -.El -.Sh SEE ALSO -.Xr aucat 1 , -.Xr midi 4 , -.Xr sndio 7 -.Sh HISTORY -The -.Nm -command first appeared in -.Nx 1.4 . Index: midiplay/midiplay.c === RCS file: midiplay/midiplay.c diff -N midiplay/midiplay.c --- midiplay/midiplay.c 20 Jul 2018 21:47:07 - 1.21 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,491 +0,0 @@ -/* $OpenBSD: midiplay.c,v 1.21 2018/07/20 21:47:07 mestre Exp $*/ -/* $NetBSD: midiplay.c,v 1.8 1998/11/25 22:17:07 augustss Exp $*/ - -/* - * Copyright (c) 1998 The NetBSD Foundation, Inc. - * All rights reserved. - * - * This code is derived from software contributed to The NetBSD Foundation - * by Lennart Augustsson (augus...@netbsd.org). - * - * Redistribution and use in source and binary forms, with or without - *
Re: rad: add support for listening on interface groups
On Tue, Nov 20, 2018 at 04:23:33PM +0100, Reyk Floeter wrote:
> On Sat, Nov 17, 2018 at 02:11:58PM +0100, Klemens Nanni wrote:
> > On Fri, Nov 16, 2018 at 08:56:52PM +0100, Reyk Floeter wrote:
> > > > the following diff allows rad(8) to watch interface groups. This
> > > > allows to automatically add/remove interfaces in a given group.
> > > >
> > > > For example, I put "interface tap" into rad.conf and it automatically
> > > > serves my VM interfaces. You could also configure a custom group in
> > > > vm.conf and rad.conf. I'm working on IPv6 for vmd that needs it.
> > Nice idea/work, I like it.
> >
> > > > For reasons that I don't remember, I always missed this feature in
> > > > rtadvd(8)[RIP]. It was amazingly simple to add it to rad(8) as it
> > > > already reinitializes itself on interface changes.
> > > >
> > > > This diff includes the previous ENXIO fix to prevent it from crashing
> > > > when a cloner interface such as tap is destroyed.
> > > >
> > >
> > > Updated diff after committing the ENXIO fix.
> > >
> > > Two explanations:
> > >
> > > - merge_ra_interfaces() calls merge_ra_interface() for each configured
> > > interface (explicit config) and for each member that is found in an
> > > interface group. It is basically just some code shuffling.
> > >
> > > - ra_iface->name is split into ra_iface->name and ra_iface->conf as
> > > "name" indicates and actual (found) interface name ("tap0") and "conf"
> > > is used to lookup the config where it was derived from ("tap" or
> > > "tap0", depending on the configuration).
> > This begs the question about priority in rad.conf(5). It's always been
> > possible to define duplicate `interface' blocks although it didn't make
> > any sense.
> >
> > Now it does since you could define a default config for the entire group
> > and add further interface specific blocks.
> >
> > As it currently is, the first matching block wins, so vether0 would
> > always get RDNS ::11 whether a more specific block exists or not:
> >
> > interface vether { dns { nameserver ::11 } }
> > interface vether0 { dns { nameserver ::22 } }
> >
> > Maybe we should clarify behaviour in rad.conf(5) regardless of your
> > changes?
> >
>
> Updated diff:
> - less indentation in merge_ra_interface()
> - manpage with additional clarification about first match
I removed that part for now, it's only true for interface group vs.
interface.
Interfaces get merged (this is also true for interface groups, it's
just that groups don't get merged with interfaces):
interface vether0 { dns {nameserver ::11 }}
interface vether0 { dns {nameserver ::22 }}
gets parsed as:
interface vether0 {
dns {
nameserver ::11
nameserver ::22
}
}
>
> OK?
>
> Reyk
>
I renamed conf to conf_name and only pass that merge_ra_interface()
since it's the name in the config, not the config itself that we
store.
This is OK florian@ if it works for you.
diff --git frontend.c frontend.c
index 6b96623fb47..700ca3df88b 100644
--- frontend.c
+++ frontend.c
@@ -70,6 +70,7 @@
#include
#include
+#include
#include
#include
#include
@@ -101,6 +102,7 @@ struct ra_iface {
TAILQ_ENTRY(ra_iface) entry;
struct ra_prefix_conf_head prefixes;
charname[IF_NAMESIZE];
+ charconf_name[IF_NAMESIZE];
uint32_tif_index;
int removed;
int prefix_count;
@@ -116,6 +118,7 @@ void frontend_startup(void);
voidicmp6_receive(int, short, void *);
voidjoin_all_routers_mcast_group(struct ra_iface *);
voidleave_all_routers_mcast_group(struct ra_iface *);
+voidmerge_ra_interface(char *, char *);
voidmerge_ra_interfaces(void);
struct ra_iface*find_ra_iface_by_id(uint32_t);
struct ra_iface*find_ra_iface_by_name(char *);
@@ -687,37 +690,84 @@ find_ra_iface_conf(struct ra_iface_conf_head *head, char
*if_name)
return (NULL);
}
+void
+merge_ra_interface(char *name, char *conf_name)
+{
+ struct ra_iface *ra_iface;
+ uint32_t if_index;
+
+ if ((ra_iface = find_ra_iface_by_name(name)) != NULL) {
+ log_debug("keeping interface %s", name);
+ ra_iface->removed = 0;
+ return;
+ }
+
+ log_debug("new interface %s", name);
+ if ((if_index = if_nametoindex(name)) == 0)
+ return;
+ log_debug("adding interface %s", name);
+ if ((ra_iface = calloc(1, sizeof(*ra_iface))) == NULL)
+ fatal("%s", __func__);
+
+ strlcpy(ra_iface->name, name, sizeof(ra_iface->name));
+ strlcpy(ra_iface->conf_name, conf_name,
+ sizeof(ra_iface->conf_name));
+
+
Re: rad: add support for listening on interface groups
On Sat, Nov 17, 2018 at 02:11:58PM +0100, Klemens Nanni wrote:
> On Fri, Nov 16, 2018 at 08:56:52PM +0100, Reyk Floeter wrote:
> > > the following diff allows rad(8) to watch interface groups. This
> > > allows to automatically add/remove interfaces in a given group.
> > >
> > > For example, I put "interface tap" into rad.conf and it automatically
> > > serves my VM interfaces. You could also configure a custom group in
> > > vm.conf and rad.conf. I'm working on IPv6 for vmd that needs it.
> Nice idea/work, I like it.
>
> > > For reasons that I don't remember, I always missed this feature in
> > > rtadvd(8)[RIP]. It was amazingly simple to add it to rad(8) as it
> > > already reinitializes itself on interface changes.
> > >
> > > This diff includes the previous ENXIO fix to prevent it from crashing
> > > when a cloner interface such as tap is destroyed.
> > >
> >
> > Updated diff after committing the ENXIO fix.
> >
> > Two explanations:
> >
> > - merge_ra_interfaces() calls merge_ra_interface() for each configured
> > interface (explicit config) and for each member that is found in an
> > interface group. It is basically just some code shuffling.
> >
> > - ra_iface->name is split into ra_iface->name and ra_iface->conf as
> > "name" indicates and actual (found) interface name ("tap0") and "conf"
> > is used to lookup the config where it was derived from ("tap" or
> > "tap0", depending on the configuration).
> This begs the question about priority in rad.conf(5). It's always been
> possible to define duplicate `interface' blocks although it didn't make
> any sense.
>
> Now it does since you could define a default config for the entire group
> and add further interface specific blocks.
>
> As it currently is, the first matching block wins, so vether0 would
> always get RDNS ::11 whether a more specific block exists or not:
>
> interface vether { dns { nameserver ::11 } }
> interface vether0 { dns { nameserver ::22 } }
>
> Maybe we should clarify behaviour in rad.conf(5) regardless of your
> changes?
>
Updated diff:
- less indentation in merge_ra_interface()
- manpage with additional clarification about first match
OK?
Reyk
Index: usr.sbin/rad/frontend.c
===
RCS file: /cvs/src/usr.sbin/rad/frontend.c,v
retrieving revision 1.17
diff -u -p -u -p -r1.17 frontend.c
--- usr.sbin/rad/frontend.c 16 Nov 2018 19:45:40 - 1.17
+++ usr.sbin/rad/frontend.c 20 Nov 2018 15:21:16 -
@@ -70,6 +70,7 @@
#include
#include
+#include
#include
#include
#include
@@ -101,6 +102,7 @@ struct ra_iface {
TAILQ_ENTRY(ra_iface) entry;
struct ra_prefix_conf_head prefixes;
charname[IF_NAMESIZE];
+ charconf[IF_NAMESIZE];
uint32_tif_index;
int removed;
int prefix_count;
@@ -116,6 +118,7 @@ void frontend_startup(void);
voidicmp6_receive(int, short, void *);
voidjoin_all_routers_mcast_group(struct ra_iface *);
voidleave_all_routers_mcast_group(struct ra_iface *);
+voidmerge_ra_interface(struct ra_iface_conf *, char *);
voidmerge_ra_interfaces(void);
struct ra_iface*find_ra_iface_by_id(uint32_t);
struct ra_iface*find_ra_iface_by_name(char *);
@@ -688,36 +691,81 @@ find_ra_iface_conf(struct ra_iface_conf_
}
void
+merge_ra_interface(struct ra_iface_conf *ra_iface_conf, char *name)
+{
+ struct ra_iface *ra_iface;
+ uint32_t if_index;
+
+ if ((ra_iface = find_ra_iface_by_name(name)) != NULL) {
+ log_debug("keeping interface %s", name);
+ ra_iface->removed = 0;
+ return;
+ }
+
+ log_debug("new interface %s", name);
+ if ((if_index = if_nametoindex(name)) == 0)
+ return;
+ log_debug("adding interface %s", name);
+ if ((ra_iface = calloc(1, sizeof(*ra_iface))) == NULL)
+ fatal("%s", __func__);
+
+ strlcpy(ra_iface->name, name, sizeof(ra_iface->name));
+ strlcpy(ra_iface->conf, ra_iface_conf->name,
+ sizeof(ra_iface->conf));
+
+ ra_iface->if_index = if_index;
+ SIMPLEQ_INIT(_iface->prefixes);
+ TAILQ_INSERT_TAIL(_interfaces, ra_iface, entry);
+ join_all_routers_mcast_group(ra_iface);
+}
+
+void
merge_ra_interfaces(void)
{
struct ra_iface_conf*ra_iface_conf;
struct ra_prefix_conf *ra_prefix_conf;
struct ra_iface *ra_iface;
- uint32_t if_index;
+ struct ifgroupreqifgr;
+ struct ifg_req *ifg;
+ char*name;
+ unsigned int len;
Re: makemap.8 patch
On Sun, Nov 18, 2018 at 08:32:47AM -0600, Edgar Pettijohn III wrote: > Use new syntax. > Sorry was on the road. Comment inlined: > Index: makemap.8 > > === > RCS file: /cvs/src/usr.sbin/smtpd/makemap.8,v > retrieving revision 1.29 > diff -u -p -u -r1.29 makemap.8 > --- makemap.8 ??13 Feb 2016 08:53:18 - ??1.29 > +++ makemap.8 ??18 Nov 2018 14:29:33 - > @@ -105,8 +105,11 @@ In addition to adding an entry to the pr > ??one must add a filter rule that accepts mail for the domain > ??map, for example: > ??.Bd -literal -offset indent > -table domains "/etc/mail/domains" > -accept for domain deliver to mbox > +table domains db:/etc/mail/domains.db > + why db ? > +action "local" mbox > + > +match for domain action "local" > ??.Ed > ??.Sh VIRTUAL DOMAINS > ??Virtual domains may also be kept in tables. > @@ -140,11 +143,13 @@ In addition to adding an entry to the vi > ??one must add a filter rule that accepts mail for virtual domains, > ??for example: > ??.Bd -literal -offset indent > -table vdomains "/etc/mail/vdomains" > -table vusers "/etc/mail/users" > +table vdomains db:/etc/mail/vdomains.db > +table vusers db:/etc/mail/users.db > + why db ? > +action "local" mbox virtual > > -accept for domain virtual deliver to mbox > -accept for domain example.org virtual deliver to mbox > +match for domain action "local" > +match for domain "example.org" action "local" > ??.Ed > ??.Sh FILES > ??.Bl -tag -width "/etc/mail/aliasesXXX" -compact > Documentation should stick to the file backend which is the best one for the general case. The db backend is an extension of the file backend and unless you have a very specific use case, it brings no benefit whatsoever. It ISN'T faster than the file backend and unless you have a good rationale for using it, there's actually no good reason to. The only reason we still support it is because some corner cases do make sense, and even in those cases I'd argue there are better backends. -- Gilles Chehade @poolpOrg https://www.poolp.org tip me: https://paypal.me/poolpOrg
Re: vmd: add support for local inet6 interfaces
Hi
On Fri, Nov 16, 2018 at 05:35:03PM +0100, Reyk Floeter wrote:
> "local interface" (-L) is an amazing feature and I use it every day;
> but it is IPv4-only and now I realized that I need IPv6 too.
>
> The attached diff implements IPv6 support for local interfaces.
>
Updated diff with feedback from kn@ and ccardenas@ (thanks, Carlos,
for testing!) with the following changes:
- keep the auto-generated local inet6 prefix across reloads.
- clarify the manpage describing the fd00::/8 prefix
- comments and minor things
OK?
Reyk
Index: usr.sbin/vmd/config.c
===
RCS file: /cvs/src/usr.sbin/vmd/config.c,v
retrieving revision 1.54
diff -u -p -u -p -r1.54 config.c
--- usr.sbin/vmd/config.c 26 Oct 2018 11:24:45 - 1.54
+++ usr.sbin/vmd/config.c 20 Nov 2018 14:22:49 -
@@ -42,17 +42,44 @@
/* Supported bridge types */
const char *vmd_descsw[] = { "switch", "bridge", NULL };
+static int config_init_localprefix(struct vmd_config *);
+
+static int
+config_init_localprefix(struct vmd_config *cfg)
+{
+ struct sockaddr_in6 *sin6;
+
+ if (host(VMD_DHCP_PREFIX, >cfg_localprefix) == -1)
+ return (-1);
+
+ /* IPv6 is disabled by default */
+ cfg->cfg_flags &= ~VMD_CFG_INET6;
+
+ /* Generate random IPv6 prefix only once */
+ if (cfg->cfg_flags & VMD_CFG_AUTOINET6)
+ return (0);
+ if (host(VMD_ULA_PREFIX, >cfg_localprefix6) == -1)
+ return (-1);
+ /* Randomize the 56 bits "Global ID" and "Subnet ID" */
+ sin6 = ss2sin6(>cfg_localprefix6.ss);
+ arc4random_buf(>sin6_addr.s6_addr[1], 7);
+ cfg->cfg_flags |= VMD_CFG_AUTOINET6;
+
+ return (0);
+}
+
int
config_init(struct vmd *env)
{
- struct privsep *ps = >vmd_ps;
- unsigned int what;
+ struct privsep *ps = >vmd_ps;
+ unsigned int what;
/* Global configuration */
ps->ps_what[PROC_PARENT] = CONFIG_ALL;
ps->ps_what[PROC_VMM] = CONFIG_VMS;
- if (host(VMD_DHCP_PREFIX, >vmd_cfg.cfg_localprefix) == -1)
+ /* Local prefix */
+ if (config_init_localprefix(>vmd_cfg) == -1)
return (-1);
/* Other configuration */
@@ -90,7 +117,7 @@ config_purge(struct vmd *env, unsigned i
__func__, ps->ps_title[privsep_process]);
/* Reset global configuration (prefix was verified before) */
- (void)host(VMD_DHCP_PREFIX, >vmd_cfg.cfg_localprefix);
+ config_init_localprefix(>vmd_cfg);
/* Reset other configuration */
what = ps->ps_what[privsep_process] & reset;
Index: usr.sbin/vmd/dhcp.c
===
RCS file: /cvs/src/usr.sbin/vmd/dhcp.c,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 dhcp.c
--- usr.sbin/vmd/dhcp.c 17 Aug 2018 07:12:28 - 1.5
+++ usr.sbin/vmd/dhcp.c 20 Nov 2018 14:22:49 -
@@ -109,7 +109,7 @@ dhcp_request(struct vionet_dev *dev, cha
resp.xid = req.xid;
if ((client_addr.s_addr =
- vm_priv_addr(>vmd_cfg.cfg_localprefix,
+ vm_priv_addr(>vmd_cfg,
dev->vm_vmid, dev->idx, 1)) == 0)
return (-1);
memcpy(, _addr,
@@ -119,7 +119,7 @@ dhcp_request(struct vionet_dev *dev, cha
ss2sin(_dst)->sin_port = htons(CLIENT_PORT);
if ((server_addr.s_addr =
- vm_priv_addr(>vmd_cfg.cfg_localprefix,
+ vm_priv_addr(>vmd_cfg,
dev->vm_vmid, dev->idx, 0)) == 0)
return (-1);
memcpy(, _addr,
Index: usr.sbin/vmd/parse.y
===
RCS file: /cvs/src/usr.sbin/vmd/parse.y,v
retrieving revision 1.48
diff -u -p -u -p -r1.48 parse.y
--- usr.sbin/vmd/parse.y1 Nov 2018 00:18:44 - 1.48
+++ usr.sbin/vmd/parse.y20 Nov 2018 14:22:49 -
@@ -120,9 +120,9 @@ typedef struct {
%token INCLUDE ERROR
-%token ADD ALLOW BOOT CDROM DISABLE DISK DOWN ENABLE FORMAT GROUP INSTANCE
-%token INTERFACE LLADDR LOCAL LOCKED MEMORY NIFS OWNER PATH PREFIX RDOMAIN
-%token SIZE SOCKET SWITCH UP VM VMID
+%token ADD ALLOW BOOT CDROM DISABLE DISK DOWN ENABLE FORMAT GROUP INET6
+%token INSTANCE INTERFACE LLADDR LOCAL LOCKED MEMORY NIFS OWNER PATH PREFIX
+%token RDOMAIN SIZE SOCKET SWITCH UP VM VMID
%token NUMBER
%token STRING
%typelladdr
@@ -181,10 +181,27 @@ varset: STRING '=' STRING {
}
;
-main : LOCAL PREFIX STRING {
+main : LOCAL INET6 {
+ env->vmd_cfg.cfg_flags |= VMD_CFG_INET6;
+ }
+ | LOCAL INET6 PREFIX STRING {
+ struct address h;
+
+ if (host($4, ) == -1 ||
+ h.ss.ss_family != AF_INET6 ||
+ h.prefixlen > 64 || h.prefixlen <
ksh: be even more posixly correct on local/typeset
When running a script with -o posix I usually do so to make sure that
the script will run anywhere with a POSIX compliant shell. Currently we
support typeset when running in posix mode, where POSIX states:
If the command name matches the name of a utility listed in the
following table, the results are unspecified[0].
>snip<
local
>snip<
typeset
>snip<
When looking at the rationale[1] I found the following:
Local variables within a function were considered and included in
another early proposal (controlled by the special built-in local), but
were removed because they do not fit the simple model developed for
functions and because there was some opposition to adding yet another
new special built-in that was not part of historical practice.
Implementations should reserve the identifier local (as well as typeset,
as used in the KornShell) in case this local variable mechanism is
adopted in a future version of this standard.
I know bash supports local and dash has the keyword, but ignores its
meaning (the variables are still global), but since POSIX is pretty
vague in how the keyword should be reserved I reckon it would help
people who want to write portable scripts.
Thoughts? Are people running -o posix in production where this could
breakage?
martijn@
[0]
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01
[1]
https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap02.html#tag_23_02_09_18
Index: c_ksh.c
===
RCS file: /cvs/src/bin/ksh/c_ksh.c,v
retrieving revision 1.61
diff -u -p -r1.61 c_ksh.c
--- c_ksh.c 18 May 2018 13:25:20 - 1.61
+++ c_ksh.c 20 Nov 2018 08:45:57 -
@@ -577,6 +577,11 @@ c_typeset(char **wp)
/* called with 'typeset -' */
break;
case 't': /* typeset */
+ if (Flag(FPOSIX)) {
+ bi_errorf(
+ "typeset not supported in posixly correct mode");
+ return 1;
+ }
local = 1;
break;
}
