Sure.
On Wednesday 22 June 2005 05:07 pm, Christian Magnusson wrote:
> Almost done now... Everything seems to be working with offset and
> direct_io option. I'll make some more tests from work tomorrow and
> I'll check in the changes from there.
>
> I'm a bit annoyed about the error functions though...
> LEVEL_CALL() will print the errno-message, and it's very common
> that errno is stuck with an error message since it's not cleared
> on successful system-calls... Only set when error.
>
> This means that an "Interupted systemcall" (-EINTR) from UT_delay()
> is set very often for me, and it stays there forever basically.
> I have cleared errno in some locations now, like in OW_ParsedName(), but
> I'm not very comfortable with it though.
>
> Is it really common to have debug-functions which always return the
> errno-message? Couldn't this usually be added by '"%s", strerror(errno)'
> to the LEVEL_CALL() argument and not always be printed?
> Just a thought... :)
>
> /Christian
>
> On Wed, 2005-06-22 at 16:18, Christian Magnusson wrote:
> > I noticed I had to fix all those FS_r_all and the array-stuff too, just
> > to support offset for all files. I'm almost done and will checkin the
> > other changes later tonight or tomorrow morning.
> >
> > /Christian
> >
> > On Wed, 2005-06-22 at 14:23 +0200, Christian Magnusson wrote:
> > > The problem is basically that offset wasn't supported in ow_read.c
> > > for all types.
> > >
> > > Two system calls where made when reading 10.061847000800/temperature.
> > > First read return 15 bytes, and the second call was reading from
> > > offset=15 and returned errno=-ENOTAVAIL according to the owfs source.
> > > I have added offset-support now and it just return 0 if
> > > offset==filesize since there are no more bytes to read.
> > >
> > > I noticed some other really nasty things with the char-buffer "c" in:
> > > FS_output_unsigned( unsigned int value, char * buf, const size_t size,
> > > const struct parsedname * pn ) {
> > > int suglen = FileLength(pn);
> > > char c[suglen+2];
> > > ....
> > > }
> > >
> > > After returning from the function, the variable "const size_t size"
> > > was corrupted! I have changed those buffers to mallocs instead just
> > > to get rid of the problem.
> > > Adding some debug-output in FS_parse_read() before and after the
> > > call to FS_output_unsigned() will show the problem.
> > >
> > >
> > > It's also possible to use fseek() now when reading from the files
> > > if somebody wants...
> > >
> > >
> > > if(!(fp = fopen("/var/1wire/statistics/read/bytes", "r")))
> > > exit(0);
> > > rc = fseek(fp, 8, SEEK_SET);
> > > if(rc) {
> > > printf("fseek returned %d\n", rc);
> > > exit(0);
> > > }
> > > pos = 0;
> > > do {
> > > if((sz = fread(&tmp[pos], 1, 1, fp)) <= 0) {
> > > tmp[pos] = 0;
> > > break;
> > > }
> > > pos++;
> > > } while(1);
> > > fclose(fp);
> > >
> > >
> > > /Christian
> > >
> > > On Wed, 2005-06-22 at 09:40 +0200, Christian Magnusson wrote:
> > > > I noticed some strange behavior with the direct_io flag in fuse. My
> > > > "cat" return an errno "Cannot assign requested address" after reading
> > > > a sensor, but "tail" works ok.. I haven't figured out why yet, but
> > > > it's something to fix.
> > > >
> > > > /Christian
> > > >
> > > > > owfs --fuse_opt="direct_io" -P /var/run/owfs.pid -s
> > > >
> > > > 192.168.1.10:3002 /var/1wire/
> > > >
> > > > > cat /var/1wire/10.061847000800/temperature
> > > >
> > > > 25.1875cat: /var/1wire/10.061847000800/temperature: Cannot
> > > > assign requested address
> > > >
> > > > > tail /var/1wire/uncached/10.061847000800/temperature
> > > >
> > > > [EMAIL PROTECTED] ~]#
> > > >
> > > > > cat /var/1wire/10.061847000800/temperature
> > > >
> > > > 25.1875cat: /var/1wire/10.061847000800/temperature: Cannot
> > > > assign requested address
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
