Menu
▾
▴
trion-kernel-dev — Discusses the kernel development.
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(16) |
Nov
(48) |
Dec
(11) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(9) |
Feb
(97) |
Mar
(61) |
Apr
(28) |
May
(52) |
Jun
(45) |
Jul
(8) |
Aug
(14) |
Sep
(10) |
Oct
(1) |
Nov
|
Dec
(24) |
| 2005 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(8) |
Oct
(9) |
Nov
(5) |
Dec
(7) |
| 2006 |
Jan
(18) |
Feb
(4) |
Mar
|
Apr
(15) |
May
(9) |
Jun
(2) |
Jul
|
Aug
|
Sep
(8) |
Oct
(16) |
Nov
(28) |
Dec
|
|
From: Stephen M. W. <ste...@br...> - 2006-04-05 18:12:41
|
I see Daniel Raffler's been a busy boy. I notice quite a few downloads of the old v0.1 source from SourceForge lately. Is the kernel source stable enough that we could be rolling a v0.2 tarball for download? -- Stephen M. Webb ste...@br... |
|
From: Manuel H. <mho...@ph...> - 2006-02-20 19:45:11
|
Hello all, I have added the code that is necessary to boot up the AP's, but I haven's put it to CVS so far because it is still causing strange errors (the APIC count register reads a useless value). I'll try to debug it in the next days. I have also started a thread on this in the forum. Besides that, I found that AMD SimNow! is a great tool for testing SMP code because it can debug all CPU's separately and not only the BSP as bochs does. It will become even more useful once we target an x86_64 architecture and switch to long mode, but it also works fine in legacy i386 mode. The only disadvantage is that it only runs on x86_64 machines... BTW, bochs seems to have a bug in the APIC code when x86_64 support is enabled... Unfortunately it took me a little longer to return to the project because I gathered some experience in setting up multitasking on SMP machines and ported my own small kernel to x86_64. But now I am pretty optimistic that Trion will also take this important step. Regards, Manuel |
|
From: Stephen M. W. <ste...@br...> - 2006-02-14 13:30:10
|
Daniel (and everyone else) You should make sure the copyright dates in your new (and changed) files is correct. It's no longer 2003. -- Stephen M. Webb ste...@br... |
|
From: Stephen M. W. <ste...@br...> - 2006-02-01 16:15:46
|
On 01/02/06 10:31, Daniel Raffler wrote: > > I've read somewhere that, on uniprocessor machines, it can actually be > usefull > to create one stub for each interrupt to save the time that it would take > to > check the PIC registers in order to find out which interrupt was fired. > With a > multi-processor system this however is of course no problem any more as > the local > APIC is located on the CPU itself so that its registers can be read-out > very fast. Modern Intel CPUs (P III and later) all have their APIC on the same die as the CPU itself. The PIC is actually emulated by the IOAPIC. Anything manufactured this century and built on the Intel ia86 architecture has an IOAPIC, regardless of the number of CPUs. How much to we want to support ancient legacy hardware? -- Stephen M. Webb ste...@br... |
|
From: Daniel R. <cos...@gm...> - 2006-02-01 15:32:07
|
Hello Manuel > Why does each CPU set up an own GDT, IDT and page tables? The entries in > all the GDT's will be identically, so it would be sufficient to use only > one. You have some point here, a single gdt/idt per system should indeed be sufficient.. > But I can't see the advantage in having multiple IDT's (and also multiple > interrupt stubs, calling the same interrupt handler). I've read somewhere that, on uniprocessor machines, it can actually be usefull to create one stub for each interrupt to save the time that it would take to check the PIC registers in order to find out which interrupt was fired. With a multi-processor system this however is of course no problem any more as the local APIC is located on the CPU itself so that its registers can be read-out very fast. I'll thus split CreateIDTEntry() into two procedures (create a new stub, link interrupt with stub) so that either of the two methodes may be used in the future. > Finally, multiple page tables allow all CPU's to see the same virtual > memory layout while having their data at different locations within > physical memory, but I wonder whether this justifies the memory overhead > causes by the page tables. It's actually only a single page-table (4kb) per cpu that is meant to describe the first 4mb of kernel-space. These 4mb would have a different mapping on each node and might therefore be used to store per processor information like, for example, a structure containing pointers to all of the cpu's hal-object: 0xE8000000 - kernel image + image_size - my hal structures + hal_size - cpu 0 hal structures + hal_size - cpu 1 hal structures + hal_size - cpu n hal structures If a systemcall is triggered the cpu may easily get the location of it's hal structures as their address is, due to the different mappings on each cpu, static throughout the whole system. I'm myself however not quite sure it this is really the most convenient way of retrieving this iformation. The two alternatives I could think of are to either store the structure relativ to the cpu's kernel stack-pointer (somewhat hackish) or to use the local APIC's id as some sort of an index (not sure how easy/fast it can be obtained). Any opinions about this ? > The kernel entry is not (yet) thread safe. As soon as an AP boots up and > enters main(), it will clobber some global variables (stack, nodestruct > and > so on) since they exist only once as part of the kernel. As the processor number is passed to the C entrypoint this could probably be avoided quite easily. You're however right that the framework as a whole isn't all that elaborated yet and I'll see if I can have a look at it this week-end. > I'll try to add some mp requirements (locks...) and APIC features (timer, > IPI) during the next days. Excellent.. regards, cosmo86 |
|
From: Stephen M. W. <ste...@br...> - 2006-01-31 13:45:16
|
Okay folks, I went in and reset all users to 'active.' I think this should fix the login problems. I'm sure you'll let me know otherwise. Oh, and feel free to suggest different categories or whatever. I made the current ones up on the fly. -- Stephen M. Webb ste...@br... |
|
From: Manuel H. <mho...@ph...> - 2006-01-31 12:07:55
|
> > See if all you all can get in to the forums now. Let me know if you can't, I > > may have to delete your existing account so you can recreate it, or maybe > The account i created "Victor" looks like will need to be deleted, it keeep saying that its inactive. The same is true for my account "xenos1984" - so please delete it from the forum. |
|
From: Victor A. <vic...@ly...> - 2006-01-31 09:52:28
|
> See if all you all can get in to the forums now. Let me know if you can'= t, I > may have to delete your existing account so you can recreate it, or maybe The account i created "Victor" looks like will need to be deleted, it keeep= saying that its inactive. --=20 _______________________________________________ Search for businesses by name, location, or phone number. -Lycos Yellow Pa= ges http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.as= p?SRC=3Dlycos10 |
|
From: Stephen M. W. <ste...@br...> - 2006-01-30 17:17:43
|
Sorry folks, I'm new to this whole web administration thing. It seems SourceForge has disabled sending mail from the web servers, so email confirmations (the default settings on phpBB2) aren't going to work. I switched off confirmation so you're valid as soon as you're signed up, which is fine by me. See if all you all can get in to the forums now. Let me know if you can't, I may have to delete your existing account so you can recreate it, or maybe tweak the data in the MySQL database, I dunno. I'm sure there's a solution so I can chalk up another "learning experience." -- Stephen M. Webb ste...@br... |
|
From: Victor A. <vic...@ly...> - 2006-01-30 09:09:26
|
It happened to me too. I tried to login, then i received username password = error. I thought i lost my password then i did the "lost password stuff", a= nd it said my account was inactive. I want so much post messages with a funny avatar ;) > ----- Original Message ----- > From: "JaeHyun Roh" <wo...@gm...> > To: tri...@li... > Subject: Re: [Trion-kernel-dev] Forums are now up and running at http://t= rion.sourceforge.net > Date: Mon, 30 Jan 2006 02:13:41 +0900 >=20 >=20 > Also am I :) > cannot login and no activation email comes to me... > but, id is in the member list in the forum. >=20 >=20 > On 1/30/06, Sergey Hakobyan <ser...@vi...> wrote: > > > > Hi Stephen, Manuel, > > > > I encountered the same problem with the forum as well. > > I didn't receive the email. > > > > Thanks and regards, > > Sergey > > > > Manuel Hohmann wrote: > > > Hi Stephen, > > > > > > somehow I can't register in the new forum... I did not receive a > > > confirmation mail, although I'm abolutely sure I've entered my mail > > address > > > correctly. Of course this can also be a problem with my mail account = so > > I'll > > > keep on trying... > > > > > > Has anyone else encountered this problem? > > > > > > Regards, > > > Manuel > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > > files > > > for problems? Stop! Download the new AJAX search engine that makes > > > searching your log files as easy as surfing the web. DOWNLOAD SPLUN= K! > > > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&d= at=3D121642 > > > _______________________________________________ > > > Trion-kernel-dev mailing list > > > Tri...@li... > > > https://lists.sourceforge.net/lists/listinfo/trion-kernel-dev > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > > files > > for problems? Stop! Download the new AJAX search engine that makes > > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat= =3D121642 > > _______________________________________________ > > Trion-kernel-dev mailing list > > Tri...@li... > > https://lists.sourceforge.net/lists/listinfo/trion-kernel-dev > > > --=20 _______________________________________________ Search for businesses by name, location, or phone number. -Lycos Yellow Pa= ges http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.as= p?SRC=3Dlycos10 |
|
From: Manuel H. <mho...@ph...> - 2006-01-30 06:43:28
|
Hi Daniel, after having a close look at the sources I have some questions and suggestions: - Why does each CPU set up an own GDT, IDT and page tables? The entries in all the GDT's will be identically, so it would be sufficient to use only one. The only advantage I can see from multiple GDT's is by putting task state segments for each CPU in a different GDT - but of course they could also be located in the same GDT. But I can't see the advantage in having multiple IDT's (and also multiple interrupt stubs, calling the same interrupt handler). Finally, multiple page tables allow all CPU's to see the same virtual memory layout while having their data at different locations within physical memory, but I wonder whether this justifies the memory overhead causes by the page tables. - The kernel entry is not (yet) thread safe. As soon as an AP boots up and enters main(), it will clobber some global variables (stack, nodestruct and so on) since they exist only once as part of the kernel. I'll try to add some mp requirements (locks...) and APIC features (timer, IPI) during the next days. Regards, Manuel |
|
From: JaeHyun R. <wo...@gm...> - 2006-01-29 17:13:43
|
Also am I :) cannot login and no activation email comes to me... but, id is in the member list in the forum. On 1/30/06, Sergey Hakobyan <ser...@vi...> wrote: > > Hi Stephen, Manuel, > > I encountered the same problem with the forum as well. > I didn't receive the email. > > Thanks and regards, > Sergey > > Manuel Hohmann wrote: > > Hi Stephen, > > > > somehow I can't register in the new forum... I did not receive a > > confirmation mail, although I'm abolutely sure I've entered my mail > address > > correctly. Of course this can also be a problem with my mail account so > I'll > > keep on trying... > > > > Has anyone else encountered this problem? > > > > Regards, > > Manuel > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > > for problems? Stop! Download the new AJAX search engine that makes > > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat= =3D121642 > > _______________________________________________ > > Trion-kernel-dev mailing list > > Tri...@li... > > https://lists.sourceforge.net/lists/listinfo/trion-kernel-dev > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat= =3D121642 > _______________________________________________ > Trion-kernel-dev mailing list > Tri...@li... > https://lists.sourceforge.net/lists/listinfo/trion-kernel-dev > |
|
From: Sergey H. <ser...@vi...> - 2006-01-29 15:32:38
|
Hi Stephen, Manuel, I encountered the same problem with the forum as well. I didn't receive the email. Thanks and regards, Sergey Manuel Hohmann wrote: > Hi Stephen, > > somehow I can't register in the new forum... I did not receive a > confirmation mail, although I'm abolutely sure I've entered my mail address > correctly. Of course this can also be a problem with my mail account so I'll > keep on trying... > > Has anyone else encountered this problem? > > Regards, > Manuel > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Trion-kernel-dev mailing list > Tri...@li... > https://lists.sourceforge.net/lists/listinfo/trion-kernel-dev > |
|
From: Manuel H. <mho...@ph...> - 2006-01-29 10:00:08
|
Hi Stephen, somehow I can't register in the new forum... I did not receive a confirmation mail, although I'm abolutely sure I've entered my mail address correctly. Of course this can also be a problem with my mail account so I'll keep on trying... Has anyone else encountered this problem? Regards, Manuel |
|
From: JaeHyun R. <wo...@gm...> - 2006-01-22 15:51:02
|
How about to setting up a wiki such as moinmoin..? :) I think it's better to share and store the knowledge of Trion OS between th= e developers. Forum is also good to use, and useful when there are some issues to talking about now... but, later it could be difficult to find or manage a data. |
|
From: Stephen M. W. <ste...@br...> - 2006-01-20 14:42:39
|
Hey fellow trionites, I've slapped up a phpbb forum on the web site so we can have a better public record of various discussions. I'm a big fan of mailing lists, but support for public perusal of the record at SF is pretty poor, so I thought I'd just add an alternative means. That and I could do it in my paltry spare time. That, and it looks like progress to be doing something, anything. If anyone has any suggestions for improvements or into which bodily orifice(s) I can insert my ideas, feel free to either reply to this message or post something in the forums. Really, I'm no web designer. If anyone is, speak up. -- Stephen M. Webb ste...@br... |
|
From: Ardian K. <kra...@gm...> - 2006-01-18 16:23:21
|
My skills VisualBasic Delphi Access SQL Linux (Advanced) UNIX (Intermediate) ASM (Advanced) Extensive experience in Graphical design of application interfaces. ____________________________________________________________________ visit my website @ www.ardiani.akrepi.com SIGNATURE: 011000017214415161011011102015316261011100116E1511616900 |
|
From: Daniel R. <cos...@gm...> - 2006-01-14 22:19:24
|
> Manuel wrote: > I think that I can also contribute by adding some mp support since > I already implemented that part with my new OS. With my last update to the cvs I've now begun preparing the framework for the muli-pocessor code: - Entry.asm now contains code that can be relocated to 0x7C00 in order to boot the APs - main() is multi-processor aware and can be used by both BSP and APs - Basic (pysical) heap management allows allocation of memory for the hal-classes of each CPU - virtual memory map is the same for all CPUs: 0xE0000000 - Start of the kernel image + image_size - This CPU's Stack + 4096 bytes - Debugging console + 4096 bytes - Nodestructure of CPU #1 + 4096 bytes - Nodestructure of CPU #2 + 4096 bytes - Nodestructure of CPU #n 0xFFFC0000 - Pagedirectory of this CPU Nodestructure: offset 0x000-0x1FF -> gdt (loaded by entry.asm) offset 0x200-0x3FF -> idt (set-up in main.cpp) offset 0x400 -> Header containing pointers to hal objs offset 0x400++ -> ~3kb free space for the hal objects Apart from the multi-processor initilization routines in main.cpp there are three hal objects that are meant to provide an interface to the functionality of the APIC. Maybe you could have a look at these classes while I'll add some more multi-processor detection and booting code to main(): * irq.hpp The irq class initializes the APIC by mapping all IRQs to a certain range of interrupt numbers (ie: 0x20 - 0x3F). Whenever an IRQ occures the static methode DeliverIRQ() gets called and informs the driver of the device(s) using the just triggered IRQ via an IPC message. * timer.hpp This class allows timers to be set and calls the scheduler on a timer event. I would like to use single-shot only as they allow a much more fine grained scheduling of tasks than periodic timers. As we don't want to lose any time between the deli- very of a timer event and the reinitialization of the internal timer clock, the class supports the NEXT_TIMER to be set in advance. Immediately after CURRENT_TIMER ran off the hardware may thus be reseted. * ipi.hpp To send an ipi the caller first has to aquire the mutex of its own ipi-class aswell as the receiver's mutex. It then copies its message to the arguments fields of the receiving CPU and causes an IPI that will be processed by the receiver's ProcessIPI() methode. Once the receiver has finished it writes a return value to the sender's arguments field which will then in turn release the two mutex. > Stephen M. Webb wrote: > Okay, I reinstalled the old toolchain and build the code no problem. > I will now undertake to convert to autoconf (including automatically > generating a bootable floppy image). Thanks alot, also for fixing the website.. > Jeff Weeks wrote: > By the way, does anyone know if sourceforge supports email notification > ofcheckins? Perforce does this, and I miss it with CVS projects... it's > niceto see what changes are being made to the code, by who, and when, as > they'rebeing made. Sure, just register to the other mailing list: http://sourceforge.net/mail/?group_id=90198 I've, by the way, noticed that the cvs reposity contains a number of empty folders that don't seem to be used any longer: http://cvs.sourceforge.net/viewcvs.py/trion/Desktop/ http://cvs.sourceforge.net/viewcvs.py/trion/include/ http://cvs.sourceforge.net/viewcvs.py/trion/source/ http://cvs.sourceforge.net/viewcvs.py/trion/trion v0.2/cvsroot/ Would anybody here mind me asking the sf-team to remove these ? regards, Daniel |
|
From: Jeff W. <jw...@ne...> - 2006-01-14 19:56:27
|
Excellent! I'm planning on syncing up the recent cvs repo and getting acquited with the code and documentation again. It's been too long. By the way, does anyone know if sourceforge supports email notification of checkins? Perforce does this, and I miss it with CVS projects... it's nice to see what changes are being made to the code, by who, and when, as they're being made. Cheers, Jeff On Tuesday 10 January 2006 19:54, Stephen M. Webb wrote: > On 10/01/06 08:53, Stephen M. Webb wrote: > > I tried building the code out of the box and failed miserably (toolchain > > problems). I'll see what I can do about getting a good toolchain up and > > running then turn my hand to the autoconfigury. > > Okay, I reinstalled the old toolchain and build the code no problem. I > will now undertake to convert to autoconf (including automatically > generating a bootable floppy image). > > -- > Stephen M. Webb > ste...@br... |
|
From: Stephen M. W. <ste...@xa...> - 2006-01-11 00:54:31
|
On 10/01/06 08:53, Stephen M. Webb wrote: > > I tried building the code out of the box and failed miserably (toolchain > problems). I'll see what I can do about getting a good toolchain up and > running then turn my hand to the autoconfigury. Okay, I reinstalled the old toolchain and build the code no problem. I wil= l=20 now undertake to convert to autoconf (including automatically generating a= =20 bootable floppy image). =2D- Stephen M. Webb ste...@br... |
|
From: Stephen M. W. <ste...@br...> - 2006-01-10 14:06:43
|
> I'll see if I can add some functionality that will be needed for mp > systems to the loader in the next few days, after that we can basically > start with the implementation of the hal. In case that you have some time > left you might have a look at one of the following issues in the mean-time: > - add support for autotools > - allow << and >> operators to be used in the console class > - maybe compile an up-to-date toolchain I haven'y been able to build an up-to-date toolchain for some time. Granted, I haven't put a lot of effort into it, since the old toolchain is Good Enough For Now. I tried building the code out of the box and failed miserably (toolchain problems). I'll see what I can do about getting a good toolchain up and running then turn my hand to the autoconfigury. I don't know if I'll be able to find the time in the next two weeks 'cos we're in crunch mode at work with a big release coming up, so we'll see. It's good to see movement again. -- Stephen M. Webb ste...@br... |
|
From: Manuel H. <mho...@ph...> - 2006-01-08 13:22:22
|
Hi Daniel, it's great to hear that Trion development continues! I'll have a look at the code in the next days. The concept looks quite clear to me. I think that I can also contribute by adding some mp support since I already implemented that part with my new OS. Regards, Manuel |
|
From: Daniel R. <cos...@gm...> - 2006-01-07 22:25:08
|
Hello, I know that I've actually promised you a full blown UML documentation but after I had a closer look at umbrello I soon abandoned the idea. While UML certainly is a great tool to describe the architecture of complex programs, using it to document the design of a nucleus seems like overkill to me as the resulting diagrams are - due to the lack of higher-level interdependencies - hardly any more expressive that plain header files. I therefore rather spent the last week building a new code branch which I've now uploaded to the cvs (module: "trion v0.2") as a reference for future releases. The code is of course still very crude but as a basic console and simple paging methodes are already supported I hope that it will be sufficient as a base. Here's a more detailed list of what the kernel can do at the moment: [loader/entry.asm] sets up a basic idt/gdt and enables paging, kernel gets mapped to 3.5GB+ [loader/main.cpp] this is the C++ entrypoint, maps x86 console in and writes a message to the screen [loader/console.cpp] prints messages needed for debugging [hal/mmu.cpp] class provides methodes to map/unmap pages The four folders are defined as follows: [hal] contains classes that allow access to the hardware and handle events (irqs, syscall, exception, ipi). All hal-objects are created dynamically per cpu, that is each cpu has its own instance of the hal. [loader] asm/c++ entrypoint and helper classes like the console that are needed for debugging [multiplexion] multiplexion classes manage the application's access-rights for the kernel resources [object] basic in-kernel memory management that allows the allocation of pages for kernel objects I'll see if I can add some functionality that will be needed for mp systems to the loader in the next few days, after that we can basically start with the implementation of the hal. In case that you have some time left you might have a look at one of the following issues in the mean-time: - add support for autotools - allow << and >> operators to be used in the console class - maybe compile an up-to-date toolchain In case that you want to write one of the hal classes (eg ports) please contact me first, I'll then give you some more information about what the class is meant to be used and what functionality is needed. cheers, cosmo86 |
|
From: Daniel R. <cos...@gm...> - 2005-12-16 14:59:19
|
>> But of course we could also port an X11 server to a native Trion API - >> just >> like any other server / resource manager in the nanokernel design. You have to be carefull here as there are actually two APIs: * The resource managers, which are built upon nucleus and drivers, export a "system-interface" that allows the allocation/delocation of resources according to a user defined (->config file) system-wide policy. The interface is very low-level as the managers only define a minimum policy that is needed to allow the multiplexion of systems that are based on more complex concepts (eg: disk -> filesystem: "file" | mouse, kbd, vga -> terminal: "focus"). * The actual "application programming interface", that is the interface that the programmer will see, is implemented in a libary which is linked to the application like a huge wrapper class. This layer is meant to provide the programmer with an easy to use interface while implementing a specific policy and communicating with the resource managers in the background. Note that the usage of libraries is, due to the low-level character of the system-interface, absolutly mandatory for everybody but some assembler masochists in an nanokernel system. The first image on this site (http://pdos.csail.mit.edu/exo.html) demonstrates how multiple APIs are meant to be used in a nanokernel system. "Exokernel" stands in our system for nucleus, drivers and resource mangers and the colored fields represent applications that might run on various subsystem APIs (the lower part of the fields: "ExOS", "PhOS", "OO OS" -> Trion, POSIX, Win32). The native API of the exokernel by Engler and Kaashoek is ExOS but, as you can see on the picture, it has no advantage whatsoever over the other APIs ("PhOS", "OO OS") regarding its position in the system. Compatibility layers as used in traditional systems (Wine: win32 -> linux -> hardware) that always mean a reduction in performace due to an extra layer of abstraction and policy, are no longer neccessary as all APIs run directly on top of the low-level mechnisms provided by the resource managers. > I disagree. I just spent a good chunk of the last year trying to > retrofit multithreading into a server that was not designed for it. > You are really better off designing from the beginning with > multithreading (in this case, multiprocessing, but most of the > design decisions are the same) from the beginning. The future is > multiprocessor systems. A new OS that can take advantage of > multiprocessor systems has an edge. Multiprocessors definitly are the future and thus I too want Trion to support such systems as soon as possible. Nevertheless I was a bit afraid that starting off with a full blown mp release might be a bit too hard a challange as we would not only have to make sure that the code is thread-safe but also deal with much more complicated hardware devices (PIC & PIT vs APIC). My idea therefore was to wait with the multiprocessor support until we at least have a basic system up but, as you're probably right that changing the code later on would mean even more work, I certainly won't insist on this.. > N.B. I have a lab full of various cpus, including dual-core 64-bit > Opterons, that I could maybe take advantage of for testing purposes. yummy.. That should really help alot when writing a x86-64 or multiprocessor release of Trion - especially as Bochs still seems to have some problems with these technologies. regards, cosmo86 |
|
From: Stephen M. W. <ste...@br...> - 2005-12-16 02:19:41
|
-----Original Message----- From: Manuel Hohmann I agree, although I think we could include SMP support from the very beginning. But we can also add this later. -----End Original Message----- I disagree. I just spent a good chunk of the last year trying to retrofit multithreading into a server that was not designed for it. You are really better off designing from the beginning with multithreading (in this case, multiprocessing, but most of the design decisions are the same) from the beginning. The future is multiprocessor systems. A new OS that can take advantage of multiprocessor systems has an edge. N.B. I have a lab full of various cpus, including dual-core 64-bit Opterons, that I could maybe take advantage of for testing purposes. -- Stephen M. Webb |
31 messages has been excluded from this view by a project administrator.
