Re: [PATCH v2 0/8] scheduler tinification

[Nicolas Pitre]

On Wed, 7 Jun 2017, Alan Cox wrote:

> > Next on my list would be a cache-less, completely serialized VFS bypass 
> > that has only what's needed to make the link between the read/write 
> > syscalls, a filesystem driver and a block driver while preserving the 
> > existing kernel APIs. And by being really small, the maintenance cost of 
> > a "parallel" implementation isn't very high, certainly much less than 
> > trying to maintain a single code path that can scale to both extremes 
> > in that case.
> 
> So once you've rewritten the tty layer, the device drivers, the VFS and
> removed most of the syscalls why even pretend it's Linux any more. It's
> something else, and that something else is totally architecturally
> incompatible with Linux.

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.

Then if most syscalls are removed then *of course* you won't be able to 
boot a standard "Linux" distro on it. But that's not the point either. 
However the compatibility is preserved the other way around i.e. user 
space from this Linux subset should just work as is on a full Linux 
kernel. And it would still be a Linux code base i.e. architecturally 
compatible with Linux at the source level.

> That's btw a good thing - trying to fit Linux
> directly into such a tiny device isn't sensible because the core
> assumptions you make about scalability are just totally different.

For a couple core components that's true, hence my approach with the TTY 
layer. But many other parts aren't that bad. And given that a small 
system can't afford that many whistles and bells then it is not like if 
the whole of Linux would be rewritten anyway.

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

> When you look at tiny hardware even core bits of the Linux
> architecture like the wait queues are just not sensible uses of memory
> and cause fragmentation. The dcache is completely insane in that
> environment, the scheduler is total overkill and the networking is easy
> to DoS in a tiny memory. The device layer assumes dynamic hot pluggable
> device architecture - and that's extremely expensive but nonsensical for
> most Âcontrollers.

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?

> 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?


Nicolas