Printable View
I'm making the vm for my network simulation idea...
Here is the design I came up with...
Please suggest an alternative for the main memory..(except storing void*s and typecasting as needed :D ) and for the other parts if you know something else will work better and easier to write.
Attachment 10699
What is main memory?
It depends on how sophisticated you want your memory management to be.
At the simplest level, a std::vector<char> might do the trick, if you are seeking to emulate the RAM on a host computer.
If you want to simulate the behaviour of a memory management unit (hardware which provides services that the operating system uses to allocate particular blocks of memory to particular processes/threads/fibres/etc and then prevents a process accessing memory that it is not allowed to access) or simulate the way an operating system manages memory, then you might need some data structure that identifies beginning and end of contiguous blocks allocated to a process, and a list structure to associate a collection of non-contiguous blocks with a process. Obviously, this list of data structures needs to map unambiguously to the pool of available RAM on your virtual host computer.
If you want your virtual machine to emulate an operating system, it might pay to separate out networking services, command interpreters, etc as entities separate from your virtual machine (device drivers if they require privileges like "kernel mode", user processes and other types of processes that don't require privileges) that make use of services provided by the operating system. One of those services may be memory management.
The thing to remember is that the design of a virtual machine is conceptually the design of an operating system, in which programs can run. The fact that your virtual machine may run on an operating system does not change the fact that, in turn, it provides services (like an operating system would) to programs (or simulations of programs) running within it.
I changed it a bit....and wrote the memory with "std::array<void*,100> " as suggested by 'tabstop' ..[I found out that it was really easy, once implemented].
Also, I am trying to make it follow the unix idea that every device is a file. Would post the structure of the code when it is half done..
You want to fancy the idea of emulating a networking system, or a virtual machine system. Because right now it appears to me you are trying to do both. Thought you were only interested in the former.
What is wrong with doing both ?
Emulating a Network System seems a bit hollow if there are no virtual machines. So, I chose to make a simplistic virtual machine and work with it.
>> What is wrong with doing both ?
Usually? A sure way of not finishing what you initially set up to do. And one of the top reasons for so many personal projects to never see an end.
Not trying to guess or jinx your initial idea, mind you; where so many failed because they just couldn't hold their enthusiasm for adding features before the actual project was done (me included), others succeeded doing just that. And you might be one of them. But... it's a risk you should be aware of.
O_o
Mario is right. A lot of newbies, and even some more experienced programmers, fall into a vicious cycle of "feature creep". Don't let it happen to you. Plan your network idea out with a set of features necessary to get the job done and get it far enough along you feel comfortable with it. Once you have your project at that level, you can work your virtual machines in with it. Just because you are being advised against trying to develop both at the same time doesn't mean you can't plan for the expansion later.
*shrug*
You can even see the dead skeletons of projects started here. Don't let it happen to you.
Soma
Ok... I'd keep that in mind.
I'd really be too easy to get lost within irrelevant code..
One exercise that usually helps is for you to always think of your projects in terms of a product serving a customer.
First think of the domain of your project. On this case, "A networking emulation system". A domain is composed of several modules all serving a common purpose. A module is a collection of closely related entities and their actions that can be collectively thought of as a uniquely identifiable part of your system. So, you may get several "Protocol" modules, an "Encryption" module, a "Transport" module, a "Services" module, etc. It's not important to know at this point whether you need these, whether these are 5the correct names, whether you need others, or whether any two these are actually just one module. That comes later. Your exercise is examining the modules in terms of who they serve. The answer must be always unequivocally, your domain and your domain only.
Now let's add the "VM" module and the "main memory module".
The "VM" can be thought of as serving the network if you think of it as your testing platform for the network emulation system (which is how you are thinking of it at this stage). For this reason alone, you could be tempted to add it to your modules. But is this relationship unambiguous? No. Because this is how you might think of the VM module right now. But can you also think about it as the network being the one serving the VM? After all that's the single purpose of any network. So what's wrong? What's wrong (and this is where the problem starts for many of us) is to never think of who a module serves in terms of its purpose, but in terms of the actual workflow of information in your system. Because that's the real purpose of the module. And who it really serves. And the VM module is clearly outside the domain of your system. The whole domain collectively works to serve the VM.
The "main memory" module itself is a no-brainer at this point. It clearly serves the VM and the VM only. In fact, at this stage you can safely say your VM is a distinct domain from your networking system. And along with the "main memory" module, you'll eventually want to define other modules for it...
If you think of a domain as serving a customer, every domain you add will serve another type of customer. And when that happens, you know you have a dividing line right there. No company develops its entire line of products before they start selling them. So you should treat your personal projects the same way. Understandably, your network emulation system won't do much without an IO (and preferably processing) device. But you can have your VM be the most crude of tools at this stage (usually it's the very main() function of your project). If you are fabricating DVD players, a 5 year old TV you got from a yard sale is all you need to test them. When that's done and over with, maybe you will want to develop a TV of your own, maybe not. But you did finish developing your DVD player.
Thank you for that insight.
Wouldn't a 'crude' vm class containing only the functions needed to participate in the network be more suitable?Quote:
But you can have your VM be the most crude of tools at this stage (usually it's the very main() function of your project).
Also, How do I represent numerous machines,routers etc within a single main function ?