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?


On Thu, 2003-07-31 at 03:23, David N. Welton wrote:
> This seems to have fallen through the cracks on -patches, so I'll
> repost here.
> 

Sorry, but remember that answers on these lists are voluntary.  In other
words, you're not paying for answers or response from them - or if you
are, you should be getting that service directly from whomever you
are paying.

> > > 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.

But it's not a bogus address - it points to a residual string, which
in your case will be "".  The idea is that you could have this call
    if (cyg_io_lookup("/dev/fd/2", &fh) != ENOERR) {
and if your DEVTAB entry said "/dev/fd/", then cyg_io_compare will match
and the cyg_io_lookup will call your device lookup with name_ptr 
pointing at the string "2", thus letting your driver support multiple
devices with a single DEVTAB entry.

How were you expecting it to work?  What does your device driver
"lookup" function do with the name pointer?

> 
> 
> 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.

Look at the calculations in "tm_basic.cxx" - it shows how to convert
ticks and raw system clocks into usable time values.

-- 
Gary D. Thomas <gary.thomas@mind.be>


-- 
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]