This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Multiple PPP interfaces in single unit
On Wed, 2004-07-28 at 16:30, Nick Garnett wrote:
> Øyvind Harboe <oyvind.harboe@zylin.com> writes:
>
> > On Wed, 2004-07-28 at 15:45, Nick Garnett wrote:
> > > Øyvind Harboe <oyvind.harboe@zylin.com> writes:
> > >
> > > >
> > > > Seperate C++ namespace for each PPPD?
> > > >
> > > > - Write a pppd2.h file
> > > >
> > > > ---
> > > > namespace PPPD2;
> > > > ---
> > > >
> > > >
> > > > - Compile PPPD twice, but second time add option:
> > > >
> > > > g++ -include pppd2.h ...
> > >
> > > I have considered several ways around the problem, but not even in my
> > > most fevered imaginings did I come up with that one :-)
> > >
> > > This would end up duplicating the code and the data. Not a good idea.
> >
> > Currently we have no solution. Thats not good either :-)
>
> I don't believe *we* need a solution. It's not something that eCos is
> intended to do at present. If you want to try this out for your own
> application then go ahead, but it is not what I would consider a good
> solution and I would not want to see it added to the repository.
Fair enough.
Maybe I'll take it for a spin.
> > If this solution requires no changes to the code, makes updates easy and
> > incurs no overhead for the common case(single PPPD)...
> >
> > Slightly increased code size(only PPPD code is duplicated, not the rest
> > of eCos) and probably not very much more ram usage.
> >
> > Perhaps you know something I don't, but it seems like a very economical
> > solution.
>
> The PPP code is currently about 80k text plus 16k data. Of that the
> PPPD-derived part is the by far the largest. If we subtract about 20k
> for the TCP/IP-resident parts, that's still 70k+ that will be
> duplicated.
Thats kinda what I expected. In my particular configuration, code size
is cheap and RAM is expensive, so I'm more concerned about whether this
approach will increase RAM usage.
More generally, code size should be optimised as well..
However, the real killer would be if I lost the ability to merge in
bug-fixes.
> > Now, the next question is whether it will work out of the box...
>
> I think that there will be lots of obscure issues to trip you up if
> you try to do it this way.
Beauty is useful as guidance when designing and I do find this approach
"ugly". :-)
But beauty aside, please share any specific issues you can think of.
I'm especially concerned about stuff that does not show up at compile
time.
--
Øyvind Harboe
http://www.zylin.com
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss