Re: new USB audio class v2.0 driver
On Tue, Jan 01, 2019 at 11:02:39PM -, Christian Weisgerber wrote: > On 2018-12-31, Alexandre Ratchov wrote: > > > Our current USB sub-system has limitations that currently allow only > > the following combinations: > > - USB v2 devices on ehci(4) only > > - USB v1 devices on uhci(4), ohci(4) or ehci(4) root hub only > > > > If you have an audio device that is class compliant (aka vendor claims > > it's "driverless" on MacOS) *and* one of the above host/hub/device > > combinations then I'd be very interested in test reports. > > Just to clarify: The new driver supports ONLY these combinations. > well, the old one supports only these as well, except that it prints no error message. > The majority of people who have xhci don't need to try: > uaudio0: xhci(4) not supported yet, try another port Thanks for insisting on this. Until the xhci driver is finished, those who absolutly want to test/use the new uaudio driver could try to disable xhci on the boot prompt. On most machines, ehci will attach instead of xhci. This would allow using usb 2.0 devices out of the box. To test usb 1.1 devices, you also need to have a usb connectors on the ehci root hub, certain machines have them, others don't. On those which have them, there's a compagnion uhci device, example: usb0 at ehci0: USB revision 2.0 usb1 at uhci0: USB revision 1.0 usb2 at uhci1: USB revision 1.0 usb3 at uhci2: USB revision 1.0 usb4 at uhci3: USB revision 1.0 uhub0 at usb1 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1 uhub1 at usb2 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1 uhub2 at usb3 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1 uhub3 at usb4 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1 uhub4 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 uaudio0 at uhub1 port 1 configuration 1 interface 1 "ABC C-Media USB Headphone Set" rev 1.10/1.00 addr 2 uaudio0: class v1, full-speed, sync, channels: 2 play, 1 rec, 8 ctls
teach arm64 to print unconfigured simplebus devices
This makes it more obvious what interesting things there are to hack on.
Thoughts? ok?
For example, from an od1000:
dlg@o1000 fdt$ dmesg | grep 'not configured'
"v2m" at ampintc0 not configured
"clk100mhz_0" at simplebus0 not configured
"clk375mhz" at simplebus0 not configured
"clk333mhz" at simplebus0 not configured
"clk500mhz_0" at simplebus0 not configured
"clk500mhz_1" at simplebus0 not configured
"clk250mhz_4" at simplebus0 not configured
"clk100mhz_1" at simplebus0 not configured
"i2c" at simplebus0 not configured
"i2c" at simplebus0 not configured
"ssp" at simplebus0 not configured
"ssp" at simplebus0 not configured
"gpio" at simplebus0 not configured
"gpio" at simplebus0 not configured
"gpio" at simplebus0 not configured
"gpio" at simplebus0 not configured
"AMD A1100 Host" rev 0x00 at pci0 dev 0 function 0 not configured
"AMD A1100 Host" rev 0x00 at pci0 dev 2 function 0 not configured
"ccn" at simplebus0 not configured
"gwdt" at simplebus0 not configured
"kcs" at simplebus0 not configured
"clk250mhz_0" at simplebus0 not configured
"clk250mhz_1" at simplebus0 not configured
"clk250mhz_2" at simplebus0 not configured
"clk250mhz_3" at simplebus0 not configured
and an rpi3:
"dma" at simplebus0 not configured
"cprman" at simplebus0 not configured
"mailbox" at simplebus0 not configured
"gpio" at simplebus0 not configured
"mmc" at simplebus0 not configured
"dsi" at simplebus0 not configured
"local_intc" at simplebus0 not configured
"sdhci" at simplebus0 not configured
"gpiomem" at simplebus0 not configured
"firmware" at simplebus0 not configured
"power" at simplebus0 not configured
"fb" at simplebus0 not configured
"vchiq" at simplebus0 not configured
"vcsm" at simplebus0 not configured
"arm-pmu" at simplebus0 not configured
"virtgpio" at simplebus0 not configured
"expgpio" at simplebus0 not configured
"clock" at simplebus1 not configured
"clock" at simplebus1 not configured
id show pine64 too, but miniroot64.fs doesnt seem to like it at the
moment.
Index: simplebus.c
===
RCS file: /cvs/src/sys/arch/arm64/dev/simplebus.c,v
retrieving revision 1.8
diff -u -p -r1.8 simplebus.c
--- simplebus.c 1 Jun 2017 21:19:07 - 1.8
+++ simplebus.c 2 Jan 2019 04:50:49 -
@@ -149,6 +149,26 @@ simplebus_submatch(struct device *self,
return 0;
}
+int
+simplebus_print(void *aux, const char *pnp)
+{
+ struct fdt_attach_args *fa = aux;
+ char name[32];
+
+ if (!pnp)
+ return (QUIET);
+
+ if (OF_getprop(fa->fa_node, "name", name, sizeof(name)) > 0) {
+ name[sizeof(name) - 1] = 0;
+ printf("\"%s\"", name);
+ } else
+ printf("node %u", fa->fa_node);
+
+ printf(" at %s", pnp);
+
+return (UNCONF);
+}
+
/*
* Look for a driver that wants to be attached to this node.
*/
@@ -221,7 +241,8 @@ simplebus_attach_node(struct device *sel
fa.fa_dmat->_flags |= BUS_DMA_COHERENT;
}
- config_found_sm(self, , NULL, simplebus_submatch);
+ config_found_sm(self, , sc->sc_early ? NULL : simplebus_print,
+ simplebus_submatch);
free(fa.fa_reg, M_DEVBUF, fa.fa_nreg * sizeof(struct fdt_reg));
free(fa.fa_intr, M_DEVBUF, fa.fa_nintr * sizeof(uint32_t));
Re: new USB audio class v2.0 driver
Thanks Alexandre! This is right off the top of my wish list. I tested with the following hardware: Sony UDA-1 (UACv2) Schiit Fulla (UACv1) Initial tests have audio playing great through both. > Then do your regular audio work, let me know how it works and > send me output of: > > dmesg > mixerctl -v -f /dev/mixer1 With the Fulla I get the following output from mixerctl: $ mixerctl -v -f /dev/mixer1 outputs.play_mute=off [ off on ] record.enable=sysctl [ off on sysctl ] But, with the UDA-1 I get an error. Though audio still plays great: $ mixerctl -v -f /dev/mixer1 mixerctl: AUDIO_MIXER_READ: Input/output error dmesg follows -- Mike M OpenBSD 6.4-current (GENERIC.MP) #0: Tue Jan 1 19:08:27 MST 2019 capt8bit@navi.local:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17118175232 (16325MB) avail mem = 16590073856 (15821MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xbff3c020 (11 entries) bios0: vendor coreboot version "CBET4000 20181210" date 11/22/2018 bios0: LENOVO 3368CTO acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT MCFG TCPA APIC HPET acpi0: wakeup devices HDEF(S4) EHC1(S4) EHC2(S4) XHC_(S4) SLPB(S3) LID_(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xf000, bus 0-63 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i3-3227U CPU @ 1.90GHz, 1895.98 MHz, 06-3a-09 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i3-3227U CPU @ 1.90GHz, 1895.70 MHz, 06-3a-09 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i3-3227U CPU @ 1.90GHz, 1895.70 MHz, 06-3a-09 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i3-3227U CPU @ 1.90GHz, 1895.70 MHz, 06-3a-09 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 1 (RP01) acpiprt1 at acpi0: bus 2 (RP02) acpiprt2 at acpi0: bus 3 (RP03) acpiprt3 at acpi0: bus 4 (RP04) acpiprt4 at acpi0: bus -1 (RP05) acpiprt5 at acpi0: bus -1 (RP06) acpiprt6 at acpi0: bus -1 (RP07) acpiprt7 at acpi0: bus -1 (RP08) acpiprt8 at acpi0: bus 0 (PCI0) acpiec0 at acpi0 acpicpu0 at acpi0: C3(200@90 mwait.1@0x30), C2(500@63 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(200@90 mwait.1@0x30), C2(500@63 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(200@90 mwait.1@0x30), C2(500@63 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C3(200@90 mwait.1@0x30), C2(500@63 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpitz0 at acpi0: critical temperature is 100 degC acpipwrres0 at acpi0: FPWR, resource for FAN_ acpitz1 at acpi0: critical temperature is 99 degC acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpiac0 at acpi0: AC unit offline acpibat0 at acpi0: BAT0 model "45N1176" serial 2589 type LION oem "SANYO" acpibat1 at acpi0: BAT1 not present acpibtn0 at acpi0: SLPB acpibtn1 at acpi0: LID_ acpithinkpad0 at acpi0 acpicmos0 at acpi0 tpm0 at acpi0: TPM_ addr 0xfed4/0x5000: device 0x104a rev
Re: Another attempt to bypass ifqs on interfaces
On Sun, Dec 23, 2018 at 01:53:48PM -0200, Martin Pieuchot wrote:
> On 20/12/18(Thu) 11:35, David Gwynne wrote:
> > My last attempt in "let etherip(4) output directly to the ip stack"
> > didn't go so well. This one at least doesn't break bridge(4) on
> > Ethernet.
>
> It breaks it on mpw(4).
I argue that mpw(4) is broken anyway, but this would make it worse, yes.
> > This diff effectively turns if_enqueue into a per interface function
> > pointer. Things still call if_enqueue(), which does some pf stuff, and then
> > it calls ifp->if_enqueue. By default, that function pointer is
> > if_enqueue_ifq() which puts the packet on the interface send queues.
> >
> > Ethernet interfaces intercept the call to if_enqueue_ifq(). They get set
> > up to call ether_enqueue, which does the bridge stuff and then calls
> > ac->ac_enqueue, which shadows the ifp->if_enqueue functionality.
>
> Why do we need two abstraction layers? It feels weird to have
> pseudo-drivers rely on a pointer in 'struct arpcom', because
> they don't necessarily need this structure.
If a pseudo-driver pretends to be Ethernet it will have arpcom. The main
reason to have two layers for Ethernet interfaces is to take bridge(4)
knowledge out of the generic interface code.
> > This takes Ethernet bridge(4) knowledge out of the generic interface
> > code. Non-Ethernet things that want to bypass ifqs can override
> > ifp->if_enqueue. Ethernet things can override ac->ac_enqueue.
>
> Why take it out of the generic? We spent a lot of energy putting it
> there, now you're taking the opposite direction. So let's spread
> NBRIDGE > 1 all over the stack again?
The bridge stuff would just be in if_ethersubr.c. Hopefully.
if_isconnected() would be harder to pull apart.
>
> > This diff includes a change to vlan(4) to take advantage of this. It
> > overrides ac_enqueue with vlan_enqueue(). So a packet sent out a vlan
> > interface will go into if_enqueue(), which will call ether_enqueue()
> > because ether_ifattach set that up. ether_enqueue() will call
> > ac->ac_enqueue which is vlan_enqueue on vlan interfaces, which will
> > eventually call if_enqueue() on the parent interface.
>
> I like the idea behind vlan_transmit().
>
> > There are some things I'd like to try if this goes in. eg, it may be
> > possible to have ether_enqueue simple call ac->ac_enqueue, and let
> > bridge(4) swap it out with bridge_enqueue code. Doing that now would
> > complicate the diff though.
>
> Why? What's the gain?
Avoiding a conditional in a hotpath?
> > Anyway, how's this look, esp relative to the previous diff?
>
> It looks better but I'm afraid this diff still breaks stuff, I'd
> suggest you to keep your fix simple. I'm afraid with all the
> abstractions that you're introducing. They look like premature
> optimizations to me.
Fair enough.
> One more comment below.
>
> > Index: net/if.c
> > ===
> > RCS file: /cvs/src/sys/net/if.c,v
> > retrieving revision 1.569
> > diff -u -p -r1.569 if.c
> > --- net/if.c11 Dec 2018 22:08:57 - 1.569
> > +++ net/if.c19 Dec 2018 06:48:37 -
> > @@ -683,34 +685,33 @@ if_qstart_compat(struct ifqueue *ifq)
> > int
> > if_enqueue(struct ifnet *ifp, struct mbuf *m)
> > {
> > - unsigned int idx;
> > - struct ifqueue *ifq;
> > - int error;
> > -
> > #if NPF > 0
> > if (m->m_pkthdr.pf.delay > 0)
> > return (pf_delay_pkt(m, ifp->if_index));
> > -#endif
> > -
> > -#if NBRIDGE > 0
> > - if (ifp->if_bridgeport && (m->m_flags & M_PROTO1) == 0) {
> > - KERNEL_LOCK();
> > - error = bridge_output(ifp, m, NULL, NULL);
> > - KERNEL_UNLOCK();
> > - return (error);
> > - }
> > -#endif
> >
> > -#if NPF > 0
> > pf_pkt_addr_changed(m);
> > #endif /* NPF > 0 */
>
> Are you sure calling pf_pkt_addr_changed() before bridge_output() won't
> create any unwanted side effect? In any case I'd suggest keeping this
> separated, to be able to revert it easily :D
bridge calls if_enqueue to send a packet out, so it'll get
pf_pkt_addr_changed() called on the new interface either way. However,
policy via pf on bridge would be affected.
Unpreoptimising the code gets us back to the original order though.
How's this look?
Index: if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.569
diff -u -p -r1.569 if.c
--- if.c11 Dec 2018 22:08:57 - 1.569
+++ if.c30 Dec 2018 02:56:06 -
@@ -632,6 +632,8 @@ if_attach_common(struct ifnet *ifp)
if (ifp->if_rtrequest == NULL)
ifp->if_rtrequest = if_rtrequest_dummy;
+ if (ifp->if_enqueue == NULL)
+ ifp->if_enqueue = if_enqueue_ifq;
ifp->if_llprio = IFQ_DEFPRIO;
SRPL_INIT(>if_inputs);
@@ -683,10 +685,6 @@ if_qstart_compat(struct ifqueue *ifq)
int
if_enqueue(struct ifnet *ifp, struct mbuf
Re: new USB audio class v2.0 driver
On 2018-12-31, Alexandre Ratchov wrote: > Our current USB sub-system has limitations that currently allow only > the following combinations: > - USB v2 devices on ehci(4) only > - USB v1 devices on uhci(4), ohci(4) or ehci(4) root hub only > > If you have an audio device that is class compliant (aka vendor claims > it's "driverless" on MacOS) *and* one of the above host/hub/device > combinations then I'd be very interested in test reports. Just to clarify: The new driver supports ONLY these combinations. The majority of people who have xhci don't need to try: uaudio0: xhci(4) not supported yet, try another port -- Christian "naddy" Weisgerber na...@mips.inka.de
ospfd: send router lsa when removing an interface
Hi tech,
when removing an interface from ospdf.conf and doing a reload other
OSPF routers should get a router LSA update. Then they can remove the
affected route. But currently this does not happen. The affected route
might be used by other routers a long time after removing it from the
config (until the LSA ages out).
Below diff fixes this.
OK?
Remi
Index: ospfd.c
===
RCS file: /cvs/src/usr.sbin/ospfd/ospfd.c,v
retrieving revision 1.102
diff -u -p -r1.102 ospfd.c
--- ospfd.c 28 Dec 2018 19:25:10 - 1.102
+++ ospfd.c 1 Jan 2019 21:23:38 -
@@ -827,7 +827,7 @@ merge_interfaces(struct area *a, struct
/* problems:
* - new interfaces (easy)
-* - deleted interfaces (needs to be done via fsm?)
+* - deleted interfaces
* - changing passive (painful?)
*/
for (i = LIST_FIRST(>iface_list); i != NULL; i = ni) {
@@ -842,6 +842,7 @@ merge_interfaces(struct area *a, struct
rde_nbr_iface_del(i);
LIST_REMOVE(i, entry);
if_del(i);
+ dirty = 1; /* force rtr LSA update */
}
}
pfctl: zap unused struct segment
There since import and last used by ALTQ which henning removed in 2004.
OK?
Index: sbin/pfctl//pfctl.h
===
RCS file: /cvs/src/sbin/pfctl/pfctl.h,v
retrieving revision 1.57
diff -u -p -r1.57 pfctl.h
--- sbin/pfctl//pfctl.h 6 Sep 2018 15:07:33 - 1.57
+++ sbin/pfctl//pfctl.h 1 Jan 2019 21:23:02 -
@@ -83,14 +83,6 @@ void warn_namespace_collision(const cha
voidpfctl_show_ifaces(const char *, int);
FILE *pfctl_fopen(const char *, const char *);
-/*
- * generalized service curve used for admission control
- */
-struct segment {
- LIST_ENTRY(segment) _next;
- double x, y, d, m;
-};
-
voidprint_addr(struct pf_addr_wrap *, sa_family_t, int);
voidprint_addr_str(sa_family_t, struct pf_addr *);
voidprint_host(struct pf_addr *, u_int16_t p, sa_family_t, u_int16_t,
const char *, int);
pfctl: bail out early on missing table command, zap wrapper
Synopsis is `[-t table -T command [address ...]]', yet tables without
commands are silently ignored:
$ pfctl -t t
pfctl: /dev/pf: Permission denied
# pfctl -t t ; echo $?
0
Commands without tables are catched, but only after opening pf(4):
$ pfctl -T show
pfctl: /dev/pf: Permission denied
# pfctl -T show
pfctl [-deghNnPqrvz] [-a anchor] [-D macro=value] [-F modifier] [-f
file]
[-i interface] [-K key] [-k key] [-L statefile] [-o level] [-p
device]
[-S statefile] [-s modifier [-R id]] [-t table -T command
[address ...]]
[-V rdomain] [-x level]
1
By moving the inter-dependence check right after option parsing is done,
we can bail out much earlier and drop the internal wrapper
pfctl_command_tables() as unneeded indirection with now duplicate checks.
With this diff both examples will show usage without doing anything as
expected. There's no other user of this wrapper.
Feedback? OK?
Index: sbin/pfctl//pfctl.c
===
RCS file: /cvs/src/sbin/pfctl/pfctl.c,v
retrieving revision 1.361
diff -u -p -r1.361 pfctl.c
--- sbin/pfctl//pfctl.c 27 Dec 2018 16:33:44 - 1.361
+++ sbin/pfctl//pfctl.c 1 Jan 2019 19:01:23 -
@@ -2482,6 +2482,9 @@ main(int argc, char *argv[])
}
}
+ if (tblcmdopt == NULL ^ tableopt == NULL)
+ usage();
+
if (tblcmdopt != NULL) {
argc -= optind;
argv += optind;
@@ -2661,7 +2664,7 @@ main(int argc, char *argv[])
pfctl_kill_src_nodes(dev, ifaceopt, opts);
if (tblcmdopt != NULL) {
- error = pfctl_command_tables(argc, argv, tableopt,
+ error = pfctl_table(argc, argv, tableopt,
tblcmdopt, rulesopt, anchorname, opts);
rulesopt = NULL;
}
Index: sbin/pfctl//pfctl.h
===
RCS file: /cvs/src/sbin/pfctl/pfctl.h,v
retrieving revision 1.57
diff -u -p -r1.57 pfctl.h
--- sbin/pfctl//pfctl.h 6 Sep 2018 15:07:33 - 1.57
+++ sbin/pfctl//pfctl.h 1 Jan 2019 19:14:36 -
@@ -77,7 +77,7 @@ intpfi_clr_istats(const char *, int *,
voidpfctl_print_title(char *);
voidpfctl_clear_tables(const char *, int);
voidpfctl_show_tables(const char *, int);
-int pfctl_command_tables(int, char *[], char *, const char *, char *,
+int pfctl_table(int, char *[], char *, const char *, char *,
const char *, int);
voidwarn_namespace_collision(const char *);
voidpfctl_show_ifaces(const char *, int);
Index: sbin/pfctl//pfctl_table.c
===
RCS file: /cvs/src/sbin/pfctl/pfctl_table.c,v
retrieving revision 1.78
diff -u -p -r1.78 pfctl_table.c
--- sbin/pfctl//pfctl_table.c 15 Oct 2018 21:15:35 - 1.78
+++ sbin/pfctl//pfctl_table.c 1 Jan 2019 18:59:55 -
@@ -54,8 +54,6 @@
#include "pfctl.h"
extern voidusage(void);
-static int pfctl_table(int, char *[], char *, const char *, char *,
- const char *, int);
static voidprint_table(struct pfr_table *, int, int);
static voidprint_tstats(struct pfr_tstats *, int);
static int load_addr(struct pfr_buffer *, int, char *[], char *, int, int);
@@ -114,15 +112,6 @@ pfctl_show_tables(const char *anchor, in
{
if (pfctl_table(0, NULL, NULL, "-s", NULL, anchor, opts) == -1)
exit(1);
-}
-
-int
-pfctl_command_tables(int argc, char *argv[], char *tname,
-const char *command, char *file, const char *anchor, int opts)
-{
- if (tname == NULL || command == NULL)
- usage();
- return pfctl_table(argc, argv, tname, command, file, anchor, opts);
}
int
Re: ripd: fib-priority
On Mon, Dec 31, 2018 at 10:06:53PM +0100, Remi Locherer wrote: > On Mon, Dec 31, 2018 at 01:33:39PM +0100, Jeremie Courreges-Anglas wrote: > > On Sun, Dec 30 2018, Remi Locherer wrote: > > > Hi tech, > > > > > > after adding the config option "fib-priority" to ospfd/ospf6d I figured > > > out > > > that it is almost the same change to add it to ripd. > > > > > > After that all our routing daemons (unicast) have an option to adjust > > > the fib-priority. Or did I miss one? > > > > The IPv6 counterpart of ripd(8) is route6d(8). Nothing sets rtm_prio in > > rouet6d, so the inserted routes end up with RTP_DEFAULT (56). > > Oh, a routing daemon from another era. ;-) Indeed, somebody should take ripd and make a rip6d out of it. route6d is fairly horrible. -- :wq Claudio
