This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problem in cyg_io_compare?


This seems to have fallen through the cracks on -patches, so I'll
repost here.

> > Without it, setting *ptr to n1 is just going to leave *ptr hanging
> > off the end of the 'real' n1, according to my reading of the code.
> > This fix seems to make things work for me (i.e. the name parameter
> > to my device's lookup function actually contains something valid).

[ Patched function included at end of message. ]

> It's not clear why you think there is an error here.  The code looks
> right to me and the only time that *ptr could point off the end of
> the string would be if n1 pointed to a string which matched 100% n2.

Maybe I am using eCos incorrectly then, because that's what happens:

I have:

BLOCK_DEVTAB_ENTRY(cyg_io_floppydev,
		   "/dev/fd",
		   NULL, /* Not dependant on other devices. */
		   &cyg_io_floppy_ops,
		   floppy_init,
		   floppy_open,
		   (void *)NULL); /* No private information.  */

and then:

    if (cyg_io_lookup("/dev/fd", &fh) != ENOERR) {

Maybe that's not the best way to do things?

If the two strings are equal, cyg_io_compare returns true, but the
'name' pointer in my lookup function is garbage because *ptr is set
off the end of n1 in the compare function.  This patch fixes that by
storing the original location of 'n1' to later put in '*ptr'.

I think that in any case, returning a bogus address should be avoided
in one way or another.

On another topic... how does one calculate ticks per second?

# Real-time clock constants.
# The RTC period is based on the clock input
# to the 8254, which is 1193180 Hz.
# CYGNUM_HAL_RTC_PERIOD is set for 100 ticks
# per second.

Is it just a coincidence that CYGNUM_HAL_RTC_DENOMINATOR is 100?  My
.ecc file has:

cdl_option CYGNUM_HAL_RTC_PERIOD {
    # Calculated value: 11932
    # Flavor: data
    # Current_value: 11932
};

And of course 1193180 / 11932 gives me about the right number, but the
top number is a 'magic number' and not to my knowledge defined
anywhere.

Thanks once again for your time,
-- 
David N. Welton
   Consulting: http://www.dedasys.com/
     Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
   Apache Tcl: http://tcl.apache.org/


static bool
cyg_io_compare(const char *n1, const char *n2, const char **ptr)
{
    char *tmp;
    tmp = n1;
    while (*tmp && *n2) {
        if (*(tmp++) != *(n2++)) {
            return false;
        }
    }
    if (*tmp) {
        // See if the devtab name is is a substring
        if (*(n2 - 1) == '/') {
            *ptr = n1;
            return true;
        }
    }
    if (*tmp || *n2) {
        return false;
    }
    *ptr = n1;
    return true;
}

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]