Message-ID: <20170607225336.253d2c80@lxorguk.ukuu.org.uk>
Date:   Wed, 7 Jun 2017 22:53:36 +0100
From:   Alan Cox <gnomes@...rguk.ukuu.org.uk>
To:     Nicolas Pitre <nicolas.pitre@...aro.org>
Cc:     Ingo Molnar <mingo@...nel.org>, Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v2 0/8] scheduler tinification

> You got at least one thing wrong. One huge benefit is to leverage 
> existing device drivers of which Linux is plentiful. So there is no 
> point rewriting device drivers.

So you want to keep a common interface for some of the common driver
APIs. Several people have managed that.

> > IMHO it would be far far better to just borrow the bits that look 
> > handy, and the bits of the ABI you need and put them together as a new 
> > OS kernel.  
> 
> Hasn't that been attempted and failed already? One nasty effect of such 
> an approach is effectively the creation of a fork, then you completely 
> lose the community leverage and gravitational effect, create 
> fragmentation, fixes are not propagated across, etc.

Almost nothing can be shared though, and for drivers you want to re-use
then if you can re-use them you can share the code for that.

> Why do you think I'm proposing scheduler patches? And TTY patches before 
> that, and having plans for the VFS? Obviously, all those things coule be 
> reimplemented for small scale in a new and separate tiny OS. But what if 
> those things could just live in the Linux source tree alongside their 
> big cousins and be swapped according to your needs? Why couldn't those 
> arguments served to the embedded people for years about joining the 
> mainline effort be extended to this use case as well?

I don't think it works like that. The overhead of the duplication
and trying to keep them aligned rapidly exceeds the value they give. The
moment you try and do the job well you also 
> 
> > It's easy to put a Unixlike OS in 256K of RAM and a pile of flash. It's
> > going to be pretty easy to put all the major bits of the Linux API into
> > it. You can run 2.11BSD with only 256K of writable memory (you need more
> > in your PDP-11 to run it but if you look all of that in a µcontroller
> > would live in flash).  
> 
> Would be nice if that could share the same source code whenever 
> possible, and also the same source tree, no?

But that will never work. The fundamental architecture of a tiny system
is different because the scaling rules and underlying algorithms are
different. wait queues don't work sanely on tiny devices, TCP queues need
a totally different architecture, scheduling is quite different, memory
mangement is totally different, things like the dcache which is fairly
fundamental to the VFS internals make no sense, the locking model for
file systems makes no sense because you can't use all that expensive
scaling. Even the device core which is designed for dynamically managed
trees of devices with hotplug, discovery and power management heirarchies
is basically a large resource expensive paper weight.

It goes on and on. Add any desire to do hard real time or meet things
like ASIL-B to that and you hit a brick wall pretty damned quick.

When you proposed the tty changes I was dubious, now you are talking
about basically writing a new OS kernel in the same git tree that shares
the drivers it looks even less sensible from a Linux perspective.

Alan

Powered by blists - more mailing lists