A pleasingly retro look and feel


I have done almost all my development of Hexxed on a Macbook, but have now updated the git repo on my Linux laptop and run it Hexxed on Linuxthere – some interesting differences:

  • the Linux app has a pleasingly retro look and feel to it – no anti-aliased fonts here
  • on Linux key reptitition works as expected – ie if one holds down a key the application is sent multiple key events, which is what one expects and which works well with the vi-like interface I am building
  • On Linux the first file open dialog is a really crude/retro looking box (think Windows 3.0), while subsequent file open dialogs reflect the system windows toolkit.

The screenshot is of a VMUFAT volume, it was my experience of writing that driver that gave me the itch that Hexxed is meant to scrtach – in particular I wanted a hex editor that would allow me to display 16 bit numbers in a given endian form and partition the memory space by arbitary block size (VMUs use a lot of 16 bit little endian numbers and a 512 byte block size). Hexxed does both of these things now, though it still has no editing facilities – just viewing.

As for VMUFAT itself: Sadly no one on LKML seems much interested in that – the first posting got some helpful comments, but since I posted the corrected code six or so weeks ago, nothing. Suppose I will have to start poking people with an electronic stick.

Advertisements

New version of mkfs.vmufat available


Linux Filesystem Permissions
Linux Filesystem Permissions (Photo credit: Wikipedia)

I have posted a new version of mkfs.vmufat, a tool to make a VMUFAT filesystem, at my GitHub repo: it will now format a file as VMUFAT volume (if you use the -f switch).

Would love to hear your feedback – my posting of the source code for the filesystem itself generated a bit of interest, but have not heard anything back from any Dreamcast hackers though.

Spoke too soon (of course)


SOMEONE SPOKE OUT OF TURN - NARA - 515451
Image via Wikipedia

It’s like the curse of the software demonstration: it doesn’t break until then.

I discovered as soon as I posted that I was ready to (try to) push the VMUFAT stuff up to main line that there was a bug in the software.

Very large VMUFAT volumes were not being properly handled. But I think I have fixed that now. Some more testing is due, though, before I proclaim victory a second time!

Taking down the bug


Finally nailed the bug in my readdir function.

The code was stuck in an endless loop because it did not return an empty dirent when it reached the end of the directory – instead returning the list of files in the directory over and over again.

To fix this I made sure that any following scan of the directory began where the previous one left off. As this would return an empty dirent, the problem was solved.

A question for a C guru


English: Dada guru
Image via Wikipedia
The debugging continues, but unfortunately I have not yet been able to identify what is fundamentally broken with my file system code.

But along the way I have spotted and fixed various bugs. Here is one, I am not even sure why it compiled in the first place, so maybe a C guru could tell me…

Was:

if le16_to_cpu(((u16 *) bh->b_data)[j * VMU_DIR_RECORD_LEN16 + VMUFAT_FIRSTBLOCK_OFFSET16] == ino)

Now:

if (le16_to_cpu(((u16 *) bh->b_data)[j * VMU_DIR_RECORD_LEN16 + VMUFAT_FIRSTBLOCK_OFFSET16]) == ino)

Filesystem works


Not much of a surprise really, as the old code worked too, but the updated VMUFAT filesystem code works with 3.2.0-rc7.

Just have to clean it up so it is of an acceptable standard.

Update: In the unlikely event that someone is testing the code I should warn you that the above was overly optimistic. On unmounting the VMUFAT volume the whole kernel crashed – a bug in the evict_inode function I think.

Working on filesystem code


English: A North American Sega Dreamcast VMU, ...
Image via Wikipedia

Nearly a decade ago I wrote a crude, but working, filesystem for the Sega Dreamcast VMU on Linux. I then put ported a very simple web server to the Dreamcast and got the whole thing on Slashdot.

I never managed to get the thing into mainline – indeed the battering I got last time I tried, in 2009, more or less made me give up writing anything for the kernel and the Dreamcast was put away.

I am not pretending my code was pretty or even particularly good but it is no wonder people get put off from contributing when you get pig ignorant comments like these:

Everything about the on-disk format is tied to the VMU. Until that sinks in, don’t bother sending me email, thanks.

This was someone, who ought to have known better, claiming that it was not possible to have a free standing filesystem for this at all – though they were making their, incorrect, claim in the manner seen all too frequently on the Linux Kernel Mailing List.

No comments.  Really.  There must be some limits on the language one is willing to use on public maillist, after all.

As you can tell this person – a top flight Linux hacker – did not like my code. And, looking back, I can hardly blame him, it was pretty ugly. But as a help to fix it this is of next to no use – and only serves to demotivate. Nasty computer scientists, again.

Ok, so I have got that off my chest. And I am once more placing myself in the firing line.

The filesystem code, a work in progress (so check where the code has got to once you click the link), can be found here. A filesystem that you should be able to mount under loopback, can be found here. All testers welcomed with open arms.