First, what are functional requirements? A quick survey of the web shows that most of us haven't got a clue. You can find some basic definitions here: http://www.cc.gatech.edu/classes/RWL/Process/Glossary.html (basic definitions of software engineering terms) A functional requirements document is a list of answers to the question "what should this system do?" which doesn't attempt to answer the question "how should it do it?". We should attempt to write our functional requirements in such a way that all the things we expect our VM system to do are spelled out and no loopholes are left for undesirable behavior to slip through. However, we must take care to write it so we end up with something that is actually possible to implement in a finite amount of time. Except for the most superficial of requirements, this is not something that can be done wellwithout having a clue about how VM systems work internally. I.e, if you are interested in contributing, make sure you're willing to do some research. Many or most of the functional requirements should be completely obvious, so you might ask "why is it even necessary to bother writing this down?" The answer is: so that, having listed them, we can determine in a methodical way the degree to which we have met or failed to meet each of them. So that, if we have to, we can reprioritize the requirements when we find that some are more difficult to satisfy than we thought. And finally, so we can say 'this is what we have built, this is what it does'. There is a grey area between 'functional requirements' and 'specifications'. Typically, the functional requirements will consist of generic phrases such as 'heat water quickly' as opposed to a formal specification which would include phrases along the lines of 'heat one liter of water to 100 degrees Celsius in 2 minutes'. Since we are highly unlikely to ever produce a formal specification for our VM, we won't worry much about this distinctions, and will feel free to write requirements in generic or specific terms, as we see fit. Establishing a truly useful list of functional requirements is an iterative process. It is not something you do once at the beginning of a project, then forget about. If you do that, you can be sure your functional requirements will not provide any useful guidance for your system development efforts, as whatever oversights and overly ambitious goals there were in the original requirements will never be corrected, and the document will be gradually recede into irrelevance. So let us now actually begin to form a list of functional requirements. Right now we are at the 'trawling' stage: we will just write down all the requirements we can think of, without attempting to organize them, and without attempting to be too correct. Later we will impose some order. Remember, this is iterative, and since nobody has ever written functional requirements for a Linux VM before, we are already sure that we will write the best one ever. I'll start by throwing out some random requirements without attempting to organize them in any way, for now: Our vm shall: - balance the resource requirements of file IO fairly against in-core memory users - balance memory allocation across zones in such a way that applications make progress as rapidly as possible (define zone) - allocate memory fairly between processes (define fairly) - detect out of memory conditions and takes appropriate action (define out of memory, define appropriate) - give 90% of memory to file cache when the only activity is file io, give 90% of memory to anonymous when the only activity is memory pigs - never deadlock or livelock - kill a process if and only if all free and freeable memory in the system and the system cannot continue make further progress. (define the criteria that constitute 'no progress') Here's one that wli contributed yesterday: - "The latency of the decision of which page to evict shall be bounded above by a constant." I'm going to stop right here, having barely gotten started, because - we hope this is going to be a collaborative effort. Plus, it's high time I considered getting some sleep, see you tomorrow :-) -- Daniel -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ IRC Channel: irc.openprojects.net / #kernelnewbies Web Page: http://www.kernelnewbies.org/
