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
