You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
(7) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(2) |
Feb
(2) |
Mar
(16) |
Apr
(1) |
May
|
Jun
(6) |
Jul
(5) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Gregor M. <Gre...@gm...> - 2001-08-19 15:12:19
|
Hi! After Waeil has done such a great work on the elfrtl we have to ask ourselves how to continue (btw: Wael, how can the kernel get the information where the initial modules lie in memory?). Now we should continue with the resource and process management. The resource management will be extensively used by the device driver modules (Armin: what do you think about the interface I defined in my small kernel you were trying to work with?). With the process and memory management we actually will hit the central point of the project for the first time. I'll leave this topic untouched for now because I'm running out of time again (sic!). But dynamic memory allocation should be possible inside the kernel as well as registering INT handers or other things device drivers will need. So we should concentrate on these features now. I think Wael could make a good start if it. BTW: Armin, I haven't heard from you for some time now. Could you send me some message? Thanks. Bye until next weekend! Gregor -- ***************************************************** * Gregor Mueckl Gre...@gm... * * * * The ChallengeOS project: * * http://challangeos.sourceforge.net * ***************************************************** * Math problems? * * Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x]. * ***************************************************** |
From: wael o. <wae...@ya...> - 2001-08-17 18:00:38
|
Hi there , well the second release of ElfRTL is now been sended to Gregor , Gregor plz, can you post it on the web site , I'll try to post it on my web site if I have time ... elfrtl release I and probably II on : www.geocities.com/wael_araiby take care... __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ |
From: wael o. <wae...@ya...> - 2001-08-13 17:01:51
|
Hi there , well , I got the ELF RTL working finally , however need your opinions to make the best modules interface , so it can runs modules , ie how modules get loaded after linking , plz reply the fastest as you can , we need to make it done to soon to speed up the work a little =) , thx ... __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ |
From: Gregor M. <Gre...@gm...> - 2001-07-08 11:32:14
|
wael oraiby wrote: > > Hello there , well as I said , I have finished the > multiboot this week , well it took me one whole night > so , it's a dirty multiboot code , we can still > optimize it and add some stuff to it , well this is > version 0.1 , maybe the next version will be better , > I m not sure that I made it fully multiboot compliant > plz read it and tell me if I did or not , and thx . > I still can't make the dam wincvs working , so plz add > this file to the challengeos project instead of me > Gregor and thx :) At a first glance it looks quite good. However I can't see whether it can handle ELF format kernels correctly (my mini kernel relies on that, because it is basically linked to an ELF executable). It doesn't have to. We can still define our own a.out type format, meaning a simple memory image that only needs to be copied. I don't know how much space is left in the boot block but the old GazOS boot block was able to load basically the same ELF binary format Multiboot can handle. If you want to, you can try to find your way through these sources and squezze the same functionality into the new boot sector. To tell you the truth I don't think this can be done because 512 bytes is simply too small for this lot of features. > that's all , I'll start the elf relocator the next > week , if you have any suggestion or any question , > feel free to email it to me :) > cya soon :) > In case of questions I'd say it's better to ask and answer them directly on the list. Anyway your working speed is really high, Wael. I would certainly have needed weeks for that code. Armin, Isaac: I'm a little bit confused because there hasn't been a reaction from you yet concerning device drivers. Do you have problems with my mini kernel? Or haven't you done anything (I don't have trouble with that, really :-))? Or do you work silently on and on without anyone knowing about it? Please tell me. I'd really like to know so that we don't happen to lose oversight on this project. So, fellows, I'll return to this list next saturday or sunday. I'll see you then. Bye, Gregor -- ***************************************************** * Gregor Mueckl Gre...@gm... * * * * The ChallengeOS project: * * http://challangeos.sourceforge.net * ***************************************************** * Math problems? * * Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x]. * ***************************************************** |
From: wael o. <wae...@ya...> - 2001-07-05 18:54:11
|
Hello there , well as I said , I have finished the multiboot this week , well it took me one whole night so , it's a dirty multiboot code , we can still optimize it and add some stuff to it , well this is version 0.1 , maybe the next version will be better , I m not sure that I made it fully multiboot compliant plz read it and tell me if I did or not , and thx . I still can't make the dam wincvs working , so plz add this file to the challengeos project instead of me Gregor and thx :) that's all , I'll start the elf relocator the next week , if you have any suggestion or any question , feel free to email it to me :) cya soon :) __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ |
From: Gregor M. <Gre...@gm...> - 2001-07-01 19:49:58
|
Hi! Armin Bauer wrote: > = > mal eine Frage: > = > K=F6nnen wir nicht f=FCr alle die Reiber entwickeln eine art Liste mach= en, dass > nix doppelt gemacht wird??? > = > Ich meld mich schonmal f=FCr Floppy und VGA. quick English translation of this: one question: Couldn't we make up a list of all drivers that we are going to develop, so that nothing is done twice? I apply for floppy and VGA. my answer: Armin: this posting went to the mailing list. But there aren't many people understanding German there. It's no problem that this happened, but please post in English in the future. I'd say we could give priorities to certain drivers. If someone still wants to write another driver, he/she may do it nonetheless. A quick draft of this list (yes, I'm in a hurry ;-)): * floppy driver - Armin * keyboard driver (no joke) * hard disk driver (IDE) * VGA driver - Armin * serial/parallel (even USB?) port support * MS-compatible mouse driver Not in a great hurry, but nice to have soon: * other graphics drivers * network card drivers, mostly NE2000-compatible + TCP/IP stack The rest should follow later. Some notes: = * since the primary interface is a GUI it will have a event system. So the kernel should pass events on keyboard/mouse events to the user space software. These will then be passed into the high level event system by a intermediate layer. * since graphics modes with a low number of colors are crappy things for GUIs 256 colors are minimum (with a 3-3-2 pallete). This means that 320x200x256 is preferred over 640x480x16, which doesn't need to be supported at all. Palettes are then pretty static and need only to be set once. For games some exceptions may be made, but games aren't an issue yet. To apply for a driver please add your name to the list above and resubmit this list to the mailing list. If the particular driver isn't listed yet, add it to the list with your name. That's all for today. I won't be reachable until next sunday (and then only the morning). Until then, contact Wael if the need for leadership arises. Bye, Gregor -- = ***************************************************** * Gregor Mueckl Gre...@gm... * * * * The ChallengeOS project: * * http://challangeos.sourceforge.net * ***************************************************** * Math problems? * * Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x]. * ***************************************************** |
From: Armin B. <ar...@au...> - 2001-07-01 18:25:52
|
mal eine Frage: Können wir nicht für alle die Reiber entwickeln eine art Liste machen, dass nix doppelt gemacht wird??? Ich meld mich schonmal für Floppy und VGA. > > -- > ***************************************************** > * Gregor Mueckl Gre...@gm... * > * * > * The ChallengeOS project: * > * http://challangeos.sourceforge.net * > ***************************************************** > * Math problems? * > * Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x]. * > ***************************************************** |
From: Gregor M. <Gre...@gm...> - 2001-07-01 17:20:37
|
Hi! Wael Araiby has convinced me to start all over again with the ChallengeOS kernel. We have come up with a kernel design that allows device drivers to be separate module files that can be loaded/unloaded at runtime. The ones neccessary for booting will be loaded together with the kernel at boot time by the boot loader. They, too, can be unloaded lateron if needed. Wael is about to do the kernel itself which will contain all sorts of resource management needed (memory, processes, etc.). Because drivers only depend on the interfaces the kernel provides we have agreed to privde a mini kernel which only supports this interface in a very minimalistic fashion. This framework, which is appended, allows to start driver development already while the real kernel is developed. Documentation for it is included. Wael, I'd ask you to import this code into CVS (directory ChallengeOS/kernel-drvdev) and have an eye on it. I didn't find the time to test this code thoroughly enough (big parts are actually untested). So it will see some bug fixes :-(. Please keep the CVS and the driver developers updated on these changes (Armin, Isaac and the others: I hope you can fix these bugs yourself and send the fixes to Wael). Please write a news article for the sf.net project that announces our new attempt (you can, but don't have to include a line about my little kernel). Your kernel code can be imported into CVS as ChallengeOS/kernel if possible (the first release will probably see a version number 0.1.0 or so). Armin, Isaac and everybody else having spare time: You could take over the driver development. I'd like to have floppy disk, hard drive, CD-ROM, graphics, mouse, etc. drivers - everything you can do. Priority is on storage (floppy, hard drive, CD-ROM, ...) of course. But don't write any file systems yet, please. To avoid work being twice please announce the drivers you are going to write here on this mailing list. There are no standard interfaces defined yet of the different driver types. You will have to design them together anyway ;-). Feel free to ask and discuss anything you like on this list. I think that it's the only right place to do it at the moment. You are going to be the real masters here anyway during the next few weeks :-). I will only be able to care for this project on weekends for the next 10 months (in the next few weeks that's even sunday morning only). Wael will take over day-to-day tasks of the project management. Wael: you probably won't meet me on ICQ during this time so please email me if you need to tell me something. Bye, Gregor -- ***************************************************** * Gregor Mueckl Gre...@gm... * * * * The ChallengeOS project: * * http://challangeos.sourceforge.net * ***************************************************** * Math problems? * * Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x]. * ***************************************************** |
From: Gregor M. <Gre...@gm...> - 2001-06-20 16:49:46
|
wael oraiby wrote: > > Hello there , I printed out both the elf format > documentation as well as the elf2core , well it was > crasy , however , I'll do both of the boot sector and > the elf modules loader , I hope ;-) . > well that's all for now :) Hi! Sorry, but I still don't get the reason why you want to write your own boot loader as well. Could you explain that, please? I'd still prefer multiboot over an own solution. Bye, Gregor PS: I don't want to enforce my own oppinion here, but I want to discuss our proposals. -- ***************************************************** * Gregor Mueckl Gre...@gm... * * * * The ChallengeOS project: * * http://challangeos.sourceforge.net * ***************************************************** * Math problems? * * Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x]. * ***************************************************** |
From: wael o. <wae...@ya...> - 2001-06-20 12:48:20
|
Hello there , I printed out both the elf format documentation as well as the elf2core , well it was crasy , however , I'll do both of the boot sector and the elf modules loader , I hope ;-) . well that's all for now :) __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ |
From: Gregor M. <Gre...@gm...> - 2001-06-14 16:41:11
|
Hi! wael oraiby wrote: > > Ok , hello there , well this are the steps that we > should do in order to make > ChallengeOS . > First we should make a multiboot . I've made a minimal implementation of that yesterday. It works, but it could be better. > Second we should make an elf real-time compiler . This > will read all different > parts of the OS and link them together in the High > Memory , as all of modules > are in Low Memory . This is made to prevent the elf > reader from acceding any > drive coz drivers should be in different modules . OK. Different drivers should be in different modules. But you cannot guarantee that modules are loaded into the lower memory. It's nowhere in the MultiBoot specification. The fact that the memory layout when the kernel is started is pretty much undefined gives me serious headaches. There is no guarantee that anything except the kernel itself is at a certain place in memory. The kernel binary itself needs to contain the memory manager because its environment is highly dynamic and the MM is the only component that can handle that. I am considering a very simple management scheme with paging disabled and no segmentation. For user space paging must be enabled, of course. > In order to make the elf reader we should hack around > the elflib functions and > see if we can manage to extract anything in order to > help us building the ELF > realtime compiler . > > -< Kintaro >- Hmm... I don't think this is neccessary. The ELF specification itself should be a much better source of information. I've appended a possibly already outdated copy of it. Bye, Gregor -- ***************************************************** * Gregor Mueckl Gre...@gm... * * * * The ChallengeOS project: * * http://challangeos.sourceforge.net * ***************************************************** * Math problems? * * Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x]. * ***************************************************** |
From: wael o. <wae...@ya...> - 2001-06-14 09:27:01
|
Ok , hello there , well this are the steps that we should do in order to make ChallengeOS . First we should make a multiboot . Second we should make an elf real-time compiler . This will read all different parts of the OS and link them together in the High Memory , as all of modules are in Low Memory . This is made to prevent the elf reader from acceding any drive coz drivers should be in different modules . In order to make the elf reader we should hack around the elflib functions and see if we can manage to extract anything in order to help us building the ELF realtime compiler . -< Kintaro >- __________________________________________________ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ |
From: wael o. <wae...@ya...> - 2001-06-11 20:08:43
|
Well , lo all I m Kintaro I m just another programmer I know C/asm well , know C++/java/pascal/... however I love to code in asm and C for more information and my latest projects try : www.geocities.com/wael_araiby __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ |
From: Gregor M. <Gre...@gm...> - 2001-06-11 17:39:45
|
Hi! I've been asked about the storage organisation a few times now. And the statement that ChallengeOS would not use a hierarchical file system would cause serious confusion. So I'm trying to give a complete explanation now. Files in ChallengeOS (you could also call them "data objects", but file is more convenient) can have one or more attributes the user can create, modifiy and delete. Attributes have values assigned to them which can be restricted to certain types (string, numbers, dates, etc.). Let me explain two examples for this: A letter to a friend could have the following attributes: file type: formatted text document addresse: Toni Bochs date of writing: 2001-05-28 (typed as date) concerning: organisation of holiday stay in Greece An mp3 file could have these attributes: file type: MP3 artist/band: Survivor title: Eye of the tiger genre: rock (typed as enumeration) personal liking: 78 (typed as an integer in the range from 0 to 100) (The attributes with no explicit type given are defined as strings.) The attributes themselves are stored in a list together with their types and constraints. So the user is presented with a given set of attributes he may define for his file. He is free to edit this list to his liking. Browsing for files is done by querying for objects with a certain set of attributes set and having certain attribute values. This query can easily be formulated using a GUI. But how is this structure stored to disk then? That's an easy one if you come from the right direction: You begin with the list of attributes available. This gives you something that very much resembles a table in a relational database. For each attribute another table exists (to which linkes are included in the attribute index) in which the objects are listed (they are linked to, speaking in other terms), that have this attribute defined, together with its value for each of the objects. And that's it - at least for the basic conception. The low level data organisation is a bit more complex than this: management of free and used disk space, ability to fragment tables/files when neccessary, etc. are neccessary to make this a full implementation of a storage organisation system (I don't want to call it file system - it's to different to what is commonly called "FS"). You are free to ask at any time if you did not understand this. I've done my best to make things comprehensive, but I'm still glad if I get some feedback on this. Finally, I have to make an administrative announcement: Beginning with July 2, I have to enter military service for 10 months. Wael Araiby, who has recently joined this project, has agreed to assist me with project administration during this time because I won't be available most of the time. Another note: This project now owns the #challengeos IRC channel on irc.openprojects.net. Feel free to drop in there any time you like. Chances are that you will meet other team members there. I've been experiencing lately that IRC and ICQ are very useful tools for developers (for those interested: my ICQ UIN is 86191474). Bye, Gregor -- ***************************************************** * Gregor Mueckl Gre...@gm... * * http://challangeos.sourceforge.net * * * * Math and alcohol don't mix, so please don't drink * * and derive! * ***************************************************** |
From: Gregor M. <Gre...@gm...> - 2001-04-11 17:29:00
|
Hi! I'm extremely busy, so I'll make it short. The only thing I can report is that Tomi Letho has left us. How are you doing? Were you able to make some progress? Bye for now, Gregor -- ***************************************************** * Gregor Mueckl Gre...@gm... * * http://challangeos.sourceforge.net * * * * Math and alcohol don't mix, so please don't drink * * and derive! * ***************************************************** |
From: Gregor M. <Gre...@gm...> - 2001-03-30 19:36:38
|
Hi! I've just had a closer look at V2OS, but I got rather disappointed. I couldn't imagine how hard to read assembly code can be (although there are comments). But that isn't the real point: I'm missing sources for important things like the modules delivered with the kernel source or the tools needed for installing, which need to be run under DOS. This is the reason why I cannot see how things are working internally. The design may be nice, but the docs (and IMHO the sources) aren't. V2OS looks cool, if you ever get it running (the kernel I compiled myself woudn't want to boot). But I don't know whether we could use it for our project - the chances are bad, actually. One thing startles me: Why does this project get so much feedback? Can anyone tell me? Bye, Gregor -- ***************************************************** * Gregor Mueckl Gre...@gm... * * http://challangeos.sourceforge.net * * * * Math and alcohol don't mix, so please don't drink * * and derive! * ***************************************************** |
From: Gregor M. <Gre...@gm...> - 2001-03-30 17:22:48
|
Fernando Fernandes Neto wrote: > > I'm interested in your ideas. What do you think about to rewrite the V2OS > kernel, with our code, "mixing" it with the actual ChallangeOS kernel ?? > I wanted to try out V2OS, but I found that I was unable to boot it on any of my computers. So I haven't had a closer look at it yet. Perhaps it is time to change it... But I don't like the idea of having too much assembly code in the kernel. Assembly code can be surprisingly fast, but it is neither portable nor easy to read. I'd accept assembly for the low level code, but the higher level code should be in C to make it platform-independent (well, just using C doesn't make such code portable, I know). A good multikernel OS would IMHO provide a slow and portable kernel to make the software run on an as many platforms as possible and specialized kernels for the more common platforms to get the last bit of performance out of them. Well, perhaps I should dream about that on another occation... ;-) Bye, Gregor -- ***************************************************** * Gregor Mueckl Gre...@gm... * * http://challangeos.sourceforge.net * * * * Math and alcohol don't mix, so please don't drink * * and derive! * ***************************************************** |
From: Fernando F. N. <fer...@ho...> - 2001-03-30 00:00:08
|
I'm interested in your ideas. What do you think about to rewrite the V2OS kernel, with our code, "mixing" it with the actual ChallangeOS kernel ?? |
From: Gregor M. <Gre...@gm...> - 2001-03-29 19:48:34
|
Fernando Fernandes Neto wrote: > > I was developing the Commando OS, a multi-kernel os, and I'd like to know if > I could team up with you. My name is Fernando Fernandes Neto and I code in > ASM. > I have some concepts such as the multi kernel concept, that I can introduce > in Challange OS. > For example : > The Challange OS can support it's own kernel and the Unununium kernel. > > What do you think about it ??? > Nice idea, really. Even nicer that you already managed to actually do it once! I like this idea and I think that we should really consider doing it. The problem is that the kernel must actively support the module management of ChallengeOS (this mostly concerns memory management and scheduling). This is the reason why I reverted to writing an own kernel. But if other kernels can do this as well, I don't see any reason why we should not support them. And the Unununium kernel should well be able to include the needed support. And as I feel like experimenting today: I have been pondering about a file system replacement. It is centered around data objects which get a unique ID and description (only the later entered by the user). These objects are referenced by entries in database-like tables containing additional descriptive values on data objects (one per table). These tables are also data objects. These tables may be created, deleted and edited by the user(s). An example would be mp3 files (well, in this case file actually fits). The description for these files could be something like artist and title. And there could be a table containing numbers representing how much you liked that piece on a scale - say - from 0 (worst) to 100 (best). In this table only numbers are allowed as values. And there could be a table listing all artists, where the entries are the artists' names (of cause!) and reference tables containing the names of the songs (in both cases any text is allowed). Both tables refer to the exactly the same data objects (files would only be linked to, that is). A drawback with this is that a big number of tables will cause you loose oversight. And I forgot: Tables are searchable with more flexibility than normal file systems. If I wanted to see the songs that didn't please me much, but not to bad, I'd search the appropriate table for songs which have a rating of (say) 30 to 65. Software modules, the kernel and the GPCDH would be stored in a similar manner, but seperated from the user data tables, because an ordinary user doesn't need access to this. But I don't want to lock it away completely - doing so might only cause trouble. Have a look at Windows and you'll know what happens if user cannot see what happens inside an OS. What do you think about these ideas? I'm pretty shure that there is a flaw somewhere but I just don't know where... ;-) Bye, Gregor -- ***************************************************** * Gregor Mueckl Gre...@gm... * * http://challangeos.sourceforge.net * * * * Math and alcohol don't mix, so please don't drink * * and derive! * ***************************************************** |
From: Fernando F. N. <fer...@ho...> - 2001-03-28 23:09:50
|
I was developing the Commando OS, a multi-kernel os, and I'd like to know if I could team up with you. My name is Fernando Fernandes Neto and I code in ASM. I have some concepts such as the multi kernel concept, that I can introduce in Challange OS. For example : The Challange OS can support it's own kernel and the Unununium kernel. What do you think about it ??? |
From: Mohamad A. F. <fou...@ho...> - 2001-03-27 22:22:13
|
Gregor, I apologize for my lack of participation over the past few months, but my time is unfortunately very limited. Since I have joined SourceForge and offered my assistance, my job responsibilities have expanded greatly. The various ideas you have conceptualized are quite interesting, and I will endeavor to offer you what assistance I can. Let me read through your various e-mails and review the current source code so that I can offer suggestions. Regards, Mohamad ----- Original Message ----- From: "Gregor Mueckl" <Gre...@gm...> To: "ChallengeOS-Developers" <cha...@li...> Sent: Friday, March 16, 2001 3:19 PM Subject: [Challangeos-developers]New team member > Hi! > > There is a new member in our team: Tomi Lehto. Welcome! > > Tomi, I think you could work together with David Spieler on the > ObjectBasic compiler. David is going to present the work he has done up > to now on this mailing list soon. This could be your starting point, I > think. > > And I forgot a set of tasks concerning networking support in the > ChallengeOS kernel. First of all drivers for network devices (ethernet > cards, preferrably NE2000 compatible for the beginning) are needed. I > know this is complicated, but it had been realized before. Who wants to > volunteer for that? > > Last thing for now: I'd like to have some fellow admins on the project > helping me managing the whole thing, as I am beginning to get short on > time again, and mere organisation consumes a lot of time. Who wants to > help me with staying on top of the development? > > Bye, > Gregor > -- > ***************************************************** > * Gregor Mueckl Gre...@gm... * > * http://challangeos.sourceforge.net * > * * > * Math and alcohol don't mix, so please don't drink * > * and derive! * > ***************************************************** > > _______________________________________________ > Challangeos-developers mailing list > Cha...@li... > http://lists.sourceforge.net/lists/listinfo/challangeos-developers > |
From: Gregor M. <Gre...@gm...> - 2001-03-24 10:55:23
|
Hi! I have merged a demo program into the kernel which accesses the ATA/ATAPI drives directly. Not all of it is working, though (playing audio CD doesn't work, for example, and I also had to comment out some lines to get the partition table reader working). I think that it is in the CVS tree, but I have also appended a complete version of the sources I am working on. The driver is in ide/ata.c. It is a lengthy, but not ill-structured source code I got from www.gaztek.org (where I got GazOS from, too). This code shows how the ATA thing works, but no more at the present state. A big drawback with this code is that it was a demo program written for DJGPP/Borland C for DOS. So it doesn't quite fit into a kernel. But I hope it can be of use to you. I also stumbled across a somewhat strange fact: the IDE ports are supposed to be using the IRQs 14 and 15, but the number of the interrupt vectors the handlers get installed to is quite different in kernel/ide/ata.c. I don't know why, because this is an hardware int and according to the docs I have read the PIC (which is responsible for them) only has 16 interrupt chanels ranging from 0 to 15 and thus causing serious confusion with the processor's exeptions, which use the same interrupt vectors. Bye, Gregor PS: There is a limit for the size of posting (including attachments), which currently at about 40kB. With the source archive I'll exceed it (and thus this posting will have to be accepted by the list admin, which is me). I'll move the limit to about 70kB, which I think is still acceptable. And if a posting gets bigger than this, I'll accept it nontheless. -- ***************************************************** * Gregor Mueckl Gre...@gm... * * http://challangeos.sourceforge.net * * * * Math and alcohol don't mix, so please don't drink * * and derive! * ***************************************************** |
From: Gregor M. <Gre...@gm...> - 2001-03-23 19:16:26
|
Hi! I have formally assigned tasks to most of you. My guideline was my older posting, which listed the tasks accurately. Not all of you had tasks assigned. The end dates are quite narrow, but it would be nice if you could stick to it (don't mind if you can't, just try). If you got no task assigned, try to help the others out or grab a task of your own. Any ideas of tasks not mentioned yet? Perhaps I will write some docs about how the current kernel works in detail, which should get updated as the kernel evolves. Bye, Gregor -- ***************************************************** * Gregor Mueckl Gre...@gm... * * http://challangeos.sourceforge.net * * * * Math and alcohol don't mix, so please don't drink * * and derive! * ***************************************************** |
From: Gregor M. <Gre...@gm...> - 2001-03-22 19:47:38
|
Hi! This time I try to lay down my plans for the future development of ChallengeOS (the next few releases of the kernel, I'll plan no further). The dates here are estimates which might be missed hard by weeks, months or even years (hopefully not...), because there should not be any time preasure comming up on that project - it's a hobby, after all. The next release could be in about June or July and will most likely contain: * completed and working memory management * scheduling (i.e. a working multitasking environment) * fixed up version of the binary loader * any drivers if they are stable enough The 0.0.4 release could be by the end of the year and will most likely contain: * reworked syscall mechanism * basic VGA graphics (320x200x256 or so for the beginning) and mouse drivers * IDE disk driver * any other drivers if they are stable enough By the time of the 0.0.4 release the data storage concepts ("file system" perhaps isn't appropriate here) should be layed out properly into a final version. The 0.0.5 release could be this year as well if we start to hurry up now and will most likely contain: * support for dynamic loading of binariy modules * basic version of data storage system (sort of prototype implementation) * system calls for drawing on screen * other drivers and bugfixes This release might be numbered 0.1.0, because the kernel could be considered quite useable at this stage. At this point development will become a more complex process which is then inevitably then involving user space parts like the VM, the dynamic linker, the System layer and so on. Because of that there is currently no way to plan beyond this stage. I've been pondering for a while because the current monolithic kernel has a design which is outdated in the common sense of OS designers (however I can't help thinking about Linux at this point ;-)). I started developing this kernel because I quickly wanted to get a simple base for the actual core parts of ChallengeOS. The problem with most of the available kernels and toolkits were that they didn't fit to this project's extraordinary special requirements. With that kernel to be a quick development it could have been thrown away and be replaces with a more sophisticated solution. But now a lot of time is wasted while trying to get the most basic things up and running. I can't help myself: what should we do? Stick together and pull things through with the existing kernel? Throw things over again and start out from scratch with an entirely new conception for the kernel? Or should we take another kernel (e.g. Linux) and rewrite it to our needs? desperately seeking an answer, Gregor -- ***************************************************** * Gregor Mueckl Gre...@gm... * * http://challangeos.sourceforge.net * * * * Math and alcohol don't mix, so please don't drink * * and derive! * ***************************************************** |
From: Gregor M. <Gre...@gm...> - 2001-03-16 20:17:27
|
Hi! There is a new member in our team: Tomi Lehto. Welcome! Tomi, I think you could work together with David Spieler on the ObjectBasic compiler. David is going to present the work he has done up to now on this mailing list soon. This could be your starting point, I think. And I forgot a set of tasks concerning networking support in the ChallengeOS kernel. First of all drivers for network devices (ethernet cards, preferrably NE2000 compatible for the beginning) are needed. I know this is complicated, but it had been realized before. Who wants to volunteer for that? Last thing for now: I'd like to have some fellow admins on the project helping me managing the whole thing, as I am beginning to get short on time again, and mere organisation consumes a lot of time. Who wants to help me with staying on top of the development? Bye, Gregor -- ***************************************************** * Gregor Mueckl Gre...@gm... * * http://challangeos.sourceforge.net * * * * Math and alcohol don't mix, so please don't drink * * and derive! * ***************************************************** |