Some suggestions to add on RC2

Ok. Here comes my first post. It should be on the RC2 area, but I just lost myself trying to know where it’s discused so I post it here…

I’ve sketched a way to make self-upgradeable (with commit and rollback) drivers for any OS (and offered it to the now dead Freedows OS). You can then insert a new driver for a video card and enhance the screen appearance inmediatly without almost stopping the drawing and commit the change or rollback inmediatly if it does/doesn’t satisfy you completely. Driver updates could be done via self-booting discs or devices, or come from the internet and install automagically via some (security controlled) system calls and presto! Hot upgrades! wink

I’ve designed too a way to create a self-defragmenting file system that can be plugged onto any existing or future file system. It works on background and keeps files always as closer as possible without delaying the user too much because it works on OS’s idle cycles.

I cannot contribute with code, because my coding skills are high but my “will to start” is very low. So I need someone to hear my ideas, discuss them a bit, start coding and then I’ll catch up and get speed. I can code in almost any language and I can even learn a language while I code, so I can catch up really fast. Assembler code is a no-brainer for myself and I can even design an instruction set for a processor but I just use my skills when I feel really rewarded (and I don’t mean money) for it. I just want my work to be useful and appreciated )

Now I wait for your counter-suggestions or for your “more details, please” type of petitions wink

Man, skills like that, you should give DarkWyrm or Axel a buzz. I bet they could use you.

I like the idea of rollback and hotswap drivers. As far as self-defragmenting filesystem, does a journalled system need to be defragged? I don’t know, I’m no coder :stuck_out_tongue:


cool stuff =)

Axel is working on the kernel right now more than anyone, and hence would know a lot more about the driver interface than anyone.
axeld at pinc-software dot de

Bruno is the one behind our OpenBFS filesystem.
bga at bug-br dot org dot br

This stuff sounds pretty cool though. I would love to hear more about your ideas for the hotswap drivers.

LOL, Freedows !?

Sorry to be offtopic here. Nitroxido, this is nothing against you or you suggestion, but I didn’t expect I would ever hear that name again!

I followed that project from early 1998 on and clearly remember the 14-year-old boy wonder promising the uber-OS to rule them all that was to be finished withing a years time, and later the self-proclaimed industry-veteran Dr. John Rohner who thought Java was all the rage and refocused the project and then disappeared a few months later.

In hindsight that project certainly had an undeniably hysterical aspect to it :wink:

I feel this thread should win “Thread of the week”. :lol:

kurtis wrote:
This stuff sounds pretty cool though. I would love to hear more about your ideas for the hotswap drivers.

Well. Basically it’s a way of making the drivers work. Instead of “drivers” I rather prefer the term “service”. Services are docked to “ports” or “bays”, each having its own “queue” of petitions. You call a service function in a port-agnostic manner through the kernel API or you can call it directly on a given port. When a new driver comes to the system, the kernel allocates a new port for it and creates a new queue for commands. After the initialization phase is over for the driver, the queue gets active and the old port queue gets redirected to the new one. Once the old port queue is empty, the port is marked as “ready to rollback” and the new one as “ready to commit”. When the user commits, the old port is freed and the resources used (queues, memory …) are released. If the user rollsback, the proccess is inverted and the old port is reactivated, while the new one is emptied. This is a spoiler, but I don’t mind my ideas to be copied if they are used for good. It’s just I cannot do them myself so I don’t mind giving them for free.
Of course, this is just a sketch. There’s still more to know to render it useable, but it’s enough to make coders start developping so I can catch up later. Any doubts, questions, requests for more information and so on to my e-mail -> raidesj at terra dot es, putting the word “Haiku:” on the subject so I can automatically clasify it on my Inbox.

Now I retire back to wait for your comments before going on on this thread. I hope we can collaborate closely and make something remarkable and useful for all :slight_smile:

Wow. Now that’s someone who has some serious skillz. Nitroxido, I know that right now we need more kernel hackers. Dare I say it, the app_server’s more likely to get done for R1 than the kernel – there’s still so much work to be done on it. If you want to help, I know they would love to have you work on the kernel if you’d be willing. TTFN.