This is the mail archive of the
ecos-patches@sourceware.org
mailing list for the eCos project.
AW: [PATCH 1] utility functions for using the extended VV interface to FIS
- From: "Neundorf, Alexander" <Alexander dot Neundorf at jenoptik dot com>
- To: "Andrew Lunn" <andrew at lunn dot ch>
- Cc: <ecos-patches at ecos dot sourceware dot org>, "Gary Thomas" <gary at mlbassoc dot com>
- Date: Mon, 8 Jan 2007 12:39:49 +0100
- Subject: AW: [PATCH 1] utility functions for using the extended VV interface to FIS
> Von: Andrew Lunn [mailto:andrew@lunn.ch]
>
> On Mon, Jan 08, 2007 at 08:48:21AM +0100, Neundorf, Alexander wrote:
> > What's actually the exact difference between libextras.a
> > and the normal lib ? I just copied this from somewhere.
>
> Object files placed into libextra.a are always included in the
> image. The linker is not allowed to throw away symbols that are not
> used. When linking with libtarget.a, the linker will only pull in
> symbols that it needs.
>
> You need to use libextra.a for device drivers. Accessing the device
> drivers via the filesystem means there is no direct reference to
> symbols in the driver, and so the linker would not include the device
> driver in the image if it was in libtarget.a.
Thanks for the explanation.
> > > +int fis_find_entry(const char* name, struct
> fis_table_entry* entry)
> > > +{
> > >
> > > Should this be static? It looks like it is just a helper
> > > function for fis_get_entry().
> >
> > It is used also in the filesystem implementation, that's why I
> > removed the static.
>
> O.K. it just looks like the API is not as clean as it could be. You
> seem to have two very similar functions.
fis_get_entry() is a thin wrapper around fis_find_entry(). Before I split the utility functions and the filesystem into two files, fis_find_entry() was static.
So for the "exported" function I should use the "cyg_fis_" prefix ?
Bye
Alex