search

BOINC / boinc

Open-source software for volunteer computing and grid computing.
https://boinc.berkeley.edu
GNU Lesser General Public License v3.0
1.96k stars 438 forks source link

--with-boinc-platform/HOSTTYPE config ignored for i386/x86_64 Linux machines #3595

Open smoe opened 4 years ago

smoe commented 4 years ago

The configure script kindly offers to specify the platform identifier via the --with-boinc-platform and --with-boinc-alt-platform options. which at https://github.com/BOINC/boinc/blob/f14d96d2be2e5a290177f7b5391b0802fbd3756c/m4/boinc_platform.m4#L68 sets the HOSTTYPE preprocessed variable.

Now, if HOSTTYPE is user-defined, it seems fair to expect it to be used as a platfom string. However, at https://github.com/BOINC/boinc/blob/ca9a2c56bf0215b591931c9617f24952e6121e81/client/cs_platforms.cpp#L209 BOINC has makes the decision to not only give another platform string the priority over the configurator's understanding what the right platform name shall be, i.e. the configurator's manual settings are completely ignored. And not a word is said about it in any log file.

This exceptional behaviour for the Intel platforms may cause havoc by OpenWrt-run clients presenting themselves disguised as regular Linux machines but not having the GNU libc installed, so these tasks would immediately fail and more work be requested. Perpetually.

To fix this I suggest to always accept the externally defined HOSTTYPE (and its alternative) whenever this is defined. The self-determined platform could possibly be allowed as a 2nd alternative, but I have not yet made up my mind about the drawbacks this has, yet. Maybe that should be delayed until it has become increasingly accepted to redistribute statically linked binaries.

AenBleidd commented 4 years ago

@smoe, could you please provide a PR with these changes?

smoe commented 4 years ago

@AenBleidd, I think this needs a bit more of a discussion about what the most desirable behaviour possibly is. We have helped ourselves with this patch https://github.com/openwrt/packages/blob/ebc19c6bd5ff3dc424ef1b6d7b5bdb0fa23ac7b8/net/boinc/patches/002-hosttypeRespected that apparently works since OpenWrt's Makefile explicitly sets the platform strings - but that may also be completely off from what the BOINC-devs may find acceptable.

The personal beef I have with that patch is that if only the alternative platform name is set, then this should be secondary to the one the system finds itself. There may be more to it.

Once the HOSTTYPE is no longer secondary to what the system finds, much of that routine can be cut. Maybe this is something for one of the next telcos.

lrosenman commented 4 years ago

Just a comment, I'm the FreeBSD port maintainer for Boinc. We can present on an AMD64/X86_64 box) 1) x86_64 FreeBSD (amd64) 2) i386 FreeBSD 3) x86_64 Linux (generally CentOS7 userland) 4) i386 Linux (generally CentOS7 userland)

I've had in my cc_info.xml i396-pc-linux-gnu (which allows us to get 32-Bit Linuix exe's that run. I'm wondering if a lot of the projects have 64-bit Linux exe's and what string(s) I need to have the port put into cc_info.xml and/or configure args.

I'm also seeing a LOT of checksum/signature rejects from the WCG project, and I'm wondering where the fault can be.

If I need to make a different issue, feel free to tell me that. or contact me at ler AT FreeBSD.org. or here.

truboxl commented 3 years ago

I agree that what is defined in HOSTTYPE and HOSTTYPEALT should be given priority rather than a fallback for Linux x86, x86-64, and if not all the existing platforms.

This will help testing platforms that can run multiple types of binaries by prioritise fetching tasks using HOSTTYPE* first.

To add on: since well known platforms like x86_64-pc-linux-gnu is always defined under the current code, the client prioritise fetching for that platform and servers always have ample supply of tasks for that platform. It's unlikely servers will finish its supply and if it does, there's i686-pc-linux-gnu.

It's unknown when will user-defined HOSTTYPE* ever get to be used since its considered 3rd and 4th tier platforms, at least when building for Linux x86-64, or on another platform using <alt_platform> in cc_config.xml...

Edit: Looks like I am wrong about that. I had set <no_alt_platform> to 1 which caused the confusion...

However it still comes back to the question why deliberately disable the fallback option when detected the platform is indeed Linux x86/x86-64? Also it seems a bit redundant to also have HOSTTYPE defined in boinc_platform.m4 when you are going to check in cs_platforms.cpp for Linux x86/x86-64 anyway...