2012/5/10, Eric J Korpela <[email protected]>:
> I'm thinking about the possibility of adding client support wine/wine64 on
> i686 and x86_64 platforms. But the current platform choice mechanism
> causes problems.
>
> The easiest, and probably safest is to add "i686-wine" and "x86_64-wine" as
> alternate platforms. That means projects would need to deliberately make
> their windows apps into wine apps. But it means that people running wine
> don't have the option of trying to join projects that don't do so.
>
> The more dangerous road would be to have machines with wine report
> "windows_x86_64" or "windows_i686" as platforms. The problem with that
> would be that on projects that have linux32, linux64, window32, and
> windows64 applications, an x86_64-linux host with wine installed would get
> all four applications, until the scheduler determined which one was
> fastest. Maybe that would be a good thing. Maybe the windows32 app is the
> fastest. The other problem would be for apps that don't work on wine.
> S@Hruns fine, but maybe apps that require window7 wouldn't.
How are you going to bridge the IPC?
The Windows science app inside Wine will expect to read a
<comm_obj_name> element from init_data.xml, and open the global file
mapping in Global\boinc_{some number}.
Meanwhile the Linux core client will be mmap()ing a file called
"boinc_mmap_file" in the slot directory. Unless api_version is 5.x, in
which case it will use shmget on a shared memory segment ID read from
init_data.xml.
None of the three mechanisms are compatible...
--
Nicolás
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
