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 (Friday, January 04, 2002 09:32):
>
> 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).
>
> 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.
>


The first thing that came to my mind when reading this was use of C++ and
migrating to 'namespace' (I am just thinking loudly).
This seems quite easy and straightforward. However, this should be
investigated deeper to see if there are some side-effects of using
'namespace' in pppd code.
Of course, this does not solve the problem of independent pppd incarnations.



> 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.
>
> For each file there will be a (global) initialization function, which
> initializes pointers to global functions in the above mentioned global
> structure.
>
> For each file there will also be a constructor, which allocates and
> initializes memory for static variables for this file.
>
> And finally for each file there will be a destructor which deallocates
> memory for static varibales for this file.
>
> As far as I can see then this solves most problems. The procedure may seem
> complicated and indeed the two problems that it solve are pervasive and
> necessitates a great number of corrections to the pppd code. The
> corrections
> are trivial though and easy to perform. In case data accessed in this way
> are used extensively, then of course performance will suffer, but this is
> not the case in pppd.
>
> Perhaps I should note that I am well avare of the possibilities
> for loading
> elf images into eCos. It seems though that this is too heavy
> ammunition for
> eCos. I think perhaps you would be better off using another
> operating system
> (like uClinux) in that case.
>
>
> I do not intend to implement demand dialing.
>
> Pppd read authentication information from two files. I intend to implement
> these files as global structs.
>

eCos has the filing system and reading necessary information from a file
(i.e. ROMFS) should be easy.
Nevertheless, implementing a global structure is good as an alternative for
systems without FS.

> Pppd uses the Unix concept of process id, this is not supported
> in eCos and
> is therefore removed.
>
> Pppd uses Unix signals (across processes). Processes are not supported in
> eCos and this is therefore removed.
>
> The following options for pppd are not ported: call, connect, disconnect,
> init, lock, activefilter, demand, logfd, logfile, login, nolog, welcome,
> xonxoff.


IMHO, 'xonxoff' could be an interesting option for embedded systems. Also,
'logfile'  sounds good for devices with file system.
In addition, chat utility seems quite interesting for porting. It would make
modem initialization and connection/disconnection easier.


Best regards,
Jura



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