> On Sun, 2007-06-24 at 11:58 -0500, Mike (mwester) wrote:
> > - We lack the source, so we cannot "fix" the Linksys automounting code.
> First of all do we know which code is responsible?
> Just knowing the mechanism makes it a lot easier to fix.
Roughly, yes. The main processes are the two USB_Detect processes.
> > We will need a daemon that polls for the results of a failed attempt by
> > Linksys code to automount a disk (in order to ensure that our code does
> > interfere with the Linksys mechanism, we need to run after Linksys has
> > its job, and rejected the partition/disk). Tailing the dmesg output
> > periodically might be a way to get this info.
> This setup has a lot problems.
> - There are lots of race conditions
> - Checking the logfile is unreliable
> - Doing extra polling is a waste of cpu
Agreed. There will be pros and cons to any solution, given that the
*correct* solution (modifying the Linksys source) is not viable.
> We could do better if we can find a hook in the linksys code and replace
> that with our own code. Our own code would the call the linksys mount
> code and check the result. If that fails we try an ext2/3 mount.
> To do this we need to know the linksys mechanism.
It's all one monolithic program, as far as I was able to determine when I
looked at this stuff in detail (over a year ago, now -- my memory is a bit
fuzzy). It calls out to mount/umount, and executes a couple of the startup
scripts if the mount was successful. Beyond that, someone will have to do
the necessary detective work to reverse engineer it. I think that truss
will run and might be helpful (I think I did that at one point, and
determined that the Linksys code is polling the presence of /proc/usb_hdd or
some such similar file).
There certainly are multiple ways to do this, it would be great if we
actually had enough information gathered and enough of this reverse
engineered to the point where we could choose the best approach out the