| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
BlockchainDB functions virtual again to avoid missing symbols error
|
|
|
|
should fix a cross dependency betewen cryptonote_basic and
blockchain_db
|
|
|
|
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
|
|
This is incompatible with block version voting
|
|
|
|
This code should die anyway.
|
|
It's not really needed, it used to be an optimization for when
that code was not using the db and needed to recalculate things
fast on startup.
|
|
Could wrap more later.
|
|
To avoid special cases
|
|
|
|
|
|
|
|
|
|
fc34132 Remove assert from status command (hyc)
|
|
Crashes every time...
|
|
|
|
And make it change behavior slightly when close/after first hard fork
|
|
|
|
Also add some more tests, and rename some instances of
"version" and "add" for clarity.
NOTE: the starting height values are sometimes wrong.
I suspect this is due to the hard fork reorg code being
buggy, since they're good when syncing after the fact.
However, they're not actually used by the consensus code,
so I'm ignoring this for now, but this needs debugging.
|
|
|
|
|
|
It returns the ideal version for a given height, which is
based on the minimum height for a fork, disregarding votes
|
|
And setup the first fork to not vote
|
|
Using major version would cause older daemons to reject those
blocks as they fail to deserialize blocks with a major version
which is not 1. There is no such restriction on the minor
version, so switching allows older daemons to coexist with
newer ones till the actual fork date, when most will hopefully
have updated already.
Also, for the same reason, we consider a vote for 0 to be a
vote for 1, since older daemons set minor version to 0.
|
|
It speeds up a lot, which can be significant when reorganizing
from the genesis block to create the hard fork data.
|
|
There is no need to fully recalculate and rewrite state, just
refill state from the DB.
|
|
An unsigned quantity is always >= 0
|
|
Add a block height before which version 1 is assumed
Use DB transactions
|
|
|
|
This allows knowing the hard fork a block must obey in order to be
added to the blockchain. The previous semantics would use that new
block's version vote to determine this hard fork, which made it
impossible to use the rules to validate transactions entering the
tx pool (and made it impossible to validate a block before adding
it to the blockchain).
|
|
There will be a delay on first load of an existing blockchain
as it gets reparsed for this state data.
|
|
I coded the whole thing from scratch.
|
|
|
|
This keeps track of voting via block version, in order to decide
when to enable a particular fork's code.
|
