[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [coldsync-hackers] Re: Problem respawning coldsync daemon



On Fri, 2002-03-01 at 08:38, Alessandro Zummo wrote:
>  On 28-Feb-02 at 21:57:24,
>   Greg KH <greg@kroah.com> wrote:
> 
> >> > you can catch the hotplug event that states that the device has now
> >> > been removed from the USB bus.
> >> 
> >> mm.. that could be interesting... any point to the relevant
> >> documentation?
> 
> > See http://linux-hotplug.sf.net/ for lots of docs on this.
> 
> > Let me know if you have any specific questions.
> 
> Maybe i could add an option to coldsync so that it waits
> for a signal, let's say USR1, before going out.
> 
> This signal coul be sent using a little script
> called from the hotplug $REMOVER.
> 
> I'm still not sure on how to indentify the correct coldsync process,
> since we may have one that listen over USB, one over the standard
> serial port, one over the net, etc etc...

Ok so I sent a bit of time on this over the weekend and here are my
findings.  Recall this is a linux box (Redhat 7.1 derivative) using a
Palm M500 over a USB cradle.

The process happens like this:
1. Press hotsync button on cradle: this triggers the kernel to hotplug
in the various kernel modules (visor.o, m500.o etc)
2. Coldsync does it hotsyncing stuff
3. Call to Palm to finish communications as a part of the shutdown
procedure.
4. Palm cradle triggers the kernel to hot-unplug the various kernel
modules, occurs at some asynchronus time.
5. Coldsync closes the serial_drain() routine and closes serial port.

Note in particular the steps are different to those given earlier in
this thread.  Most important is that the Palm removes itself from the
USB bus potentially <BEFORE> coldsync has closed the serial ports.

So what changes have I made.  (Due to a slight problem on my part --- I
left the patch file at home --- the patch file will be sent tomorrow)
Firstly, I introduced a blanket sleep at the end of the routine given in
step 3 --- a better method would be to poll to see if the link had
disappeared, but this may break code for non hotplugging devices. 
Secondly, the serial_drain() routine needs to change as the call to
tcdrain() will permanently block if the device has un-plugged.

I will send the patch files tomorrow for both these cases.  Based on the
2.3.0 coldsync version --- is this the appropriate version?

A second point.  It occured to me that it may be possible to use this
hotplugging facility in a much better way.  I understand that when a
device is hotplugged it can call a script, perhaps this script could
then call coldsync to do its stuff.  With this approach one doesn't need
to run coldsync as a daemon (avoiding a process running which has to
continually poll the USB).

Cheers,
	Andrew
-- 
Dr Andrew Bainbridge-Smith
Senior Research Engineer 
Machine Vision Group
CSIRO Manufacturing Science and Technology
Australia


-- 
This message was sent through the coldsync-hackers mailing list.  To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body.  For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.