2.6 kernels and OWFS

Hello!
I seem to recall that there were issues of some sort concerning the
USB One-Wire adapter, and the 2.6 family of kernels, and of course
OWFS.

Have these been resolved or have I been living the lives of Doctor
Who, and are remembering something else entirely?

--

-- 
Gregg C Levine gregg.drwho8 <at> gmail.com
"This signature was once found posting rude
 messages in English in the Moscow subway."

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: 2.6 kernels and OWFS

Hi,

Gregg Levine:
> I seem to recall that there were issues of some sort concerning the
> USB One-Wire adapter, and the 2.6 family of kernels, and of course
> OWFS.
> 

The one problem I've seen is that newer kernels, with some distributions,
include the kernel 1wire driver and auto-load it when they see the USB
adapter. That of course conflicts with OWFS.

The simple solution is to blacklist the module (and/or unload it before
starting owserver) -- and ask your distro not to compile that module by
default. I have no idea if anybody uses it; it doesn't even support
hubs.

--

-- 
Matthias Urlichs   |   {M:U} IT Design  <at>  m-u-it.de   |  smurf <at> smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
We won't have a society if we destroy the environment.
					-- Margaret Mead

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: 2.6 kernels and OWFS

Am Mittwoch, 1. August 2007 08:21 schrieb Matthias Urlichs:
>
> The simple solution is to blacklist the module (and/or unload it before
> starting owserver) -- and ask your distro not to compile that module by
> default. I have no idea if anybody uses it; it doesn't even support
> hubs.
>
Well, from my point of view, the w1 kernel modules are in some kind of limbo, 
it hasn't changed much the last month. 

We discussed some minor items on this list a long time before with the w1 
author, Evgeniy Polyakov. Evgeniy is still active in linux kernel 
development, but his latest project was the distributed storage subsystem. 
I'm unsure if he has interest in w1 any more. If not, we could change the 
linux w1 subsystem so it doesn't interfere with owfs or make it an actually 
*useful* basic layer for owfs.

Paul, could you ask him about that? From our last discussion, I had the 
impression I can't find the right words to talk to him.

Kind regards

	Jan Kandziora
--

-- 
"And the next time you consider complaining that running Lucid Emacs
19.05 via NFS from a remote Linux machine in Paraguay doesn't seem to
get the background colors right, you'll know who to thank."
		-- Matt Welsh

-------------------------------------------------------------------------

Re: 2.6 kernels and OWFS

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

_______________________________________________
Owfs-developers mailing list
Owfs-developers <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: 2.6 kernels and OWFS

Am Mittwoch, 1. August 2007 12:58 schrieb Paul Alfille:
>
> So that is the status of the w1 interface. It's very linux-specific, and
> even at best won't add any new function. I was more interested before we
> managed to get I2C working, since there is a kernel module for that as
> well.
>
> In short, just unload the ds9490r and everything will work. User-space
> drivers are the way to go!
>
Well, first I'd like to backup user space drivers are the way to go. They are 
just more flexible.

Where a linux kernel driver comes in handy is sharing bus ressources between 
different applications. Ok, we have owserver for that but then, all the 
applications have to use owfs.

I specifically think of onewire chips built into laptop batteries. As soon a 
user encounters such a device, wants to monitor it through the usual kernel 
hardware monitoring interfaces *and* connects some devices to the laptop 
through owfs (e.g. servicing my vending machine), he will run into 
a "deadlock".

Ok, as far as I read it, w1 isn't connected to the hardware sensor facility so 
far, but it may come up.

Kind regards

	Jan
--

-- 
Who is General Protection Fault and why is he reading my hard disk?

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: 2.6 kernels and OWFS

Hi,

Jan Kandziora:
> I specifically think of onewire chips built into laptop batteries. As soon a 
> user encounters such a device, wants to monitor it through the usual kernel 
> hardware monitoring interfaces *and* connects some devices to the laptop 
> through owfs (e.g. servicing my vending machine), he will run into 
> a "deadlock".
> 
A conflict would exist only if those are connected through the same
interface.

I think that's exceedingly unlikely. A laptop battery's monitor would be
connected via I²C, I'd assume. There's no reason at all to sacrifice an
internal USB port plus pay for an expensive USB->1wire adapter.

I also assume that nobody who's remotely sane would add put an externally-
accessible I²C or 1wire interface into their laptop … and even if so,
using the same wire that's carrying the battery monitor data would be
deadly. :-/

--

-- 
Matthias Urlichs   |   {M:U} IT Design  <at>  m-u-it.de   |  smurf <at> smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
A continuing flow of paper is sufficient to continue the flow of paper.
		-- Dyer

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Owfs-developers mailing list
Owfs-developers <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: 2.6 kernels and OWFS

Am Mittwoch, 1. August 2007 14:41 schrieb Matthias Urlichs:
> Hi,
>
> Jan Kandziora:
> > I specifically think of onewire chips built into laptop batteries. As
> > soon a user encounters such a device, wants to monitor it through the
> > usual kernel hardware monitoring interfaces *and* connects some devices
> > to the laptop through owfs (e.g. servicing my vending machine), he will
> > run into a "deadlock".
>
> A conflict would exist only if those are connected through the same
> interface.
>
> I think that's exceedingly unlikely. A laptop battery's monitor would be
> connected via I²C, I'd assume. There's no reason at all to sacrifice an
> internal USB port plus pay for an expensive USB->1wire adapter.
>
No, but the problem exists for the i2c<->1w bridge as well. And that chip is 
cheap enough.

> I also assume that nobody who's remotely sane would add put an externally-
> accessible I²C or 1wire interface into their laptop … and even if so,
> using the same wire that's carrying the battery monitor data would be
> deadly. :-/
>
Ok, you have a point here. USB<->remote 1W is the most likely configuration.

Kind regards

	Jan
--

-- 
DOS: n., A small annoying boot virus that causes random spontaneous
	system crashes, usually just before saving a massive project.
	Easily cured by UNIX.  See also MS-DOS, IBM-DOS, DR-DOS.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Owfs-developers mailing list
Owfs-developers <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

How should we chain?

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

_______________________________________________
Owfs-developers mailing list
Owfs-developers <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: How should we chain?

Hi,

Paul Alfille:
> The new DS28EA00 is a temperature chip that has a special "chain" mode to
> tell location. Specifically there are in/out pins that tell which chip is
> connected to which.
> 
Nice. Remind me to beat myself up because the wiring I've been using
definitely doesn't have a spare wire for that kind of feature. 

> 1. have a directory entry "chain" that would have a list (comma separated)
> of the chained ID numbers

Why commas? I'd use newlines, they're much more convenient for
sequential reading from script languages as well as C.

> 3. Put the "chain" file under "simultaneous -- already a per-segment
> directory entry.
> 
Makes sense.

> Any thoughts?
> 
I'd definitely go with the third option.

As I understand the protocol, selectively enabling just one sensor in
order to figure out what the next one's address is is not possible.
Thus, you need multiple accesses to walk through the whole bus segment.

The individual device directories are for individual devices, and each
file access in there takes one bus access (usually). Putting their
relationship to other devices in that directory doesn't make sense,
neither from a conceptual nor a performance PoV.

--

-- 
Matthias Urlichs   |   {M:U} IT Design  <at>  m-u-it.de   |  smurf <at> smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
The most utterly lost of all days, is that in which you have not once
laughed.
					-- Chamfort

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: How should we chain?

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

_______________________________________________
Owfs-developers mailing list
Owfs-developers <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers