Loading ...
Sorry, an error occurred while loading the content.
 

Re: [nslu2-linux] Ext3 external drive

Expand Messages
  • Mike (mwester)
    ... Roughly, yes. The main processes are the two USB_Detect processes. ... the ... not ... done ... Agreed. There will be pros and cons to any solution,
    Message 1 of 11 , Jun 24, 2007
      Marcel writes:
      > 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
      the
      > > Linksys code to automount a disk (in order to ensure that our code does
      not
      > > interfere with the Linksys mechanism, we need to run after Linksys has
      done
      > > 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
      possible ones!

      > --
      > marceln


      Mike (mwester)
    Your message has been successfully submitted and would be delivered to recipients shortly.