Hi all,
I'm just forwarding to the list a message from Peter. Right now, I am a
little bit short in time; I'll answer this e-mail later.
Luca
-----Forwarded Message-----
> From: Peter Wiehe <pet...@ly...>
> To: Luca Abeni <luc...@em...>
> Subject: Re: [Oslib-devel] Outsourcing the extender?
> Date: 31 Dec 2003 00:36:09 +0100
>
> > what's the advantage in making the extender an independent project?
> - Emphasizing the Compliance to the MB spec and the MB "spirit".
> Making it easier to reenter DOS with a NASM kernel that doesn't use OSLib.
> Making OSLib source code clearer, leaner, more adaptive to future
> bootloaders.
> - Having different developers, philosophies, websites, docu, docu writers.
> - Lower entry level for developers to join in.
> - Advantage for projects that use only X or only OSLib!
> Kernel developers without DOS fandom care nothing about X!
> And all the many MB compliant OSs might be keen to tell the
> users/co-developers: "Hey folks, there are 2 ways to boot our kernel:
> Grub from disk and X from DOS [X is at x.sf.net!]" but are interested
> no way in OSLib (especially the OS end users).
> - Some people may want to hack around with the X code because of its
> switch to pmode and back and because of its file loading and progam
> linking.
>
> > For example, the eXtender can load oslib programs from DOS allowing
> > such programs to return to DOS when they finish (very useful for
> > debugging).
> Aren't there a way to do this with grub? I'm asking because I think it would
> fit more to the general idea that was behind the MB spec.
> Maybe by providing an command line arg with the return address!? Seems
> simple, and it's similar to what You already do with the DOS mem area.
> Maybe by DPMI or VCPI? (Big monsters but universal standard)
>
> > I think this can be also done by using the memory maps supported by the
> > multiboot standard (and creating a fake memory map that marks dos memory
> > as ROM), but I still have to have a better look at this solution.
> Memory map might be cool for other reasons for a kernel, but I think what
> You call an extension to MB is quite conforming to the MB spec. And so I
> think it's quite elegant.
> It would only be desirable, that the DOS mem passing can be turn offed by a
> switch on the DOS command line.
> Maybe it would be good to provide a mmcpy function (probably already is), an
> evacuate function (using mmcpy) and a default evacuation that leaves all
> potential BIOS mem intact anyway? Like Linux and most other kernels and
> bootloaders do at startup (and later)! They simply think of lower part of
> "page" 0 and everything from "page" 0xA to 0xF as "taboo".
>
> > > For example, this means: example/mbdemo.c should show the loader name,
> > This is correct, thanks for pointing it out... I'll fix mbdemo.c in the
> > next days.
> Wait, wait. It already shows the name I think. INstead my idea was to remove
> the X variable.
> [If You have too much free time You can fix something diefferent ;) mbdemo.c
> doesn't check for "X"! It checks for any loader name starting with an
> uppercase X! Imagine Santa Claus writing "Xmasboot" and wondering why his
> kernel "chimney" (using OSLib) crashes ;) Most elegant solution would be
> adding some string.h routines (especially strcmp), but I didn't want to
> bugger You with that.]
>
> -------------
> > >>And OSLIb should ignore, by which loader it was booted.
> > Yes and no... I would say the converse... X should be able to boot
> > multiboot images that are not written knowing that they will be booted
> > by the extender...
> OSLib should be bootable by Grub, too! So ignoring is not the only way,
> fallback would be another one. But OSLib heavily relying on X would make it
> closed, a niche-software.
>
> > the X_CallBIOS feature... that for example we use heavily inside the shark
> > kernel (http://shark.sssup.it) to get support for the VESA graphic cards
> > using BIOS calls...
> Why isn't the VESA 2 or 3 32bit interface used for shark? Or X? COmplicated?
>
> Kind regards
> Peter Eiehe
|
