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
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
