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?


David N. Welton wrote:
"Gary D. Thomas" <gary.thomas@mind.be> writes:


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


How about something along these lines:

Although it may need a bit more glue, you can add this to io/common/current/doc/io.sgml at the end of the "how to write a driver" chapter (but before the how to write a serial hardare interface driver section) and send the patch (cvs diff -u) to ecos-patches. Thanks!


  <para>
    The <parameter>**tab</parameter> parameter holds a pointer to the
    memory location of the devtab entry.  This indirection allows the
    device driver author to create a new devtab entry in the lookup
    function, in order to provide for pluggable devices, and devices
    where multiple instances are possible.
  </para>
[snip]
Of course, it needs some tweaking, as I'm not %100 sure on how **tab
might be used, but adding that would be an improvement, especially WRT
to the name parameter and it's "confusing" behavior.

:-). I think it's accurate. The idea is that something could return a completely different (perhaps artificially created i.e. not found in __DEVTAB__) handle pointing to a devtab entry for future accesses. Different cyg_devtab_entry_t means different function pointers etc. so it makes it quite generic. In practice, without a "cyg_io_close" this has some limitations.


I think your description is accurate though.

Jifl
--
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


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