driver

X86BinaryAssembler.java (and potentially others) have code like this:

502	    public final int get32(int offset) {
503	        int v1 = m_data[offset++];
504	        int v2 = m_data[offset++];
505	        int v3 = m_data[offset++];
506	        int v4 = m_data[offset];
507	        return (v1 & 0xFF) | ((v2 & 0xFF) <<  | ((v3 & 0xFF) << 16)
508	            | ((v4 & 0xFF) << 24);
509	    }
510	
511	    public final long get64(int offset) {
512	        long v1 = m_data[offset++];
513	        long v2 = m_data[offset++];
514	        long v3 = m_data[offset++];
515	        long v4 = m_data[offset++];
516	        long v5 = m_data[offset++];
517	        long v6 = m_data[offset++];
518	        long v7 = m_data[offset++];
519	        long v8 = m_data[offset];
520	        return (v1 & 0xFF) | ((v2 & 0xFF) <<  | ((v3 & 0xFF) << 16)
521	            | ((v4 & 0xFF) << 24) | ((v5 & 0xFF) << 32)
522	            | ((v6 & 0xFF) << 40) | ((v7 & 0xFF) << 48)
523	            | ((v8 & 0xFF) << 56);
524	    }
525	
526	    public final int get8(int offset) {
527	        return (m_data[offset] & 0xFF);
528	    }

Actually I don't have many clues about filesystems, however I have/had troubles with the DuCommand.
I've got the Information to get the block size of a filesystem by getting the Device and casting it to a FSBlockDeviceAPI. Currently in the DuCommand the Device is queried through mountpoints and the FileSystemService.

Sounds fine, but actually doesn't work well in practice.
When booting from CD, the / and /devices directories have no mount point at all (should this be ok?) and the mounted directories are either ATAPISCSIDevice or VirtualDevice which both don't implement the FSBlockDeviceAPI.

Ok, "virtual" filesystem on CD or in RAM may don't have sectors or blocks (as I said, I have no clue), but at least a "getSectorSize()" method should return me a 1.

(As reported by Peter in another issue)

I'm not sure if it is described or discussed anywhere yet, but on my box I'm very used Ctrl+key commands. To name some I personally use: a (home), e (end), k (cut til eol), y (paste), r (reverse history search). All of them print strange characters in JNode. pageup/pagedown does not do anything, in my box it uses the string before the cursor position and reverse searches the history for a command starting like the string.

Another strange behaviour is on an empty prompt: If you press the key-down button you go into the history from the beginning. I'm not sure if it's a feature or a bug, but I was confused the first times it happend as I didn't expect it.

(Mine)

I find the way that JNode history entries are managed to be unhelpful. JNode won't add an entry if the line is the same as the last line. Also, if the line has been entered previously, it moves it down to the end of the history. The net result is that the "history" doesn't actually reflect history, and is harder to use than a typical UNIX shell's history.