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_s...@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 <oxr...@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, m...@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-boun...@lists.openwrt.org] > >>> On Behalf Of Philip Prindeville > >>> Sent: Samstag, 2. Mai 2020 23:54 > >>> To: OpenWrt Development List <openwrt-devel@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@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 _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
