|
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.
Submission reference: IN937
Do we submit to \\raptor\files\proj\co527\assess3\login\ or \\raptor\files\proj\co527\assess4\login\ because the first seems to have my last assessment in it... or did I submit that one wrong? :(
It should be the assess4 directory, there was a mistake on the assessment 4 description; fixed it now. (you shouldn't be able to write into the assesss3 directory, though you can still see its contents).
Keywords: coursework
Submission reference: IN943
In the description of the assessment you have said that the inode number is represented as:
((itable << 24) | (ioffset & 0x00ffffff))
I understand what "<<" means. Can you explain to me what "&" means?
The single-ampersand is bitwise-and in Java (and various other languages). You can think of it as a 'bit' version of the normal boolean 'and' (i.e. 1 & 1 = 1, 1 & 0 = 0). Applied to whole words and suchlike (in binary and hexadecimal):
001010011100 & 0x29c
010011001111 0x4cf
------------ -----
000010001100 0x08c
The way the assessment uses it is with all 1-bits after a certain point (0x00ffffff), so it acts to clear the upper 8 bits (and preserve the lower 24 bits).
Keywords: coursework
Referrers: Question 104 (2006)
Submission reference: IN947
For the output of the assessment I didn't understand what the numbers represent. For example:
0xc00003a 11147 1000 1000 rs422code.c
0xc00003a is the inode number Can you explain me what the other parts are? Thanks.
Rather than me explaining them, look at the bit of code in SmallFS.java that prints them on the screen, and see what it's printing. :-)
Keywords: coursework
Submission reference: IN933
In response to question 99, this is what I am doing to get the numbers:
[snip code]
This seems to produce 1 and 0. Is there anything else I have to do, like look at some table or other? Sorry if I'm being stupid here.
Just extracting the inode table number is not quite the whole story — see Question 100 (2006). On programming, you have something of this form:
(x << N) >>> N
which is a rather complicated way of setting the top N bits to zero (provided N >= 1). See Question 102 (2006).
For those who haven't encountered the '>>>' operator before, it's an unsigned right-shift (or logical right-shift) — new high-order bits are set to zero. The regular right shift operator, '>>' preserves the sign-bit (also called arithmetic right-shift) — new high-order bits are set to the sign-bit (zero or one).
Keywords: coursework
Submission reference: IN934
What outputs should we be getting for the other disks? Especially the one thats bad?
In reference to Question 94 (2006). The 'badtest.dsk' image should produce this output:
0x1000000 512 0 0 . 0x1000000 512 0 0 .. 0xc00003a 11147 1000 1000 rs422code.c 0xc000011 15684 1000 1000 16dpy.c 0xa000017 15478 1000 1000 ATmegaBOOT.c SmallFS::fsDumpRoot(): failed to read directory entry inode 5 of 8 0x200001f 169589 1000 1000 gen10.c 0x700001e 239274 1000 1000 sched.c
And the 'bigger.dsk' image should produce this:
0x1000000 1856 0 0 . 0x1000000 1856 0 0 .. 0xc000247 11147 1000 1000 rs422code.c 0xc0000b1 15684 1000 1000 16dpy.c 0xa0000e9 15478 1000 1000 ATmegaBOOT.c 0x100007b 154575 1000 1000 gen11.c 0xe0000fe 169589 1000 1000 gen10.c 0x100002c 239274 1000 1000 sched.c 0x64 24544 1000 1000 12chardisp.asm 0x22d 22279 1000 1000 4chardisp.asm 0x20000fa 22354 1000 1000 8chardisp.asm 0x6000248 160 1000 1000 atest1.asm 0xa00003f 22495 1000 1000 lightwalk.asm 0x80001e4 4477 1000 1000 macrov_remove.asm 0x400027b 5640 1000 1000 mvrm2.asm 0x9000231 5614 1000 1000 mvrm2b.asm 0xb000192 5441 1000 1000 mvrm2-old.asm 0xf0001dc 27221 1000 1000 parprog.asm 0xe000031 32335 1000 1000 parprog-current.asm 0x30001c0 20379 1000 1000 ppboard.asm 0x1000195 20390 1000 1000 remote_ir.asm 0xf0000b3 18420 1000 1000 remote_ir_temp.asm 0x400015d 1322 1000 1000 remote_ir_timer.asm 0xb000048 5320 1000 1000 rs422code.asm 0x900025c 9536 1000 1000 sboard.asm 0xdc 20846 1000 1000 tempboard.asm 0xd000095 7607 1000 1000 uarttest1.asm 0xb000074 19716 1000 1000 uarttest2.asm 0x200018d 1091 1000 1000 wibble.asm
Keywords: coursework
Referrers: Question 111 (2006) , Question 132 (2006) , Question 136 (2006)
Submission reference: IN932
I am having trouble understanding the current assignment. I have looked through our lecture slides and can't seem to find anything about this. Which lecture did we learn about this? Are there any books which will help help me to understand this assignment?
0xttoooooo ((itable << 24) | (ioffset & 0x00ffffff))
This confuses me and i know you have had lots of questions about it but your answers haven't helped me. Is it supposed to be something along the lines of:
0xttoooooo = ((itable << 24) | (ioffset & 0x00ffffff))
But even then the 0xttoooooo confuses me... is this the inode number which is given as a parameter to the method? Do we query the superblock for the itable like in the first assignment?
The contents of the assignment (from an operating-systems perspective) have not been covered in lectures yet, but as I've stated on the assessment descriptions this isn't necessary. As programming goes, you should have learnt enough in CO520 (further object-oriented programming), in conjunction with programming exercises in other modules, to tackle this successfully. Any extra information that you might need as regards programming (e.g. the precise nature of bitwise operations) should be readily available in most programming textbooks (which you should ideally have on your bookshelf!), and I expect, in many operating-systems textbooks. Failing that, there's the library (with lots of good books), and a whole wealth of on-line material.
The string "0xttoooooo" is a representation/template of the inode number. You've already seen the that the root inode has a value of 16777216, or 0x01000000 in hexadecimal. Applying that value to the template gives 'tt' as 0x01 (the table number) and 'oooooo' as 0x000000 (the inode offset within the table).
As the method specifies that it should return a block number for the inode (and a byte offset within the block), and given that these are located in the superblock data, yes, you will need to query the superblock.
Keywords: coursework
Referrers: Question 109 (2006) , Question 110 (2006) , Question 114 (2006)
Submission reference: IN956
The crude visualisation doesnt work for me:
OS: Mac 10.4.8 Java: "1.5.0_07" $ java Harness --vis test.dsk 2007-02-27 13:21:25.788 java[13953] CFLog (0): CFMessagePort: bootstrap_register(): failed 1103 (0x44f), port = 0x10c03, name = 'java.ServiceProvider' See /usr/include/servers/bootstrap_defs.h for the error codes. 2007-02-27 13:21:25.792 java[13953] CFLog (99): CFMessagePortCreateLocal(): failed to name Mach port (java.ServiceProvider) Exception in thread "main" java.lang.RuntimeException: VDDev::VDDev(): no such file [--vis] at VDDev.(VDDev.java:288) at Harness.main(Harness.java:53)
Yeah, something clearly blew up there. Unfortunately that error is about as meaningful to me as I expect it is to you. Do any graphical Java programs work (from the command line)? — this one uses Swing (JFrame and some JLabel's). You could have a look in the header file for the error definition as it suggests, might indicate what the problem is.
Keywords: coursework
Referrers: Question 108 (2006)
Submission reference: IN961
with regards to Question 107 (2006), there is no problems with the code, just the way you are running it. This is the line you want to look at:
Exception in thread "main" java.lang.RuntimeException: VDDev::VDDev(): no such file [--vis]
You need to run it this way round on the command line:
$ java Harness test.dsk --vis
Then all is good :)
Yep, well spotted :-), although looking at the code I wrote in Harness.java, it really shouldn't matter that the '--vis' argument comes first.. [tries it, it fails in a similar way, finds bug]. There's a line in 'Harness' which says:
vdisk = new VDDev (args[0], svis);
whereas it really ought to say:
vdisk = new VDDev (thefile, svis);
Keywords: coursework
Submission reference: IN951
In reference to Question 106 (2006); so from the 0xttoooooo we need to find a way to retrieve the ioffset. The itable is known since it is the values of the inode_table offset written in binary.
So, the only way in which we can retrieve the ioffset is by using binary operators? Also, do we have to write by ourselves a method which converts digits to hexadecimal or binary?
Your question sounds a bit confused.. :-(. I've shown you the structure of the inode number, and how the table and offset are encoded within it. The first step in a solution would be to extract these into some local variables (essentially doing the reverse of the code which put them together). You'll certainly need to use bitwise operators to achieve this; see other questions for pointers on finding out more about these.
The term "binary operator" refers to an operator which takes two operands (as opposed to a "monadic operator" which takes only one operand). Normal arithmetic plus, subtract, times, divide and modulo are binary operators. I suspect you meant bitwise operator, which indicates that the operator works on bits, not on arbitrary values (which would be arithmetic operators).
But no, you do not need to write anything which converts digits to hexadecimal or binary. How we represent the number as humans is purely for our convenience. When dealing with bits and bytes and words, hexadecimal and binary are more suitable representations (base-16 and base-2 respectively) than decimal (base-10), because each digit contains an integer number of bits. In base-10 numbering (which is what we're taught at school, and use day-to-day), there are about 3.2 bits per digit, which makes decimal representations hard to work with.
Keywords: coursework
Referrers: Question 118 (2006)
Submission reference: IN938
Hiya Fred, I'd just like a bit of clarification on what we are supposed to do for the assessment. Am I correct in thinking that our method needs to, in effect, decode the inode number to retrieve whereabouts the particular inode in question begins and ends? Also am I correct in thinking that in order to do this we need to work backwards through the inode number? Cheers!
Pretty much, yes, but it should not be a complicated process! See also Question 106 (2006) and Question 100 (2006).
Keywords: coursework
Submission reference: IN935
I seem to get the same output as you describe for the test.dsk but I don't think I get the correct output for badtest.dsk and bigger.dsk. I get the following results:
[snip expected 'badtest' output, broken 'bigger' output]
Im guessing badtest.dsk's output could be correct if it has a single error in the inode entry. Are my ouputs correct? If not could you give my any pointers please? My code follows:
[snip code]
I am not a debugger :-). The correct outputs are shown in Question 105 (2006). One approach would be to print out the inode numbers your method is being asked to process and see if there's anything different about them compared to the ones which appear to work ok. You'll probably want to print the number out in hexadecimal too (regular decimal might not be much help); with something like:
System.err.println ("decoding inode " + String.format ("0x%-8x", inode));
Keywords: coursework
Referrers: Question 116 (2006)
Submission reference: IN936
I currently have the following code:
[snip code]
but I am getting the errors:
SmallFS::getBlocksFromInode(): invalid inode block storage specification! SmallFS::fsDumpRoot(): failed to read directry entry 0 of 22369621 SmallFS::fsDumpRoot(): failed to read directry entry 1 of 22369621 SmallFS::fsDumpRoot(): failed to read directry entry 2 of 22369621 ...
I am trying to (using the example from the assessment page) get the 'tto' value by shifting to the right until they are the only three values left. Likewise with the offset, I'm pushing the values the other way, however I believe if you do this, it puts in 0's on the right, which will change the value of the number? Alternatively I could of course have the wrong end of the stick entirely :P
You've kind of got the right idea, but not exactly. To get the inode table number, you need to extact the 'tt' portion of the number (just 2 hexadecimal digits, not 3). Regarding the offset, that doesn't need to be shifted at all — it's already in the correct 'digit positions'. As you point out, shifting will change its value (in a bad way probably).
Keywords: coursework
Submission reference: IN940
Have you got any more test disks with files on to try as, I am concerned that I have missed something, as my working solution took 20 mins to write with 7 lines of code (with error checking), with me not entirely understanding everything that you have said, i.e how does the inclusive OR in your documentaion feature in the conversion process?
[snip code]
I am convinced about errors in my code.
7 lines of code seems a bit short for this. My model solution is 14 lines of useful code, though it could be fewer. I would probably be safe to say that if you don't understand what's going on in your solution, chances are there are errors. The provided tests should be good enough.
As regards the inclusive bitwise or, here's something to try and explain it (though I would expect the wealth of established programming textbooks in the library to be more helpful):
int table = ..; // 0xtttttttt
int offset = ..; // 0xoooooooo
int inode = (table << 24); // 0xtt000000 (shift left, keeping lower 8 bits)
int noffs = (offset & 0xffffff); // 0x00oooooo (mask out top 8 bits)
inode = inode | noffs; // 0xttoooooo
So the 'or' is just used to combine the two halves. In this case I could also have used '+' (but this is not the same operation as bitwise-or in the general case, as you should probably know and understand!).
Keywords: coursework
Referrers: Question 118 (2006)
Submission reference: IN948
Can you explain me what 0xttoooooo is? Thanks.
See Question 106 (2006) (and others).
Keywords: coursework
Submission reference: IN944
So far for assessment 4 I have:
[snip code]
Am I along the right lines?
Sort of, although there's a strange shift in there. Make sure that you understand what's going on at each step in your code (don't code blind!).
Keywords: coursework
Submission reference: IN963
My code will work for all three disks. But will only print out the size for the first two directories (. and ..) and will just print out 0 as a gid and uid for all of them. Is there any obvious cause for this?
See Question 90 (2006). The root inode number is 0x01000000, so if it works for this one, is there anything different about the other inode numbers (which don't work so well)? [Hint: print out the inode numbers in hexadecimal — see Question 111 (2006)].
Keywords: coursework
Submission reference: IN952
Is it possible by making use of the formula that you gave to us:
0xttoooooo ((itable << 24) | (ioffset & 0x00ffffff))
To use it over all the itables and ioffsets and if we don't get the 0xffffff we can return null else return the arraylist?
Can we do this? Or this is not what you want?
You sound a bit confused :-(. There are no 'arraylist's here.. But your code shouldn't be iterating over any arrays anyway (no need to do that here, and it would be inefficient). It is not a comparison issue either: the inode table number (which you can extract from the inode numbers) specifies which table the inode is in. The locations of the inode tables (and their lengths) are given in the superblock (within two arrays there). Then read the method header of what you've got to implement again :-).
Keywords: coursework
Referrers: Question 118 (2006)
Submission reference: IN954
So are you saying then what we need to do is the following:
0xttoooooo ((16777216 << 24) | (16777216 & 0x00ffffff))
?? sorry for being a tad thick, but I am just lost with how inodes and that work, I have looked in both my OS books and asked other people and they all seem to know about as much as I do - not a lot. Thanks
What you have there would not do anything meaningful, and this is something you should be able to establish for yourself! :-). If you change the decimal numbers into hexadecimal, you'd get:
((0x01000000 << 24) | (0x01000000 & 0x00ffffff))
Which computes in the following way (more or less):
0x01000000
0x01000000000000 (shift-left 24)
----------------
0x00000000 (32-bit result)
0x01000000
0x00ffffff (bitwise and)
----------------
0x00000000
Doing a bitwise or on the resulting values will always produce zero, so not much use.
What an inode is and how it works is not necessarily an issue. You're presumably finding information about the contents and purpose of inodes from books. However, the issue you're having is about how inode numbers are represented in the Java code. They are pretty much separate.
See Question 117 (2006), Question 113 (2006), Question 109 (2006) and others.
Keywords: coursework
Referrers: Question 137 (2006) , Question 138 (2006)
Submission reference: IN953
I currently have the code:
[snip code]
However this is only printing out:
0x1000000 128 0 0 .
0x1000000 128 0 0 ..
when it comes to the directory/files part, and also the 128 should be a 512, and I can't work out why this is! I have had a quick look through the fsDumpRoot() method, and I beleive the 128 relates to the size(?) but at the moment I'm at a bit of a loss :'(
The 128 value you're seeing would indeed be the size (look at the SFSInode inner-class, well documented there!). I can't obviously see why it's getting this value, looking at the code, but the likely reason is that your method is returning incorrect values. But, even before that, the check you had (which returns null) should probably have failed for the root inode anyway.. Try sticking some debug print statements into your code to see what the values of various variables are at each stage (printing these in hexadecimal will be more meaningful).
Keywords: coursework
Submission reference: IN957
Hi, What silly thing have I done wrong when I get this error?
SmallFS::getBlocksFromInode(): invalid inode block storage specification!
Thanks. (I know I'm doing something daft just can't see what I have done wrong!)
The code that prints the message is in SmallFS.java, have a look at that code to see why it actually prints the error. The test disk has good inode data, so this type of error shouldn't occur. This means that the inode data passed to getBlocksFromInode() must be broken somehow. That probably happens because the inode data is read incorrectly from the disk, which is where your code comes in. Your code is responsible for determining the on-disk location of a particular inode; if it returns incorrect values then you'll see various errors further downstream.
Keywords: coursework
|
Maintained by Fred Barnes, last modified Thu May 8 12:58:00 2014 |
