In keeping with the pattern of mtd@partition, I have added loop@path as a way to specify a loopback device. This way you can do things like mount directories in /system using cramfs from a file otherwise on /system (just one example oof how I'm using it). I specifically went with loop@ rather than adding this feature as a flag as the flags system is designed to set bits in the flags argument to mount: using loop@ fit the model in a much simpler manner and actually feels "correct".
This is a better version of the previously submitted 4045 that also refactors the mtd@ case. The reason for this is that I received comments that I should check for errors and return errors rather that do work in the case of success and fall through, but the mtd@ case wasn't doing that either and it became awkward to design the function so that it was half in one style of error handling and half in another. I also made certain to use inequality comparisons for Unix's -1 error returns rather than checking for -1, refactored my large if statement so as not to have danling parentheses, and disassocited the loop device on mount failure.
If the SD card is partitioned and one attempts to use a partition of the SD card for another purpose (maybe even booting off of it), then mmcblk0 is considered "busy" when mountd tries to mount it (as specified by /etc/mountd.conf). Normally, it would then attempt to mount partitions of the device, but as "busy" is specially treated in the code it does not consider this to be an error condition.
The argment for this check is that "the device is likely already mounted", but that is obviously not something that should be assumed (and is not true in this example situation). Even if the device were already mounted, from the auto-mounter's viewpoint this should be considered an error anyway, as it failed to mount it as it was told. I therefore believe this check to not only be causing the above problem but also to be incorrect. This change removes it.
For more information, see this thread:
http://groups.google.com/group/android-porting/browse_thread/thread/a67cbe36603d429a
