owfs-developers — Developer's list for OWFS

RE: [Owfs-developers] SF.net is awful tonight : info + mail bug

[Matthew D. <ma...@ma...>]

Vadim Tkachenko wrote:
> Actually, I can just go ahead and do it, it's a 5 minute job. If you
> don't mind, that is.

I wouldn't mind seeing this script myself too :-)

Thanks,

Matt

[Owfs-developers] re: Website supported by CVS

[Vadim T. <vt...@fr...>]

Hello all,

I've added the HTML pages and the PDF document to the CVS. Module name is
'ow-website'. Currently, site is accessible as

	http://owfs.sourceforge.net/new

As soon as the rest of work is done, it will just replace the current site.

Changes I'd like to implement: basically, move all the binaries to the SF
release site. Hope I have enough permissions to do that ;)

--vt

[Owfs-developers] Testers needed.

[Paul A. <pal...@ea...>]

We need people to test OWFS with different chips.

So far, the DS1904 clock
DS2401
DS2405
DS18S20
DS1822
DS1993,5,6
DS2890
DS2438
and the TO=92 version of the DS2406 have actually been tested. Can
anyone confirm the 2450 works?

If we write for it, can anyone test the DS2409, DS2436 and DS2438?

Paul

Re: [Owfs-developers] SF.net is awful tonight : info + mail bug

[Vadim T. <vt...@fr...>]

According to Paul Alfille:

> Great, perhaps you can send me some private instruction.

Actually, I can just go ahead and do it, it's a 5 minute job. If you don'=
t
mind, that is.
=20
> Paul

--vt

> On Wed, 2003-09-03 at 19:15, Vadim Tkachenko wrote:
> > According to Nicolas Huillard:
> >=20
> > > PS=B2 : it also says that "All projects using SourceForge.net proje=
ct web=20
> > > services are required to display the SourceForge.net logo on their =
pages."
> > > PS=B2=B2 : I can update the web site if you tell me where are the s=
ources=20
> > > (on the SSH shell, on your workstation, somewhere else ?)
> >=20
> > I've successfully followed the following pattern throughout last few =
years:
> >=20
> > - Web pages are a part of the distribution tarball;
> > - Changes to the website are committed to CVS;
> > - There's a script on shell.sf.net that pulls the CVS content once in=
 a
> >   while (hourly is more than enough)
> >=20
> > Benefits: changes become distributed, you don't have to log on to SF =
to make
> > them; maintenance becomes nonexistent
> >=20
> > Disadvantages: none that I can think of ;)

Re: [Owfs-developers] SF.net is awful tonight : info + mail bug report

[Paul A. <pal...@ea...>]

File size will be fixed in the next release. It was a pretty easy fix.

Paul

On Wed, 2003-09-03 at 19:00, Nicolas Huillard wrote:
> I've uploaded 0.95 in the file release system (FRS) on SF.net, but it's 
> to slow right now (must be transatlantic network) to also submit the 
> following bug :
> 
> The files "type", "tempC" and "tempF" are in fact binary because they 
> are right-padded with ^@ (ASCII code 0x00) characters.
> This is conform to the reported size of the file by "ls -l", but it 
> seems a little strange.
> temp? decimals are also right-aligned in a 12 chars wide area (blanks at 
> the beginning of the file).
> I doesn't seem to hurt my frist scripts, but it surely will hurt someone 
> someday...
> 
> NH
> 
> PS : the acceptable use states that "File releases may not be made 
> available via your project web space (unless you have received 
> permission in writing from SourceForge.net staff), with the exception of 
> nightly snapshots. File releases should be made available using the File 
> Release System."
> PS² : it also says that "All projects using SourceForge.net project web 
> services are required to display the SourceForge.net logo on their pages."
> PS²² : I can update the web site if you tell me where are the sources 
> (on the SSH shell, on your workstation, somewhere else ?)
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] SF.net is awful tonight : info + mail bug report

[Paul A. <pal...@ea...>]

Ok, put the log there, on the top line.

Paul

On Wed, 2003-09-03 at 19:00, Nicolas Huillard wrote:
> I've uploaded 0.95 in the file release system (FRS) on SF.net, but it's 
> to slow right now (must be transatlantic network) to also submit the 
> following bug :
> 
> The files "type", "tempC" and "tempF" are in fact binary because they 
> are right-padded with ^@ (ASCII code 0x00) characters.
> This is conform to the reported size of the file by "ls -l", but it 
> seems a little strange.
> temp? decimals are also right-aligned in a 12 chars wide area (blanks at 
> the beginning of the file).
> I doesn't seem to hurt my frist scripts, but it surely will hurt someone 
> someday...
> 
> NH
> 
> PS : the acceptable use states that "File releases may not be made 
> available via your project web space (unless you have received 
> permission in writing from SourceForge.net staff), with the exception of 
> nightly snapshots. File releases should be made available using the File 
> Release System."
> PS² : it also says that "All projects using SourceForge.net project web 
> services are required to display the SourceForge.net logo on their pages."
> PS²² : I can update the web site if you tell me where are the sources 
> (on the SSH shell, on your workstation, somewhere else ?)
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] SF.net is awful tonight : info + mail bug report

[Paul A. <pal...@ea...>]

Great, perhaps you can send me some private instruction.

Paul

On Wed, 2003-09-03 at 19:15, Vadim Tkachenko wrote:
> According to Nicolas Huillard:
> 
> > PS╡ : it also says that "All projects using SourceForge.net project web 
> > services are required to display the SourceForge.net logo on their pages."
> > PS╡╡ : I can update the web site if you tell me where are the sources 
> > (on the SSH shell, on your workstation, somewhere else ?)
> 
> I've successfully followed the following pattern throughout last few years:
> 
> - Web pages are a part of the distribution tarball;
> - Changes to the website are committed to CVS;
> - There's a script on shell.sf.net that pulls the CVS content once in a
>   while (hourly is more than enough)
> 
> Benefits: changes become distributed, you don't have to log on to SF to make
> them; maintenance becomes nonexistent
> 
> Disadvantages: none that I can think of ;)
> 
> --vt
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] SF.net is awful tonight : info + mail bug report

[Vadim T. <vt...@fr...>]

According to Nicolas Huillard:

> PS=B2 : it also says that "All projects using SourceForge.net project w=
eb=20
> services are required to display the SourceForge.net logo on their page=
s."
> PS=B2=B2 : I can update the web site if you tell me where are the sourc=
es=20
> (on the SSH shell, on your workstation, somewhere else ?)

I've successfully followed the following pattern throughout last few year=
s:

- Web pages are a part of the distribution tarball;
- Changes to the website are committed to CVS;
- There's a script on shell.sf.net that pulls the CVS content once in a
  while (hourly is more than enough)

Benefits: changes become distributed, you don't have to log on to SF to m=
ake
them; maintenance becomes nonexistent

Disadvantages: none that I can think of ;)

--vt

[Owfs-developers] SF.net is awful tonight : info + mail bug report

[Nicolas H. <nhu...@gh...>]

I've uploaded 0.95 in the file release system (FRS) on SF.net, but it's=20
to slow right now (must be transatlantic network) to also submit the=20
following bug :

The files "type", "tempC" and "tempF" are in fact binary because they=20
are right-padded with ^@ (ASCII code 0x00) characters.
This is conform to the reported size of the file by "ls -l", but it=20
seems a little strange.
temp? decimals are also right-aligned in a 12 chars wide area (blanks at=20
the beginning of the file).
I doesn't seem to hurt my frist scripts, but it surely will hurt someone=20
someday...

NH

PS : the acceptable use states that "File releases may not be made=20
available via your project web space (unless you have received=20
permission in writing from SourceForge.net staff), with the exception of=20
nightly snapshots. File releases should be made available using the File=20
Release System."
PS=B2 : it also says that "All projects using SourceForge.net project web=
=20
services are required to display the SourceForge.net logo on their pages.=
"
PS=B2=B2 : I can update the web site if you tell me where are the sources=
=20
(on the SSH shell, on your workstation, somewhere else ?)

[Owfs-developers] 0.95 Submitted

[Paul A. <pal...@ea...>]

Minor fix-ups. Single threading. DS2502,5,6 support.

Perhaps Vadim can convert to CVS format.

unmount error message (harmless) will need to be fixed later. FUSE
doesn't return umount status, so wil have to copy that code.

Paul

[Owfs-developers] FUSE memory leak

[Paul A. <pal...@ea...>]

Following a bug report from Nicolas Huillard, I've confirmed impressive
memory grabbing by owfs.

It appears that the underlying FUSE userpace routines create threads but
don't kill them. They also seem to grab a significant amount of RAM for
each new thread.

I tried the simple FUSE example: hello. All it does is make a filesystem
with one file, called hello that prints "Hello World!".

After 10 reads from the file, hello had 11 processes, using ~3MB.

My solution, albeit inelegant, will be to force single-threading.

Since the 1-wire bust is probably the limitting step, I doubt any
true performance hit. 

Re: [Owfs-developers] df: `/path/to/1-wire/devices': Function not implemented

[Paul A. <pal...@ea...>]

Exactly right!

The next version will not give an error for 'df'

>df -a
...
/proc/fs/fuse/dev    0    0    0   -  /mnt/1wire


-- Paul

On Tue, 2003-09-02 at 10:00, Nicolas Huillard wrote:
> Paul Alfille wrote:
> 
> > Any idea what "function" needs to be implemented? fstat? 
> 
> Maybe "statfs, fstatfs - get file system statistics" ?
> Extract of man page :
> ------------------------------------------------------
> STATFS(2)                       Linux Programmer's Manual 
>                                                      STATFS(2)
> 
> NAME
>         statfs, fstatfs - get file system statistics
> 
> SYNOPSIS
>         #include <sys/vfs.h>
> 
>         int statfs(const char *path, struct statfs *buf);
>         int fstatfs(int fd, struct statfs *buf);
> 
> DESCRIPTION
>         statfs  returns  information about a mounted file system.  path 
> is the path name of any file within the mounted filesystem.  buf is a 
> pointer to a statfs structure defined
>         as follows:
> ------------------------------------------------------
> 
> The user command "stat" gives the following good results on either 
> device dirs or files (besides the date already stated) :
> 
> [nhuillard@palma:devices]$ stat DS9097U
>    File: "DS9097U"
>    Size: 0               Blocks: 0          IO Block: 4096   Directory
> Device: 9h/9d   Inode: 226         Links: 2
> Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
> Access: Thu Jan  1 01:00:00 1970
> Modify: Thu Jan  1 01:00:00 1970
> Change: Thu Jan  1 01:00:00 1970
> 
> [nhuillard@palma:devices]$ stat 01.7E54CC080000
>    File: "01.7E54CC080000"
>    Size: 0               Blocks: 0          IO Block: 4096   Directory
> Device: 9h/9d   Inode: 229         Links: 2
> Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
> Access: Thu Jan  1 01:00:00 1970
> Modify: Thu Jan  1 01:00:00 1970
> Change: Thu Jan  1 01:00:00 1970
> 
> [nhuillard@palma:devices]$ stat 10.629F54000800/tempC
>    File: "10.629F54000800/tempC"
>    Size: 32              Blocks: 0          IO Block: 4096   Regular File
> Device: 9h/9d   Inode: 240         Links: 1
> Access: (0444/-r--r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
> Access: Thu Jan  1 01:00:00 1970
> Modify: Thu Jan  1 01:00:00 1970
> Change: Thu Jan  1 01:00:00 1970
> 
> [nhuillard@palma:devices]$ stat 10.629F54000800/crc8
>    File: "10.629F54000800/crc8"
>    Size: 2               Blocks: 0          IO Block: 4096   Regular File
> Device: 9h/9d   Inode: 241         Links: 1
> Access: (0444/-r--r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
> Access: Thu Jan  1 01:00:00 1970
> Modify: Thu Jan  1 01:00:00 1970
> Change: Thu Jan  1 01:00:00 1970
> 
> 
> NH
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] Bug tracker

[Nicolas H. <nhu...@gh...>]

I have configured a bit the SF bug tracker, in the hope we could use it...

Categories :
	command-line tools (default assignement to nhuillard)
	owfs (default assignement to alfille)
	owhttpd (default assignement to alfille)
	owlib (default assignement to vtt)

Groups :
	up to v0.8
	v0.9x
	v1.0x (future)

I hope this is self-explanatory.

The bug tracker URL is 
https://sourceforge.net/tracker/?group_id=85502&atid=576393
You must be logged in to submit a bug (I'm tired of spam).
Support requests, Patches and Request For Enhancements are treated the 
same way as bugs, but I didn't configure them.
Paul should have received a bug from me (799186).

I'll receive every mail as CC, to check if the tracker works as expected.

NH

Re: [Owfs-developers] df: `/path/to/1-wire/devices': Function not implemented

[Nicolas H. <nhu...@gh...>]

Paul Alfille wrote:

> Any idea what "function" needs to be implemented? fstat? 

Maybe "statfs, fstatfs - get file system statistics" ?
Extract of man page :
------------------------------------------------------
STATFS(2)                       Linux Programmer's Manual 
                                                     STATFS(2)

NAME
        statfs, fstatfs - get file system statistics

SYNOPSIS
        #include <sys/vfs.h>

        int statfs(const char *path, struct statfs *buf);
        int fstatfs(int fd, struct statfs *buf);

DESCRIPTION
        statfs  returns  information about a mounted file system.  path 
is the path name of any file within the mounted filesystem.  buf is a 
pointer to a statfs structure defined
        as follows:
------------------------------------------------------

The user command "stat" gives the following good results on either 
device dirs or files (besides the date already stated) :

[nhuillard@palma:devices]$ stat DS9097U
   File: "DS9097U"
   Size: 0               Blocks: 0          IO Block: 4096   Directory
Device: 9h/9d   Inode: 226         Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: Thu Jan  1 01:00:00 1970
Modify: Thu Jan  1 01:00:00 1970
Change: Thu Jan  1 01:00:00 1970

[nhuillard@palma:devices]$ stat 01.7E54CC080000
   File: "01.7E54CC080000"
   Size: 0               Blocks: 0          IO Block: 4096   Directory
Device: 9h/9d   Inode: 229         Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: Thu Jan  1 01:00:00 1970
Modify: Thu Jan  1 01:00:00 1970
Change: Thu Jan  1 01:00:00 1970

[nhuillard@palma:devices]$ stat 10.629F54000800/tempC
   File: "10.629F54000800/tempC"
   Size: 32              Blocks: 0          IO Block: 4096   Regular File
Device: 9h/9d   Inode: 240         Links: 1
Access: (0444/-r--r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: Thu Jan  1 01:00:00 1970
Modify: Thu Jan  1 01:00:00 1970
Change: Thu Jan  1 01:00:00 1970

[nhuillard@palma:devices]$ stat 10.629F54000800/crc8
   File: "10.629F54000800/crc8"
   Size: 2               Blocks: 0          IO Block: 4096   Regular File
Device: 9h/9d   Inode: 241         Links: 1
Access: (0444/-r--r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: Thu Jan  1 01:00:00 1970
Modify: Thu Jan  1 01:00:00 1970
Change: Thu Jan  1 01:00:00 1970


NH

Re: [Owfs-developers] Coming features

[Nicolas H. <nhu...@gh...>]

Vadim Tkachenko wrote:
>>  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.

Seems like the owfs tree is to be split into a device tree and a 
configuration tree. Both can live in the same mount point.
We have to think a bit about what kind of configuration would be 
available. I think caching and polling are part of that (caching = 
accessing cached values for device properties ; polling = scanning the 
bus for alarming devices).

> 
> btw, is it possible to make owfs a part of a /proc subtree? It would be a
> natural place for it...

Like I2C... This will be possible when mounted by root and/or when coded 
as a kernel module...
I think this is a long-term goal.

btw², I've expressed two different possibilities for polling :
* the application is blocked on reading a (configuration) file, which 
will then return IDs of alarming devices (many at a time) => 1-wire 
polling is done at the FS level.
* the application constantly polls a directory containing links to 
device directories => 1-wire polling at the application level.
I don't know which one i sthe best one and which one is the easier to use.

> 
> 
>>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
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

-- 
Nicolas Huillard
Directeur Technique
GHS Solutions Interactives
38, rue du Texel - 75014 PARIS - FRANCE
Tél. 01 43 21 16 66 - Fax 01 56 54 02 18
E-mail : nhu...@gh... - URL : http://www.ghs.fr
--------------------------------------------------------------------
e-dition, la solution Internet pour la presse écrite et l'édition

Visitez notre site : http://www.e-dition.fr
--------------------------------------------------------------------
Nos dernières réalisations :

http://www.france-chimie.com
http://www.cnr.fr
http://www.esf-editeur.fr
--------------------------------------------------------------------

Re: [Owfs-developers] Coming features

[Vadim T. <vt...@fr...>]

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

[Owfs-developers] Coming features

[Paul A. <pal...@ea...>]

Working on the next version.

Since there aren't any show-stoppers, currently, I'll wait to upload
until it's feature complete.

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?

  B. Bus scanning (directory listing) will be locked.

  C. Each file (device property) has an internal value of static, stable
or volatile. Static values do not need bus activity. stable values are
set, or changed, under our control. Volatile are sensed or changing
values, and can only be queried. Locking will affect only stable and
valoatile values. These states will also be used for caching when/if
that's implemented.

2. I'd like to fix the mount/unmount errors.

3. I'd like to fix the 'df' error.

4. I need suggestions on other devices to support.

5. Preliminary thoughts on secure iButtons. How to pass a password in
filesystem symantics? My suggestion: Use memory.password as the
filename.

6. I plan to make owhttpd a multithreaded application since the locking
will be implemented.

7. Any suggestions on USB drivers?

Paul

Re: [Owfs-developers] df: `/path/to/1-wire/devices': Function not implemented

[Paul A. <pal...@ea...>]

Any idea what "function" needs to be implemented? fstat? 

Paul

On Mon, 2003-09-01 at 11:36, Nicolas Huillard wrote:
> Not very important, but df reports a 'Function not implemented' on the 
> OWFS mount...
> Since OWFS is not a disk-based FS, maybe it should work like /proc or 
> /dev/pts :
> * do not report it in df (I don't know if it's a FS attribute or if df 
> detects it) : see command 1
> * report all zeros when specifically asked for : see command 2
> 
> 
> ===================== command 1 =====================
> [nhuillard@palma:nhuillard]$ df
> Filesystem           1k-blocks      Used Available Use% Mounted on
> /dev/hda3             19365760  12752160   6613600  66% /
> /dev/hda1                15522      2175     12546  15% /boot
> df: `/home/nhuillard/mnt/1-wire/devices': Function not implemented
> ===================== end command 1 =====================
> 
> ===================== command 2 =====================
> [nhuillard@palma:nhuillard]$ df /proc
> Filesystem           1k-blocks      Used Available Use% Mounted on
> proc                         0         0         0   -  /proc
> ===================== end command 2 =====================
> 
> 
> NH
> 
> 
> PS : should we use SF's bug tracker or not ? If so, the web site pages 
> should have links to it (and a link to the project's summary page). I 
> can update these if you wish.
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] df: `/path/to/1-wire/devices': Function not implemented

[Nicolas H. <nhu...@gh...>]

Not very important, but df reports a 'Function not implemented' on the 
OWFS mount...
Since OWFS is not a disk-based FS, maybe it should work like /proc or 
/dev/pts :
* do not report it in df (I don't know if it's a FS attribute or if df 
detects it) : see command 1
* report all zeros when specifically asked for : see command 2


===================== command 1 =====================
[nhuillard@palma:nhuillard]$ df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda3             19365760  12752160   6613600  66% /
/dev/hda1                15522      2175     12546  15% /boot
df: `/home/nhuillard/mnt/1-wire/devices': Function not implemented
===================== end command 1 =====================

===================== command 2 =====================
[nhuillard@palma:nhuillard]$ df /proc
Filesystem           1k-blocks      Used Available Use% Mounted on
proc                         0         0         0   -  /proc
===================== end command 2 =====================


NH


PS : should we use SF's bug tracker or not ? If so, the web site pages 
should have links to it (and a link to the project's summary page). I 
can update these if you wish.

Re: [Owfs-developers] Reply-To header for owfs mailing list

[Vadim T. <vt...@fr...>]

According to Gregg C Levine:

> In fact, since I'm listed as a developer for this group, I would have done
> it. If I could figure out the Mailman's instructions. And then double
> billed Source Forge for it.

Don't blame SourceForge, it's all about the way Mailman is configured. It's
a, should I say, religious preference - there are arguments pro and con
setting Reply-To: header.

> Gregg C Levine han...@wo...

--vt

RE: [Owfs-developers] Reply-To header for owfs mailing list

[Gregg C L. <han...@wo...>]

Hello (again) from Gregg C Levine
Actually go ahead. I'm more annoyed at a certain UK based company
actually causing a gaggle of messages between, Paul and I, and the
regular One-Wire group. It seems they don't even care that their MTA
is a broken one. In fact, since I'm listed as a developer for this
group, I would have done it. If I could figure out the Mailman's
instructions. And then double billed Source Forge for it.
-------------------
Gregg C Levine han...@wo...
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."=A0 Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )



> -----Original Message-----
> From: owf...@li...
[mailto:owfs-developers-
> ad...@li...] On Behalf Of Vadim Tkachenko
> Sent: Friday, August 29, 2003 5:25 PM
> To: owfs
> Subject: [Owfs-developers] Reply-To header for owfs mailing list
>=20
> Hello,
>=20
> I hope noone would mind if I change the Reply-To: option in the
mailing list
> admin to send the replies to the list. I assume most of you are as
annoyed
> with multiple copies of the same message walking around as I am ;)
>=20
> --vt
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] Reply-To header for owfs mailing list

[Vadim T. <vt...@fr...>]

Hello,

I hope noone would mind if I change the Reply-To: option in the mailing list
admin to send the replies to the list. I assume most of you are as annoyed
with multiple copies of the same message walking around as I am ;)

--vt

RE: [Owfs-developers] CVS: owhttpd module added

[Alfille, P. H.,M.D. <PAL...@PA...>]

 Great work, Vadim!

1. I'm not sure fuse can be easily separated. I just looked at the code. At
least the /lib and /include directories will have to be included. /kernel and
/example are not needed.

2. There is a lot of shared code between owfs and owhttpd. 90% or so. That's
what makes the developement so easy!

3. src/c,include and man sounds fine. 

Thanks for attacking this project.

Paul

-----Original Message-----
From: Vadim Tkachenko
To: owf...@li...
Sent: 8/29/03 4:13 PM
Subject: [Owfs-developers] CVS: owhttpd module added

Hello,

I've just created a 'owhttpd' module in the SourceForge CVS.

Since I don't have much time at the moment, and didn't want to disrupt
existing code too much, I've made some shortcuts:

- include/autoconf.h.in shouldn't really be there, but autoheader
complains
  about missing template: HAVE_SOCKLEN_T

- I'd propose a slight directory structure change, just for consistency:

	src/c - C files
	src/include - includes
	src/man - manual file[s]
	
Updating the build structure with Automake would be a nice addition
(make
all check install uninstall man ...), I'll take care of it a little bit
later.

I also plan to add two more modules to CVS:

owlib - for the stuff common between owhttpd and ow, if any
owfs - for the code currently distributed as 'ow'

This, of course, with Paul's approval.

I'd also propose to make a default 'make install' target location to be,
say, /opt/OWFS - this way, all the modules can reuse common directory
subtree. This, however, may conflict with the layout proposed by...
forgot
the name, it was a standards body that defines a filesystem layout. Have
a
link somewhere, will find and post.

What I'd like to see happening (again, will try to make it happen) is a
separation of the fuse code and owfs code. There are several reasons to
do
this:

- FUSE is an independent project. Even though it progresses at a slow
pace, it
  is still separately developed and maintained. It would be a royal pain
to
  cut out the FUSE structure out of OWFS structure and merge in a new
one
  every time there's an upgrade in FUSE that mandates OWFS upgrade.
  
- With FUSE being just an OWFS dependency, it'll be much easier to
  understand what OWFS is (for newcomers) and maintain it.
  
- If there's an alternative to FUSE someday, it'd be much simpler to
create
  an abstraction layer between OWFS code and dependencies, and provide
an
  ability to select the underlying library with a simple configure time
  option.

I hope it is possible to just include FUSE as a dependency - Paul, does
it
make sense now?

--vt


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Owfs-developers mailing list
Owf...@li...
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] CVS: owhttpd module added

[Vadim T. <vt...@fr...>]

Hello,

I've just created a 'owhttpd' module in the SourceForge CVS.

Since I don't have much time at the moment, and didn't want to disrupt
existing code too much, I've made some shortcuts:

- include/autoconf.h.in shouldn't really be there, but autoheader complains
  about missing template: HAVE_SOCKLEN_T

- I'd propose a slight directory structure change, just for consistency:

	src/c - C files
	src/include - includes
	src/man - manual file[s]
	
Updating the build structure with Automake would be a nice addition (make
all check install uninstall man ...), I'll take care of it a little bit
later.

I also plan to add two more modules to CVS:

owlib - for the stuff common between owhttpd and ow, if any
owfs - for the code currently distributed as 'ow'

This, of course, with Paul's approval.

I'd also propose to make a default 'make install' target location to be,
say, /opt/OWFS - this way, all the modules can reuse common directory
subtree. This, however, may conflict with the layout proposed by... forgot
the name, it was a standards body that defines a filesystem layout. Have a
link somewhere, will find and post.

What I'd like to see happening (again, will try to make it happen) is a
separation of the fuse code and owfs code. There are several reasons to do
this:

- FUSE is an independent project. Even though it progresses at a slow pace, it
  is still separately developed and maintained. It would be a royal pain to
  cut out the FUSE structure out of OWFS structure and merge in a new one
  every time there's an upgrade in FUSE that mandates OWFS upgrade.
  
- With FUSE being just an OWFS dependency, it'll be much easier to
  understand what OWFS is (for newcomers) and maintain it.
  
- If there's an alternative to FUSE someday, it'd be much simpler to create
  an abstraction layer between OWFS code and dependencies, and provide an
  ability to select the underlying library with a simple configure time
  option.

I hope it is possible to just include FUSE as a dependency - Paul, does it
make sense now?

--vt

Re: [Owfs-developers] LCD over owfs

[Nicolas H. <nhu...@gh...>]

Alfille, Paul H.,M.D. wrote:
> Hmm...
> 
> As I recall, Marc Nichols / Shawn Silverman's device uses a proprietary Java
> driver. Actually, since OWFS is entirely in user space, that isn't truly a
> problem. I'm not sure how you will get your input, keyboard? Is this a
> console/terminal replacement?
> 
> Louis Swart's driver controls the HD44780 chip and he mentions screen sizes
> up to 20x4 or 40x2.

In order for this to be really useful, the gui need :
* a reasonably large screen : I have a 40x24 spare LCD... I think 20x4 
is too small for a standard computer application. With this kind of 
display, the application must be specific.
* a few keys : up/down/left/right (these are used as-is by lynx, for 
instance, in an relatively obvious way), + ok/cancel (or enter/escape) 
for a few needs. This is the kind of input device every mobile phone have.
* a terminal escape codes interpretation software that allow grey 
levels, inverse video, etc (much like HD44780 does).
* a termcap (in the Unix way) database entry that allow termcap-enabled 
applications (curses, etc.) to send terminal espace codes in an 
application-standard way.
* an application that can make use of only a few keys...

My alternative is to use an old Psion 5 with it's large touch screen, 
connect it through either an ethernet compact-flash card, or through a 
serial PPP link to an always-on PC (the 1-wire master ?). The last one 
is simply use a real computer, with all the related problems (noise, 
size, time to load, etc...). These alternatives are simply not fun...

NH

> 
> Paul
> 
> -----Original Message-----
> From: Nicolas Huillard [mailto:nhu...@gh...]
> Sent: Friday, August 29, 2003 6:36 AM
> To: 1-wire dev; owfs-developers
> Cc: lc...@ge...
> Subject: Re: [Owfs-developers] LCD over owfs
> 
> 
> Having read the specs for the OWFS to LCD related stuff, I doubt my 
> vision could be ever implemented...
> 
> Marc Nicholas and Shawn Silverman have implemented an LCD connected to a 
> 2408, as I remember (Marc's site is still empty after his crash, so I 
> can't check) : can one of them explain how the software interface work ? 
> Is the connected LCD based on standard HD44780 modules ?
> 
> What I describe below implies that the lynx process (text-only HTTP 
> browser, allowing me to only develop a single user interface, usable on 
> LAN or internet computers, or directly on the always-on LCD) is linked 
> via it's STDIN/OUT file descriptors to always-open sockets on the OWFS, 
> ie. continuous output to the file descriptor will send a continuous flow 
> of data on the 1-wire network.
> This continuous flow must not block other traffic... I think that's the 
> problem there...
> 
> Comments on that ?
> 
> NH
> 
> PS : lynx is just a sample app. one can replace it by any ncurses 
> text-only application, provided the application can work completely with 
> the only few keys near the LCD...
> 
> Nicolas Huillard wrote:
> 
> 
>>Paul Alfille wrote:
>> > LCD support is next.
>>
>>Cool : I'd love to run lynx on my 40x24 LCD screen, with a few keys to 
>>travel the pages.
>>    $ TERM=vt100 TERMCAP=...li#24:co#40... \
>>        attach-tty --stdin 1-wire/[2408]/sensed \
>>        --stdout 1-wire/[2408]/PIO \
>>        --mode 4bits_in_4_bits_out \
>>        --stderr /var/log/owfs-tty.log \
>>        lynx http://localhost/
>>attach-tty is a imaginary but maybe already existing glue, that create a 
>>tty from a read-only file (STDIN) and a write-only file (STDOUT), adding 
>>a little environment and signal handling, that run the given command and 
>>make sure to re-run it if it ever exits...
>>Maybe I'm not dreaming, despite the current time in the night at GMT+2.
>>
>>NH
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: VM Ware
>>With VMware you can run multiple operating systems on a single machine.
>>WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
>>at the same time. Free trial click 
>>here:http://www.vmware.com/wl/offer/358/0
>>_______________________________________________
>>Owfs-developers mailing list
>>Owf...@li...
>>https://lists.sourceforge.net/lists/listinfo/owfs-developers
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers