Skip to content
This repository has been archived by the owner on Mar 24, 2022. It is now read-only.

Windows Binary Support #205

Closed
solvingj opened this issue Jun 8, 2019 · 4 comments
Closed

Windows Binary Support #205

solvingj opened this issue Jun 8, 2019 · 4 comments

Comments

@solvingj
Copy link

solvingj commented Jun 8, 2019

Is it possible that Fastly will ever consider allocating developer resources to make Lucet create Windows binaries? Based on an analysis of the existing codebase, it seems as unlikely as possible. It seems that such a thing would have to be a completely separate and community-driven fork just for Windows, with no chance of ever getting such support merged back into this mainstream project because it would substantially complicate everything from the code to the build system.

@iximeow
Copy link
Contributor

iximeow commented Jun 8, 2019

I'm not sure I'd write Windows support off quite that quickly! I know it's not a terribly high priority at the moment but off the top of my head I think the only unixy-specific places that would have to change are:

  • OS-based selection of artifact choice from lucetc (so on Windows, write a PE, .dll or .exe). Faerie doesn't support PE, so this might be The Hard Part.
  • Check that the stack probe function lucetc inserts plays nice with Windows
  • A Windows-friendly implementation of Region (I'm not sure if a direct translation of MmapRegion would be sufficient, or behave well with Windows APIs, but it might!)
  • context switching would need a version for Windows as well.
  • sysdeps would need to learn about what a Windows thread context looks like

again, just off the top of my head, but those are the only OS-specific places I'd expect.

You may well have seen something I didn't mention - are there any other rough spots you found? What about this build system would you expect to be complicated by Windows support?

@solvingj
Copy link
Author

solvingj commented Jun 8, 2019

Windows binary support is possible with time and resources. It is very likely that it has come up at least once in internal discussions at Fastly. This question was for someone at Fastly, and very specifically about the possibility of the company devoting such time and resources.

@pchickey
Copy link
Contributor

pchickey commented Jun 8, 2019

Hi! First off, ixi is part of the team here at Fastly. They’re right that windows support is a moderate undertaking, maybe a month or two of work for a developer familiar with the project and the target.

We don’t currently have a business case for supporting windows, so we couldn’t put those resources towards it. We run Lucet exclusively on Linux in production, and some developers use it on the Mac.

However, we are enthusiastic about accepting community contributions to the project. We are very happy to work with developers who are building support for other operating systems, processors, or environments, and if the abstractions we currently have are unsuitable for porting we can work on evolving them together. We can accept ports provided they don’t break our existing platforms, and have adequate CI testing (currently something we’re working to improve, we haven’t set up Mac OS CI yet). But at the moment we don’t have the bandwidth or business case to drive any ports ourselves.

@solvingj
Copy link
Author

Thanks for the response and being open about your ability to drive the effort.

For many types of OSS projects, long-term, successful community-contributed platform support is possible. I would not personally consider a compiler-like such as Lucet to be this type of project. Community ports most often falls into disrepair if it's not accepted into the upstream, constantly tested, maintained or perhaps even used internally by core maintainers.

Hopefully a group of interested people, or an organization will show up and fill in the gap for Windows support in a robust and long-term way.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants