Also, why are we accepting the completely made-up "RLIM_AS" but not the
real "RLIMIT_AS" in .rc files?
Bug: http://b/293894041
Test: treehugger
Change-Id: I18b10b6dd77265a9a14b88bfdf1cc0b474800a94
Android-base has an implementation of the future std::expected<>.
This provides the same baseline functionality as Result<>, so use it
instead of our own version.
Bug: 132145659
Test: boot, init unit tests
Change-Id: I11e61bcb5719b262a6420483ed51a762826a9e23
Due to a bug with ParseUint(), init would defacto accept -1 for an
infinite rlimit, but only on 64bit devices. That bug is now fixed,
such that -1 would be rejected by ParseUint() for all devices.
This change explicitly checks for -1 for all devices or 'unlimited' to
match ulimit's reporting and accepts either as an infinite rlimit.
Bug: 112668205
Test: new (and old) unit tests
Change-Id: Ie28ff622cdf375a65ceb5f32ffb14fb3d5d9f2ba
Add a new service option, `rlimit` that allows a given rlimit to be
set for a specific service instead of globally.
Use the same parsing, now allowing text such as 'cpu' or 'rtprio'
instead of relying on the enum value for the `setrlimit` builtin
command as well.
Bug: 63882119
Bug: 64894637
Test: boot bullhead, run a test app that attempts to set its rtprio to
95, see that the priority set fails normally but passes when
`rlimit rtprio 99 99` is used as its service option.
See that this fails when `rlimit rtprio 50 50` is used as well.
Test: new unit tests
Change-Id: I4a13ca20e8529937d8b4bc11718ffaaf77523a52
