Re: mvsw(4): present each port as a separate interface
On Mon, May 30, 2022 at 09:14:47PM +0200, Mark Kettenis wrote: > > Date: Sat, 28 May 2022 15:08:49 +1000 > > From: David Gwynne > > > > the espressobin is the least worst thing ive settled on. it's not > > too expensive, it has a case, it has multiple interfaces, and > > kettenis and patrick have already worked on the platform stuff. the > > only problem with it was that the interfaces are on a switch chip > > supported by mvsw, and mvsw configures the switch as a switch. this > > makes it hard to use as a router. > > So I have a Turris MOX that is based on the same SoC. It is modular > and I have a switch module that integrates the same Marvell switch > chip. That is the hardware I used to develop the current mvsw(4) > driver. The interesting thing is that the Turris MOX actually has two > mvneta(4) interface; mvneta0 is connected to a normal Ethernet PHY, > whereas mvneta1 is connected to the switch chip. In this setup it > makes sense to use the mvneta0 port as a "WAN" port and the swithc > ports as "LAN" ports and have let the hardware do the switching > between the "LAN" ports. nice. i didn't realise you were using the mox in a load bearing capacity already. the way mvsw interacts with mvneta after this diff depends on what's in the fdt. the mvsw ports nodes should have one that references the phandle of an ethernet interface, which is how the "cpu" ports on the switch are identified. my diff also adds glue to of_misc.c that allows drivers to register interfaces so they can be found by node or phandle, and i've added that registration to mvneta. that allows mvsw to find it later, and then steal it. stealing it means it takes it over like aggr/trunk takes over an interface. it replaces the input handler on mvneta (which is ether_input) with mvsw_p_input, which allows the kernel to demux packets coming from mvsw. mvsw itself is configured to add it's dsa tag to packets heading toward the cpu, which is how the kernel knows which downstream/user port actually received the packet. however, if the fdt doesnt have an ethernet port node for an mvneta interface, mvneta is left alone. on the mox i think mvneta0 will remain independent, and mvneta1 will get taken over by the switch. > > this diff makes mvsw present its ports as individual interfaces, > > and configures the switch so each external port can only talk to > > the host system. it's basically an ethernet mux instead of a switch. > > > > this is inspired by the dsa framework in linux, which in turn seems > > to have been inspired by and written for the link street family of > > switch chips thats in the espressobin. > > > > like dsa, mvsw now tries to understand the different roles of switch > > ports and their topology. most ports are externally accessible, and one > > is wired up internally to mvneta. the fdt describes these roles and > > relationships, and now mvsw does different things depending on these > > roles. > > > > the internal port wired up to mvneta is a "cpu" interface. mvsw now > > takes over mvneta, much like how aggr or trunk takes over an interface, > > and unconditionally configures the switch port to tag packets so the > > kernel can know which mvsw port a packet was received on. > > > > the externally accessible ports are enumerated and attached as separate > > network interfaces in the kernel, and configured on the switch so that > > they can only talk to the cpu/mvneta switch port. packets sent out > > a kernel mvsport interface are tagged and sent out mvneta instead, > > kind of like vlan interfaces. > > How does configuring IP addresses work with your diff? Do you still > configure and address on the mvneta(4) interface? Or do you configure > addresses on the individual mvsport(4) interfaces? And how does one > configure additional VLANs in this scenario? mvneta (or whatever ethernet interface is wired up to the switch) with an mvsw on it is no longer usable for layer 3 in the kernel. you just have to bring it up so packets can flow over it. the stack operates on mvsport interfaces instead. mvsw is configured to ignore vlans, so they get passed straight from the port they're received on to the cpu, and visa versa. my isp here uses pppoe over vlan 2, which works fine over an mvsport interface. ebin# for i in /etc/hostname.*; do echo == $i ==; cat $i; done == /etc/hostname.mvneta0 == up == /etc/hostname.mvsport1 == up == /etc/hostname.mvsport2 == inet autoconf ebin# ifconfig lo0: flags=8049 mtu 32768 index 3 priority 0 llprio 3 groups: lo inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff00 mvneta0: flags=8b43 mtu 1500 lladdr f0:ad:4e:1c:08:42 index 1 priority 0 llprio 3 trunk: trunkdev mvsw0 media: Ethernet autoselect (1000baseT full-duplex) status: active enc0: flags=0<> index 2 priority 0 llprio 3 groups: enc status: active mvsport0: flags=8002 mtu
Re: mvsw(4): present each port as a separate interface
> Date: Sat, 28 May 2022 15:08:49 +1000 > From: David Gwynne > > the espressobin is the least worst thing ive settled on. it's not > too expensive, it has a case, it has multiple interfaces, and > kettenis and patrick have already worked on the platform stuff. the > only problem with it was that the interfaces are on a switch chip > supported by mvsw, and mvsw configures the switch as a switch. this > makes it hard to use as a router. So I have a Turris MOX that is based on the same SoC. It is modular and I have a switch module that integrates the same Marvell switch chip. That is the hardware I used to develop the current mvsw(4) driver. The interesting thing is that the Turris MOX actually has two mvneta(4) interface; mvneta0 is connected to a normal Ethernet PHY, whereas mvneta1 is connected to the switch chip. In this setup it makes sense to use the mvneta0 port as a "WAN" port and the swithc ports as "LAN" ports and have let the hardware do the switching between the "LAN" ports. > this diff makes mvsw present its ports as individual interfaces, > and configures the switch so each external port can only talk to > the host system. it's basically an ethernet mux instead of a switch. > > this is inspired by the dsa framework in linux, which in turn seems > to have been inspired by and written for the link street family of > switch chips thats in the espressobin. > > like dsa, mvsw now tries to understand the different roles of switch > ports and their topology. most ports are externally accessible, and one > is wired up internally to mvneta. the fdt describes these roles and > relationships, and now mvsw does different things depending on these > roles. > > the internal port wired up to mvneta is a "cpu" interface. mvsw now > takes over mvneta, much like how aggr or trunk takes over an interface, > and unconditionally configures the switch port to tag packets so the > kernel can know which mvsw port a packet was received on. > > the externally accessible ports are enumerated and attached as separate > network interfaces in the kernel, and configured on the switch so that > they can only talk to the cpu/mvneta switch port. packets sent out > a kernel mvsport interface are tagged and sent out mvneta instead, > kind of like vlan interfaces. How does configuring IP addresses work with your diff? Do you still configure and address on the mvneta(4) interface? Or do you configure addresses on the individual mvsport(4) interfaces? And how does one configure additional VLANs in this scenario? > there is no longer any config that allows mvsw switch ports to > communicate directly, if you want to bridge them now you have to > do it in software with veb (or bridge or tpmr). So this would "break" my current setup on the Turris MOX. Now actually I currently only use a single port on the switch, but my plan was to connect some of my equipment directly to the MOX instead of my 24-port switch. I just didn't get around to doing that. > presenting the ports as separate interfaces allows them to fit in > nicely with the existing kernel functionality. in particular, it > lets us wire up ifmedia and mii so you can see the phy on each port, > which in turn will let ifconfig operate on them as you'd expect. That *is* nice. > the diff below is very rough, but i think it's far enough along > that it demonstrates where im going. if the ideas are acceptable, > i'd like to commit it and hack on it in the tree. I would like to understand things a bit better. And make sure this doesn't break things to badly for me. That Turris MOX is my firewall and wireless access point, so breaking things would be bad for OpenBSD development ;). Unfortunately, it also means it isn't trivial for me to test things. > there's some future work to be done. the mdio bus probably needs a lock > around it. i have no idea how mii/ifmedia works, so some pointers > there would be good. The mvmdio(4) driver already uses a mutex to control access to the bus. > it would be nice to hack on another switch chip at some > point. recent banana pi routers might be a good candidate for > that. they have mediatek or realtek switches on them from what i can > tell, and they link to the doco for them. it might be possible to > factor the "port interface" code out for all these and just have the > switch drivers provide glue for them. The "Banana Pi BPI-R2 Pro Router" might be the most interesting one. That one is based on a Rockchip RK3568 SoC for which we already have some support in the tree and hardware in the hands of other developers (me and patrick). That one integrates a MediaTek MT7531BE switch chip. The other Banana Pi router boards are based on SoCs that we don't support. > it would be interesting to teach veb and vlan how to offload switching > to a switch chip for port interfaces. there's a bunch of functionality > we offer in our virtual bridges that wouldn't work on a hardware > chip (eg, pf, bridge rules, ipsec, etc), but
Re: apmd(8): reconnecting AC, not battery
> On 28. May 2022, at 16:31, Jan Stary wrote: > > On May 28 10:34:35, s...@spacehopper.org wrote: >> On 2022/05/28 06:52, Jason McIntyre wrote: >>> On Fri, May 27, 2022 at 07:19:37PM +0200, Jan Stary wrote: apmd says: When the power status changes (battery is connected or disconnected), apmd fetches the current status and reports it via syslog(3) with logging facility LOG_DAEMON. Is "battery" really meant here? Should that be the AC power? Batteries are typically not being reconnected while running ... >> >> They certainly can be, either while on external power, or in the case of >> machines with multiple batteries (several generations of X series ThinkPads >> have both internal and external batteries, so you can swap without powering >> down even while on battery power). But yes the common case would be >> external power. >> (The manpage calls it "external power", "line current" and "AC" interchangably.) Jan >>> >>> hi. >>> >>> i think you're right that the text is off. the author possibly meant to >>> say battery was charging or discharging. >>> >>> anyway, if i don;t hear any reason not to soon, i'll commit your >>> suggested diff (which i think is simpler and makes sense). >> >> Why be inaccurate when we don't need to be - it's very uncommon to have >> a machine with a battery with an AC input. "External power" would make >> more sense. > > I never liked the AC nomenclature either; Me neither, but I believe this may have originated in the APM specification which talks about "AC line status” for i.e. "Get Power Status” function. Seems like it went from specification into code (see machine/apmvar.h) and then into documentation/man page. > it's battery vs wall socket, not AC vs DC. > Feel free to change the wording of course.
Re: grep(1): fix printing trailing context when using -m
Omar Polo writes:
> Dave Voutila wrote:
>> I noticed this today while grepping through a very long kdump output and
>> using something like:
>>
>> $ fgrep -n -m2 -C2 'kevent -1' dump.txt
>> 641- 31513 vmd RET sendmsg 1848/0x738
>> 642- 31513 vmd CALL kevent(5,0x90d4c2e4000,1,0x90d8004a000,2048,0)
>> 643: 31513 vmd RET kevent -1 errno 4 Interrupted system call
>> 644- 31513 vmd CALL sigreturn(0x7f7d6430)
>> 645- 31513 vmd RET sigreturn JUSTRETURN
>> --
>> 661- 31513 vmd RET sendmsg 44/0x2c
>> 662- 31513 vmd CALL kevent(5,0x90d4c2e4000,1,0x90d8004a000,2048,0)
>> 663: 31513 vmd RET kevent -1 errno 4 Interrupted system call
>>
>> Notice how grep(1) isn't printing anything after the last requested
>> match even though I've specified -C2. (I assure you...there're a lot
>> more lines after that match. ;)
>>
>> The below patch changes the logic to avoid bailing out of the loop in
>> util.c:procfile() even after the match count is hit but we still have
>> some after-context lines to print.
>>
>> In procline(), it will skip attempting matches after hitting the match
>> count. (This does mean that when using -n, a line within the
>> after-context that may match will not get printed with the matched
>> prefix ":".)
>>
>> With the diff:
>>
>> $ fgrep -n -m2 -C2 'kevent -1' dump.txt
>> 641- 31513 vmd RET sendmsg 1848/0x738
>> 642- 31513 vmd CALL kevent(5,0x90d4c2e4000,1,0x90d8004a000,2048,0)
>> 643: 31513 vmd RET kevent -1 errno 4 Interrupted system call
>> 644- 31513 vmd CALL sigreturn(0x7f7d6430)
>> 645- 31513 vmd RET sigreturn JUSTRETURN
>> --
>> 661- 31513 vmd RET sendmsg 44/0x2c
>> 662- 31513 vmd CALL kevent(5,0x90d4c2e4000,1,0x90d8004a000,2048,0)
>> 663: 31513 vmd RET kevent -1 errno 4 Interrupted system call
>> 664- 31513 vmd CALL sigreturn(0x7f7d6430)
>> 665- 31513 vmd RET sigreturn JUSTRETURN
>>
>> FWIW: GNU grep (v3.3) seems to do my proposed behavior including not
>> marking possible matches in the after-context of a final match. Busybox
>> grep (v1.33.1) acts like our current grep and fails to print the
>> after-context of the final match when using -m.
>>
>> ok?
>
> the current behaviour seems a bug to me more than a feature: i think we
> should honour -C even when -m is specified.
>
> not my department, but recently i was hacking in grep too and the diff
> reads and works fine to me. ok op@ (given my ok counts something in
> this area :-)
>
>> @@ -212,6 +212,8 @@ procline(str_t *l, int nottext)
>> c = 1;
>> goto print;
>> }
>
> nitpick: i'd probably add a space between <= and 0
>
>> +if (mflag && mcount <=0)
>> +goto print;
>>
>> for (i = 0; i < patterns; i++) {
>> offset = 0;
Ah, yes. Fixed that.
Committed with additional ok millert@. Thanks!
some package oddities
Due to some slowdown in updating texlive, I've looked up duplicate files inside packages. Most packages are okay, a few are not... The following list shows the maximum number of times a file appears in a given package (just looking at its checksum) Note sdcc, which stores a crazy number of identical .deps files (all 8 bytes long) I've stopped the list at count 50, but there are still a large number of duplicated files. (we're talking actual copies on the filesystem, pkg_create will recognize symlinks and hardlinks and package them accordingly) Those are not necessarily wrong, but it would be lovely if some of the maintainers could look them up (myself included thanks to stepmania). Right now, updating sdcc is probably way slower than deleting and reinstalling it ;) sdcc-3.8.0p0.tgz: 6402 ansible-5.8.0.tgz: 840 texlive_texmf-full-2021.tgz: 663 google-cloud-sdk-386.0.0.tgz: 588 coq-8.13.2p2.tgz: 580 lumina-1.4.0pl1p6.tgz: 381 mate-utils-1.26.0p0.tgz: 336 ruby27-gettext-3.2.2.tgz: 334 ruby31-gettext-3.2.2.tgz: 334 py3-vsphere-automation-7.0.3.2.tgz: 267 routersploit-3.4.0p2.tgz: 240 py3-opengl-3.1.3b2p3.tgz: 207 py-opengl-3.1.3b2p3.tgz: 207 mate-panel-1.26.0p0.tgz: 193 logstash-7.10.0v0.tgz: 185 qcad-3.24.3.0p2.tgz: 178 stepmania-5.0.12v0.tgz: 178 ruby30-passenger-6.0.4.tgz: 167 ruby31-passenger-6.0.4.tgz: 167 egoboo-2.8.1p0.tgz: 137 tuxpaint-stamps-20211125.tgz: 135 pycharm-2022.1.1.tgz: 134 texlive_texmf-minimal-2021.tgz: 121 javahelp-2.0.05p3.tgz: 121 granite-5.5.0.tgz: 121 py3-jedi-0.18.1.tgz: 120 mariadb-tests-10.6.7p0v1.tgz: 109 mate-control-center-1.26.0p2.tgz: 108 stellarium-0.22.1.tgz: 105 kdoctools-5.91.0.tgz: 103 odoo-15.0.20220427p0.tgz: 102 mate-calc-1.26.0.tgz: 102 kibana-7.10.0.tgz: 102 atril-1.26.0p0.tgz: 102 arduino-esp32-2.0.1.tgz: 101 megaglest-data-3.13.0p1.tgz: 98 warmux-11.04.1p9.tgz: 95 py3-botocore-1.26.0.tgz: 94 py3-pandas-1.3.4p0.tgz: 94 nextcloud-23.0.4.tgz: 92 neverball-data-1.6.0v0.tgz: 92 nextcloud-21.0.9.tgz: 92 nextcloud-22.2.7.tgz: 92 heimdal-devel-docs-7.7.0p0.tgz: 83 mate-power-manager-1.26.0p1.tgz: 82 epic4-2.10.5p3.tgz: 81 fillets-ng-1.0.1p2.tgz: 81 yaru-22.04.4p0.tgz: 80 qt6-qtdeclarative-6.3.0.tgz: 80 py3-sympy-1.7.1p0.tgz: 79 mate-system-monitor-1.26.0p0.tgz: 74 solr-8.11.1p0.tgz: 70 librenms-22.4.1v0.tgz: 68 ghidra-9.1.2p1.tgz: 67 widelands-1.0.tgz: 67 nagios-web-4.4.6p0-chroot.tgz: 63 nagios-web-4.4.6p0.tgz: 63 fs-uae-launcher-3.0.5p0.tgz: 60 os-test-0.41p1.tgz: 58 chromium-101.0.4951.67.tgz: 55 unknown-horizons-2019.1p0.tgz: 54 iridium-2022.04.100.0p1.tgz: 53 py3-scikit-learn-1.0.2.tgz: 53 botan2-2.19.1p1.tgz: 53 electron-8.2.0p5.tgz: 53 libreoffice-java-7.3.3.2v0.tgz: 52 qt6-qtbase-6.3.0.tgz: 51 [...]
