Board index FlightGear Development

Steps for Removing subsystems in flightgear source code

FlightGear is opensource, so you can be the developer. In the need for help on anything? We are here to help you.
Forum rules
Core development is discussed on the official FlightGear-Devel development mailing list.

Bugs can be reported in the bug tracker.

Steps for Removing subsystems in flightgear source code

Postby Divi » Mon Aug 31, 2015 6:35 pm

If we want to remove an subsystem from the flight gear source code, without leaving any trace of it.. What are the essential steps ?(for example, if the sound update has to be removed, what are steps to be followed).
Divi
 
Posts: 34
Joined: Wed Jul 09, 2014 9:06 am
Version: 3.0
OS: Ubuntu 12.04

Re: Steps for Removing subsystems in flightgear source code

Postby Hooray » Mon Aug 31, 2015 9:45 pm

Divi wrote in Mon Aug 31, 2015 6:35 pm:If we want to remove an subsystem from the flight gear source code, without leaving any trace of it.. What are the essential steps ?(for example, if the sound update has to be removed, what are steps to be followed).


See the following links, and the corresponding patches/topic branches - most of this is based on plans/work announced by FlightGear core developer James Turner (Zakalawe on the forum), who has been working on making the FlightGear subsystem architecture less monololithic and increasingly modular as part of his Reset/re-init work, as well for better support for regression testing (e.g. using valgrind, gdb etc) by working towards a "headless" mode, with some subsystems (e.g. graphics) entirely disabled: http://wiki.flightgear.org/FlightGear_Headless


The links above will provide the necessary background to better understand the main issues, and motivation, behind supporting more a modular subsystem architecture, where most subsystems can be made entirely optional.

Most of this work dates back to discussions that James Turner and Melchior Franz (former Nasal maintainer) had years ago, to allow FlightGear to start up with fewer mandatory subsystems and move towards an incremental boot sequence with explicit and better-formalized run-time dependencies. Orginally, the main idea discussed by James and Melchior was supporting "run-levels" analogous to Unix/Linux run-levels: http://wiki.flightgear.org/FlightGear_Run_Levels

Meanwhile, the main motivation was to provide a Canvas GUI front-end by establishing a safe subset of the FG main loop, including Nasal support: http://wiki.flightgear.org/FGCanvas

You will find that much/most of this is available in a corresponding topic branch, which supports a script-able initialization sequence, as per Zakalawe's original idea: http://wiki.flightgear.org/Initializing_Nasal_early

Image

In the above screen shot, most subsystems can be turned off entirely, without having to hard-code anything, i.e. they can also be turned on dynamically. With Nasal/Canvas being among the very first subsystems to be made available.

Here's a screen shot showing a subset of the remaining subsystems still active:
Image

Description: The screen shot is showing the performance monitor in a patched version of FlightGear 3.2 where subsystem initialization is made better configurable and increasingly optional by allowing subsystems to be explicitly disabled/enabled during startup. Decoupling internal subsystem dependencies means that we can more easily provide support for benchmarking, but also headless regression testing - and eventually, also a standalone FGCanvas startup mode.

One of the goals here is not just to support regression testing, but also automated testing/benchmarking and to provide the necessary hooks for supporting feature-scaling, so that subsystems can be dynamically toggled on/off and customized as needed, and so that better backward compatibility for old hardware can be provided:


However, the underlying patches were never reviewed/committed by any core developers when they were put up in a merge request, due to the parties asking for this taking a hiatus from FG at the time, and those who ended up being around, disagreeing with the approach taken without bothering to check back with the devel list archives to look up the relevant postings made by other core developers.

Nevertheless, you can look at the corresponding explanations/patches to learn more about making subsystems optional or removing them altogether. The reset/re-init and headless efforts can be considered to be actively maintained, while most of the "initializing Nasal early" and FGCanvas work got much less attention due to people working on different solution, namely the Integrated Qt5 launcher and Phi.

However, none of those other efforts are actually intended to help clean up the main loop accordingly by making more subsystems optional.

For the whole picture, you will undoubtedly want to look at the quotes archived on the wiki, linking back to the original discussions, to learn more about what core developers like Zakalawe stated in the context of reset/re-init, FG headless, but also about initializing Nasal earlier and providing a FGCanvas mode.

Besides, you need to differentiate between removing a subsystem entirely from the code, or making it just optional by providing a means to remove it from the main loop at run-time. The sound system in particular can be easily removed/disabled entirely - other subsystems are not so easy, i.e. may have non-standard constructors or even hard-coded dependencies in other places/subsystems, so may need to be carefully reviewed anyway before being removed at run-time, because doing so may trigger segfaults due to the hard-coded assumption that all subsystems will always be registered and running - unfortunately, even new code is added like this, despite conflicting with the corresponding reset/re-init and headless efforts that Zakalawe has been working on.

The Nasal-level challenges are discussed on the wiki - in general, the process of removing a subsystem involved editing fg_init.cxx and navigating to createSubsystems() and removing unneeded stuff there, but that is an inherently fragile process - as per the "initializing Nasal early"-journey documented on the wiki, because FG was never designed with this requirement in mind, and still is not being maintained/developed accordingly (despite HLA and similar efforts).
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Steps for Removing subsystems in flightgear source code

Postby erik » Tue Sep 01, 2015 1:14 pm

Divi wrote in Mon Aug 31, 2015 6:35 pm:If we want to remove an subsystem from the flight gear source code, without leaving any trace of it.. What are the essential steps ?(for example, if the sound update has to be removed, what are steps to be followed).

If I'm correct in assuming you want to build a FlightGear binary without sound support you could add 'cmake -DENABLE_SOUND=OFF' for SimGear.

Erik
erik
 
Posts: 1520
Joined: Thu Nov 01, 2007 1:41 pm

Re: Steps for Removing subsystems in flightgear source code

Postby Hooray » Sat Nov 21, 2015 3:09 pm

Divi wrote in Mon Aug 31, 2015 6:35 pm:If we want to remove an subsystem from the flight gear source code, without leaving any trace of it.. What are the essential steps ?


This may be of interest to you:
http://wiki.flightgear.org/Howto:Reset/ ... leshooting
Image
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am


Return to Development

Who is online

Users browsing this forum: No registered users and 4 guests

cron