I like “CONSTRAINED” as well. We could even have:
CONFIG_CONSTRAINED_MEM and: CONFIG_CONSTRAINED_DISK and if either is set, then it sets CONFIG_CONSTRAINED as well. > On May 2, 2020, at 4:09 PM, Lucas Ramage <oxr...@gmx.us> wrote: > > 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 _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
