|
From: Vadim T. <vt...@fr...> - 2003-09-02 06:06:31
|
According to Paul Alfille: > 1. (for Nicolas Huillard) Locking of device and bus. > A. The 1-wire bus (actually the serial port) will be locked during > communication with devices. I'll drop the lock during conversions, to > allow other activity, but this will confuse non-powered situations when > a strong pullup is needed. Anyone have a solution? Well, not a solution, but a suggestion. There should be two levels of locks. First, serial port (or USB device) level lock, should be on as soon as OWFS is up. No communication to the adapter other than through OWFS layer (actually, owlib layer that provides functionality for both owfs and owhttpd) must be accepted. In case of a serial port it's a port level lock, in case of a USB device it may be more complicated, but still doable. Second, 1-wire bus level lock. This one, indeed, should behave as you describe. > B. Bus scanning (directory listing) will be locked. Yes and no. Bus scanning may take significant time. When accessing this function through owfs, applications that use the functionality may not (and need not) be aware of the fact that this is a time and resource consuming operation, therefore there's a risk of a painful bottleneck. One of possible solutions is not to perform a bus rescan every time there's a directory listing, but return collected data instead. And bus rescan may be initiated by an operation like cat /dev/null > /mnt/owfs/rescan.now (for synchronous rescan) cat /dev/null > /mnt/owfs/rescan.background (for asynchronous) like some /proc entries do. btw, is it possible to make owfs a part of a /proc subtree? It would be a natural place for it... > 5. Preliminary thoughts on secure iButtons. How to pass a password in > filesystem symantics? My suggestion: Use memory.password as the > filename. exactly > 6. I plan to make owhttpd a multithreaded application since the locking > will be implemented. owlib may need to be multithreaded - concurrent requests to owfs by different applications are possible as well. > Paul --vt |