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
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 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
> >>> 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,
