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