TomTom Settlement Aftermath: Get the FAT Out (Groklaw)

Unlike Groklaw I do not think that there will be anything 'Easy' about it. However I do have a idea on what could be used to replace it effectively.

One thing to keep in mind is that I do not think that it is necessary to remove FAT support for Linux distributions. Microsoft repeated stated that they were not targetting Linux or open source with this patent attack and I figure until they actually do then it is worthwhile to simply keep what already exists in place.

However it is important for embedded developers to work out a way to mitigate Microsoft's threat on new devices. So those are the people that need to be concerned about it.

I'll outline my thoughts:

There are a number of different reasons why Fat is the defacto standard for this sort of thing. Reasons like:

1. USB Mass storage is supported by modern OSes by default. As is FAT. This means that you can have your devices used on any OS without requiring users to install extra drivers. This is a HUGE benefit.

2. Fat is simple to impliment and has low resource requirements.

3. Everybody else is using it.

These are all very good reasons. Fabulous and very strong good reasons. Alternatives like ext2 require extra drivers on Windows. And with Window's way of dealing with drivers this means that if people try to move to Ext2 then there would end up being thousands of different versions of ext2 support floating around. USers using multiple devices will probably run into new difficulties. So avoiding installing new drivers for file systems in Windows is a huge priority.

So my idea is to not support USB Mass storage at all on these sorts of devices.

My idea right now, although I haven't looked into it to deeply is to replace USB mass storage + FAT with USB virtual enthernet driver + http + Webdav.

It may sound insane, but I think it would have a good chance of working for many devices.

Remember that we are dealing with consumer embedded devices running Linux with some sort of GUI interface. The processing power and memory requirements needed to run that sort of setup will also be able to run a embedded-style web server. Included on the device may be a small FAT16 partition that can be used to launch a autorun script.

So what this provides you with is the ability to run a nice graphical configuration utility, built into the device. This GUI would be write-once, use-everywere since it will be built using web standards.. the only requirement on the end user side is to have a web browser.

There is precendence for using virtual usb ethernet connections. Many 'Broadband' devices like Cell phones or modems that allow users to connect to 3G networks have virtual ethernet devices that they setup. This is because PPP over USB has a lot of overhead and will be throttled by the USB speeds before it maxes out the wifi connection. Ethernet frames have much lower overhead.

And, like FAT, Webdav is pretty much universally supported by modern OSes and can provide a file system-like interface for Gnome, Windows XP (or newer) and OS X. So if it desirable for a user to simply drag-n-drop files then that is acheivable.

So what this gets you is a nice write-once, run everywere, GUI interface for administrating the device. A nice way to provide links to online resources. Puts a higher degree of control over your device since your not exposing the full file system to the end user. Allows for better feedback from users for important tasks like firmware updates. etc etc.

The added expense can be offset by the fact that you can use native file system drivers and avoid needing additional block-to-flash translation layers needed to support FAT, as well as avoiding Microsoft's licensing costs. And you'll save on packaging and shipping costs since you won't need to bundle drivers so much.

And on top of that if you are creating a device that has additional features like wifi or broadband support then your application would be able to use that also without being re-written or changing user documentation.