Does your professor require a "low-level" component in the project? For example, anything that deals with the hardware or the instruction architecture. If so, your professor will not allow you to do the project in Python. The project must be written in C and assembly. And you will invariably be working on modifying the Linux kernel.
However, nowadays Operating System is no longer confined to the low-level aspect. Virtualization, database, parallelization are all built on top of the Operating System. If your professor is "old school" then he/she may not consider those new topics to be part of Operating System. So, you may need to bring some sample ideas to your professor and seek clarification.
Whether to go into low-level, as some have suggested, depends entirely on the professor's educational goals.
- To teach basic concurrent programming constructs, such as events, semaphors and mutex. This can be taught by writing some multi-thread applications. It is arguably too easy as a goal for an OS class. Nevertheless, this is in fact the most "marketable" skill you will get from the class.
- A variation on this theme is to teach how to "use" a particular flavor of OS API.
- To teach how to write applications that make efficient use of the operating system. This may require you to implement some entry-level OS-related algorithms inside a "simulated OS project" (say, in Java or Python, could also be in C++). Each aspect can be studied in separate projects/simulators, without using a full-blown OS.
- For example, to teach how to use the file cache efficiently, it is necessary to make students play with a "toy" file cache using a simple algorithm.
- To teach the hardware aspect of operating system (including the ugliness of it), namely, how it interacts with the instruction set architecture and hardware I/O. This is usually done with "embedded system", with a small prototyping board.
- To teach real-world algorithms used inside modern operating system. This will require lots of paper reading, as well as implementing a non-trivial algorithm inside a real Linux kernel. This level is appropriate for graduate studies.
A good project would include one or more of:
- Input / Output
- Storage
- Deciding what to cache / predicting what to pre-load
- Starting / managing / logging tasks (processes, threads or Python functions), locally or remotely
- Managing resources
- Require each process to give estimates of how much peak memory will be used, and to report a "progress" percentage regularly throughout their execution, which can then be used together to make estimates about resource usage
- Communication
- Concurrency
A project that does not directly interact with hardware, but would still be good project, will be:
- If your project provides an abstraction of the operating system to the apps that will run "inside" your project
- In other words, the "apps" rely solely on your "operating system project" for their I/O, storage, task management, resource, communication needs
- Your project makes good (efficient, measurable) use of the real operating system (Windows, Linux etc)
Then it will be a good Operating Systems project, regardless of the language used.
I would suggest implementing your own memcached, map-reduce or a simple version control system as good project examples.
Edited: removed ranting