It cannot be used as-is. It should probably be implemented as a
standalone "fake pool" application anyway, to properly gauge the effect
of queue/scantime/expiry and network latency.
If someone really needs this, they can revert this commit.
Closes#116.
This is trivial and shouldn't be so hard: it required modifying
functions in both sgminer.c (for NCurses stuff) and api.c. There is
much code repetition, since the NCurses interface is hard-coded in.
Removing it would simplify things greatly.
One small change to work well with previous ones.
Number of warnings now is 151, down from 157.
Still a long way to go. Most of the serious warnings are related to variables in miner.h, which is so intertwined with everything else that I fear of breaking something or making performance worse if I touch miner.h too much.
This reverts commit 8dd1c2d4af.
Introduced a security bug: since CCAN/opt is used to parse the JSON
config (something it is not meant to do), it was possible to specify
the default of
"api-listen":false
in .conf and expect the API to be disabled. However, since CCAN/opt
does not check for parameters to OPT_WITHOUT_ARG, this got set to
true anyway, and enabled the API on a (possibly unfirewalled) network.
For this reason, configuration options are not named uniformly.
This should have been reverted as soon as it became known:
4c4b909be6 (Fri Feb 28)
Sorry for that.
It looks like there's an exploit that abuses said command, but it is still not clear exactly how.
There's also an additional message when the reconnect happens: "WARNING: POTENTIAL CLIENT.EXPLOIT!", but it requires you to be actively monitoring your log to catch it, and in which case you already get a "Reconnect requested from Pool 0 to 127.0.0.1" message.
Note that disabling 'client.reconnect' might affect some pools that rely on the feature, like pools that you lease your rig to.
Oh and this is dry-coded. :)
WIP!
Use a string instead of a state-machine-ey kernel selection mechanism
where kernel names have to be predefined. This should allow just dropping
new kernels into dir `kernel` without bloating the code in three other
places.
Is in dire need of a cleanup, function parameter check, edge case check -
all the usual testing.
In particular, checking these definitions/keywords:
* enum cl_kernels
* kname
* [c]gpu[s]->kernel (and similar)
* memory cleanup after strdup()?..
* chosen_kernel
* queue_scrypt_kernel
* strbuf
* initCl
Also squashed:
config: add log messages to set_algo() and set_nfactor().
algorithm: use set_algorithm_nfactor() when setting default nfactor in set_algorithm().
Otherwise algorithm->n defaults to 0.
P.S. Did I already mention how this could have been C++?..
Had two bugs:
1. Will not compile due to unknown algorithm_t size.
2. nfactor is set to 0 (bad calling, fix later).
So squashed two commits:
1. algorithm: move algorithm_t definition to header.
2. config: if --nfactor is specified, properly set algorithm->nfactor.
Doc in `doc/configuration.md` (has to be started sometime, no?).
Configuration function has to be lamely-named set_algo(), because
set_algorithm() is already declared in algorithm.h (prevent namespace
conflict).
algorithm has to be added as global variable due to the way the
callback is done (by CCAN/opt, which in itself is nice).
This can be cleaned up significantly by (at least) introducing a
global configuration struct, but there is no reason to do it now
just for this - better a wholesale manana.