Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Detect unix socket support at runtime #4762

Closed

Conversation

rimrul
Copy link
Member

@rimrul rimrul commented Jan 10, 2024

I still need to teach t0301 to skip based on the runtime check and probably clean this up a little.

Once this PR is finished, this fixes #3892

@rimrul rimrul force-pushed the unix-socket-runtime-check branch 3 times, most recently from d733052 to d9dd162 Compare January 11, 2024 16:05
@carenas
Copy link

carenas commented Jan 12, 2024

it might be interesting to invent a third state for the Makefile variable that could be used to build it in an "dynamic/autodetect" mode.

I presume the default Windows build would rather have this hardcoded to avoid the extra delays, but as older versions of Windows become less common it might be worth switching to the "autodetect" mode and that way "mostly" enable this code.

@rimrul
Copy link
Member Author

rimrul commented Jan 12, 2024

it might be interesting to invent a third state for the Makefile variable that could be used to build it in an "dynamic/autodetect" mode.

I have thought about that, but decided it wasn't all that necessary.

I presume the default Windows build would rather have this hardcoded to avoid the extra delays,

testing time git credential-cache exit (single core Windows 8.1 VM on an i5-4670 host) I get

real 0m0.064s
user 0m0.000s
sys 0m0.000s

with the hardcoded error message and

real 0m0.066s
user 0m0.000s
sys 0m0.000s

with the dynamicly detected error message, so I don't think we need to worry about the delays too much.

but as older versions of Windows become less common it might be worth switching to the "autodetect" mode and that way "mostly" enable this code.

Seeing as Cygwin 3.5 is supposed to be released in a few weeks, Git for Windows 2.44 is likely the last Version to support Windows 7 and Windows 8. That leaves only Windows 8.1 and some old non-updated Windows 10 versions.

@carenas
Copy link

carenas commented Jan 12, 2024

That leaves only Windows 8.1

There is also that "opensource windows" that usually tracks windows server 2003, plus all the server versions that are also most likely to have longer lifetimes IMHO.

not sure if the "service" trick would work realiably in all of them for the detection code, and regardless, I presume that cygwin would rather need a different codepath since the UNIX socket implementation there predates the native version,

@rimrul
Copy link
Member Author

rimrul commented Jan 12, 2024

That leaves only Windows 8.1

There is also that "opensource windows" that usually tracks windows server 2003,

I don't think Git for Windows ever supported reactOS. And I think upstream Git doesn't build there either.

Edit: It is seemingly possible to tweak Git for Windows 2.10.0 to work on ReactOS

plus all the server versions that are also most likely to have longer lifetimes IMHO.

As far as Microsoft is concerned they get the same 10 years as the desktop versions. As far as Git for Windows is concerned they go out whenever we drop support for their corresponding desktop version. So when I said Windows 8.1 I also meant Windows Server 2012 R2.

not sure if the "service" trick would work realiably in all of them for the detection code

It's more or less what Microsoft recommends, but I think I can set up some test VMs for that as well.

and regardless, I presume that cygwin would rather need a different codepath since the UNIX socket implementation there predates the native version,

AFAIK Cygwin Git (and MSYS2 Git) is already built without NO_UNIX_SOCKETS and shouldn't hit any codepath in compat/mingw.c those should use _can_use_unix_sockets() which is marked as inline and returns a constant 0 or 1 depending on wether NO_UNIX_SOCKETS is defined. Most compilers should optimize that out.

@rimrul
Copy link
Member Author

rimrul commented Jan 26, 2024

not sure if the "service" trick would work realiably in all of them for the detection code

It's more or less what Microsoft recommends, but I think I can set up some test VMs for that as well.

I've tested this on Windows Server 2019 and 2012R2 and both behave like their desktop counterpart. I've also checked against the list of Nano Server APIs that all functions should be available in docker containers.

@rimrul rimrul force-pushed the unix-socket-runtime-check branch 2 times, most recently from 83bb240 to acb4425 Compare April 3, 2024 12:16
Windows 10 build 17063 introduced support for unix sockets to Windows.
bb390b1 (git-compat-util: include declaration for unix sockets in
windows, 2021-09-14) introduced a way to build git with unix socket
support on Windows, but you still had to decide at build time which
Windows version the compiled executable was supposed to run on.

We can detect at runtime wether the operating system supports unix
sockets and act accordingly for all supported Windows versions.

Signed-off-by: Matthias Aßhauer <mha1993@live.de>
@rimrul rimrul force-pushed the unix-socket-runtime-check branch from acb4425 to d8e64ac Compare April 3, 2024 12:19
@rimrul rimrul closed this Apr 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

"credential-cache unavailable; no unix socket support"
2 participants