* Admittedly not very well thought out, but it should be good
enough for now; it doesn't really make sense to initialize jobs
that is never run due to failed conditions.
* Job, and Target now have a common base class BaseJob that deals
with the conditions.
* Moved related test code from DriverSettingsMessageAdapterTest to the
SettingsParser class.
* Added SettingsParserTest class -- most tests already succeed, but not
all; support for the flattened "not" is not working yet.
* You can now add arbitrarily named fields to the message as well,
without having them all specified in the template.
* Also added a missing converter method that is called when there
are no values to add, and implemented all methods in the base
class, so that you only have to implement the methods you actually
need.
* BRoster now allows settings a "no-registrar" mode that is currently
only honored in _LaunchApp(), though.
* Job::Launch() is now using this, which also allows launching
applications by signature (ie. if the job name matches the
signature, you can omit the "launch" option).
* You can now put jobs/services into a target.
* Instead of having Login started as part of the normal boot process,
it's now in the "login" target.
* The app_server now launches the login target when a login becomes
available (ie. during startup, but that could be improved later on).
* Instead of launching Tracker/Deskbar directly, we now launch the
Login application.
* This will now start a new session for the selected user (the password
is currently ignored).
* When a user session is started, the launch_daemon forks, and the
child then restarts the LaunchDaemon application in user mode.
* It then registers itself with its parent, in order to resolve user
dependent services.
* Added a user launch file that will cause Tracker, and Deskbar to
start in the new session.
* Job is now a BJob, and includes the former LaunchJob functionality.
* Dependencies are now resolved on init, and jobs are removed early
when they are not met (or are cyclic, which is now also detected).
* Implemented a multi-threaded job queue, that launches as many as CPU
count jobs at once -- due to SSDs, this number could possibly even be
made much larger, though.
* Launching a job now happens within that worker queues as a LaunchJob.
* Put all init jobs into an init target, and make the launch jobs depend
on it.
* Added initializing /tmp & /var/shared_memory to the launch_daemon.
* Moved clockconfig.cpp code into the launch_daemon.
* This follows systemd design; since those jobs are fixed, it doesn't
matter where you maintain them.
* The init jobs are BJobs, but the JobQueue is only used for that
one use for now. At a later time, I intend to put the job launching
in there, as well. BJob allows to represent the dependencies already.
* get_roster_port_name() is no longer needed.
* This also removes the app_server restart code from the debug
server -- this will be done by the launch_daemon in the future.
* Instead of letting the kernel search for the syslog port, the
daemon now registers itself with the kernel (which even solves
a TODO).
* A port is created for the actual log messages from the launch_daemon,
and used on start.
* However, the SyslogTest does not yet work, due to the BMessage <->
KMessage communication problems.
* These methods don't really work yet, as BMessage doesn't support
replying with a KMessage; the request is received, but the reply
never gets to the target.
* Dropped "create_port" -- this is now the default for services.
* Additionally (or alternatively, if you use the "legacy" mode), you can
now create named ports, and specify their capacity.
* Added convenience methods to BLaunchRoster that automatically use the
signature of the current be_app.
* This is actually working already, although we cannot reproduce all
the features of the former Bootscript yet. This is without any
dependency support in launch_daemon.
* All shell activity like cleaning out /tmp, setting up the environment,
setting the time, etc. is not yet working.
* We're checking with IsTargetLocal() if we're allowed to access
it or not.
* This might introduce regressions, if the registrar is using its own
services via the BRoster API.
* This fixes a deadlock when the system clipboard tries to get
initialized within the registrar.
* When the team that we got the synchronous reply from immediately
terminated afterwards, it might have still owned (and therefore
destroyed) our reply port.
* Make sure it's not added to the pool again, but is recreated instead.
* BRoster::Launch() cannot be used (yet), as it pre-registers the
application we're launching, and that won't work for the registrar or
anything else until the registrar is up and running.
* Renamed B_GET_LAUNCH_CONNECTIONS to B_GET_LAUNCH_DATA.
* Add the team ID to the get-launch-data reply.
* Added BLaunchRoster::GetPort() for convenience.
* Removed some superfluous debug output, but temporarily dump all stdio
to /dev/dprintf (ie. the syslog).
* Made job matching case insensitive (as MIME types should be).
* This enables a mechanism to profile almost the complete boot process
(starting with main2()), if SYSTEM_PROFILER is defined to 1.
* You can access the profiling data using "profile -r".
* This will be heavily inspired by Apple's launchd, as well as
systemd -- for now it really doesn't do a whole lot, though.
* What works so far: the configuration files are read, parsed, and
the jobs created.
* The jobs are even initialized, and their message ports created.
* BApplication now retrieves a previously created port from the
launch_daemon for use with BServer.
* Only the registrar actually uses this for now.
* When pressing shift it will also extend the selection to the bottom
or the top of the page.
* It does not deselect anything yet, but Tracker's selection logic is
pretty questionable, anyway, and it's way too complicated to
implement this nicely as of now.
