pppd namespace pollution

[Ralf Corsepius]

Am Fre, 2003-03-21 um 09.46 schrieb Valette Eric:
> Till Straumann wrote:
> > Here are some symbols defined and globally exported by pppd.
> > I didn't even include things like "link_down", "exit_code", "write_char"
> > just the worst ones:
> > 
> >    debug output modem netmask protocols status user
> >    line character clean echo quiet report frame magic
> >    privileged die hostname ifname phase progname
> >    linep lock temp2 fcs demand framelen framemax
> >    crtscts devnam getword holdoff initializer inspeed
> >    kdebugflag linkname lockflag maxconnect maxfail
> >    nodetach notty passwd persist updetach welcomer
> >    print_string relock slprintf strlcat strlcpy
> >    unlock vslprintf read_packet setdtr sys_cleanup
> >    sys_close sys_init wait_input baud_rate detached
> >    devstat do_callback hungup novm prepass
Thanks.
 
> > IMHO, this is unacceptable for RTEMS-4.6.
ACK.

>  Couldn't you at least create a
> > 'configure' option '--enable-pppd' as for the rdbg package, please?

I prefer taking pppd out of librtemsbsp into a separate library and to
require users to explicitly link with it instead.

> > So
> > people who want to pollute their namespace have to explicitely ask for it?

I have to repeat what I said before, though pppd pollutes rtems's
namespace, if you actually suffer from problems with it, your
application probably also is polluting the namespace.

> > Sorry for being a pain but this causes a lot of trouble for me.
If you don't need pppd, you can temporarily work around the issue
yourself, by taking out pppd from
c/src/libnetworking/wrapup/Makefile.am.

> > -- Till.
> > 
> > PS. Ideally, all of those add-on applications should be unbundled
> > or at least made 'configure options'.
> > 
> > Here are some goodies from the webserver: "error",
This name's got to be changed.

> > "trace", "dirname"
Bummer, I'd have to look into these. 

According to the Linux manpages, 
* dirname is a SUSv2 function (I'd have to check what SUSv3 says about
it.
* trace is part of ncurses - So I'd call this an application bug.

> While I agree with the namespace polution problem, I think its easy to 
> understand why things are like that :
> 	- The sources for the program originally come from system where 
> namespace polution is not a problem as each process has its own address 
> space,
> 	- If you modify all the globals, tracking changes  of the original 
> packages and apply them becomes a nightmare,
Exactly. That's why I say, that renaming globals can only be considered
as a workaround and a systematic solution is needed, instead.

> So, at least, there is a tradeoff between name space polution and 
> easiness to apply original packages changes. So at least package 
> maintainer (if such a notion exist in rtems), should be prepared to have 
>   a lot more work if such changes are commited...
The actual problem is detecting such conflicts.

Ralf