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

Sat May 2 22:40:29 EDT 2020

I’m not convinced that would be necessary, or that this proposal would create any new circumstances.

An example is that certain architectures are supported by MUSL and others by uClibc, or eglibc, etc.  That in turn means that some functionality is available and others not, because not all packages compile against all architectures and runtimes, etc.

The schism of “fat” vs. “skinny” device in some cases might be an architectural issue, as some processors or SoCs don’t have the physical ability to address more than N megabytes of memory, so they are architecturally constrained.  It’s common for 32-bit processors to have under 4GB of memory and in some cases substantially less than 4GB.

Likewise ARM64 and x86_64 processors can almost guarantee platforms having at least 1GB and usually more.

So we wouldn’t need to cleave things on a “device” basis, but on a “processor family” (i.e. architecture) basis.

> On May 2, 2020, at 7:05 PM, Dustin Howett <dustin at howett.net> wrote:
> 
> I'm concerned about introducing a global configuration symbol that
> changes the behavior of any individual package--right now, large- and
> small-format devices share the same package feeds, and there's no
> provision in opkg for package variant flags.
> 
> This suggests that we'd need to host a feed for skinny builds and a
> feed for chonky builds, which would really increase storage, hosting
> and buildbot demand.
> 
> On Sat, May 2, 2020 at 5:29 PM Philip Prindeville
> <philipp_subx at redfish-solutions.com> wrote:
>> 
>> Wherever we can find common ground, I’m willing to go.
>> 
>> I’ve worked on various projects that used OpenWRT in some atypical scenarios (positioning radios, traffic shapers, home security hubs, etc).  I think it gets used for a broader base of development than most people realize.  There’s a LOT downstream of it.
>> 
>> -Philip
>> 
>> 
>>> On May 2, 2020, at 5:51 PM, Lucas Ramage <oxr463 at gmx.us> wrote:
>>> 
>>> 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
>> 
>> 
>> _______________________________________________
>> 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