You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(11) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <cyg...@li...> - 2002-01-30 02:09:19
|
I've been out of town for awhile. Got back and somehow lost all my data. Fortunately I've at least got the stuff from Sourceforge.net. I've downloaded the code from CVS, but it is not as current as what I use to have (I had a bunch of experimental stuff that had not been committed). Well, I'm releasing two new files, copies of what was in CVS. I plan to use CVS less often and release files more often from now on. Brad |
From: <cyg...@li...> - 2002-01-23 20:02:41
|
How's it going? No news for a long time, thought I'd drop a line. Ravi |
From: <cyg...@li...> - 2001-12-15 21:32:44
|
I've noted a few problems with the implementation of the service manager and memory layout. 1. The method for calling the service manager at address 2G will not work. The user code will get a protection violation when trying to execute the code. I recommend using a software interrupt to invoke the service manager. This would make the whole implentation a lot simpler, make the memory layout easier, and take care of the next problem listed. 2. The invoke() function, cannot use registers to pass parameters and also have variable arguments. How do would you know how many registers to fill? Unless you had a seperate parameter that told it, which would be a waste of a register. 3. Since Cygnus is a microkernel design. There is no need to worry about relocating the kernel modules. Each modules can be loaded as a seperate thread, and all at the same address. No relocation necessary. Also, each module would only see itself and the kernel in it's memory space. Not any other module. Since the kernel and the modules should have different protection levels, the modules will get protection violation errors if they try to touch the kernel. Which will cause the kernel to shut them down. Essentially, I'm suggesting that modules be implemented the same (as far as memory management is concerned) as user tasks. Brad Proctor __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com |
From: <cyg...@li...> - 2001-12-14 07:09:23
|
To All, Well, I guess I could have tried compiling it before releasing it. Here is another go at it, with a few additional changes. Attached is: cc-0.0.2-rc1.tar.bz2 If anyone has any suggestions, comments, etc. please let me know. If there isn't any objections, we could get this into CVS. By the way, my name is Brad Proctor (unix: fredlie) and I'm currently in the process of getting added to this project as a developer. Brad cyg...@li... wrote: > Attached to this message is a start for the Cygnus C Compiler. The > Lexical Analyzer is mostly complete, but still needs work. Currently it > will read a file and spit out a list of tokens. > > Brad -- Plural Operating System - <http://www.plural-os.org/> Linux Parallel Computing - BogoMIPS: 4857.67 RC5-64: 6,672Mkeys/sec <http://www.plural-os.org/cluster.php> |
From: <cyg...@li...> - 2001-12-13 23:32:36
|
Attached to this message is a start for the Cygnus C Compiler. The Lexical Analyzer is mostly complete, but still needs work. Currently it will read a file and spit out a list of tokens. Brad |
From: <cyg...@li...> - 2001-12-10 18:52:43
|
Read and respond to this message at: http://sourceforge.net/forum/message.php?msg_id=1439660 By: sincery In this paper , we will see a step by step process to write a simple kernel module - demo1. 1. Knows what you want. The first step to write a good module is to know what you want from it. In this demo , let's suppose that we need a module that can allocate dynamic data (something like the heap). To simply the problem , let's assume that the data can only be allocated in blocks , and the module will not be accessed by more than one modules at the same time. 2. Choose an algorithm and data structure. The secord step is to choose an efficient algorithm. A possible solution for the above module is described as follows. We can use a list to represnt all the available data blocks , each has a flag to indicate whether it's free. Then , when someone needs a block , the module can search the list linearly and returned the first free block it finds. ( This is not an efficient algorithm , it's used only as a demo) 3. Decide the interface of this module Now we should design the API of this module. A possible one is: int demo1_getparm(int ptype,int val) - always have for a module void* demo1_getmem(int msize) - return pointer to a block whose size is msize int demo1_freemem(void* pmem) - frees a block int demo1_freeblocks() - return how many free blocks remained 4. Write the specification and header file Then , we should write the module specification and header file. A specification should contain at least the following information: the module name ( in this example , demo1 ) , a brief description of the module , a detailed description on the function of module , the algorithm and main data structures used , the service interface and the service guid. A specification for the demo1 module should have been included here. Forgive my laziness ! Then we write an header file according to the specification. Here is it. // This is the header file for the demo1 module // Naming convention : int+modulename , so this file will be intdemo1.h // The subfunction code for the APIs #define DEMO1_GETMEM 1 #define DEMO1_FREEMEM 2 #define DEMO1_FREEBLOCKS 3 // The guid is defined here // To use the guid , we need to declear a variable like this : GUID guid=DEMO1_GUID; // This way to represent the guid is stupid , but we have to settle for it when // there is no better solution #define DEMO1_GUID {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0} // This is definitely not a real guid ! // Here is the macros to make the invokation of services more natual // They are not used in the c file !! #define demo1_getparam(ptype,val) invoke(DEMO1_ADDR,GEN_GETPARAM,ptype,val) #define demo1_getmem(size) invoke(DEMO1_ADDR,DEMO1_GETMEM,size) #define demo1_freemem(ptr) invoke(DEMO1_ADDR,DEMO1_FREEMEM,ptr) #define demo1_freeblocks() invoke(DEMO1_ADDR,DEMO1_FREEBLOCKS) // Constant for the module #define BLOCKSIZE 512 #define NUMOFBLOCKS 4096 #define ERR_NOERR 0 #define ERR_INVALIDPTR 1 // This is the end of intdemo1.h 5.Implement the module Here is the source code for the file demo1.c #include <u.h> #include <intf/libsvr.h> #include <intf/intsvrmgr.h> #include <intf/intdemo1.h> typedef struct { int used; uchar data[BLOCKSIZE]; } BLOCK; BLOCK blks[NUMOFBLOCKS]; int getparm(int ptype,int value) { // TODO return 0; } void* getmem(int size) { int i; for (i=0;i<NUMOFBLOCKS;i++) if (blks[i].used==0) { blks[i].used=1; return &blks[i].data; } return (void*)0; } int freemem(void* ptr) { int i; for (i=0;i<NUMOFBLOCKS;i++) if (ptr==&blks[i].data) { if (blks[i].used==0) return ERR_INVALIDPTR; blks[i].used=0; return ERR_NOERR; } return ERR_INVALIDPTR; } int freeblocks() { int i,n; n=0; for (i=0;i<NUMOFBLOCKS;i++) if (blks[i].used==0) n++; return n; } extern void ServiceEntryPointAsm(void); int ServiceEntryPoint(int subcode,int parm1,int parm2,int parm3) { switch (subcode) { case GEN_GETPARM: return getparm(parm1,parm2); case DEMO1_GETMEM: return getmem(parm1); case DEMO1_FREEMEM: return freemem((void*)parm1); case DEMO1_FREEBLOCKS: return freeblocks(); } } int Init(char* cmdline) // Initiate the module { int i; GUID giud=DEMO1_GUID; for (i=0;i<NUMOFBLOCKS;i++) blks[i].used=0; return svrmgr_regsvr(&ServiceEntryPointAsm,&guid,VERSION(0,0,0,0)); } 6.What's missing First , the function ServiceEntryPointAsm isn't in the source. It's in fact an assembly routine in the startup code. The function of it is simple - it just push the registers to stack and then calls ServiceEntryPoint. ( The function names used here is just an illustration) Secord , the implemenation of the setparm function is trivial. I may provide an nontrivial version of it in future. Finally , the service code and the initial code is mixed together. In future , we may be able to put them into two different sections and then discards the unnecessary parts when the initation completes. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge and visit: http://sourceforge.net/forum/monitor.php?forum_id=120824 |
From: <cyg...@li...> - 2001-12-10 16:35:24
|
All, It might be a good idea to have a doc like "Examples. some samples to reveal how to write kernel modules." Any ideas ? Why don't you send some preliminary examples/ideas/samples here. Later we will consolidate into a document to be posted into the doc area in at sourceforge.net . Give in to the cygnusos temptation at sourceforge. ;) Also, let me know what part of cygnusos you would like to work on. Ravi |
From: <cyg...@li...> - 2001-12-06 17:24:25
|
Please share your thoughts on this document. https://sourceforge.net/docman/display_doc.php?docid=8089&group_id=35095 |
From: <cyg...@li...> - 2001-12-06 15:07:26
|
All, In case of such emails, just reply to the email. I believe there is no need of visiting the site as indicated here, because the whole team will receive this. Ravi ----- Original Message ----- From: <cyg...@li...> To: <no...@so...> Sent: Thursday, December 06, 2001 7:50 AM Subject: [Cygnusos-open] [cygnusos - Open Discussion] Suggesttion on Cygnus > > Read and respond to this message at: > http://sourceforge.net/forum/message.php?msg_id=1437168 > By: raviss > > Re posting sincery's post here to see if it will automatically mail it to the > list: > > What advanced features from other operating systems impress you most during > the years ? Which of them do you think suitable for Cygnus ? How to incorporate > them into the new system through special design modules ? Please feel free to > express your opinions here. > > ______________________________________________________________________ > You are receiving this email because you elected to monitor this forum. > To stop monitoring this forum, login to SourceForge and visit: > http://sourceforge.net/forum/monitor.php?forum_id=120824 > > _______________________________________________ > Cygnusos-open mailing list > Cyg...@li... > https://lists.sourceforge.net/lists/listinfo/cygnusos-open > |
From: <cyg...@li...> - 2001-12-06 14:50:10
|
Read and respond to this message at: http://sourceforge.net/forum/message.php?msg_id=1437168 By: raviss Re posting sincery's post here to see if it will automatically mail it to the list: What advanced features from other operating systems impress you most during the years ? Which of them do you think suitable for Cygnus ? How to incorporate them into the new system through special design modules ? Please feel free to express your opinions here. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge and visit: http://sourceforge.net/forum/monitor.php?forum_id=120824 |
From: <cyg...@li...> - 2001-12-06 14:28:27
|
From: Ravi S. <rs...@qw...> - 2001-12-06 14:22:43
|
From: Ravi S. <rs...@qw...> - 2001-12-06 14:21:31
|
-------------------------------- Ravi Shamihoke Flowthru Tester 271/IMA System Test Phone 303.896.8293 Pager 303.201.7998 CUID rshamih |