realtek: Prepare for multiple SoC types

[oliv3r]

This MR prepares the Makefile for a future where non-switch chips would also be supported.

In doing so, we introduce the 'switch' device type.

[Borromini]

At least the present SoC families (RTL83xx and RTL93xx) are wholly unfit for routing (weak MIPS SoC and whatnot). In addition, there's little flash (even more so if we like to stick with the dual-partition layout multiple OEMs offer). I only see drawbacks in switching to the router DEVICE_TYPE. It will pull in dnsmasq, but also ppp support which eats flash space. The case for including dnsmasq is a flimsy one. Who has their switches acting as a DHCP server? I'm sure the few people who do can use the image builder or compile their own image.

The realtek target was switched away from the default router target earlier on, and with good reasons if you ask me. I think this is a bad idea.

[oliv3r]

At least the present SoC families (RTL83xx and RTL93xx) are wholly unfit for routing (weak MIPS SoC and whatnot). In addition, there's little flash (even more so if we like to stick with the dual-partition layout multiple OEMs offer). I only see drawbacks in switching to the router DEVICE_TYPE. It will pull in dnsmasq, but also ppp support which eats flash space. The case for including dnsmasq is a flimsy one. Who has their switches acting as a DHCP server? I'm sure the few people who do can use the image builder or compile their own image.

The realtek target was switched away from the default router target earlier on, and with good reasons if you ask me. I think this is a bad idea.

Currently, openwrt does not offer the 'switch' type. So a good argument can be made for one.

Secondly, it's all about choice, yeah, and 'they can use the builder' is a very poor form of choice. One can argue of having 2 images, one that's stripped down and in favor of limited flash space (6MiB flashes, and dual firmware support) where a more feature filled device would have 14MiB-ish of space. Btw, my branch has offered both types of images for 6 months already :) stuff that hasn't been merged, sure.

So dnsmasq isn't really that big, is it? And 'who uses their switch as DHCP? Many IT staffers. They get Cisco and HP switches, which all offer DHCP as an option, and some happilly configure it as such. So who is our end-user here?

So then the only point becomes PPP. That is a nasty one I admit, probably because of PPP-OE on the wan port (less likely for actual modems) but even here, 'home-users' may have this switch behind a ISP modem, which does basic firewalling and basic routing, but PPP-OE is handled by the switch :)

Anyway, the 'router' target is far more accurate then the 'basic' target. And that does not mean you have to use it as a router. There is no WAN port configured, it is not 'natural' to set it up as a router, but it is certainly possible. Users choice, freedom and all that.

Also, just because it is poor choice, doesn't mean its impossible. With L3 offloading, performance won't be that horrible, you don't have to route it all with the CPU...

[Borromini]

Currently, openwrt does not offer the 'switch' type. So a good argument can be made for one.

Honestly? Until this PR I actually thought we had one, but it turns out our hardware just extends the 'basic' device type. I do not know the rationale behind it. It does work, though.

Secondly, it's all about choice, yeah, and 'they can use the builder' is a very poor form of choice.

Well - on one hand, you'te talking about IT staffers. You can safely assume they're skilled at what they do. If they decide to use OpenWrt on their hardware in a production environment, they hopefully know their way around the buildroot or the image builder. On the other hand, you're talking about choice, yet would like to be your preference the default (which is your prerogative, of course). Including extra stuff/settings just for a tiny minority that might use it does not constitute 'choice'. Again: we're talking edge cases here. 'Use the image builder or buildroot to strip X or Y' or 'disable X or Y after installation' is not what I would consider choice.

One can argue of having 2 images, one that's stripped down and in favor of limited flash space (6MiB flashes, and dual firmware support) where a more feature filled device would have 14MiB-ish of space.

I am not immediately aware of other embedded stuff OpenWrt supports that offers multiple images for the exact same device. I think there's a strong point to be made in favour of sticking with the OEM dual partition layout, especially for the less mature realtek subtargets like rtl93xx. Switching back and forth between both firmware slots is very handy, still.

So dnsmasq isn't really that big, is it? And 'who uses their switch as DHCP? Many IT staffers. They get Cisco and HP switches, which all offer DHCP as an option, and some happilly configure it as such. So who is our end-user here?

The FOSS and networking enthusiasts are. Since even rtl83xx is not feature complete, I do not see any IT professionals deploy them with OpenWrt in a production environment, unless you do not need the stuff like LACP and the likes. All my rtl83xx switches do run OpenWrt at home, but for another deployment where I did need LACP, they're still on ZyXEL's OEM firmware, as much as it pains me.

Ask yourself how many people will be weirded out when their network starts behaving badly upon installing OpenWrt with a DHCP server on a switch - switches which default to exactly the opposite behaviour on OEM firmware - and how long it will take them to figure out why they have multiple DHCP servers running. That's bad publicity. Again: people who do need it will know full well how to pull in a DHCP server. Easy peasy. Done in a jiffy.

Anyway, the 'router' target is far more accurate then the 'basic' target. And that does not mean you have to use it as a router. There is no WAN port configured, it is not 'natural' to set it up as a router, but it is certainly possible. Users choice, freedom and all that.

The present defaults are sane if you ask me. Users are free enough to hack together whatever they'd like.

Also, just because it is poor choice, doesn't mean its impossible. With L3 offloading, performance won't be that horrible, you don't have to route it all with the CPU...

Let's not encourage poor choices just because they are possible.

[oliv3r]

Currently, openwrt does not offer the 'switch' type. So a good argument can be made for one.

Honestly? Until this PR I actually thought we had one, but it turns out our hardware just extends the 'basic' device type. I do not know the rationale behind it. It does work, though.

I initially had that in my branch for 6 months, not realizing it didn't even work lol.

After writing my earlier comment, I realized, we should have. So I added it as part of this MR :)

Secondly, it's all about choice, yeah, and 'they can use the builder' is a very poor form of choice.

Well - on one hand, you'te talking about IT staffers. You can safely assume they're skilled at what they do. If they decide to use OpenWrt on their hardware in a production environment, they hopefully know their way around the buildroot or the image builder. On the other hand, you're talking about choice, yet would like to be your preference the default (which is your prerogative, of course). Including extra stuff/settings just for a tiny minority that might use it does not constitute 'choice'. Again: we're talking edge cases here. 'Use the image builder or buildroot to strip X or Y' or 'disable X or Y after installation' is not what I would consider choice.

Well we are talking about 'a sensible default for most users' though. E.g. if joe-sixpack downloads openwrt, installs it on his hardware, and what he expects to be there. I think comparing it to 'off-the-shelf' solutions, isn't far-fetched tbh. My 15 year old SoHo 8 port switch offers these things too.

One can argue of having 2 images, one that's stripped down and in favor of limited flash space (6MiB flashes, and dual firmware support) where a more feature filled device would have 14MiB-ish of space.

I am not immediately aware of other embedded stuff OpenWrt supports that offers multiple images for the exact same device. I think there's a strong point to be made in favour of sticking with the OEM dual partition layout, especially for the less mature realtek subtargets like rtl93xx. Switching back and forth between both firmware slots is very handy, still.

afaik, 'off-the-shelf' openwrt doesn't support dual partitioning, does it? Anyway, I'm already offering 2 images, one that fits in the OEM partition layout, one that fits into the whole flash space.

Having said that, the 'oem/vendor' layout will likely move towards the 'tiny' subset, that some routers have (think 4/8MiB devices). I think these switches (with dual-firmware layout) will be restricted herein and offer far less functionality. But that's fine, it's a choice in the end. I think we're lucky in that we don't need a lot of the router/wifi packages which cost a lot of space as well.

So dnsmasq isn't really that big, is it? And 'who uses their switch as DHCP? Many IT staffers. They get Cisco and HP switches, which all offer DHCP as an option, and some happilly configure it as such. So who is our end-user here?

The FOSS and networking enthusiasts are. Since even rtl83xx is not feature complete, I do not see any IT professionals deploy them with OpenWrt in a production environment, unless you do not need the stuff like LACP and the likes. All my rtl83xx switches do run OpenWrt at home, but for another deployment where I did need LACP, they're still on ZyXEL's OEM firmware, as much as it pains me.

Ask yourself how many people will be weirded out when their network starts behaving badly upon installing OpenWrt with a DHCP server on a switch - switches which default to exactly the opposite behaviour on OEM firmware - and how long it will take them to figure out why they have multiple DHCP servers running. That's bad publicity. Again: people who do need it will know full well how to pull in a DHCP server. Easy peasy. Done in a jiffy.

But why would we enable the dhcp server by default? We just want the option to be a click away to turn it on. I wouldn't expect that a dhcp server be running by default handing out IP addresses without user intervention!

Anyway, the 'router' target is far more accurate then the 'basic' target. And that does not mean you have to use it as a router. There is no WAN port configured, it is not 'natural' to set it up as a router, but it is certainly possible. Users choice, freedom and all that.

The present defaults are sane if you ask me. Users are free enough to hack together whatever they'd like.

You do know, that we already add firewalling packages as part of our specific basic + packages, yeah? :) so we're not even using the basic target :p

Also, just because it is poor choice, doesn't mean its impossible. With L3 offloading, performance won't be that horrible, you don't have to route it all with the CPU...

Let's not encourage poor choices just because they are possible.

But that's in the eye of the beholder. Again, if we look at cisco, HP or Jupiter, what they offer 'out of the box' is not an unreasonable default to have in terms of software availability :)

[oliv3r]

hmm, dropping this change, it builds and runs; but spewing illegal instruction.

rebuilding with 24kc to confirm this was causing it first. weirdly, the CPU IS being identified as 34kc ...

[KanjiMonster]

The difference of 34kc vs 24kc is only relevant for the kernel. For userspace GCC generates identical code for both. So changing this from 24kc to 34kc has no advantage as the built binaries will still behave the same, but has the disadvantage of now requiring a mips_34kc stage 2 builder and its own package set.

So a NAK on this change anyway.

[oliv3r]

It's already gone, but I don't think this is true any longer. I'm getting 'Illegal instruction' errors with 34kc, and 24kc works fine. So technically this chip isn't truly 34kc compliant anyway it seems.

Anyway, what triggered me was the following patch: 308-mips32r2_tune.patch, which does some explicit 34kc stuff.

[KanjiMonster]

The issue is/was more likely that there is no CPU_CFLAGS_34kc defined anymore in include/target.mk, so GCC probably defaulted to mips32r1. It was removed in a11843b.

[phinexhung]

How about using a more generic name for all of the boards? If I add rtd129x, rtd1319 and rtd1619b, the list will be a little bit lengthy ? How about put these SoC specific in the subtarget makefile ?

[oliv3r]

The name would be extended to RTL83xx/RTL93xx/RTD1xxx so not too bad. We should put the names somewhere, so users can find it easily. Oth, the subtargets will already list it anyway, so removing it is not a bad idea.

[phinexhung]

Good for me to extend RTD1xxx sub targets.

[oliv3r]

@Ansuel this has a little global impact as well, so if you can share your 2 cents ...

[Neustradamus]

@oliv3r: Have you progressed on this PR?

[oliv3r]

I think it was stuck a bit on the reivew part wasn't it @Neustradamus

[phinexhung]

Any suggestions that we can do to let this go further?