[LEDE-DEV] lede integration issues remaining from the detrius of cerowrt

[Daniel Curran-Dickinson]

On Tue, 2016-06-14 at 11:05 -0700, David Lang wrote: 
> On Mon, 13 Jun 2016, Daniel Curran-Dickinson wrote:
> 
> > On Mon, 2016-06-13 at 11:17 +0200, Jo-Philipp Wich wrote:
> >> Hi,
> >>
> >> no need to overreact :)  I think parts of the topics are about the
> >
> > Hope you're referring to Pinney and not me!  I was concerned because
> > Dave Taht's email and David Lang's post) seemed to me to imply changing the
> > defaults to suit bigger iron as the default rather than simply making
> > it a supported option.
> 
> I think you misunderstood our comments and concerns. We want the bigger hardware 
> to be a supported option, and don't like the response that this initially got of 
> "that's something only needed for bigger hardware, we shouldn't have it as an 
> option in LEDE"

I think you misunderstood my reaction.  I didn't mean that I didn't
think bigger hardware/VMs should be supported - in fact I have some
patches in queue for exactly that kind of scenario - I just was
concerned that it appeared to be a request to alter the defaults, not
just allow the support.

> 
> Both of us play with very small hardware as well, we don't want to close out the 
> low end devices.
> 
> > I also think that talking about a 5-10 plan as
> > the basis if making decision of what to include by default in *current* builds
> > is rather foolish thinking.  Yes planning for the future is important but to
> > it reminds of a quote from when I was religious: "Don't be so heavenly-minded
> > you're no earthly good".  Basically here and now needs not to be forgotten in
> > dreams of future wonders.
> 
> Agreed, but at the same time you shouldn't ignore support for the larger 
> hardware.
> 
> Remember, this thread started with the request to support hard drives >2TB and 
> the reaction was "we don't need that routers only have a few tens of KB of 
> flash" (even though it turned out that the support has already been included)

Again I think you read too much into what I said (admittedly I do the
same myself, at times, as you well know), but I wasn't saying there is
no use case for it, only that it's not the 'primary', or 'default' use
case.

By all means, I'm game for maximum flexibility that doesn't hurt the
primary use case. 

In the case the 2TB+ drives, I was concerned that such support would come
*at the expense of* the primary use; fortunately it doesn't, but if it did,
I would argue against kernel options (for example) for making the support
the *default* (e.g. in buildbot builds), except maybe for something like x86
boards/use cases (in the case of x86 I'm not sure that limiting hardware
support to save space is in most cases necessary; other cases like default
userspace I'd argue should be kept consistent and changes from default
management with things like ImageBuilder.

In general I'm a fan of ImageBuilder because, provided the kernel support is there,
you can use the SDK and build whatever packages you want to add on, and use
ImageBuilder to generate images that use those packages (along with the standard
ones you still want), without getting in the way of the primary use case.

> >
> > To a certain extent though, I question the need for something as restricted as OpenWrt
> > for the new bigger devices anyway; there are elements like netifd that would be good to
> > see continue, but I'm not sure that most of OpenWrt really makes as much sense when you're
> > not needing to squeeze maximum use out of very erase block, and that therefore, while it
> > may be a smaller market/mindshare, that focussing on the the true embedded type scenario,
> > seems to be more of what LEDE's niche is.
> 
> LEDE/OpenWRT is a good fit for any device that operates on raw flash instead of 
> a hard drive or ssd with wear leveling. Once you have storage that you don't 
> worry about wearing out and is large enough to hold a normal Linux Distro, it 
> makes sense to move to such a distro and update packages individually.

Hmmm...the wear levelling thing is confusing.  I was told by someone who I thought knew
what they were talking about, that flash chips included some form of hardware-based
wear levelling built in already.  Apparently that is was inaccurate (hardware-level
support is something I only having minor knowledge of; it's not the part the interests me,
nor where I have worked on it for any length of time; I'm more interested in what you can
do with existing hardware support combined with software rather developing the core support
itself).

> But when you have a limited amount of boot/OS storage that does not have wear 
> leveling in place, then the OpenWRT/LEDE approach of a complete filesystem image 
> that gets updated as a whole still makes sense.
> 
> Even when we have a few Gb of flash storage available, we will still want to use 
> compressed, read-only filesystems for the main OS packages.

Actually I'm rather a fan of the squashfs / overlay, or alpine-style LBU
thing where you revert to 'factory defaults' by removing all changes
from flashed (or stored on read-only partition in the case of alpine)
image.  Also squashfs shrinks the size requirements quite nicely for
things you know in advance you need.

Whether that means whole LEDE stack remains useful on bigger iron, or
whether it simply provides some good starting points, is something I'm
of two minds about.

I'm not 100% how I feel about LEDE/OpenWrt on larger devices; in some
respects I want to make LEDE/OpenWrt useful for e.g. NAS/IoT and/or
lightweight containers/VMs, OTH I'm not sure that's a useful way to
spend my time, given other alternatives that are already available.

Regards,

Daniel