Messages in this thread | | | Date | Wed, 7 Jun 2017 17:15:32 -0400 (EDT) | From | Nicolas Pitre <> | Subject | Re: [PATCH v2 0/8] scheduler tinification |
| |
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 | |