altosdev-kernel Mailing List for alternative OS development
Status: Planning
Brought to you by:
dozz
Menu
▾
▴
altosdev-kernel — Kernel development
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
(51) |
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Kernel P. <rzh...@he...> - 2002-04-03 13:30:54
|
Hello, Benjamin. On Wednesday, April 03, 2002 at 5:04:01 AM you wrote: BJ> I'm awake. I'm just kind of waiting for people to give me stuff to do... It would be nice if you proposed something about the drivers. I mean, the questions I asked in the letter you are replying to.. 'Cause I can't decide everything on my own, and there seems to be noone else here except for us.. -- Regards, Kernel Panic mailto:rzh...@he... |
|
From: Benjamin J. <bsj...@mi...> - 2002-04-03 02:05:12
|
I'm awake. I'm just kind of waiting for people to give me stuff to do... Ben Kernel Panic wrote: > Hello, AltOsDev. > > So.. I've been thinking on the drivers model for quite a while, but > haven't come up with anything. How are we going to write drivers?? > > I suggest something like what I've seen in FreeBSD (don't know about > Linux). A driver is declared by some magic macro (like > DRIVER_MODULE([...])) right in the C-source. I have no clue how it > works, but somehow it does =) . (If anyone is interested, I can post a > link to FreeBSD drivers programming guide.) The thing is, that we can > define this macro in such a way, so that it produces an exportable > (global) symbol. So, when we load the driver, we can easily find the > its description. This description (defined by the above-mentioned > DRIVER_MODULE or something) is basically a structure which lists the > name of the driver and pointers to the list of methods it allows > (open, close, ioctl, etc.). This seems rather easy. > > Well, now the hardest part starts. First, how do we organise the info > about drivers inside the kernel (in run-time, I mean)? Say, we have > loaded a PCI bus driver, which has found that there are 5 devices > attached to it. How is this information going to be passed to the > kernel? (It's also clear now the we have to maintain a tree-like > structure for the list of drivers. Or am I wrong?) Then.. suppose we > have a bunch of drivers loaded now, that represent the physical > devices. But we also need virtual devices (I mean, non-physical, or > not strictly phisical), like a console, various partitions on the > harddrive etc. How are they going to be loaded and assigned to the > correct device? I guess we wouldn't like to reinvent a wheel, so if > you are familiar with any existing implementation of this, please tell > me. New ideas are also welcome. > > Also.. I have no clue of how to support non-self-enumerating buses > (like ISA), but I don't think that's a problem right now, as we don't > have any drivers at all. > > Then.. I guess we would have to write a simple statically-linked C > library for the drivers (because drivers are executables, and cannot > import anything from the kernel). It would also provide the means of > IPC transparent to the driver. > > Suggestions are welcome.. > > HEY, GUYS, WAKE UP!!!!!!!! =)) > > -- > Regards, > Kernel Panic mailto:rzh...@he... > > _______________________________________________ > altOSdev-kernel mailing list > alt...@li... > https://lists.sourceforge.net/lists/listinfo/altosdev-kernel |
|
From: Kernel P. <rzh...@he...> - 2002-04-01 22:19:27
|
Hello, AltOsDev. So.. I've been thinking on the drivers model for quite a while, but haven't come up with anything. How are we going to write drivers?? I suggest something like what I've seen in FreeBSD (don't know about Linux). A driver is declared by some magic macro (like DRIVER_MODULE([...])) right in the C-source. I have no clue how it works, but somehow it does =) . (If anyone is interested, I can post a link to FreeBSD drivers programming guide.) The thing is, that we can define this macro in such a way, so that it produces an exportable (global) symbol. So, when we load the driver, we can easily find the its description. This description (defined by the above-mentioned DRIVER_MODULE or something) is basically a structure which lists the name of the driver and pointers to the list of methods it allows (open, close, ioctl, etc.). This seems rather easy. Well, now the hardest part starts. First, how do we organise the info about drivers inside the kernel (in run-time, I mean)? Say, we have loaded a PCI bus driver, which has found that there are 5 devices attached to it. How is this information going to be passed to the kernel? (It's also clear now the we have to maintain a tree-like structure for the list of drivers. Or am I wrong?) Then.. suppose we have a bunch of drivers loaded now, that represent the physical devices. But we also need virtual devices (I mean, non-physical, or not strictly phisical), like a console, various partitions on the harddrive etc. How are they going to be loaded and assigned to the correct device? I guess we wouldn't like to reinvent a wheel, so if you are familiar with any existing implementation of this, please tell me. New ideas are also welcome. Also.. I have no clue of how to support non-self-enumerating buses (like ISA), but I don't think that's a problem right now, as we don't have any drivers at all. Then.. I guess we would have to write a simple statically-linked C library for the drivers (because drivers are executables, and cannot import anything from the kernel). It would also provide the means of IPC transparent to the driver. Suggestions are welcome.. HEY, GUYS, WAKE UP!!!!!!!! =)) -- Regards, Kernel Panic mailto:rzh...@he... |
|
From: Kernel P. <rzh...@he...> - 2002-04-01 21:43:27
|
Hello, AltOsDev. Ok, say, now we can load drivers (though it's not tested yet). New address space and all that stuff.. What drivers should we actually write first? -- Regards, Kernel Panic mailto:rzh...@he... P.S. It seems like I'm alone on this list %( .. |
|
From: Kernel P. <rzh...@he...> - 2002-03-29 19:42:09
|
Hello, AltOsDev. How do you think, is it better to implement the ELF loader (for kernel to load the drivers) as a separate module (like filesystem and harddriver modules) or compile it into the kernel? BTW, are you receiving my posts? -- Regards, Kernel Panic mailto:rzh...@he... |
|
From: Kernel P. <rzh...@he...> - 2002-03-27 21:12:40
|
Hello, AltOsDev. Мать вашу, вы там живые или как? Literal translation from Russian: Your mother.. are you alive there or what? (guess what "your mother" means..) -- Regards, Kernel Panic mailto:rzh...@he... |
|
From: Kernel P. <rzh...@he...> - 2002-03-27 15:39:34
|
Hello! Could Danil Kipnis, Prakash Verma, Detonator and Venkata Narayana, please, send a message to this mailing-list, so that we know that you are still with us (if you are)? We would also welcome a description of your skills (as your profiles at sourceforge.net are set to private) and what part of the OS (well.. rather what part of the kernel) you would like to develop. Looking forward to hear from you :) .. -- Regards, Kernel Panic mailto:rzh...@he... |
|
From: Kernel P. <rzh...@he...> - 2002-03-25 19:10:31
|
Hello, everyone. So.. now that the loader is ready (if bugs are found, they can always be corrected), we can actually start writing the kernel. It can now read files on its partition (but not write), and display some messages. It also has a simple memory allocator. Some considerations about implementing drivers. As we are writing a microkernel, in order to load a driver we should create a new address space for it. A driver should be an executable, but doesn't have to have an entry point. If it does, we may call it, and it would return a pointer to its description (i.e. how it's called, what methods it allows etc.). Otherwise, it should have an exportable symbol (which should be the same for all drivers) that should point to that description. My suggestion is that kernel should only load one driver, a kind of an initializer; it doesn't even have to be a driver in the common meaning, rather a kernel module, which can be unloaded afterwards in order not to waste memory. This way, it should be loaded into the kernel address space. Kernel would then provide it with the list of drivers or something like that. The initializer would then load the drivers and exit. Another option (it seems better and easier) is to have the kernel divided into two parts: the one needed for initialization and actually the kernel. We sould then have to put all the initialization stuff into separate segments and free those when initialization is done. BTW, I think it would be rather easy to port the drivers from other major opensource OS's if we have some basic drivers. I've looked at FreeBSD NIC drivers, and it seemed that we could even use some drivers without modifying the source, provided that we change some include files. And.. streams.. yeah.. ehh.. hmm.. I guess dozzer has something more to say about them =) . Waiting for your suggestions =) .. -- Regards, Kernel Panic mailto:rzh...@he... |
|
From: Kernel P. <rzh...@he...> - 2002-03-22 11:31:50
|
Hello, Ben. On Thursday, March 21, 2002 at 1:27:12 AM you wrote: BJ> I'm willing to do whatever...you gonna put the file online what? I can either post all the sources with executables here (or put somewhere), or just put the disk image somewhere.. Or both :) . Well, it's not some great step forward or something :) , it's just so that we will be able to move on.. BJ> Also, I need the info you sent before about a pc emulator or something BJ> like that? http://bochs.sourceforge.net. It's a PC emulator, which is AFAIK used by most operating systems developers (even for one proprietary OS - the Trumpet's Petros or something). Versions for both Linux and Windows exist (and I guess somewhat older versions even for Mac). You can either download the 1.3 binaries, or the current CVS version. If you have any problems, feel free to ask here or at the Bochs' mailing list. -- Regards, Kernel Panic mailto:rzh...@he... |
|
From: Ben J. <bsj...@mi...> - 2002-03-21 00:27:15
|
I'm willing to do whatever...you gonna put the file online what? Also, I need the info you sent before about a pc emulator or something like that? Thanks, Raz0rSharp |
|
From: Alexey M. <tkt...@cs...> - 2002-03-20 17:03:53
|
> Hello, AltOsDev. Hei, > Loader is ready. When the "kernel" is started, it now reads a file > from the disk and shows its first 10 bytes. Anyone willing to test? Roll'n Roll! [happy] Post it here. -- See you later, d. +358 040 817 8540 |
|
From: Kernel P. <rzh...@he...> - 2002-03-20 16:23:04
|
Hello, AltOsDev. Loader is ready. When the "kernel" is started, it now reads a file from the disk and shows its first 10 bytes. Anyone willing to test? -- Regards, Kernel Panic mailto:rzh...@he... |
|
From: Alexey M. <tkt...@cs...> - 2002-03-16 10:57:40
|
> Hei, Hei, > > Yeah, I know it's kind of too large =) . Should I just CVS it? (Or > > what else is CVS for? ;) ) > Wait with CVS. I approve your message manually. It should appear here in > several hours or minutes... ;) Khe... I examined your source code and I think it is bad for skeleton... Anyway I think we should use GRUB; cuz: 1. It loads kernel and modules in elf or a.out format. 2. It enters protected mode and jumps to kernel entry. 3. It passes to kernel entry information about modules location. 4. It passes many different information (ex. memory map and size). As you can see, GRUB can do a lot of activities we can use. Btw, may be after several hours I change my decision about your source code... -- See you later, d. +358 040 817 8540 |
|
From: Alexey M. <tkt...@cs...> - 2002-03-16 10:41:07
|
Hei, > akalsn> Your mail to 'altOSdev-kernel' with the subject > akalsn> Re[2]: [Altosdev-kernel] Getting started.. > akalsn> Is being held until the list moderator can review it for approval. > akalsn> The reason it is being held: > akalsn> Message body is too big: 172775 bytes but there's a limit of 40 KB > Yeah, I know it's kind of too large =) . Should I just CVS it? (Or > what else is CVS for? ;) ) Wait with CVS. I approve your message manually. It should appear here in several hours or minutes... ;) -- See you later, d. +358 040 817 8540 |
|
From: Kernel P. <rzh...@he...> - 2002-03-15 20:22:12
|
On Friday, March 15, 2002 at 9:19:20 PM you wrote: akalsn> Your mail to 'altOSdev-kernel' with the subject akalsn> Re[2]: [Altosdev-kernel] Getting started.. akalsn> Is being held until the list moderator can review it for approval. akalsn> The reason it is being held: akalsn> Message body is too big: 172775 bytes but there's a limit of 40 KB Yeah, I know it's kind of too large =) . Should I just CVS it? (Or what else is CVS for? ;) ) -- Regards, Kernel Panic mailto:rzh...@he... |
|
From: Kernel P. <rzh...@he...> - 2002-03-15 20:18:46
|
Hello, Alexey. On Friday, March 15, 2002 at 6:20:05 PM you wrote: AM> Why do you need your own loader? Why don't you get ready one; GRUB? It AM> performs all what your loader should do. 'Cause I don't know if GRUB supports shared libraries. If it does, then an extra loader is useless, of course =) . Well, at least I'll be able to reuse the code for an ELF loader.. (Actually, I didn't know of GRUB when I started writing it.) AM> OK. I agree. We need some kind of skeleton to begin work on different AM> parts of kernel and drivers. I understand, that loader in progress, but AM> can you post kernel (or your skeleton) here? Ok, I'm sending it in attachement (it's kind of large file). Hope it'll be able to go through the sourceforge. Most of the include files there are taken from FreeBSD 4.2.. Also one sourcefile.. There are some stupid comments everywhere, just ignore them. If you have any questions, feel free to ask.. -- Regards, Kernel Panic mailto:rzh...@he... |
|
From: Benjamin J. <bsj...@mi...> - 2002-03-15 19:22:56
|
I'm done with my coursework for the next 7 months so I'm ready to start coding... Raz0rsharp Alexey Malev wrote: > > Hi, everyone! > Hi, > > > As I have written, I have a (almost) working loader (with shared > > libraries support) and memory-allocation routines for the kernel (with > Why do you need your own loader? Why don't you get ready one; GRUB? It > performs all what your loader should do. > > > a simple write-only console). As soon as I get it done, we can start > > implementing some basic process management (for loading the drivers, > > as it's going to be a microkernel, so drivers are all separate > > user-mode processes), inter-process communication routines and drivers > > themselves. ..Kind of plans for the nearest future.. > OK. I agree. We need some kind of skeleton to begin work on different > parts of kernel and drivers. I understand, that loader in progress, but > can you post kernel (or your skeleton) here? > > -- > See you later, > d. > > +358 040 817 8540 > > _______________________________________________ > altOSdev-kernel mailing list > alt...@li... > https://lists.sourceforge.net/lists/listinfo/altosdev-kernel |
|
From: Alexey M. <tkt...@cs...> - 2002-03-15 17:20:23
|
> Hi, everyone! Hi, > As I have written, I have a (almost) working loader (with shared > libraries support) and memory-allocation routines for the kernel (with Why do you need your own loader? Why don't you get ready one; GRUB? It performs all what your loader should do. > a simple write-only console). As soon as I get it done, we can start > implementing some basic process management (for loading the drivers, > as it's going to be a microkernel, so drivers are all separate > user-mode processes), inter-process communication routines and drivers > themselves. ..Kind of plans for the nearest future.. OK. I agree. We need some kind of skeleton to begin work on different parts of kernel and drivers. I understand, that loader in progress, but can you post kernel (or your skeleton) here? -- See you later, d. +358 040 817 8540 |
|
From: Kernel P. <rzh...@he...> - 2002-03-15 11:15:37
|
Hi, everyone! So far we have heard me, Raz0rSharp and dozzer here. Could the others, please, post here their ideas about their skills and what part of the OS they want to develop? As I have written, I have a (almost) working loader (with shared libraries support) and memory-allocation routines for the kernel (with a simple write-only console). As soon as I get it done, we can start implementing some basic process management (for loading the drivers, as it's going to be a microkernel, so drivers are all separate user-mode processes), inter-process communication routines and drivers themselves. ..Kind of plans for the nearest future.. -- Regards, Kernel Panic mailto:rzh...@he... P.S. I hope to get the loader working by the end of the week. If I fail, I'll ask someone for assistance. |
|
From: Alexey M. <tkt...@cs...> - 2002-03-13 09:58:05
|
> Hello, Alexey. Hei, > The general idea is to get a simple kernel running now.. (wait, we > have to write it yet..).. I've done a simple kernel with memory > management routines (malloc, free..) and a console, but am now stuck > with djgpp.. LD doesn't link the kernel as it should.. there appear to > be overlapping segments there.. Well, that doesn't matter much, I hope > I'll cope with that.. But I'm waiting for input from others (it's an > ELF file built under DJGPP with GCC 3.0.4 and bintuils 2.11.2; it > builds ok under FreeBSD 4.2).. OK. May be you should post it here. I suppose your kernel in archieve can be attached to your letter and posted here. > You know, developing kernel is not just designing a streams model or > something.. We should actually start writing!! Or it'll get boring > very soon.. Let's begin, if you want. -- See you later, d. +358 040 817 8540 |
|
From: Benjamin J. <bsj...@mi...> - 2002-03-12 22:36:04
|
I agree. I believe we should just get some fundamental ideas down about what the basic implementation details of the kernel will be, and then worry about the user later...we should still keep the user in mind while we do it, but like Kernel Panic says, if we don't get started soon most o= f us will become bored and lose interest. As for me, I just finished an OS class for my school where we had to implement a kernel basically from scratch...since it was just in groups o= f 2 in only 9 weeks, it wasn't anything great but we still had to do proces= s scheduling, memory management (physical and virtual), serial I/O, and system calls like fork, exec, wait, getpid, ... I'm ready to do some hardcore c programming (or whatever language). I have finals this week like I said earlier but those are over on friday. If we need more programmers, I can probably get some but until we know that we definitely do, I will hold off from asking them. See ya, Raz0rSharp Kernel Panic wrote: > Hello, Alexey. > > On Tuesday, March 12, 2002 at 9:46:26 PM you wrote: > > AM> No one answer about GUI organization. I wrote it several days ago. > It's not in the Docs section. Do you mean you posted it here? ..Well, > anyway, GUI will come later.. We first have to develop a kernel.. I've > started many-many weeks ago.. I'm having minor problems, but that > doesn't matter much.. > > I mean, we can spend years on just thinking on it (as it is with > another project I'm involved in now; not years.. but long enough to be > irritating..). > > What about actually writing? Coding stuff? You know.. Compiling.. > Linking.. etc =3D) . > > The general idea is to get a simple kernel running now.. (wait, we > have to write it yet..).. I've done a simple kernel with memory > management routines (malloc, free..) and a console, but am now stuck > with djgpp.. LD doesn't link the kernel as it should.. there appear to > be overlapping segments there.. Well, that doesn't matter much, I hope > I'll cope with that.. But I'm waiting for input from others (it's an > ELF file built under DJGPP with GCC 3.0.4 and bintuils 2.11.2; it > builds ok under FreeBSD 4.2).. > > You know, developing kernel is not just designing a streams model or > something.. We should actually start writing!! Or it'll get boring > very soon.. > > I guess, a general approach will be keeping everything not very > complicated.. Rather, simple.. We have a strategy (an OS with streams > as an IPC method), now we have to develop the tactics. My approach now > is doing everything as fast as possible, because if we concentrate on > a certain part too much, we may get stuck in it and never go further. > That means, eveything should be designed well, but not necessarilly > implemented that well. We should get the system working, and only then > think about some optimizations and stuff.. > > Also, we should know who will write what.. At the moment, we have only > heard a couple of developers here, out of 7 listed at our project's > site. I would like to know what the others' skills are, and what they > can do for the project. We have to somehow distribute our efforts, you > know.. > > I would love to write the OS-dependant stuff, but I can't do the whole > thing on my own.. So.. anyone willing to help me? Well, anyway, kind > of resum=E9s of all the members are welcome.. > > Sorry for taking kind of administrating voice =3D) .. but we may be jus= t > discussing our great model of the OS forever, without writing.. > > -- > Regards, > Kernel Panic mailto:rzh...@he... > > _______________________________________________ > altOSdev-kernel mailing list > alt...@li... > https://lists.sourceforge.net/lists/listinfo/altosdev-kernel |
|
From: Kernel P. <rzh...@he...> - 2002-03-12 21:25:34
|
Hello, Alexey. On Tuesday, March 12, 2002 at 9:46:26 PM you wrote: AM> No one answer about GUI organization. I wrote it several days ago. It's not in the Docs section. Do you mean you posted it here? ..Well, anyway, GUI will come later.. We first have to develop a kernel.. I've started many-many weeks ago.. I'm having minor problems, but that doesn't matter much.. I mean, we can spend years on just thinking on it (as it is with another project I'm involved in now; not years.. but long enough to be irritating..). What about actually writing? Coding stuff? You know.. Compiling.. Linking.. etc =) . The general idea is to get a simple kernel running now.. (wait, we have to write it yet..).. I've done a simple kernel with memory management routines (malloc, free..) and a console, but am now stuck with djgpp.. LD doesn't link the kernel as it should.. there appear to be overlapping segments there.. Well, that doesn't matter much, I hope I'll cope with that.. But I'm waiting for input from others (it's an ELF file built under DJGPP with GCC 3.0.4 and bintuils 2.11.2; it builds ok under FreeBSD 4.2).. You know, developing kernel is not just designing a streams model or something.. We should actually start writing!! Or it'll get boring very soon.. I guess, a general approach will be keeping everything not very complicated.. Rather, simple.. We have a strategy (an OS with streams as an IPC method), now we have to develop the tactics. My approach now is doing everything as fast as possible, because if we concentrate on a certain part too much, we may get stuck in it and never go further. That means, eveything should be designed well, but not necessarilly implemented that well. We should get the system working, and only then think about some optimizations and stuff.. Also, we should know who will write what.. At the moment, we have only heard a couple of developers here, out of 7 listed at our project's site. I would like to know what the others' skills are, and what they can do for the project. We have to somehow distribute our efforts, you know.. I would love to write the OS-dependant stuff, but I can't do the whole thing on my own.. So.. anyone willing to help me? Well, anyway, kind of resumés of all the members are welcome.. Sorry for taking kind of administrating voice =) .. but we may be just discussing our great model of the OS forever, without writing.. -- Regards, Kernel Panic mailto:rzh...@he... |
|
From: Benjamin J. <bsj...@mi...> - 2002-03-12 21:01:26
|
I'm mostly here to code / develop. I don't really have a preference in terms of design. Raz0rsharp Alexey Malev wrote: > > Hi, everyone! > Hei, > > > What about writing something, not just thinking about it?.. > No one answer about GUI organization. I wrote it several days ago. > > -- > See you later, > d. > > +358 040 817 8540 > > _______________________________________________ > altOSdev-kernel mailing list > alt...@li... > https://lists.sourceforge.net/lists/listinfo/altosdev-kernel |
|
From: Alexey M. <tkt...@cs...> - 2002-03-12 20:46:41
|
> Hi, everyone! Hei, > What about writing something, not just thinking about it?.. No one answer about GUI organization. I wrote it several days ago. -- See you later, d. +358 040 817 8540 |
|
From: Kernel P. <rzh...@he...> - 2002-03-12 20:40:14
|
Hi, everyone! What about writing something, not just thinking about it?.. -- Regards, Kernel Panic mailto:rzh...@he... |
