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 06:57, David N. Welton wrote:
> "Gary D. Thomas" <gary.thomas@mind.be> writes:
> 
> > 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.
> 
> I realize that, and I greatly appreciate the time you guys dedicate to
> answering questions.  I'm not paying anyone - I'm slowly but surely
> developing an app that will be the basis for an article on eCos, but
> not making any money myself on it other than that.  Maybe the app will
> even be an interesting demo for others to use - it will be free
> software.  I apologize if I came across as nagging - it wasn't my
> intention.

Fair enough.

> 
> [ snip ]
> 
> > > Maybe I am using eCos incorrectly then, because that's what
> > > happens:
> 
> > > I have:
> 
> > > BLOCK_DEVTAB_ENTRY(cyg_io_floppydev,
> > > 		   "/dev/fd",
> 
> [ snip ]
> 
> > > 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?
> 
> Oh it was just printing it out, and I noticed it was blank, and so
> investigated it, and thought the behavior might not be correct.
> 
> It's nothing I really need to depend on, but if it were my own
> software I think I would either:
> 
> 1) Make it return a real name.
> 
> or
> 
> 2) Document the existing behavior - "it's a feature, not a bug".
> 
> I would be willing to contribute a documentation patch as well once I
> am sure I understand the underlying thought behind these functions.  I
> didn't find this either in the on-line documentation, or in my copy of
> Anthony Massa's book.
> 
> Restating: it works as it does in order that the *name passed to the
> lookup function can be added to a 'base name' known to the driver to
> create a full name?

Yes, that's the intention, perhaps not very well documented or 
articulated (I wrote that code oh so long ago...)

> 
> > > On another topic... how does one calculate ticks per second?
> 
> [ snip ]
> 
> > Look at the calculations in "tm_basic.cxx" - it shows how to convert
> > ticks and raw system clocks into usable time values.
> 
> Thankyou, that works.

Great.

> 
> Thanks again for your time, I do appreciate it.  If any of you folks
> ever happen through Italy, it would be my honor to take you out to a
> nice dinner in the Colli Euganei(*) , but that's about all I can offer at
> this point.

Too bad we didn't have this conversation a couple of months ago, just 
as I was on holdai for two weeks (in June) in Italy :-)

Take care.

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