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: Porting of PPP to the eCos operating system


Erik Aagaard Knudsen wrote:
> 
> As told in a previous mail (Fri. 23 nov. 2001) I am in the process of
> porting pppd (v. 2.3.5) to eCos. I have ported the driver part (not tested
> yet though) and have started porting the application part. There are a few
> problems, which I would very much like to have comments on.
> 
> One is the problem of global variables and functions (there are many in
> pppd). I don't want to pollute the eCos namespace with all these names (to
> avoid the risk of name clashes with ports of other programs).

Jurica's idea of using C++ namespaces is interesting. An alternative would
be to postprocess the .o files using objcopy, and rename the symbols after
they have been built. That's quite yucky though.

> The other is the problem of independent incarnations of pppd. This gives a
> problem with static variables, which cannot be independent across
> incarnations in eCos.
> 
> I intend to solve the problem with global functions by allocating a global
> structure inside which the names are defined.

Fair enough.
 
> And I intend to solve the problem with incarnations by utilizing the means
> in eCos for making functions thread safe. I will dynamically allocate a
> structure inside which global variables are defined and I will also
> dynamically allocate a structure for each file inside which static variables
> are defined.

You could have one structure, that contained all the variables, global and
all the file local ones. And then just map the old names to the new
structure members using the preprocessor (which you were probably intending
to do anyway).
 
> Pppd read authentication information from two files. I intend to implement
> these files as global structs.

Yes, auth info is small enough just to stay as structs.
 
> Pppd uses the Unix concept of process id, this is not supported in eCos and
> is therefore removed.

Or you could add dummy setuid etc. calls that do nothing, thus perturbing
the sources less.
 
> Pppd uses Unix signals (across processes). Processes are not supported in
> eCos and this is therefore removed.

Is this just SIGHUP for children? If so, then sort of fair enough - it's
maybe not unreasonable to send SIGHUP to yourself.
 
Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]