XML

kent logo

CO527 Anonymous Questions and Answers

This page lists the various questions and answers. To submit a question, use the anonymous questions page. You may find the keyword index and/or top-level index useful for locating past questions and answers.

We have taken the liberty of making some minor typographical corrections to some of the questions as originally put. Although most of the questions here will have been submitted anonymously, this page also serves to answer some questions of general interest to those on the course.


Question 1:

Submission reference: IN738

This is a test question for 2006.

Answer 1:

This is a test answer.


Question 2:

Submission reference: IN738

This is a test question for 2006.

Answer 2:

and this is another test reply :)


Question 3:

Submission reference: IN742

Two questions about the essay on NTFS: 1) Does there need to be a bibliography ie referencing like the co321 essay last year? 2) Do there need to be headings in the essay or just continuous prose (excepting the main heading) like a long answer?

Answer 3:

Answers:

  1. Just put in major references; no great detail.
  2. Just like a long answer will do.


Question 4:

I have been reading about interruption vectors. The way they work, is that each one points to a list of interrupt handlers and when an interrupt is raised it goes through all the interrupt vectors and their sub-lists until it find an interrupt handler which can deal with it. Is that correct ?

Answer 4:

Nearly; but not quite as complicated as you describe it. There is usually just one set of interrupt vectors -- one for each hardware or software interrupt (single list, no sub-lists). On the IBM PC one will find these vectors at the beginning of memory (approximately 256 * 4-bytes of them). The data kept in the vector are memory addresses; when the interrupt is triggered (hardware or software) the processor starts executing the code at the address contained in the relevant vector (probably the OS's FLIH).

Keywords: interrupts

Referrers: Question 6 (2006)


Question 5:

Submission reference: IN744

Essay title says 'You should also include any perceived techincal limitations' Do you mean in relation to NTFS in general or relating to the reliablity charateristics discussed in the essay?

Answer 5:

Technical limitations that affect reliability, or reliability features that affect something else, should cover it!


Question 6:

In reference to Question 4 (2006):

But while I was reading through the "Applied Operating Systems" book, it said that the the computer has more interrupt handlers than it has address elements in the interrupt vector. How do we insert the memory addresses of the interrupt handlers in the interrupt vector, since an interrupt vector doesn't have the required space?

What I would like explained to me is, what is interrupt chaining and how this relates to the interrupt vector table?

Answer 6:

The need for more than one interrupt handler per vector typically arises from hardware limitations, e.g. more devices than interrupt lines for them. PCI devices at least know how to share interrupts nicely (but the CPU still only sees one interrupt).

Interrupt chaining is one (software) solution to this, albeit at a fairly low-level code wise. Essentially, we still have one interrupt handler per actual interrupt -- which may be now be triggered for various devices. With interrupt chaining, the OS sets up a linked-list (or more likely a simple array) containing the addresses of the various handlers for that interrupt. It does this somewhere in its own global data (not in the interrupt vector table itself). Parts of the OS interested in the interrupt insert their own (essentially first-level) handlers in this table. The first-level handler runs through this table calling each in turn until one of them indicates that it was their bit of hardware which triggered the interrupt (most hardware can be examined to see if it just triggered an interrupt).

Another (chaining) approach which can be used, although it is less "clean", is where device-drivers/etc. still put their own address in the interrupt vector table, but keep a note of the previous value in the table. When the handler routine is called, it checks to see if the interrupt was for it -- if so, it is handled there, otherwise the handler that was previously there is called, and so on (chain effect).

The second of these is more obviously "chaining", but it is harder for the OS to manage. For instance, if a device driver breaks down and the OS needs to disable it, it might not be able to tell what entries in the interrupt vector table (and chains thereof) might belong to it, nor how to remove them. If device-drivers and suchlike (things interested in hardware interrupts) register handlers with the OS kernel and not in the interrupt vector table, cleaning up becomes easier. Of course, the trade-off is a bigger kernel (code to manage this stuff) and a slight run-time overhead in interrupt handling (of a few cycles probably).

Keywords: interrupts


Question 7:

Submission reference: IN759

Could you clarify exactly what you want from the second part of the Operating Systems assignment 2? The first 80% was easy but the final 20% doesn't make a great deal of sense to me. I see that it is possible to pull out the value dead beef. This was in the first 80%...Also:

$ cat test.dsk | xxd | grep 'dead beef'
0000000: dead beef 0000 0100 0000 0000 0001 0000  ................

Shows that the 'magic bytes' are indeed present at the start of the disk image, as my java code outputted the same thing. So what now? Am I supposed to just do a String comparison between what I get out using BM.tohexbuf() and the String 'deadbeef' or...? Surely I'm missing something here!

Answer 7:

Doing a string comparison against the the output of "BM.tohexbuf()" would be wrong -- if I changed the code in the BM class to make the output prettier, etc. things would fail. But there is a way of checking it without using the to-hex-buf method (which is mostly for debugging/information). Of course, you can safely use "BM.tohexbuf" on the magic data for the first part of the assessment -- that's informative.

Keywords: coursework

Referrers: Question 9 (2006) , Question 13 (2006) , Question 34 (2006)


Question 8:

Submission reference: IN760

For the java filesystem assessment, I am confused by the part:

------------------------------------------------------------
Inode tables at     : (2-2) (3-3) (4-4) (5-5) (6-6) (7-7) (8-8) (9-9) (10-10) (11-11) (12-12) (13-13) (14-14) (15-15) (16-16) (17-17)
Total inodes	    : 1024
Used inodes	    : 1
Free inodes	    : 1023
Root inode	    : 16777216
------------------------------------------------------------

I don't know where to get the data from with this. I have completed the rest of the assessment, but this part does not follow the patern of the rest of the assessment and looks like a tuple?

I'm just trying to hack it together at the moment, but would like to know what I'm doing! Thanks.

Answer 8:

I presume you're talking about the first row of information there -- the locations of the inode tables. The superblock contains an array giving the starting blocks of the inode tables, and another array containing the lengths (in blocks) of the tables. What you have to do here is read through this array and output the inode tables in the form "(start-block - end-block)".

Keywords: coursework

Referrers: Question 9 (2006) , Question 14 (2006) , Question 15 (2006) , Question 27 (2006) , Question 43 (2006)


Question 9:

I am currently doing assessment 2 and am having some problems. My output currently looks like this:

   virtual disk starting, 256 * 4096-byte blocks
   File-system magic 222173190239
   File-system version: 0.1
   Superblock age 0
   Total blocks 256
   Block bitmap at 1
   (2-1) (3-1) (4-1) (5-1) (6-1) (7-1) (8-1) (9-1) (10-1) (11-1) (12-1) (13-1) (14-1) (15-1) (16-1) (17-1)
   Total inodes 1024
   Used inodes 1
   Free inodes 1023
   Root inode 1

Which is pretty close, there are however two major problems! When I read the lengths of the inode tables all I get is 1s. I am using exactly the same technique as I did to read the block offsets of inode tables, and I'm pretty sure I'm looking at the right bit of the file, so what could be going wrong?! Also my root inode value is incorrect, it is also 1.

Finally, how does the magic value translate to the word "deadbeef"? It is ASCII values? Any help you could provide me with would be great,

Answer 9:

For the inode tables, what you are printing is essentially correct -- and it makes sense. Looking at the output, the inode tables start on consecutive blocks (2,3,4,..), so they could only have at most length 1! Question 8 (2006) has some pointers on this one.

With the root inode number, double check that you're reading it from the right location in the superblock (or for a more directed debugging, see if that value of "1" is present in another field).

The magic value "deadbeef" is a hexadecimal representation of the bytes which make up the magic bytes (1 bytes = 2 hexadecimal digits; 4 magic bytes at the start of the C structure = 8 hexadecimal digits). Question 7 (2006) has some more information on this one.

Keywords: coursework

Referrers: Question 14 (2006)


Question 10:

I've managed to get this far with the assessment:

   virtual disk starting, 256 * 4096-byte blocks
   magic identifier : deadbeef
   major FS version : 0
   minor FS version : 1
   superblock age : 0
   total number of blocks : 256
   block offset of bitmap: 1

I've read the anoymous questions, but I've still got no idea how to do this bit:

   uint32_t itable_offset[SFS_NTABLES];  /* block offsets of inode tables */
   uint32_t itable_length[SFS_NTABLES];  /* lengths (in blocks) of inode tables */

Could you give me any hints or an example?

Answer 10:

These define arrays of values, each of length "SFS_NTABLES" (a named constant with value 16). Another way of writing effectively the same thing would be this:

   uint32_t itable_offset0;             /* block offset of first inode table */
   uint32_t itable_offset1;             /* block offset of second inode table */
   ...
   uint32_t itable_offset15;            /* block offset of sixteenth (SFS_NTABLES) inode table */

Plus similar for the lengths. You can see why using arrays is a sensible choice: otherwise you'd be dealing with the inode table block-offsets/lengths individually, not in a neat collection (the arrays of them).

Keywords: coursework

Referrers: Question 14 (2006) , Question 15 (2006) , Question 23 (2006)


Question 11:

Submission reference: IN765

I too am having trouble with the 2nd bit of the assessment. You said that comparing the string values would be incorrect, does this mean that you should read this number as 4 8-bit ints then compare these to something? If so what would do you compare them too?

Answer 11:

Without complicating it, yes -- do it as 4 8-bit comparisons. The values to compare them to are shown in the sample output; the string "deadbeef" is a 4-byte hex-string, which has the values you need to compare them to.

Keywords: coursework

Referrers: Question 13 (2006) , Question 16 (2006)


Question 12:

Submission reference: IN764

Hi, I am having a bit of trouble with the first part of assessment 2. Specifically the following part:

    Total inodes	: 1024
    Used inodes 	: 1
    Free inodes 	: 1023

I assume to get the total number of inodes, we merely divide 4096 by 4 (with respect to the total number of bytes on the disk, and the size of an inode). However I am stumped as to how to work out if an inode is in use or not. Any hints would be greatly appreciated :)

Answer 12:

The fact that 4096 divided by 4 gives the number of inodes is pure coincidence. Fortunately you do not need to manually work out whether an inode is in use or not, nor how many there are: these numbers are given in the superblock :-).

Checking to see whether the contents of the disk match up with what the superblock thinks should be there is a significantly harder exercise.

Keywords: coursework


Question 13:

Submission reference: IN767

I do not understand the second part of the assessment. I have read Question 7 (2006) and I am still confused. Are we just checking that the hexadecimal equivalent of "deadbeef" is at the begining of the block? Say there was another disk who's magic was "cafebabe"; this would fail if we were checking for "deadbeef" right? Otherwise I'm lost with what exactly you wish me to do.

Answer 13:

The answer to Question 11 (2006) should shed some more light on this. But yes, if the magic at the start of the superblock is not "deadbeef", then the routine should fail.

Keywords: coursework


Question 14:

Submission reference: IN769

Hi, I really do not understand how to output this:

    Inode tables at     :(2-1) (3-1) (4-1) (5-1) (6-1) (7-1) (8-1) (9-1) (10-1) (11-1) (12-1) (13-1) (14-1) (15-1) (16-1) (17-1)

I have read the assesment what to do and read the anonymous questions, and I feel like I am banging my head against a brick wall, please explain what we are supposed to to, as this whole assesment is making about as much sense to me as Japanese.

Answer 14:

The answer to Question 10 (2006) should explain how the data for this is stored - in arrays of length 16. You'll notice that the output I'm asking for (which isn't quite the same as you've got above, see Question 8 (2006) and Question 9 (2006)) consists of 16 pairs of numbers; for each pair, one from the first array and one from the second (which would give you the output above). I.e. the "itable_offset" array contains values (2,3,4,...,17) and the "itable_length" array contains values (1,1,1,...,1). All your code has to do here is read and print them (but printed slightly differently from what you've got above).

Keywords: coursework

Referrers: Question 15 (2006) , Question 39 (2006)


Question 15:

Submission reference: IN771

I also am stuck at the same part of printing the inode table. I've tried various ways of getting it to print out correctly but i feel i don't fully understand whats going on and i'm just hacking away hoping i'll get the correct output.

As there have been a few questions on this part and it seems quite a few people are stuck would it perhaps be possilbe to spend a small part of tomorrows lecture explaining this a bit further?

Answer 15:

Hopefully the answers to Question 14 (2006), Question 10 (2006) and Question 8 (2006) will make this clearer. If it still doesn't make sense, remind me in the lecture and I'll go through it quickly.

Keywords: coursework


Question 16:

Submission reference: IN773

In reference to Question 11 (2006).

I have two byte arrays being check with "Array.equals()", in your answer you say to do 4 comparisions. Should I change mine or am I ok?

Answer 16:

It sounds a bit dubious to me, but run with it if you think it's ok! (alternatively, try changing the magic values in the disk image to something else, and check that it fails).

Keywords: coursework


Question 17:

Submission reference: IN775

I am a little perplexed about quite what you want us to do if the method fails (should it say the magic number failed but try and read out the data any way?), should it print any thing to the screen, or should it just return a non-zero value straight away without going any further.

Answer 17:

If it just returns non-zero and does nothing else, that's fine. But catering for the real-world type situation, it might be nice if it output some error message (on System.err) along the lines of (just a suggestion):

    invalid magic value: expected "deadbeef" but found "00000000"

Keywords: coursework


Question 18:

Submission reference: IN779

Should the assessment close itself if 0 is returned by the method we are editing? Mine does, but still requires me to terminate it manually?

Answer 18:

Yes, it is supposed to hang (sort of). This is mentioned under "compiling and running" in the assessment description. :-)

Keywords: coursework


Question 19:

Submission reference: IN778

Is this code correct for the inode tables?:

   [snip code]

Or am I barking up the wrong tree? I presume length 1 means that only one block contains one cell?

Answer 19:

Yes, that code is along the right lines, and looks mostly correct. However, it's not the nicest code I've seen.. -- there are better (clearer) ways of writing the same thing. Hint: it's nice to be able to look at a 'for()' loop and instantly see how many times it iterates, without requiring mental arithmetic.

As for the length, I'd need to understand what you mean by "cell".. :-). The comment for this says, "lengths (in blocks) of inode tables". Essentially, each inode table spans a number of consecutive blocks on the disk, e.g. "256,257,258", which would have offset 256 and length 3. Because the disk image I've provided is so small (1 meg), it only needs 1 block per table (the number of tables, 16, is fixed). Within each disk block (4096 bytes), you can fit 64 inode (64 bytes each) [64 * 64 = 4096]. But don't worry too much about the inodes for now.

Keywords: coursework

Referrers: Question 21 (2006)


Question 20:

Submission reference: IN783

[tadpole:733]:~/.../java:0$

Can you pls confirm who-what this tadpole is ? Thank you.

Answer 20:

It's part of my command-prompt, e.g. "[machine:cmd]:path:result$ ". The default on most unix machines is either "hostname$ $" or "bash$ " (or if you're really unfortunate, csh, tcsh or just plain old sh), none of which are particularly helpful.. Including the current path is almost necessary (otherwise you'll be typing "pwd" all the time to remind you which directory you're in); including the hostname is useful if you have a lot of machines; including the command-number is useful for history commands (e.g. "!245" would re-execute the command-line with number 245); including the result is useful to see what the last thing you ran returned. These are all UNIX-isms...

As for the name itself, the machines I own are named after pond-life: frog, tadpole, seaplane (wireless box), swordfish (firewall box), shark and goldfish. Just a naming scheme... :-).

Valid CSS!

Valid XHTML 1.0!

Maintained by Fred Barnes, last modified Thu May 8 12:58:00 2014