From fnaumann@mail.cs.uni-magdeburg.de Thu Dec 11 23:56:29 2003 Subject: Re: [MiNT] This fight From: Petr Stehlik To: mint@lists.fishpool.fi In-Reply-To: References: <1071149734.743.107.camel@joy.sophics> <1071152636.743.142.camel@joy.sophics> <1071172235.1717.45.camel@joy.home> <1071180006.1728.81.camel@joy.home> Content-Type: text/plain; charset=iso-8859-2 Message-Id: <1071182829.2410.25.camel@joy.home> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 11 Dec 2003 23:47:09 +0100 X-MIME-Autoconverted: from 8bit to quoted-printable by ns1.avonet.cz id XAA14047 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: joy@sophics.cz Precedence: bulk List-help: List-unsubscribe: List-ID: X-List-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by prinz.cs.uni-magdeburg.de id hBBMuR017260 V Čt, 11. 12. 2003 v 23:26, Frank Naumann píše: > > I said 'drivers'. For example the sound driver (which is not yet a > > module). Anyway, forget it for now (it's a discussion about > > TSR-after-MiNT which is another major topic and would increase the > > confusion even more). > > Ah, so instead writing FreeMiNT drivers you want to write TSR (ok, I know > you want to support TOS and MagiC). From my FreeMiNT side it's not in my > scope to add support for TSR drivers. You didn't understand me. Even if I said "forget it" you replied. Now I have to explain it at large to prove that it wasn't about writing TSRs. Actually it was exactly about the opposite - about fixing TSRs to cope with MiNT and about making MiNT bootable on TOSless machines (is it called bootstrap?) For that the subject change is necessary. It has to be a new thread. And the discussion is even less interesting than the NatFeat extension as actually no one here needs bootstrapping MiNT. > But you don't want to abstract and generalize this stuff into the > operating system so that all users can profit of them. How could this be generalized in the kernel? NatFeat covers all possible extensions at once. I thought about the platform generalization at the library level. Maybe I was wrong. > > it could call the NF_NAME to obtain the host name. > > Wrong, sysinfo() use gethostname() to obtain the hostname. I am too lazy to check the MiNTlib source code to see the function chain. My idea was just to return "ARAnyM/iMAC" or "STonX/Oxygen" instead of "Falcon" or "TT". Just a pure visual thingy, nothing important. It was just a (bad) example of how 'useful' NatFeats can be ;-) > > These two calls are used for invoking the NatFeats from a C code. > > Ah, to clarify, you just want a generic way to add anything you like and > get this pushed through the kernel. Sort of, yes. It should have been possible to call NatFeats while keeping it under the kernel supervision and also offering a replacement for the NF cookie pointers. Luckily Lonny has just opened my eyes - the cookie pointer problem was not a real problem as there is no real demand. We can fix it internally as I already said. > you want it aranym specific there is no need to enhance or develop > anything on the FreeMiNT kernel or VDI/AES side. Well. It's hard to comment this for fifteenth time. I will better go sleep. Petr