Motorola Droid SD card file access

Sat, 7 November, 2009

Got a Droid yesterday. No manual was included, let alone technical specs, and I feel lucky to have found some leaked version of a manual - good thing the users don't get a hold of this!

Mounting the SD card to share files was tricky. Here's how I managed.

Assumption: Your kernel supports the FAT file system. It probably does, but if you suspect otherwise, check the menuconfig at File systems -> DOS/FAT/NT Filesystems -> VFAT (Windows 95) Support.

  • Plug the device into your machine via USB. I mount drives manually, which you'll probably have to do also since an auto-mount is likely to fail.
  • Watch /dev for udev to create the device node, which for me is sda (/dev/sda).
  • The partition should have been detected but wasn't. The work-around is fdisk /dev/sda, then the q command to quit without saving changes. This seems to be enough that ls /dev includes the partition /dev/sda1
  • Now the mount command:
    mount /dev/sda1 /mnt/usb -t vfat -o rw,dirsync,nosuid,nodev,noexec,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro
    
  • And now, as root, I can copy files onto the SD card:
    cd /mnt/usb
    mkdir music && cd $_
    cp /home/erik/music/* .
    

The copy operation fails with vague I/O errors, but after several iterations my music is copied. The Droid is very good about finding files anywhere on the SD card, and finding the album art, etc.

I hope this helps one Droid owner get around the issues I've had.

What I did this summer

Sat, 29 August, 2009

Inspired by Django, I've written an MVC web framework in C.

What the hell?

It's serving up this blog. It's a pretty responsive site, yes?

Features

  • CGI
  • Templating engine supporting inheritance (unlimited levels), template includes, iterative templates, and chained formatter functions
  • Templates are initialized structs in a .c file
  • User views, implemented as a node tree with a few basic data types
  • Pretty URLs, parsed in a friendly way for matching to a view
  • Site configuration is #defined in a header
  • Will be released as GPL

Benefits

  • A native-code CGI is easy to deploy
  • Tiny surface area means higher security and fewer bugs (I'll defend this shortly)
  • Very green (low resources, high throughput)
  • Very fast

Minimal surface area for bugs and attacks

How is the framework "minimal surface area"? Everything is hard-coded at compile time. The trend in recent years has been to move configuration, templates, and data out of the framework code. Everytime an item is moved out of the binary, type safety is lost, which invites all kinds of bugs. The parsing of a configuration file represents more than overhead, it also means all kinds of user errors won't be detected until runtime.

Don't read this as a claim that the code is bug-free. But with a code-base this small, bugs are not hard to locate and fix.

To-dos

  • Unicode support - stop snickering, I know what needs to happen here and it won't take too much effort.
  • Template-block-level caching. This will be high-effort, but I can't defend a high-performance claim if a tag cloud has to be re-calculated with every request.

Might-dos

A data access layer. Currently the site runs without a database and I'm okay with that. I can easily add an interface to DBI when I need it. Or maybe I won't.

Won't-dos

  • ORN. An ORM is a time-saver at the start of a project, but an impediment later. What happens when your app upgrade requires a column be split into two columns? Maintaining data integrity here requires more care and feeding than an ORM will afford you.
  • Run-time template parsing. Explained earlier.

Confession

Part of the Django inspiration is that I don't think the dynamic-languages crowd has any kind of exclusive lease on elegant design, and I'm a little tired of this pretense by some (not all) of the members of these (Python, Ruby) communities.

Stay tuned

There will be a source release when I've got a few more features working like I want them. I hope a small niche of users will enjoy using this.

Home-brew virtualization lab

Sun, 29 March, 2009

I'm on the hunt for a good virtualization setup. Really, I just want my primary machine to be able to run at least 3 VM's at once. This is for exploratory purposes. I can use the lab to learn about:

  • Load balancing
  • Samba as Primary Domain Controller
  • Proxy servers
  • General try-before-I-buy software evaluation, keeping primary machine clean

Has anyone else out there explored this? What works for you?

Requirements:

  • Low memory footprint (256-512 MB) - I want at least three VM's running on a 2GB box.
  • Low disk footprint (IGB image)
  • Working setup without too much configuration (network comes up, drivers found, etc)
  • X is optional - I'm fine with CLI and would prefer the low overhead.

QEMU is the platform of choice, even though I can't get kqemu working. It appears that Intel's virtualization features (I don't have this) is required for kqemu, although QEMU's documentation doesn't sqy this specifically.

As much as I like Gentoo, compiling everything under a very CPU-bound QEMU sounds painful. Also, lots of disk space is required, although I could mitigate this by having all VM's mount a shared /usr.

Running standard desktop distros is painful - Ubuntu's live CD is barely usable after it boots in this environment. Puppy and Damn Small perform reasonably, although one (I forget which) doesn't find the network.

If you have a good working setup for this kind of thing, please shoot me an e-mail (comments not working right now).

About Me

Erik Mackdanz is a software developer in Austin, Texas, along with everybody else.

Links