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

[David Lang]

On Tue, 14 Jun 2016, Daniel Curran-Dickinson wrote:

> 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,
>>>>
> Again I think you read too much into what I said (admittedly I do the
> same myself, at times, as you well know)

fair enough, now we've both clarified and find that we are pretty much in 
agreement.

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

I generally compile my own images because I am tweaking even kernel options 
(disabling connection tracking on any build that's not a firewall for example), 
but getting better images and image generation would be very good.

With Imagebuilder and things pre-compiled, what does it take to create an image? 
I'm wondering if this is something that can be converted to a web UI where we 
could have someone select stuff (or upload a config file) and have the system 
spit out a custom tailored image a few seconds later.

Something like this could do wonders to move people away from the 'base image 
must contain what I need' mentality.

>>> 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).

raw flash chips like we have in a router have nothing.

flash chips packaged in SD cards, USB drives, etc commonly have very primitive 
wear leveling (in many cases only targeted at the places that the FAT filesystem 
is going to use)

flash chips packaged into SSD drives or anything more sophisticated tend to have 
very extensive wear leveling setups, and will move existing, unmodified data if 
needed to balance things.

I haven't looked recently, but a couple years ago the idea of having an 
in-kernel flash wear leveling capability was getting a lot of discussion on the 
kernel mailing list. I din't remember seeing what finally happened with that.

For the very tiny devices, it doesn't make sense to try and make use of 
something like that (it takes more space ond isn't going to apply to a static, 
pre-build compressed filesystem)

But for the overlay filesystem where new stuff may get added on newer devices 
that have the much larger NAND flash, it may be something to look into, even 
though it complicates the base config for such systems.

David Lang