Re: [PATCH v2 0/8] scheduler tinification

[Alan Cox]

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

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

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


Alan