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

Sat May 2 21:05:00 EDT 2020

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