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

Sat May 2 19:51:52 EDT 2020

I like that even better.

OpenWrt has traditionally focused on embedded systems such as routers and the like. So these should be the default as you say.

Then if I want to run OpenWrt on a larger machine, I can add the fat so to speak.

On May 2, 2020 11:48:03 PM UTC, 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