Excellent idea! But perhaps we could use either CONFIG_CONSTRAINED, or CONFIG_DEVICE_THIN instead?
Regards, On May 2, 2020 9:54:16 PM UTC, Philip Prindeville <philipp_s...@redfish-solutions.com> wrote: >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@lists.openwrt.org >https://lists.openwrt.org/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
