2010-07-05 09:24:31     usb handling

Document created by Aaronwu Employee on Aug 22, 2013
Version 1Show Document
  • View in full screen mode

2010-07-05 09:24:31     usb handling

Filip Vanalme (BELGIUM)

Message: 90911   


In my application, I have to detect the insertion of a usb memory device, check for the presence of a file and, when it exists, perform some action with the contents of it . In my hotplug script, I'm sending a USR1 signal when the usb device is plugged in and a USR2 signal when removed (I use killall -USR1 appname, to send the signal to the application).

I have a multi-threaded application. Because I want to receive the signal only once, I only allow SIGUSR1 and SIGUSR2 for only one specific thread (the usb handling thread). I block these signals for all other threads (using pthread_sigmask()).


In the signal handler for USR1 and USR2, the only thing I do is generating a pthread signal with pthread_cond_signal. On receiving this signal (pthread_cond_wait), I start the actions on my usb. So far, everything is working.


However, in that handling routine, after opening the file on the usb, I'm using a fscanf to read from that file. This always returns with the EINTR error (interrupted system call).  I already tried with fgets(), but it gave me the same problem.


Some questions :

- this the best way to handle usb insertion detection ? Better alternatives ?

- what to do with the fscanf problem ? I suppose it's caused by the signal I'm sending when inserting the usb device. But how to avoid that behaviour ?


Thanks for any help.




2010-07-05 09:35:28     Re: usb handling

Mike Frysinger (UNITED STATES)

Message: 90912   


you could create your own thread to process netlink messages and signal the other thread when the device you care about shows up


once the the signal has been sent & processed, it shouldnt interrupt anything else.  is there just the one signal ?


are you able to read the usb files from another shell ?


what if you use fread() or just read() ?




2010-07-05 10:22:50     Re: usb handling

Filip Vanalme (BELGIUM)

Message: 90915   


Thanks Mike for this fast response !


"are you able to read the usb files from another shell ?" This question pointed me in the good direction. Because I created the file directly on the board's filesystem, I was quite sure that the contents was there.... From the Kernel prompt, I checked the file. Although I created the file on my usb device manually from the uClinux Kernel prompt, filling it with data with the vi editor, the file appeared to be empty when I plugged in the usb stick again. I created the file again on a pc and tried again. Now everything works fine. After plugging in the usb device, I can open the file and read its content without any error report. So, that looks OK now.

Brings me to a new problem : why the file was not correctly written ?

I did some tests. I plug in my usb device. From the hotplug script, the usb device is automatically mounted to /mnt/usb/sda1. I can do a list of all files on it. With vi, I create a new file, enter some data and quit with wq to save the data. I check the content with cat and I can see that everything is correct. I remove the stick. The hotplug script automatically unmounts the device. Then I plug in the device again. Checking the mounted device, I see that the file I created was not there any more ! It looks like the content was not updated on the stick. I have the feeling that I'm missing something fundamental here. After mounting, can I write to the usb device just like that, or do I have to do some other actions ? Or does it have something to do with the removal/unmounting of the usb device ?




2010-07-05 10:31:23     Re: usb handling

Michael Hennerich (GERMANY)

Message: 90916    Did you mount the usb drive #mount -o sync?




2010-07-05 10:54:08     Re: usb handling

Filip Vanalme (BELGIUM)

Message: 90918   


No I didn't... I will try it.






2010-07-05 14:59:34     Re: usb handling

Mike Frysinger (UNITED STATES)

Message: 90925   


umm, no, you cannot rely on the unplug event to cleanly unmount.  you've just possibly corrupted the fs.  you need to unmount *before* unplugging or you need to run `fsck` and such on the disk every time (and possibly lose data).


you can either force all writes to be synced to the device to workaround, or manually call one of the sync functions when data you care about needs to be written out, or you can cleanly unmount it when you're done.  the last option is the only sane one.


note: this is no different from any other operating system out there.  this is exactly why windows has a little icon in the taskbar to eject the device.