GENERIC kernel issues

[Warner Losh]

On Mar 6, 2013, at 4:40 PM, Aleksandr Rybalko wrote:

> On Wed, 6 Mar 2013 15:16:02 -0800
> Adrian Chadd <adrian at freebsd.org> wrote:
> 
>> Peeps,
>> 
>> If you make the boot process too complicated and it stops being "load
>> kernel via flash/NFS, boot" then people may just not bother. :-)
>> 
>> I know you're going for correctness and we're hampered by how "linux
>> does things', but I really do suggest that you first get working,
>> packaged, easily installed and updated systems using what we currently
>> heave before you try to make a 'much nicer but noone ever uses it'
>> solution.
>> 
>> Please don't fall down the trap of "over-engineering correctness that
>> noone will ever use." that software people do when they don't have
>> deliverables.
>> 
>> 2c,
>> 
>> 
>> 
>> Adrian
> 
> Adrian, 
> 
> I hope you don't compile special kernel before first boot on
> every new laptop/desktop/server? :)))
> 
> We want also find such drugs for so mach fancy ARM world, so anybody
> will have a way to boot board with one of few install images, but not
> one per board.

another way of saying this is that the commercial folks that have been using ARM boards have discovered that a diversity of kernels is bad, and the more boards one kernel can support the better for their support load. Also, we've been down the compile it per board route, and it is showing signs of strain. Linux also went down this route years ago and found the strain too much so has been evolving into a single kernel image that supports any FDT platform. We're a ways away from *THAT*, but one of the issues that needs to be solved is loading stuff in the right place, and Ian is well down that path and should have a solution to that. Then all we have to worry about are things like DELAY, cpu_*, platform_*, cache coherence differences (currently ifdefs in pmap v6 code), switching between v4/5 and v6/7 pmap, and likley a few others that I've forgotten. All these things today make a single image impossible. But it is a solveable, whack-a-mole problem rather than an infinite set of things we have to struggle with.

So while we're not trying to stop someone from having a custom kernel, we're trying to have a viable GENERIC that actually works like x86 and ppc do today, hopefully without a big performance hit.... Should we succeed, then you can still build a specific thing, should we fail, you can still build a specific thing...  But if we succeed you won't be forced to do so...

Warner