Re: [Oslib-devel] Outsourcing the extender?

[Luca A. <luc...@em...>]

Here is my late reply to the mail from Peter:

> > 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.
Well, I think this is already done: people can go to the sf project page
and download the extender independently from oslib. I agree that the
extender is kind of "hidden" in the oslib web page, and I'll try to
restructure the site to fix this problem.

>   Making OSLib source code clearer, leaner, more adaptive to future
> bootloaders.
I have to double-check the code, but I think that there is not much
eXtender-dependent code in oslib... Only the few lines needed to take
advantage of the eXtender if it is used. I'll do some code review in the
next days, and I'll see if there are dependencies that can be
simplified/removed.

> - Having different developers, philosophies, websites, docu, docu writers.
> - Lower entry level for developers to join in.
Currently, I don't have the time to maintain 2 different projects and
web sites. Of course, if someone wants to step in and say "I want to
maintain the eXtender!" he can feel free to create a new sf project (it
is GPLed software, after all).

> - 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).
I think there currently is no problem about this. As said, people can
already download only oslib or only the eXtender. I know for sure of
someone using the eXtender for booting rtems programs. If someone does
not case about the eXtender, he just does not download it, and lives
happyly with GRUB (or another bootloader). I can agree with you that
there is some "advertisement" problem, but I think that it can be solved
without having to create a new project (I think this is what the concept
of package is for).

> - 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.
Very easy: they can just do
cvs -d:pserver:ano...@cv...:/cvsroot/oslib co eXtender
and they can start hacking ;-)

> > 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 don't think it is possible without any hack... When grub loads a
program, DOS is not there, hence there is no place to return to...

> Maybe by providing an command line arg with the return address!?
That is not the problem. The real problem is that oslib can return to
DOS if DOS is there, hence we need some way to know who booted the
program (if it was GRUB, DOS is not there).

> Seems
> simple, and it's similar to what You already do with the DOS mem area.
Dos mem area are an extension to MultiBoot implemented only by the
eXtender. You can use them only if you know that the eXtender was used
to boot the program.

> Maybe by DPMI or VCPI? (Big monsters but universal standard)
DPMI and VCPI are largely unrelated to this problem, I think. They are
standard interface that permit to use PM (or memory above 1MB) from DOS
programs. oslib is not about DOS programs...

> > 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.
No, they are just extensions created by Gerardo and me. A strictly MB
conformant program cannot use them.

> 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".
There are other problems. For example, if you loaded smartdrv (or
similar beasts) some of the memory above 1MB can be "taboo" too. If a
program is loaded from DOS, and if we want to return to DOS, we need to
know which part of the memory is used by DOS (it may depend by the TSRs
that are currently running, and by many other factors).


> > > 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!
Ok, this is very easy to fix: we can just check for 'X' 0, and that's
all. Anyway, mbdemo is just an example...
As said, in the next days I'll review the code and try to fix all these
problems.

> > >>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...
This is already possible. I know for sure that x.exe can boot rtems
programs, and someone is actually using it. Once upon a time, I was also
able to boot l4 halzemut (www.l4ka.org) by using x.exe.

> OSLib should be bootable by Grub, too!
In fact, it is. Just try to compile the examples, and use something like
kernel (fd0)/<example name>.xtn
at the GRUB command line.

> 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.
I still fail to understand why you think that oslib heavily relies on X.
It relies on X only for using features that only X provides (as said, if
GRUB does not load the DOS, it is not possible to return to DOS!).
 
> > 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?
In theory, shark could use the vm86_callBIOS() function, that does not
rely on X. However, it seems that there are big problems: some video
bioses are broken and do not work well in vm86 mode.

Regarding the 32bit interface, I tried it some time ago. On some video
cards it worked well, but I found a video card in which the video BIOS
was using a DPMI call for invoking a RM interrupt!!! In other words, the
32bit interface is not always usable.

In any case, Paolo, I recently fixed some bugs in the vm86 code... I
think you should try to use vm86_callBIOS() and see if there are still
problems. Have a look at the biosdemo example (in particular, look at
the "emulate()" function) to see how to reflect RM interrups in vm86
mode.

				Luca