Re: [gentoo-user] Re: Kernel upgrade from 4.1.12 to 4.4.6 hangs without writing logs.

[Michael Mol]

On Saturday, April 30, 2016 01:32:54 AM Hans wrote:
> On 30/04/16 00:28, Michael Mol wrote:
> > On Friday, April 29, 2016 10:56:28 PM Hans wrote:
> >> On 28/04/16 22:22, Hans wrote:
> >> Kernel 4.4.6 as a bug. x11-drivers/xf86-video-virtualbox does not
> >> compile.
> >> Reason:
> >> /usr/src/linux-4.4.6-gentoo/include/linux/string.h
> >> 'char *strreplace(char *s, char old, char new);' causes compile failure.
> >> "new" is a C++ keyword.
> >> Changing tp 'char *strreplace(char *s, char oldstr, char newstr);' fixes
> >> the problem.
> > 
> > That's not a bug in the kernel per se, that's a bug in using that kernel
> > header (written in C) in a compiler expecting C++ code. Which would make
> > it a bug in xf86-video-virtualbox for not linking against a C-compiled
> > object file.
> > 
> > Granted, it'd be a heck of a lot more convenient if the kernel header
> > files
> > didn't use C++ keywords...but it *is* fundamentally a problem with
> > compiling a source file using the wrong language. Like trying to read
> > something in Portugese, except it was written in Spanish. It might work
> > some of the time, but it'll catch you out eventually.
> 
> The Virtualbox internal runtime compiler, assembler and gcc compiler to
> build executables such as app-emulation/virtualbox-guest-additions, etc.
> use some of the kernel sources and headers.

Assuming those components are using this string.h header file, that just means 
that those components are correctly treating treating these header files as C 
header files, and not C++ header files.

> 
> Kernel 4.1.12 string.h and earlier did not have this silly problem.

That just means that Kernel 4.1.12 string.h and earlier weren't exposing a bug 
in xf86-video-virtualbox. 

The Linux kernel is written in C with a smattering of platform-specific 
assembler, and some other used languages at build time. The header files for 
Linux are written in C. It's built with a C compiler. It's expected to be 
consumed by things expecting to be consuming C.

xf86-video-virtualbox is trying to build C code in a C++ environment, and 
that's not guaranteed to work. In fact, it's semantically broken, as C isn't 
simply a subset of C++, nor is C++ simply a superset of C. They're two 
distinct languages that can be made to work reliably together if you pay 
attention, and the VirtualBox developers...didn't. Linux promises a stable ABI 
for existing API calls, but the symbol name for an *argument* of an API call 
isn't part of the ABI; functions' arguments' names aren't preserved at compile 
time. Similarly, adding new API calls doesn't disrupt existing API calls or 
the ABI, so adding a new API call with an argument named 'new' doesn't violate 
that ABI promise.

Now, an argument can be made that the kernel developers working in C shouldn't 
use C++ keywords, but that's a dangerous slippery slope; there are a *lot* of 
languages out there that are superficially syntactically (and even 
semantically) similar to C, but *aren't*. What makes C++ special enough that 
the kernel should respect it, but not every other language? No...userland is 
built around the kernel, not the other way around--that's what makes it the 
kernel. The kernel has a fairly well-defined set of rules in that it's written 
in a supremely common standardized language, and there exist good practices 
for interfacing code written in that language with code written in other 
languages.

I get that it's frustrating. Just trying to help you understand what's going 
on a a lower level, and why.

-- 
:wq

signature.asc
Description: This is a digitally signed message part.

SOLVED Re: [gentoo-user] ATLAS@home and VirtualBox

[Peter Humphrey]

On Wednesday 27 Apr 2016 10:03:58 Peter Humphrey wrote:
> On Tuesday 26 Apr 2016 19:54:09 Gregory Woodbury wrote:
> > On Tue, Apr 26, 2016 at 5:40 AM, Peter Humphrey 
> > 
> > wrote:
> > > Has anyone here succeeded in getting this BOINC project to run? No
> > > matter
> > > what I try, I get "task postponed 86400.00 sec: Communication with
> > > VM
> > > Hypervisor failed."
> > 
> > Is the "user" boinc runs as in the vboxusers" group?
> > By default, boinc runs as a non-root (daemon?) user and if its group is
> > not in the vboxusers group,
> > VirtualBox will not start or run for the user.
> > 
> > The recommended workaround is to run boinc as a real user (generally
> > "you") so that things operate properly.  Additionally, the actual way
> > that the cernvm runs can change "just a bit" and it will upset the
> > balance of getting VBox to run boinc tasks.
> 
> Thanks for the reply. Yes, boinc is running as me, as shown below, and I
> am in the vboxusers group. Boinc is also in that group. All the files and
> directories under ~/boinc and ~/.VirtualBox are owned prh:prh. But I've
> just noticed that the files under ~/.VirtualBox are all 0600; I wonder if
> that's thet problem: that the boinc user can't read them. But then boinc
> is running as me, the owner of all the files involved.
> 
> I'm going round in circles again.
> 
> $ ps U prh
>   710 ?SNsl   4:10 /usr/bin/boinc_client --daemon --dir
> /home/prh/boinc --redirectio 880 ?Sl22:23 /usr/bin/boincmgr
> [...]
> 19613 ?RN   372:47
> ../../projects/www.cosmologyathome.org/camb_2.16_i686-pc-linux-gnu
> params.ini [...]
> 24897 ?SNl0:08
> ../../projects/pogs.theskynet.org_pogs/wrapper_x86_64-pc-linux-gnu_4.02
> [...]
> 28001 ?RN 7:17 ./fit_sed 10 filters.dat observations.dat
> [...]

The fix has already been done, silently - no outward evidence other than the 
dates on a couple of files. I only found out when I compared a new 
installation with what I'd backed up a few hours earlier.

The problem was that /etc/init.d/boinc was starting the client with an su 
command, but now a start-stop-daemon call has been substituted. Job done. I 
can now move on to the next problem.  :)

-- 
Rgds
Peter