From fnaumann@mail.cs.uni-magdeburg.de Sun Jul 11 20:41:20 2004 Message-ID: <40F1889D.8010500@inf.tu-dresden.de> Date: Sun, 11 Jul 2004 20:36:13 +0200 From: Norman Feske User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: Frank Naumann CC: mint@fishpool.com Subject: Re: [MiNT] MiNT on Coldfire References: <40F1519D.40604@inf.tu-dresden.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at inf.tu-dresden.de X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at fishpool.fi Delivered-To: mint@fishpool.com Delivered-To: mint@lists.fishpool.fi X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: nf2@inf.tu-dresden.de Precedence: bulk List-help: List-unsubscribe: List-ID: X-List-ID: X-Milter: milter-regex 1.5jel X-Milter: milter-regex 1.5jel Dear Frank, > You speak against yourself :-) You already complained in private e-mails > about all the hazzle and ugly code we have in bios.c and biosfs.c that > is necessary to use the TOS-BIOS devices. It's slow and inefficient too > as the BIOS device are not interrupt driven and need to be polled. Yes. This is true. The code in bios.c and biosfs.c is really shocking. But the interface that is actually used as 'backend' of biosfs is quite small. (only a dozen system calls and some system variables - as I documented in my article) A replacement of bios.c and biosfs.c could use the same interface during the startup (until native drivers are loaded via a driver module). > E.g. all the reasons for implementing native drivers for the serial > ports you can perfectly apply to the remaining console device too. But then, you needed to include routines for init video (for the different platforms), drawing characters (for the different video modes) etc. into the MiNT kernel just for starting it up. Wouldn't it be nicer to leave all this crap to a boot-loader and care about these things when the rest of the kernel is up and running? > Btw. FreeMiNT already catch keyboard input by hacking into TOS, just to > catch ctr-alt-del (I'm sure you aggree that this is a very good idea) > and for scan code mapping (keyboard language mapping). I have not looked about the ctr-alt-del handling but I noticed the keytbl-thing. But this is no hack at all. You use a well documented system call (Keytbl) to request the keyboard tables, which is just great. > For a new hardware you always need to write new drivers. And things are > much easier if you use and advanced interface to the kernel instead > using a single-tasking designed API from TOS from the year 1985. Yes, of course. I strongly agree with you. MiNT needs to provide decent driver interfaces. My argumentation was just about the bootstrapping. For the actual working-state, I wish to have custom drivers for all devices, managed by the MiNT kernel. For example, once the MiNT kernel booted up, it should take over the serial interface (by an optionally loadable driver), which was previously just used as boot-console and managed by the boot loader. > You do this over which interface? TOS-BIOS? MiNT requests the Iorec buffer for the keyboard from TOS via the Iorec system call and then polls it periodically within _mint_vbl. In my serial interrupt, I just feed this Iorec buffer. That is all - much easier than I thought. Greetings, Norman