[OpenWrt-Devel] Proposal: Differentiating "skinny" platforms from others... (resending)

Sat May 2 20:26:59 EDT 2020

I think we’re both agreeing that there’s a time/place for “largish” platforms to have their own allowances called out, aren’t we?

We can explicitly call out either the constrained or the seemingly limitless… either way is fine.

The benefit of calling out the constrained is that they’re hopefully a diminishing population, but that might be overly optimistic on my part.

I’m not sure the purpose of OpenWRT *is* to provide the minimum necessary.  After all, isn’t that why we’re replacing the factory programming in a lot of COTS boxes like the Linksys WRT54NL, etc?  Because the minimum wasn’t enough?

As for defining it, I’d say it’s less about “nice-to-have” and more about “why handcuff yourself when you don’t have to?”

Maybe:

CONFIG_LARGE_FLASH
CONFIG_LARGE_MEMORY

and:

CONFIG_FAST_CPU

(“Huge” tends to have a particular connotation in the Linux kernel that doesn’t apply here…)

-Philip

> On May 2, 2020, at 5:48 PM, mail at adrianschmutzler.de wrote:
> 
> Hi,
> 
> just a single thought on this:
> 
> For me, this quickly raised the question: What's normal and what's exceptional?
> 
> Your proposal assumes that "huge" devices are normal (default), and skinny devices are the exception which has to be "marked".
> 
> Why not the other way around? For standard, just keep the basic stuff, and then mark some targets/devices that have the capability to carry on extra work/duties...
> 
> While I intentionally raise this question for a _general_ discussion, in practice "my proposal" actually would have some benefits:
> - While your proposal would mark all tiny devices/targets, I would just mark the "excessive" devices. So, with "my" solution there is no chance a tiny device is overlooked and broken by some package adding a lot of stuff to the upgrade. If on the other hand an "excessive" device is overlooked, no damage would be done.
> - Since this is about "extra features", and you seem to think about different categories, it makes more sense and would be easier to (specifically) mark the devices that would get those extra features, instead of marking a whole lot of other devices not getting them.
> - Your whole idea for me sounds like it's about "nice-to-have" stuff. Since the OpenWrt default is to provide the necessary minimum, the default config should also mirror this concept (again, thus marking the "extra").
> 
> So, while I'm not sure whether I really like your idea in general, I'd create something like
> 
> CONFIG_HUGE_FLASH
> CONFIG_EXTRA_MEMORY
> 
> or whatever similar to mark the "big" devices if I had to.
> 
> Best
> 
> Adrian
> 
>> -----Original Message-----
>> From: openwrt-devel [mailto:openwrt-devel-bounces at lists.openwrt.org]
>> On Behalf Of Philip Prindeville
>> Sent: Samstag, 2. Mai 2020 23:54
>> To: OpenWrt Development List <openwrt-devel at lists.openwrt.org>
>> Subject: [OpenWrt-Devel] Proposal: Differentiating "skinny" platforms from
>> others... (resending)
>> 
>> Hi all,
>> 
>> We sometimes get into debates about whether certain functionality should
>> be allowed and oftentimes the gating factor is “will this fit in a skinny
>> platform” (i.e. something highly constrained, like 32MB of DRAM)?  I suppose
>> there’s a similar argument about what a “small footprint” machine has in
>> terms of Flash, as well.
>> 
>> Some of us work with more current machines that are also more capable,
>> realizing that eventually machines with 32MB of DRAM and 128MB of Flash
>> will “age out” through failure and scarcity.
>> 
>> By then we’ll have a new “normal” about what the minimum expectations
>> are, and the conversation will continue, but with different parameters.
>> 
>> Understanding that the definition of a “skinny” machine isn’t today what it
>> was 5 years ago, and that it won’t be the same again in another 5 years, I’d
>> like to proposal a CONFIG_ symbol that denotes that a platform is in a class of
>> constrained architectures.
>> 
>> Or, conversely, that a platform doesn’t have to observe overly restrictive
>> constraints on “what will fit”.
>> 
>> (The smallest router platform I own has 256MB of DRAM, an 2GB of Flash for
>> instance, and it’s a 12 years old PC Engines Alix 2D… most of the “current”
>> machines I have are AMD64 and have 64GB of DRAM and 32GB or more of
>> Flash… with 256GB being the median…)
>> 
>> This would allow us to develop packaging that both fits into constrained
>> architectures, as well as targeting further along the evolving curve of “more
>> RAM, more disk” that newer and newer platforms inevitably follow.
>> 
>> For instance, I was on IRC yesterday with Jo-Philipp talking about whether
>> the xt_geoip database should be propagated across sysupgrades,
>> understanding that:
>> 
>> (1) some people might use it in their firewall rules (/etc/firewall.user) to
>> block certain country codes as part of their system coming up, and don’t
>> want to be in the vulnerable position of just having performed a sysupgrade
>> and reboot, but now finding themselves without the geo-location database
>> and therefore not able to block certain countries, ISPs, etc. that are known to
>> harbor APT’s;
>> 
>> (2) the database takes slightly over 7MB today, and that might be more than
>> one can reasonable propagate during a sysupgrade, and some people might
>> not want to risk a failed sysupgrade… understanding that they can re-
>> download and re-install the database without too much trouble (it takes a
>> couple of minutes to download and unpack, even on a modest broadband
>> connection);
>> 
>> My proposal is the CONFIG_SKINNY parameter (and possibly others, if we
>> need to triage in multiple dimensions; see below).  If this is set, then
>> conservative decisions need to be made in packaging about disk and RAM
>> consumption.  If this isn’t set, packaging might assume there’s “room to
>> stretch one’s legs”.
>> 
>> In the prior scenario, the assumption would be that backing up the geo-
>> location database is feasible on unconstrained platforms, and one could add:
>> 
>> ifneq ($(CONFIG_SKINNY),y)
>> define Package/iptgeoip/conffiles
>> /usr/share/xt_geoip/
>> endef
>> endif
>> 
>> to feeds/packages/net/xtables-addons/Makefile for example.
>> 
>> Then we can move away from the argument about “should X be allowed” to
>> the more productive discussion “when is it acceptable to allow X” instead?
>> 
>> And hopefully, what’s “allowed” (or viable) will only increase over time,
>> giving us more and more options to tailor OpenWRT into the optimal
>> configuration for our needs.
>> 
>> So, I put to you 4 questions:
>> 
>> (1) should we include CONFIG_SKINNY?
>> (2) what is the minimum DRAM that a platform should have to not be
>> considered “skinny”?
>> (3) what is the minimum Flash (or other storage) that a platform should have
>> to not be considered “skinny”?
>> (4) should clock speed figure into this?  or some “normalized” accounting of
>> clock speed, that takes super-scalar and deep pipelining into consideration,
>> such as MIPS, be considered?  or should this be an orthogonal parameter,
>> such as CONFIG_SLOW?
>> 
>> I’ll kick off with my own initial empirically derived answers, with:
>> 
>> (1) yes, it can’t really do any harm… people who don’t want to deal with it
>> won’t, making everything effectively “skinny” which is the status quo;
>> (2) 256MB is already fairly capable… we can use that as the initial definition of
>> “skinny” and tweak it as experience dictates is reasonable;
>> (3) 512MB is also a fair amount of space for image plus extended logging;
>> (4) above 1000 MIPS, I’d not consider an embedded platform to be “slow”… a
>> 500MHz processor executing 2 instructions per cycle, or having 2 cores and 1
>> instruction per core per cycle, is fairly capable, easily able to handle traffic
>> shaping on a 100Mb/s link;
>> 
>> What does everyone else think?
>> 
>> Thanks,
>> 
>> -Philip
>> 
>> 
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel