Messages in this thread | | | Date | Wed, 7 Jun 2017 22:53:36 +0100 | From | Alan Cox <> | 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
| |