Menu
▾
▴
oslib-devel
|
From: Peter W. <pet...@ly...> - 2003-12-30 15:33:49
|
Why someone wants OSLib anyway? Because modularizaition is a good thing. So it seems to me, that this should be applied to the extender as well. The extender should become a project independent of OSLIb. And OSLIb should ignore, by which loader it was booted. For example, this means: example/mbdemo.c should show the loader name, but it should not have a check or a variable for eXtender. Kind regards Peter Wiehe |
|
From: Luca A. <luc...@em...> - 2003-12-30 18:16:19
|
Hi Peter, what's the advantage in making the extender an independent project? It already is in a separate cvs module (the eXtender module in the sf cvs), and can be downloaded separately from oslib (oslib and the extender are different packages in the sf project page). > And OSLIb should ignore, by which loader it was booted. Well, let's say that it can ignore the loader by which it was booted. But if it knows that it has been loaded by the eXtender it can take advantages from this fact. For example, the eXtender can load oslib programs from DOS allowing such programs to return to DOS when they finish (very useful for debugging). But in order to safely return to DOS a program must not corrupt the DOS memory. Hence, x.exe passes information about the DOS memory to oslib (this is an extension to the multiboot standard). If a program ignores the loader, it cannot safely return to DOS. 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. > 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. Luca |
|
From: Paolo G. <pao...@ti...> - 2003-12-30 20:20:13
|
Hi Luca, Hi Peter, I see no problem if the extender continues to be coded as a part of OSLib... As Luca already said, they can be thought as independent parts of the same projects... The only reason why I could imagine that splitting the extender is a good reason is to make it more visible to people that do not want to use OSLib but that can anyway get advantages in using the extender... I could suggest probably to make the eXtender page a lot more visible in the web page, actually it is somehow more hidden than the rest... (it is not cited in the Project Overview, but can be found in the subproject)... probably the weight of the web site should be half libraries/half extender... >>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... But if I boot with the extender, I got some nice features like the return to DOS, and 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... Actually I tried to boot with X also another OS, called MarteOS (http://marte.unican.es) , and it worked fine... apart of course for the return to dos... bye PJ |
|
From: Peter W. <pet...@ly...> - 2003-12-30 23:49:46
|
I've replied to Luca only, not to the list :( because I clocked "Reply" [The "Reply To All" was always contrary to my way of thinking :( because I think I get a mail by the listbot and if I reply it will go to the bot. But that's wrong!] But I wanted to reply to the list. Luca, can You forward my reply, please? |
|
From: Peter W. <pet...@ly...> - 2003-12-31 14:47:17
|
Somewhere on the net is a document "Why Replyto-munging is harmful". From
that document I conclude that my way of thinking ("I reply to the list") is
definitely wrong! Because ReplyToAll is an official "protocol". (Probably SF
will enforce that policy and hence change list settings unasked.)
--------------------
When I had all this hassle, wondering if my mail went through anyway (I use
old Netscape 4 Messenger on Linux), I rethought about it. Now I think I'm
going to write a completely new, DPMI based loader. Then I can see if
there's a more powerful solution for the between-modes interface. If it
works as I imagine, it will be both simple and powerful.
Now my reccomendations for OSLib modularization would go into a rather
different direction:
- Move all from ll, libcons and libm to one of the three lib levels.
- Put all xlib functionality in x0.o.
- Either a) give a i386 subdir to all libs or b) use no i386 subdir at all.
(a) would mean a widely used mechanism, good for portability.
(b) would mean: "OSLib can never be ported because the booting mechanisms
are too different on other architectures. So let's write pure i386 code!"
Both soultions seem good to me, but not an inconsitent i386 port as it seems
now to me.
Probably these suggestions sound again much better in my ears than in yours,
knowing the OSLib code better than me.
---------------------------
Having already brought in the design and aim question above, I think the
open question from kl/oq.txt is somehow related to that issue.
The application writers have other methods at hand for doing low level
stuff; and OS designers try to put a control layer between the application
code and the hardware.
On the other hand, besides from OSLib the kernel writer has nearly no free
kernel library that takes the assembler burden off him.
Conclusion: I personally think, that OSLib should be optimized for kernel
developers, not for application developers.
Kind regards
Peter Wiehe
|
|
From: Luca A. <luc...@em...> - 2004-01-02 12:09:09
|
Hi Peter, [...] > Now my reccomendations for OSLib modularization would go into a rather > different direction: > - Move all from ll, libcons and libm to one of the three lib levels. I think this will make things more complex... Someone may want to use ll without libm or libcons, for example. I know for sure that there are projects using ll but using a different libcons. > - Put all xlib functionality in x0.o. x0.o contains the startup code, whereas xlib contains library code. They quite different things. > - Either a) give a i386 subdir to all libs or b) use no i386 subdir at all. > (a) would mean a widely used mechanism, good for portability. > (b) would mean: "OSLib can never be ported because the booting mechanisms > are too different on other architectures. So let's write pure i386 code!" > Both soultions seem good to me, but not an inconsitent i386 port as it seems > now to me. I agree with this idea in principle, but I do not have time for restructuring the directory structure right now... I leave this as an "open task" for the future. Maybe someone can contribute some ppc code, and we will have to rearrange everything for incorporating it ;-) Just dreaming... Luca |
|
From: Luca A. <luc...@em...> - 2004-01-02 11:58:07
|
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 |
|
From: Paolo G. <pao...@ti...> - 2004-01-02 18:24:14
|
>>>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. Ok... I just added bug 174 in the shark bugzilla... soon or later I'll do that... bye PJ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X