We can't reliably set contemporary processors to an arbitrary frequency.
There are dependencies between cores and thechnologies like Turbo Boost
which may make actual frequency significantly different than the requested.
Moreover, it is the scheduler job to decide how much CPU performance is
needed and user shouldn't interfere with that.
In current state this driver is useless anyway. It's not MP safe.
The P-state values stored in hardcoded tables are only for processors
on which we can't use SpeedStep, because of lack of invariant TSC.
Proper driver should get P-states from ACPI, ensure that the CPU offers
invariant TSC and obviouslt be MP safe.
Use findpaths to find the makefile-engine to include. This addresses the
remaining aspect of #10011. I.e. the package can now also be installed
in home.
We need to use the package's .self symlink, since that does point to
the package's installation location. The containing directory lives in
/boot/system/package-links and would therefore always resolve to the
system installation location.
Add a constructor and a SetTo() method with a
BPackageResolvableExpression parameter instead of a path. The path of
the package satisfying the expression is used.
The new functionality lives in libpackage as it uses the package kit.
Most of the hooks don't strictly need a non-empty implementation. The
defaults now simply throw exceptions in those that do. This allows the
class to be instantiated, which is useful when a BPackageManager is only
used for finding packages.
Require the installation interface and the user interaction handle to
be passed to the constructor. Formerly, derived classes set them
manually in their constructors. This makes using the class without
having to subclass it possible.
* get_file_attribute(): Use O_NOTRAVERSE, so we correctly read the
attribute from symlinks.
* internal_path_for_path(): Shuffle things around a bit: The dependency
is resolved before handling B_FIND_PATH_PACKAGE_PATH, now. This adds
support for getting the package file for a dependency. The dependency
was ignored in this case before.
* Use kSystemPackageLinksDirectory instead of hard-coding "/packages".
* Mark the current connected device, or disable "Disconnect" menu when
there is no connection.
* Save and restore serial port settings
* Improve drawing code: make sure the border around the termview is
repainted, and do not leave a 1px space between lines unpainted.
* Remove possibility to temporarily disable small task packing.
* When small task packing target gets overloaded continue packing
threads on another core, but avoid migrating the already packed
ones.
Scheduler still tends to needlessly migrate threads to another cores
when under heavier load, but it is now much better than before.
It's a browser for the system package content, where entries can be
selected to blacklist them. The selected entries are removed from the
packagefs instance in the boot loader, so that e.g. selected drivers
won't be picked up. The paths are also added to the safe mode driver
settings and will be interpreted when the system packagefs instance is
mounted by the kernel.
* Make Menu and MenuItem polymorphic.
* MenuItem:
- Make SetMarked() virtual, so it can be overridden.
- Add SetSubmenu() and Supermenu().
- Delete the submenu in the destructor.
* Menu:
- Add Entered()/Exited() hooks. They frame the time the user navigates
the menu or any of its submenus. The hooks allow for subclasses
populating their item list dynamically.
- Add SortItems().
* Update boot loader menu copyright text to include 2013, now that it is
over soon. :-)
In each installation location, it is now possible to create a settings
file "packages" that allows to blacklist entries contained in packages.
The format is:
Package <package name> {
EntryBlacklist {
<entry path>
...
}
}
...
<package name> is the base name (no version) of the respective package
(e.g. "haiku"), <entry path> is an installation location relative path
(e.g. "add-ons/Translators/FooTranslator").
Blacklisted entries will be ignored by packagefs, i.e. they won't appear
in the file system. This addresses the issue that it may be necessary to
remove a problematic file (e.g. driver, add-on, or library), which would
otherwise require editing the containing package file.
The settings file is not not "live". Changes take effect only after
reboot (respectively when remounting the concerned packagefs volume).
