Messages in this thread | | | Date | Mon, 3 Oct 2005 21:00:55 +0100 | From | Jon Masters <> | Subject | Re: what's next for the linux kernel? |
| |
On 10/3/05, linux-os (Dick Johnson) <linux-os@analogic.com> wrote: > > On Mon, 3 Oct 2005, Lennart Sorensen wrote:
> > I suspect most 'simple' OS teaching tools are awful. Of course writing > > a complete OS from scratch is a serious pain and makes debuging much > > harder than if you can do your work on top of a working OS that can > > print debug messages.
> But the first thing you must do in a 'roll-your-own' OS is to make > provisions to write text to (sometimes a temporary) output device > and get some input from same.
Indeed. I started work on a microkernel for a final year University project. Didn't get very far beyond minimal memory management and a vague handy-wavy concept of a process in the end as it's easy to get unstuck figuring out random blackbox hardware. Makes you respect some of these people who really figured it out for real and got it working.
> Writing such basic stuff is getting harder because many embedded > systems don't have UARTS, screen-cards, keyboards, or any useful > method of doing I/O.
It's easier now that we have a growing number of cheaper ARM/PPC boards on the market. But in order to do much of this, you really need a hardware debugger. In my case, I tried to do this on an Apple powerbook but once you've broken the BAT/page mapping for your framebuffer you're rapidly running out of ways of debugging, e.g. a VM. It's difficult enough even with a UART, or an LED, or whatever.
> This is where an existing OS (Like Linux) can help you get some I/O > running, perhaps through a USB bus. You debug and make it work > as a Linux Driver, then you link the working stuff into your headless > CPU board.
A lot of people end up doing that - I've heard of some interesting stories which I'm sure aren't widespread. One case, the guy had basically bolted a small realtime module on to Linux (not really quite like RTLinux) but had been able to do a lot of testing through existing APIs. Another trick is to write as much as you can to sit right atop the existing firmware - OpenFirmware, U-Boot, whatever and perhaps even forgo trying to handle exceptions/VM for yourself in the beginning.
Jon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |