**** BEGIN LOGGING AT Tue Apr 02 02:59:57 2019 Apr 02 06:04:30 tmn505: did you see my email about the conflict with Sebastian's EFI patches? subject was: Rebasing "Generate EFI grub images for x86 platforms" Apr 02 09:08:42 hello there, I've got http://www.nuvoton.com/hq/products/microprocessors/arm9-mpus/nuc970-industrial-control-series/nuc976dk62y and I want to add it to openwrt Apr 02 09:09:27 somebody please explain me required steps... Apr 02 09:09:53 they provided 3.10 based kernel and uboot for it https://github.com/OpenNuvoton/NUC970_Linux_Kernel Apr 02 09:11:31 AFAIK I cant use custom kernel with open wrt, but I have to port some drivers to current openwrt kernel is it true? Apr 02 09:12:16 I also dont get difference between wiki pages: Adding a new device/Adding new device support/Adding new platform support Apr 02 09:13:25 please somebody take guide over me Apr 02 09:18:35 philipp64: Hi, AFAIK my patches didn't remove anyting that EFI patches were relying on Apr 02 09:19:00 swex: i'm no dev but a new platform is when your CPU or SoC isn't suppored. new device means existing platform Apr 02 09:19:43 Borromini: but what if cpu supported https://openwrt.org/docs/techref/instructionset/arm_arm926ej-s but soc is not :)? Apr 02 09:22:36 you said it yourself Apr 02 09:22:50 new platform = SoC Apr 02 09:23:29 mediatek, qualcomm, marvell, ... they all have ARM SoCs Apr 02 09:23:41 but they're all different platforms Apr 02 09:24:09 to be honest, looks like a slow/old device, I wouldn't waste too much time adding support for it Apr 02 09:45:42 stintel: slow or not I have alot of them and I need to make something with ti Apr 02 09:47:49 https://www.cnx-software.com/2016/07/11/nuvoton-nuc970-arm9-microprocessor-gets-mainline-linux-support/ Apr 02 09:48:25 I guess it shouldn't be *too* hard Apr 02 09:51:01 although it seems not everything of that series was accepted Apr 02 09:54:38 and if you look at a commit that adds a new target, you might get an idea Apr 02 09:54:40 e.g. https://git.openwrt.org/84c212da Apr 02 09:58:29 stintel: thank you for link, yep when I look at mainline I cant see any of nuvoton patches Apr 02 09:59:17 what are kernel requirements for now? I can't find any specific wiki page... Apr 02 09:59:57 upcoming 19.x release will use 4.14, next will most likely use 4.19 Apr 02 15:22:23 I haven't messed with .dts files before but the &gmac sections in this https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ipq806x/files-4.9/arch/arm/boot/dts/qcom-ipq4019-gl-b1300.dts;h=53824e3c8d996a478f2e62a04e62a105b24c5c06;hb=04d3308b6248ef21a6f0bc3378b342906c2d2865 suggests that the interfaces are using vlan tags to talk on the switch port. However, in the case of vlan 1, the switch is configured with vlan Apr 02 15:22:23 1 untagged on that port. Apr 02 15:23:09 I'm trying to figure out if it would be possible to perform the tagging through kernel configuration instead, thus allowing more than one vlan on the physical ports. Apr 02 15:25:02 Is it worth investigating (rebuilding with a different .dts file and seeing if I can configure vlans on the interfaces directly) or is there some sort of silicon limitation that would make that futile? Apr 02 15:26:40 Generally many vlans are possible per port... I have no idea about DTS in this scope.. This said in all generality without knowing A device restrictions Apr 02 15:27:53 olmari: I think they did it this way not to expose the vlans directly to the OS, but that prevents us from actually touching the switch since the vlans to the CPU are essentially hardcoded. Apr 02 15:29:41 FinboySlick: is this device using dsa? Apr 02 15:29:55 FinboySlick: It's a limitation of Qualcomm's essedma driver. It seems to have taken the job of VLAN untagging. Apr 02 15:30:06 And/or trough a switch driver... but like said, I have even less deep experience and also no idea about device you have.. IE hardware might be there but.. jow came to rescue xD Apr 02 15:30:35 * jow has no clue either Apr 02 15:30:40 jow: I have no idea. Though I just tested configuring the with vlan1 tagged on the cpu port and it works just fine. Apr 02 15:30:44 just suspected that maybe QinQ is a possiiblity Apr 02 15:31:22 There is a rewritten edma driver by blogic using DSA in someone's staging tree but I forgot where exactly that is :( Apr 02 15:31:35 FinboySlick: is each port represented as network device? E.g. "lan1", "lan2", "wan" or do you have swconfig capabilities (swconfig list is not empty) Apr 02 15:32:05 jow: swconfig appears full-featured. I can tag untag and even mix. Apr 02 15:32:26 so ... everything is working? Apr 02 15:33:27 jow: Switch-wise, yes. But I can't get those vlans to touch the CPU since it seems to have its own hard-coded tag configuration. Apr 02 15:33:40 ah now I got it Apr 02 15:34:24 yeah, I guess the backend driver is not full featured enough for that Apr 02 15:36:25 hello ! Apr 02 15:41:37 gch981213: OK. So I'll file this as a longer-term project than just playing around flipping dts config entries. Apr 02 15:42:03 gch981213: If you do find it though, I'd be interested in giving it a try. Apr 02 15:44:19 I suspect this might be it: https://github.com/chunkeey/LEDE-IPQ40XX/commit/a04cf208fe317074502f7ea81dafa828c89b74bb Apr 02 16:40:07 hi Apr 02 16:40:49 Hi Apr 02 16:43:02 Hauke: got a spam mail from "wallystech" today too. must be harvesting ML Apr 02 16:43:32 or git maybe Apr 02 16:45:12 m4t: I got the same mail and this is the second time. Apr 02 16:45:24 :( Apr 02 16:45:55 let's invite them to irc then flame them ;) Apr 02 16:46:16 FinboySlick: I found it: https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=e20f74440d544098ef2c43d2a5923f9957a23082 Apr 02 16:57:16 m4t: Been getting those email too. I was tempted to reply that I don't accept spam for products that don't at least 2 gigabit interfaces. Apr 02 16:58:56 xD Apr 02 17:02:34 gch981213: I understand better now. There is only one gigabit on the device and the vlans are exposed as distinct ethX devices. I thought there were somehow two interfaces and both were connected to the same switch port (which makes no sense come to think of it). Apr 02 17:24:22 tmn505: they didn't, but they touched some of the same places causing merge conflicts… Apr 02 17:36:22 Another victim of wallystech here. Seems like there sending emails everyone... Apr 02 17:40:27 philipp64: that's something that we can't avoid since it's not in master :), anyway jow updated his staging tree, should be fine now Apr 02 17:40:52 okay, good. Apr 02 17:41:30 jow: how much is tangibly broken that needs to get fixed before we can merge the EFI stuff? maybe daniel has some ideas… Apr 02 18:44:30 philipp64 what is EFI? Apr 02 18:46:05 lol I googled and got European Forest Institute: and Electronics For Imaging. Apr 02 18:46:15 eh Apr 02 18:46:24 extensible firmware interface Apr 02 18:46:27 Tapper: ^^ Apr 02 18:46:37 lol KK thanks Apr 02 18:47:27 https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface In grand scheme EFI replaces old BIOS... part of that is EFI system partition and methods of booting out from such thing... Apr 02 18:47:33 I know there is not mutch of Forest in Openwrt Apr 02 18:47:37 lol Apr 02 18:47:50 it's easier to search for as UEFI, not exactly the same, but close enough for most intents and purposes Apr 02 18:47:51 thanks olmari Apr 02 18:48:13 pkgadd thanks Apr 02 18:48:58 Is that just for x86 or is it for other targets? Apr 02 18:50:11 O it has a • CPU-independent architecture Apr 02 18:50:14 Generally it could be used by.. well.. pretty much anything, but x86 an derivates are mainly adopted to that... Apr 02 18:50:25 * Tapper nods Apr 02 18:50:26 mostly x86 and x86_64, but also ARMv8 (the server grade stuff) and in general purpose distros they're increasingly working on making u-boot fake a UEFI environment, so they can use grub-efi Apr 02 18:50:40 also linked wiki has info about that too... Apr 02 18:50:49 pkgadd for booting of bigger disks? Apr 02 18:51:25 pkgadd: not directly related, but 'yes' Apr 02 18:51:31 grr, Tapper ;) Apr 02 18:51:35 disk size has little to do with that... Apr 02 18:52:05 or well.. has to do with GPT support, which in turn means larger partitionsizes too Apr 02 18:53:00 Just scan trough the wiki article :) Apr 02 18:53:25 only on the windows side of it. windows only accepts GPT partitioned disks (which are mandatory for >4 TB disks) when booting via UEFI -- and UEFI implementations generally want a GPT partitioned disk, strictly speaking not necessarily, but in general, yes (linux can boot from GPT disks in BIOS or UEFI mode) Apr 02 18:59:11 Can I summit a simple patch to able set the interface name via DTS? So you can set the ifname in the same way as it is done in DSA code. Apr 02 18:59:59 This can be useful for device like ubnt ER-X-SFP which labeled the ports with eth0-5. Apr 02 19:00:25 Current patch: https://github.com/vDorst/linux-1/commit/c74c15e10adee37d8e3c1b48ecfcdadaffc3a853 Apr 02 19:01:23 I did some reading on DSA since our earlier discussion. I'm not entirely sure what it means from a practical standpoint. Switch devices become exposed as if they were plain linux bridges? Apr 02 19:02:04 With the bridge ethernet device being the 'CPU' port? Apr 02 19:02:23 FinboySlick: Plain linux eth-devices to be more precise I think Apr 02 19:03:19 olmari: One eth per port you mean? Apr 02 19:04:57 I have no direct idea how traditional CPU port goes in DSA.. but the general idea is that every switch port would be seen as ethX, that can then be used like one... ofcourse at the background hardware is used almost like it is now... or I mean there shouldn't be any performance losses because of DSA, at least when done bug free Apr 02 19:07:08 olmari: Hmm. The switch itself would still have to appear as a bridge so that vlans can be managed through vlan filtering. Apr 02 19:09:33 why? or.. well... We'd need better terms how to talk about these... as in "hat user sees" and what drivers do in the background might be totally separate and diffirent things... also when done "right" the driver(s) exposes the ports as ethX and that's that, so to speak... you can attach a vlan to one like any old eth, bridge them together like any old eth.. so on..."just works".. Apr 02 19:11:31 olmari: Yeah. The semantics still get pretty messed up when you have more vlans than ports though, unless you're creating one bridge per vlan. Apr 02 19:12:25 well isn't that the burden of DSA driver (including switch) Apr 02 19:13:40 a vlan itself doesn't yet need a bridge Apr 02 19:14:15 olmari: From a usability perspective, not quite. You need an object to apply those configurations to. Exposing one eth device per port is fine so long as they are treated separately but once you start connecting them together, you end up with an object missing from the equation. Apr 02 19:14:33 (that is the switch) Apr 02 19:15:16 connecting more ports together needs a bridge, yes, no matter do you bridge vlan to it or not Apr 02 19:16:25 olmari: But now you end up with a bridge object per vlan. Because vlan 2 might be on eth 1 3 4, but vlan 3 is only on 2 and 4. Apr 02 19:16:50 olmari: that's pretty much why the netdev guys came up with bridge vlan filtering. Apr 02 19:16:57 basically idea would be just the same as throwing 5 physical ethernet cards to your computer and doing business with them Apr 02 19:18:09 sure, youd need 2 bridges for vlan 2 and vlan 3 purposes... or you could even bridge eth2.3 and eth 1.44 together and so on (at least in perfect world) Apr 02 19:19:26 olmari: with vlan filtering you only use one bridge but you decide which vlans go to which port. Basically, it becomes the same as an L2 managed switch. Apr 02 19:20:14 olmari: You end up in weird cases where you reuse vlan numbers on different bridges with the DSA approach though. Apr 02 19:20:38 Also... what needs to be exposed to user is totally separate how driver handles it... but this is also an area where more educated pwoples should really answer :) Apr 02 19:20:52 Because even though these vlans might be on completely separate bridges with different member interfaces, they're still in the same switch (and therefore connected). Apr 02 19:22:11 that all depends how the ahrdware actually does things... which I have no deep insight on... Apr 02 19:22:45 also, again, I'm talking of user point of view, and perfect world.. no idea current states of affairs is Apr 02 19:23:57 olmari: Yeah. My point really is that if you're going to 'abstract away' the switch... You'll end up needing switch that were designed to be abstracted that way. Apr 02 19:24:02 Maybe this would be good read for that https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt Apr 02 19:24:17 olmari: That's exactly what I've been reading. Apr 02 19:24:40 or, good enough driver that can achieve that, which I'd asume is better on some than other devices (: Apr 02 19:26:48 also, this IS a thing driver needs to handle... aand also a thing that DSA is specifically meant to do (well... it wouldn't exist if 'old' way of things would have been deemed good enough for the kernel people (: Apr 02 19:27:33 olmari: Even if you wanted to do it in the driver, in my earlier example (which is an edge case but good example), you'd either need hardware that can re-write tags so you can do magic and pretend that vlan 3 on the first bridge is not the same as vlan 3 on the second bridge. Or you'd need otherwise useless ACL capability to block vlan 3 tagged traffic on the first bridge's member ports from reaching the second bridge's member po Apr 02 19:27:33 rts. Apr 02 19:28:30 isn't that exaxtly drivers problem to handle it as good as the device itself can do it? Apr 02 19:28:42 also, the whole idea on DSA Apr 02 19:30:10 I mean the more I'm now reading that linked document, the more it is clear... (Also would have been good to read it way earlier, but no cna do now :) ) Apr 02 19:31:25 olmari: A much simpler example of the problem is if you have eth1.3 and eht2.3, they're automatically bridged together by the switch hardware. Apr 02 19:32:28 olmari: That is, with the notion that each switch port is exposed as an ethX device. Apr 02 19:33:25 in DSA conf, are they? also that doc has entire section about bridge and vlan... Apr 02 19:34:45 olmari: Yeah. The way I parsed it is that the switch itself would be exposed as a bridge device. Apr 02 19:35:11 olmari: with the ethX ports of that switch being automatically members of that bridge. Apr 02 19:36:09 Why would you parse it like that? Nothing I have seen hasn't suggested that... not that I've read that completely yet Apr 02 19:37:06 Also that would even break the whole idea in some ways Apr 02 19:37:59 I think the whole idea breaks regardless of how it is put. Apr 02 19:38:30 Now we are starting to circle around... Apr 02 19:39:04 The cpu/driver can't see frames that are bridged by the switch itself. It has no way of preventing them from being bridged together. Apr 02 19:39:11 Idea is awesome as heck, implementation... well... haven't yet seen on at mine hands so :P Apr 02 19:40:10 Unless, as I mentioned earlier, the switch was actually designed with this in mind (like the SDN switches popping up on the market these days). Apr 02 19:40:14 Why wouldn't it? What makes you think it wouldn't sing it to the downstream? Apr 02 19:40:43 Because if it sings it downstream, you're CPU bridging and that defeats the purpose of having a switch chip? Apr 02 19:41:48 they can be managed now by "conventional" switch driver, are you implying it doesn't know what has been configured or that it wouldn't know what is going on on the switch? Apr 02 19:42:15 (again, can't speak for 100% of cases in 100% of hardware there is) Apr 02 19:42:33 Oh! I think that's where the misunderstanding is. Apr 02 19:42:52 I don't mean the CPU wouldn't know what's configured. That's easy enough. Apr 02 19:43:05 I mean the CPU wouldn't know what is being bridged by the chip. Apr 02 19:44:30 Let's take the most basic example. Apr 02 19:45:03 You have a 3 port switch chip with two physical ports (0 is CPU, 1 and 2 are physical) Apr 02 19:45:21 Why wouldn't it? cou is the one configuring swithc at the first place (switch driver is), apart from some defautl state they be at boot time and maybe before init Apr 02 19:46:20 olmari: It'll become obvious with the example. Apr 02 19:47:08 So now you have eth1 and eth2 and DSA is doing magic and hiding port 0 as the cpu port. Apr 02 19:48:06 That linked document states quite deeply how things is done, including PHY managemetn Apr 02 19:48:22 Yes. Apr 02 19:48:39 I don't see generally anything that would make stuff not work as expected Apr 02 19:50:40 olmari: What happens if you create eth1.3 and eth2.3, internally? Apr 02 19:50:59 Most of current hardware does nothing without that switch driver anyways... they don't just magically know stuff, and they talk to their drivers much anyhow... We as users don't just see that part much, and that would be the case with DSA too in general Apr 02 19:51:40 define internally? generally first PHY management and queries, then bridge layer and vlan filtering, as per that document Apr 02 19:53:39 olmari: We both agree that what should happen there is that you can receive vlan3 tagged packets on eth1.3 and know they came in on eth1.3 and they should be separate from packets that you might receive on eth2.3, right? Apr 02 19:54:54 (from a user perspective) Apr 02 19:56:55 I'd say so, and document generally describes how too Apr 02 19:57:32 OK, so port 1 of the switch configured with vlan3 tagged, port 2 of the switch is configured with vlan 3 tagged... Apr 02 19:57:43 And now they're bridged together and there's nothing you can do about it. Apr 02 20:00:54 In fact, for the OS to even see these frames, port 0 has to be a member of vlan3. And as such, there's no way to tell whether a vlan3 tagged frame received by the CPU came in through eth1.3 or through eth2.3 Apr 02 20:01:18 The driver runs on the CPU, it doesn't run on the switch. Apr 02 20:01:20 why wouldn't I? you make no sense.... driver is there to see things, also like already said switch hardware doesn't generally do shit until drivers initialize them and configure them.. I don't see where you figure out switch hardware would magically create/join/whatever 2 ports vlan and not tell anywhere anything Apr 02 20:01:51 switch also sings "hey, cable plugged", driver can react to that Apr 02 20:02:36 olmari: Yes, that's an event. But the switch never sings 'hey, here's all the bytes of the packet I got on port x" Apr 02 20:03:37 You seem to treat the switch hardware like it just does stuff without communicating anything to anywhere... also like it wouldn't conf itself like driver tells it to.. which might not be bridging 2 vlans together.... Apr 02 20:03:53 olmari: when it comes to actual switching, that is exactly the case, yes. Apr 02 20:04:14 switch connects VLANS and whatnot like told to, be it on init and never again... Apr 02 20:04:51 olmari: If you configure the same vlan number on two ports of a swich, they get bridged. The CPU doesn't have a word to say about it. Apr 02 20:05:25 The CPU can decide which vlan goes on which port. But it can't prevent the switch from bridging them. Apr 02 20:05:28 stuff are still generally configurable... that's why there IS a driver... and current model of oxposing configs and whatnot... DSA isn't taking any of those capabilities away... just uses them diffirently Apr 02 20:06:01 That's what you say, I don't believe you in general case Apr 02 20:06:50 So at this point we just need to agree to disagree, as this is getting way too offtopic for this channel, while interesting discussion in itself Apr 02 20:07:00 olmari: I think this is where you should research a little further. I'm not saying it is impossible... But switches are not designed the way you seem to think they are. Apr 02 20:08:32 olmari: Yeah, fair point. But you should definitely look into it. Pretty fancy SDN switches aside. Your typical embedded switch might not do what you think it does. Apr 02 20:09:13 Well then at the worst case scenario then DSA "simply" need to generate the bridge for "vlan 3" and attach all configured "ethX.3" to it, tagger or untagged Apr 02 20:46:07 FinboySlick: AFAIK current DSA does not support multiple CPU ports, so everything would be routed through eth1 (or eth2, depending which one is assigned as the "cpu" port) Apr 02 20:48:12 KanjiMonster: In our example it would have been eth0 (I wasn't sure it if created an eth device for the cpu port). eth1 and eth2 were example physical ports. Apr 02 20:48:48 ah, I see Apr 02 20:49:00 KanjiMonster: My (later) point was just that having tagged the same tagged vlan on two physical interfaces would automatically bridge them together. Apr 02 20:49:24 (without the CPU having anything to say about it) Apr 02 20:49:27 not necessarily. if the switch supports q-in-q these could be in different outer vlans Apr 02 20:50:30 KanjiMonster: Yeah. Though then wouldn't you be eating the QinQ feature of the switch for your internal management purposes and it becomes unavailable for external use? Apr 02 20:51:13 for a long time dsa didn't even support letting the switch bridge in hardware, and anything would need to be forwarded by the cpu; I'm sure there are safeguards that prevent implicit bridging in that case Apr 02 20:51:52 KanjiMonster: The overarching point being that 'abstracting away' the switch might gain in basic usability but you end up sort warping the underlying concepts. Apr 02 20:53:30 KanjiMonster: Hmm... I'm not sure if I'm keen on the idea of DSA then. It sounds like something that would really be better suited to SDN. Apr 02 20:53:34 Also while not too detailed, as these kind of documents are, https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt section Bridge VLAN filtering suggest that configuring stuff would work and if not fallback to software implementation... (cna't say how exactly would all these apply here) Apr 02 20:54:27 olmari: You couldn't 'software implement' my example without specific hardware support in the switch (like QinQ as KanjiMonster pointed). Apr 02 20:57:59 "When VLAN filtering is turned on, the hardware must be programmed with rejecting 802.1Q frames which have VLAN IDs outside of the programmed allowed VLAN ID map/rules." suggests there generally is vlan ID map/ruleset somehow imposed to switch Apr 02 20:59:16 olmari: That's the easy 'which vlans are on which port' part. It doesn't solve the situation where you have the same vlan on two ports and you don't want them bridged. Apr 02 21:01:26 KanjiMonster: Is DSA meant to be runtime enabled/disabled? I can see it making things easier in basic setups but for advanced stuff it sounds more like it would pointlessly handicap the hardware. Apr 02 21:03:23 why would it? even if all you say is true, it doesn't take anything away (again, assuming bugfree stuff and hardware implementation working properly) Apr 02 21:04:17 All your main gripe implies is that DSA needs to take care of generating a proper bridge in userland too Apr 02 21:04:52 olmari: The gripe implies that it hides the switch. Apr 02 21:04:55 but instead of "how I can config this thing" it becomes configing like any other networking hardware Apr 02 21:09:52 I vote DSA being novel goal, simplifying everyday networking config instead having to figure out a random switch hardware configuring methods :) Apr 02 21:10:07 hardware isn't going anywhre, just exposed diffirently to user Apr 02 21:11:30 olmari: I'm not against the idea. I just don't think there's a way to reconcile the feature set without designing network hardware specifically for DSA. Apr 02 21:11:46 In the future we ought to even see hardware more directly made to comply with it, should it really take off, but that'll we see in some 20 years :D Apr 02 21:12:21 olmari: Yes. That's essentially what's being done with SDN, which is a much more sane approach. Apr 02 21:14:05 olmari: SDN switches are essentially programmable rule sets that will behave a lot like what you seem to think current embedded switches do. Apr 02 21:15:11 They're the GPGPU of switches, more or less. Apr 02 21:16:46 Well they aren't even completely overlapping things.. or.. well... in grand scheme of things DSA is more or less subset of what SDN does Apr 02 21:19:43 SDN could easily provision a device that uses DSA within itself Apr 02 21:21:04 olmari: What makes SDN work is that the harware can (and will) consult the controller with all the metadata necessary to establish a switching decision. Apr 02 21:21:24 DSA is more of driver for a hardware, SDN is then set of rules how whole networking enviroment needs to work dynamically within allotted parameters Apr 02 21:21:29 olmari: DSA is being applied to hardware that cannot do that. Apr 02 21:22:11 My gripe is that in order to implement dsa on hardware that is too dumb to understand dsa, you end up killing pretty useful hardware features. Apr 02 21:22:30 But that's the only gripe. I'm all for DSA otherwise. Apr 02 21:23:07 DSA itself doesn't define what hardware is capable of... also I don't still see what DSA will take away from your switch hardware capabilities that is there now? Apr 02 21:24:07 There are existing networking features that cannot be expressed in terms of ethX devices and bridges. Apr 02 21:25:28 such as? Apr 02 21:25:34 To pretend that physical switch ports are 'standard ethX devices' you need to steal the vlan feature for yourself. Now if you want vlan ethX.n devices, you need to steal the QinQ feature. Apr 02 21:26:34 Assuming that it is even there. If you don't have QinQ, then your ethX.n semantic only works in some generic cases. Apr 02 21:26:56 like said, all that DSA needs to do in this case is to generate the damned bridge for userland and let hardware vlan away like today Apr 02 21:26:59 (eg, no overlapping/conflicting vlan numbers on different ethX devices) Apr 02 21:27:45 But then it's not a 'Real' bridge because the semantic breaks once again as soon as you remove an interface from the bridge. Apr 02 21:28:15 like you can define a switch port not to be part of an VLAN today? Apr 02 21:29:07 olmari: You can get close if you force all switch ports to become captive of a vlan_filtering capable bridge. Apr 02 21:29:53 But then you will never get ethX.n devices. Those cannot exist in that setup. vlans become managed by the bridge (sing the iproute2 bridge utility). Apr 02 21:30:36 So you have a good working setup, but you've defeated the purpose of having your switch ports abstracted as normal vlan interfaces Apr 02 21:32:12 how would removing eth2.3 from an bridge (or removing eth2.3 alltogether in user point of view) differ from me going in openwrt networking settingsfile and nukeing the 2t from switch config for vlan 3? Apr 02 21:32:53 instead latter I can use normal networking tools and don't care how hardware does it Apr 02 21:33:40 While that said, openwrt IS the one good "os" that exposes such switch config somewhat sanely to user.. don't know what abstraction is that ;D Apr 02 21:33:52 olmari: Our misunderstanding still stems from your notion that the data coming in on a switch port are visible to the driver/os. Apr 02 21:34:22 I have to get going but you should probably investigate that. Apr 02 21:34:44 it does not have to be... you cna still configure switch port to be part of vlan X or not Apr 02 21:35:02 Yes... But that's when you run into trouble implementing actual vlans. Apr 02 21:35:58 Again... Still have to get going. It's a stimulating talk, don't get me wrong. Apr 02 21:36:13 I hope I didn't cause too much frustration. Apr 02 21:36:43 We can pick it up elsewhere tomorrow if you'd like ;) Apr 02 21:37:31 why... like said, for the dumbest of these switches, force the DSA to impose bridge for a vlan "numbers" and assing ethX to it... be it eth2 as untagged or eth2.3 as tagged... switch hardware does exactly same stuff as currently Apr 02 21:40:32 data reaches "cpu" like it will with current way, everything is tagged in cpu port, doesn't need to reach cpu if no data is directed to "there".. how that is exposed to user in DSA, I'd say not really, as it is more of drivers problem than users... Apr 02 21:44:09 sure it is deficiency in users point if view, but does exactly same thing that current driver does, you cna't do any better config with the current one either Apr 03 00:19:00 Tapper: What Borromini said. Apr 03 01:16:34 If I've built FPU emulation into my kernel (mipsel) and I build things with soft float, aren't I just being wasteful? Or is fully-userspace FPU a little faster because of not having the system call? Apr 03 01:20:56 fpu emulation on mips is extremely slow whatever you do Apr 03 01:22:17 FinboySlick: A prerequisite of using DSA is that the switch can actually add a separated part to the packet saying 'this packet came from port X'. VLAN isn't a must to be involved here. And DSA was originally implemented in a way that it treat every port as separated ethX and bridge is done by CPU instead of the switch. The bridge offload is added Apr 03 01:22:18 later and the that only works with blindly bridging several ports. Apr 03 01:22:55 Oops. He's offline. Apr 03 01:23:45 pkgadd: OK, I'm just wondering if I'm bloating things by having -fsoft-fpu is all Apr 03 01:24:00 I mean -msoft-float Apr 03 01:25:51 being in a library vs. being in the kernel Apr 03 01:26:40 Do you happen to know which lib that is? Apr 03 01:26:52 Hopefully a shared lib Apr 03 01:27:11 I mean it's not sitting in libgcc is it? Because I believe that would be statically linked Apr 03 01:28:08 oh crap, I forgot how that works. and I've modified it before. Does libgcc have a static and shared section, or is it just always shared? :( Apr 03 01:29:40 dansan: I think the compiler just use other instructions to implement float point calculation. No library involved here. Apr 03 01:29:42 oh well, I'll look into that later Apr 03 01:29:48 ahh, ic Apr 03 01:29:57 So that would mean the code would bloat a bit, thanks Apr 03 01:30:20 I've never worked on the mips gcc backend before, only the x86 Apr 03 01:30:53 ty! Apr 03 01:34:11 dansan: Sorry. My assumption is wrong. After some Google searching I found that it is calling a library function. Apr 03 01:35:48 gch981213: oh cool! Apr 03 01:36:03 dansan: The library function is a part of libgcc. Apr 03 01:36:05 gch981213: ty, could you link that for me pretty please? :) Apr 03 01:36:09 oh great! Apr 03 01:36:25 ok, and that is static by default I think, there's a static and a shared version Apr 03 01:36:59 I remember now because I was trying to figure out how to have sections that were always static even when the build with with --shared-libgcc Apr 03 01:37:42 *was with Apr 03 01:38:59 dansan: This post is talking about x86 though: https://stackoverflow.com/questions/1018638/using-software-floating-point-on-x86-linux Apr 03 01:39:09 cool, thanks! :) Apr 03 01:48:42 Those are pretty large functions too. e.g., __mulsf3 is 720 bytes. So I guess verifying removing -msoft-float when FPU emulation is enabled can save a tiny bit of memory at the expense of floating point being every so slightly slower -- at least for programs that use it. Apr 03 01:48:59 s/verifying removing/removing/ Apr 03 02:00:47 i think kernel fpu emulation traps the illegal instruction and passes it to some kind of handler Apr 03 02:01:06 seems it'd be more overhead Apr 03 02:01:07 oh thanks Apr 03 02:01:29 yeah, I don't know. it still has to switch to kernel mode Apr 03 02:01:39 I suppose I can do a benchmark Apr 03 02:01:55 I have to have it on because somebody wants to use golang on our board Apr 03 02:02:09 and it needs FPU emulation Apr 03 02:02:38 m4t: that's a pretty smart way to implement it though, it makes sense Apr 03 02:04:52 i dunno how else the kernel would do it **** ENDING LOGGING AT Wed Apr 03 02:59:57 2019