|
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! * ***************************************************** |