Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 592. (Read 5806103 times)

Yep, it does. There have been a few minor API changes since then, but I've tried to retain compatibility.

Ok, it's not too easy (for end users) to add/remove drivers right now. Adding support for that is mostly trivial, though (a dlopen and a driver registration function).

I think this is already possible, but I haven't tried it yet.

Yep, this is completely done already. Doing so for JSON API data is also written, but Kano refuses to merge it because he doesn't want outside code providing new stuff for the JSON API or something silly like that.

Sure, here is the current driver interface, the original refactoring, and the first FPGA driver.

Would a properly maintained cgminer fork be sufficient?

I'm not sure we speak of the kind of plugin interface I'm thinking of (unless you have a fork of cgminer implementing the kind of interface I'm elaborating below).
What I'm looking for is an interface that make it easy for a third party to develop an hardware plugin that should work (mostly) unmodified when cgminer code evolves. Some ways to do so I can think of :

• an autoconf system that would allow configuring a cgminer build to include an arbitrary new plugin whose code would be distributed separately
• a binary API that would allow a dynamic library load

A solution must be designed so that the single interface through which any hardware plugin would be used must allow what we already have today without modifying cgminer's code. This isn't restricted to the pure mining process if we want "true" plugins independent from the core code. I can think of a few things :

• defining command line parameters/JSON keys to parse to configure the hardware (how to select them, how to set clocks, ...)
• passing information from the hardware to the display/log layers of the code in a common way.

I don't care much if the plugin interface is a binary or source one : what matters to me is the ease of maintenance of a separate piece of code. So the interface must completely isolate the internal workings of the plugin and the ones of cgminer only allowing communication through a documented, restricted interface. The complexity (from my point of view, I might overestimate this) is that the interface must be flexible enough that it can accommodate current hardware types and even foreseeable future ones. Questions someone designing the interface could ask herself : « would the plugin interface work without any cgminer code change if I need to write a plugin for an ASIC on a PCIe card/a mining appliance communicating through HTTP ? » ... whatever she can think of.
Retrocompatibility would be nice, cgminer should allow plugins not to answer a subset of the interface (ie: some functions would be mandatory for a plugin and others optional). The actual mining process is obviously mandatory, the statistics reported in the UI/command line parameters might be optional
for example.

Maybe you could describe how your plugin interface work (or better point me to the source files implementing the plugin interface in cgminer and the one interfacing with it in a plugin) : if it does what I want you'll have new BTCs (the amount would depend of the actual content of your changesets so that if there's still work to be done I can reserve some BTCs as described in my earlier post) if not I may be better able to see where my explanations fall short.
The changes must be accepted by ckolivas (my goal is obviously that future enhancements of cgminer would not systematically break the plugin interface).[/list]

Yeah, and that's exactly what I did. What's your point?

Luke - I'm pretty sure everyone (but you) understands what he means by a plugin.
In case you weren't up with current technology, here's an explanation that's not too bad:
http://en.wikipedia.org/wiki/Plug-in_%28computing%29

Edit: ... though you could sort of say that the RPC API is like a plugin
(No I'm not trying to weasel BTC out of nor do I want any BTC from gyverlb's )

Sorry, I think people have a right to know if their donations really won't affect the status quo of regression you've adopted. I don't know any other way to interpret your response than "I want people to donate to me, but I don't want to change the status quo".

I already migrated cgminer to a plugin interface. That was necessary to add FPGA support in the first place. Admittedly, the CPU and GPU code could be pulled out of core better, but the FPGAs have been modular from the start. If you still want to give me the 20 BTC donation for the modularization, you can send it to 1KqGgsE2fHn5MdwAMmYjjwknSvFRZPRAWs. If there's something somehow still lacking, would you mind elaborating?

Thanks guys, much appreciated comments. As for plugins, the code is already very modular, and true "plugin" architectures written in c aren't really very practical. I will continue to develop the areas I'm most interested in, and find donations very effective at making me interested in things too The bitcoin community on the whole has been generous in that regard, and of course the incentive of a feature being implemented appears to be one of the greatest motivators for donations.

The code seems rather modular already : you can compile support for various things in or not if you wish. Plugins might be a good idea, but they require to design a plugin interface. Accommodating the various peculiarities of each hardware type in the interface might be difficult and designing it to make plugins load in a portable way (Linux/Windows/...) is probably a nightmare.
I'd be pleasantly surprised if ckolivas and cgminer contributors think otherwise and as I think it would benefit myself if possible I even pledge 40BTC for an hardware plugin interface and migration of current GPU/FPGA code to plugins (20 BTC for the cgminer work, 20BTC to split evenly among hardware plugins).
Couldn't agree more.

Thanks. I can confirm 2.3.4 is working on my system as expected.

Donation coming your way.

It was fixed in 2.3.3

Hmm.  Let me try 2.3.3 on one of the rigs.

2.3.3

I only update if I need a feature that is not available in the current release or if the new release brings improvements etc.

No need to use 2.3.4 because I don't run a ZTEX

What version of cgminer?
I noticed that it doesn't affect my rigs running 2.1.2 but it does affect the ones running 2.3.1f & 2.3.2

I have submit stale also on also.

About 700 000 shares total submitted and SS still 0 like it should be.

Strange ...

If submit-stale = true (or pool is using submit-stale flag) shouldn't SS always be 0?

If submit-stale = true and  SS is > 0 what is happening.
A) cgminer is not submitting share? err?
or
B) cgminer is.

B is less of a problem but it results in bogus stats.  If share is submitted then it will either be returned as rejected (R count ++) or accepted (A count ++).  If SS is also being incremented then the same share is being counted twice.

The reason I ask is I have submit-stale = true and lately have been noticing an SS count of > 0.  It is a low % (say 0.5%) but it should always be 0 right?

On edit:  so I looked at all my rigs.  It seems only "newer" cgminer has SS > 0.
I have some rigs still on cgminer 2.1.2 (BAMT 0.4) they all properly show SS = 0 (one has been running 60 days w/ SS = 0).
I have some rigs on cgminer 2.3.1f (BAMT 0.5) they all have SS > 0.

THIS.

To many people fighting about what should, or should not be included.  Fighting about what the display should look like, fighting about what information should be displayed and what shouldn't.  This is getting to be a pain in the ass.

ckolivas, it's your baby, do what you want with it.  If I were you, I would just strip it down to the bare minimum, then run all the extra shit off of plug-ins.  Want a different interface, use a different plugin, want support for super-duper-FPGA-miner-3000?  Get someone to write a plugin for it.  Want Luke and Kano to stop fighting?  Let them write their own separate plugins.

You sir, wrote an great little piece of software, but you will never make everyone happy, don't try.

Great stuff !

Just let me know when I can flash my GPU BIOSes without using RBE and using only cgminer.

Also let me know when I can attach cgminer to my grill to cook me some eggs as well !

Too many features in cgminer will not be beneficial for anyone. cgminer is good for one thing : mining.

If you start also allowing it to flash FPGA bitstream and firmware then why not expand it to a household alarm monitor as well etc.

Look at BFL and their "easyminer" software. That is what every FPGA dev should develop instead of piggybacking onto cgminer with puny donations like 10 BTC.

Yes. There are a few things missing still:

- support for quad boards (1.15y)
- suspend
- high speed bitstream upload
- hotplug
- firmware upload (to support hot upgrade and the new bogus firmware feature)
- Support for the latest firmware (120417, bitstream 15d4) - This is already done but waiting on inclusion on the main repository

All of the above will be addressed as time permits. You can use the latest firmware if you compile cgminer yourself, grab it here -> https://github.com/nelisky/cgminer/tree/ztex-120417

There is a lot more I want to do but I've been mining with ztex 1.15x boards on cgminer for roughly one month now and it works great

Yes.
And the pull request I have in at the moment adds Ztex (and the frequency) to the API PGA output
(frequency on the end of course)

Regarding ztex support, is dynamic frequency scaling supported (like with BTCMiner)?