This is a challenging assignment, and I fully expect that in addition to working together as a team, you will need to consult with me. Don't be shy.
SCHED_FIFOscheduling policy. Note that we will be using these same machines in the next lab (with permuted group membership), so it would be desirable not to do anything irreversible to them. If you do manage to foul the machine up, be sure to 'fess up. We've got a special CD-ROM and boot disk which we can use to bring the machine back to a clean state; I'll show you this. So long as you don't make too much trouble for the rest of us, you can feel free to do whatever other experiments you want on these machines.
I will issue each team five diskettes. Two of these diskettes are write protected, have "Orig 2.2.12 boot" written on them, and contain identical copies of the Linux 2.2.12 kernel, suitable for booting any of our three PCs. (You put the floppy in the drive and turn the machine on.) You should leave at least one of these two diskettes write-protected. The other three diskettes are MS-DOS formatted, and contain some uninteresting Windows setup files (from OmniTech), which you can delete. You can put one of these disks in an already booted Linux machine, or equally well in one of the normal lab machines, and mount it using the command
mount /mnt/floppyAt this point, the diskette is available to you as the /mnt/floppy directory. When you are done reading or writing it, before you physically eject the diskette you should give the command
umount /mnt/floppyYou will need to mount MS-DOS floppies like this in order to transport files back and forth between our experimental machines and the normal lab machines. You will need to do this in order to print files, maintain safe backup copies, etc. (Don't treat the hard drive of your experimental machine as a safe place to leave your work.) The experimental machines are not networked.
sched_yieldsystem call doesn't work. Particularly, it has been reported that with
sched_yieldsystem call doesn't seem to do anything at all. The situation with the
SCHED_RRpolicy is presumably the same, since these two policies are handled nearly identically. The situation with
SCHED_OTHERmay well be different (since it is handled quite differently) but that doesn't mean it works correctly either.
SCHED_FIFOpolicy, forks a child process, and uses
sched_yieldto yield to that child. Have the parent and child both print some output out, so you can see which order they run in. You will need to run this test program as root. Hopefully you should be able to confirm the report that yielding isn't working.
SCHED_OTHER) processes, you will need a different testing strategy. Talk with me if you can't come up with one. (Don't get hung up on this; the main part of the lab is still to come.)
sched_yieldis implemented. In particular, write an explanation of why it isn't working correctly. You can focus on the procedures
sys_sched_yield(the system call itself),
scheduler(the actual scheduler, which chooses the next process, hopefully respecting any yielding that is being done), and
prev_goodness(helpers used by
sched.cthat should make
sched_yieldwork. If you find this too challenging to do in general, consider just making it work for
SCHED_RR, or alternatively just for
SCHED_OTHER. Remember, this may not be a simple matter of fixing a localized typo kind of bug in one place. You may need to scrap (and replace) substantial parts of the design of how yielding is done. Discuss your design with me.
sched.cin accordance with your redesign, building a new kernel incorporating your change, booting your new kernel, and testing. You should test both that the system seems to still be more or less working and also see whether you have indeed fixed
sched_yield. To rebuild the kernel, put a blank disk in the floppy drive and, with your current directory being /usr/src/linux, give the command
make bzdiskTo boot your new kernel, leave that disk in the drive and give the command
rebootRemember that kernel hacking is difficult, and debugging especially so. So don't feel bad if your modifications don't work at first. Be sure to consult with me.
Instructor: Max Hailperin