As you can guess, I completely agree with you. We are working on the impedance mismatch with w1 and user-space generic access.
Some if the issues: 1. 1wire writes and reads back the same stream for all communication. In sysfs the best we could come up with is write to a file, and read the response from it back. Evgeniy points out correctly that there are potential race conditions if two user-space programs compete for the same file. (Yes, the serial adapter is prey to this now. Yes, owserver can negotiate access.) 2. Chips can have a state (like which voltage source is being access in the DS2438 or what temperature resolution is selected) that requires more than an atomic transaction. There are potential race conditions there. 3. I don't believe the alarm state is currently exposed. OWFS gets around all these issues by having a higher level understanding of each chip, and locking a chip for longer transactions. With exclusive access, w1 can function as a multi-type adapter. Alternatively, w1 can be a kernel-space version of OWFS. Currently only a few chips are supported. My guess is that people who use w1 for OWFS will have to know that using kernel sensor monitoring at the same time make cause interference. We may be able to work around the most common interactions. Paul Alfille -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jan Kandziora Sent: Friday, March 10, 2006 7:31 AM To: owfs-developers@lists.sourceforge.net Subject: Re: [Owfs-developers] w1 changes Am Freitag, 10. März 2006 12:43 schrieb Christoph Scheurer: > > > Sorry, that was too unspecific. What I mean is: one could just use an > > > empty I2C-slave module with only the basic I2C communication support > > > that recognizes the DS2482 and move all the W1 specific functions to > > > OWFS. > > > > Besides having only a brief look into the w1 kernel code, I think > > handling the remote chips is a userspace task, like with RS232 host > > adapter interface in kernelspace and modem/terminal control by a > > userspace program. > > That is exactly what I had in mind. The DS2482 is an I2C slave, so you have > a kernel module for the DS2482 which only recognizes the chip as an I2C > slave and attaches it to the I2C master (whatever that is in your > application: on-board, in-chip, parallel, serial, ...). Then you can > communicate to the DS2482 through opening the /dev/i2c-? that represents > the I2C-bus on which your DS2482 is attached the same way as you talk to a > serial 1-wire adapter through /dev/ttyS? . The only complication (which is > more like the USB case) is that now you have to explicitly include the > I2C-address of your DS2482 since there can be multiple DS2482 on any > I2C-bus. > Hm, I like parts of Evgeniy's approach. The way you describe it i2c->Onewire hosts would not be transparent against e.g. rs232->Onewire hosts. To fix my position: I think it's best to have a generic w1 kernel interface like the generic usb, serial or parport driver. But I'll think Evgeniy already implemented that. All additional interfacing should be doen in userland. Kind regards Jan -- It's no wonder they call it WinNT; WNT = VMS++ ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642 _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
