On Tue, Sep 08, 2015 at 11:53:33PM +0100, KatolaZ wrote: > On Tue, Sep 08, 2015 at 09:40:12PM +0200, Edward Bartolo wrote: > > Hi all, > > > > I think, a simple way to avoid the backend having to call external > > programs like ifup and ifdown, is to use code belonging to these > > programs as it they were functions. This means, their code would be > > used like this: > > > > Suppose int main(int argc, char * argv[]) is the main function for > > ifup. The main function's name would be changed like this, and the > > other code belonging to ifup would be used. > > > > int ifup_main(int argc, char * argv[]); > > > > If I am correct, this should allow the backend to avoid having to use > > execl to call ifup or ifdown or whatever other external program. > > > > So you are basically suggesting that your backend should swallow ifup, > ifdown and who knows how many other executables, just because you > don't want to call execl? No matter where the code of ifup lives, it > requires root privileges to do anything relevant, so having it inside > your backend won't avoid having at least one executable with SUID set > (the backend), or launched by init as a daemon (and thus owned by > root). > > I still don't see why on Earth you want to "avoid having to use execl > to call ifup". Esecuting an existing command-line program into a child > is exactly what the wide majority of all the ncurses and GUIs > frontends (not just for network config) actually do. This is the > normal way of doing things. > > "Incorporating code from other programs" == "bloating your little > software".
Which has implications for maintainability. Your code won't benefit from bug fixes made to ifup. Except, of course, the ifup code is a thin command-language wrapper around a shared library or system call that does the actual work; then just calling the shared library or system call is OK. -- hendrik _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng