aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/native
Commit message (Collapse)AuthorAge
* Windows JNI: make the builder .bat executable Gravatar László Csomor2017-03-23
| | | | | | | | | | Came up while working on https://github.com/bazelbuild/bazel/issues/2725 -- Change-Id: I923690642d0fc93dcdb5050837b5ddaaa2a1d494 Reviewed-on: https://cr.bazel.build/9469 PiperOrigin-RevId: 150880961 MOS_MIGRATED_REVID=150880961
* Make Bazel work with all MSVS 2017 editions Gravatar Alexander Chung2017-03-16
| | | | | | | | | | | | | Added support for Enterprise, Professional, and Community editions of Microsoft Visual Studio 2017. In the Community edition, the working directory changes after vcvarsall.bat is called. Not sure why. Closes #2658. -- Reviewed-on: https://github.com/bazelbuild/bazel/pull/2658 PiperOrigin-RevId: 150203876 MOS_MIGRATED_REVID=150203876
* Initialize the mutex in JNIEventsDiffAwareness Gravatar Julio Merino2017-03-07
| | | | | | | | | | | | | | | | | | | | | | | | pthread mutexes must be initialized with pthread_mutex_init and cleaned up with pthread_mutex_destroy. This seems to fix a race where poll() would access invalid array indexes on an array constructed based on the size of a shared list protected by the mutex. This is understandable because the mutex may not have been doing anything due to the lack of its proper initialization -- and, if so, I'm surprised the consequences were not more catastrophic. As with any race condition, it is hard to confirm that this fixes the observed problem, but I could trivially reproduce this issue earlier and now I cannot with this fix after tens of runs. See reproduction code in the referenced bug for details on how to expose the issue. Fixes #1676. -- Change-Id: Ia5a4a8f12da7c3780f33266b9922eeba7645b3a4 Reviewed-on: https://cr.bazel.build/9230 PiperOrigin-RevId: 149414125 MOS_MIGRATED_REVID=149414125
* Windows, JNI: allow empty cwd for processesGravatar Laszlo Csomor2017-03-07
| | | | | | | | | | | | | | | | More specifically, change windows_util.AsShortPath to accept empty inputs, as well as paths with forward slashes. Also output more accurate error messages for bad input paths than before. This fixes //src/test/java/com/google/devtools/build/lib:windows-tests but not //src/test/java/com/google/devtools/build/lib:standalone-tests -- PiperOrigin-RevId: 149399449 MOS_MIGRATED_REVID=149399449
* Windows, JNI: shorten the cwd for CreateProcessGravatar Laszlo Csomor2017-03-06
| | | | | | | | | | | | | | The hard limit for SetCurrentDirectory{A,W} is MAX_PATH-1, even with UNC prefix, therefore a process' cwd may also not be longer than that. See https://github.com/bazelbuild/bazel/issues/2107 See https://github.com/bazelbuild/bazel/issues/2406 See https://github.com/bazelbuild/bazel/issues/2181 -- PiperOrigin-RevId: 149290147 MOS_MIGRATED_REVID=149290147
* Move FileAccessException to the vfs packageGravatar Ulf Adams2017-02-17
| | | | | | | | | | | | | | It was previously in unix, but also used from non-unix file systems, which means it's not actually unix-specific. This is in preparation for splitting compilation of the unix and windows file systems into separate libraries. That improves layering and reduces compile times - note that Bazel already injects the vfs into its lower layers, which should only rely on the normal vfs APIs, not on anything platform-specific. -- PiperOrigin-RevId: 147829659 MOS_MIGRATED_REVID=147829659
* Windows: use JNI CreateJunction in Java code Gravatar Laszlo Csomor2017-02-15
| | | | | | | | | | | | | | | | Use the new CreateJunction in the Windows JNI code every time we need to create junctions. This means updating WindowsFileOperations and related tests. Add test for WindowsFileSystem.createSymbolicLink. See https://github.com/bazelbuild/bazel/issues/2238 -- Change-Id: I5827e2e70e8e147f5f102fabf95fa9a148b3bcdc Reviewed-on: https://cr.bazel.build/8896 PiperOrigin-RevId: 147598107 MOS_MIGRATED_REVID=147598107
* Bazel client, JNI, Windows: impl. CreateJunction Gravatar Laszlo Csomor2017-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | Implement a CreateJunction function in the Windows JNI library. Also move a bit of code from file_windows to the JNI library, where it is (also) needed. This implementation is an improved version of `blaze_util::SymlinkDirectories` in blaze_util_windows: this version handles Windows paths as `name` and `target`, and performs more validation (e.g. on the length of `target`), plus has more comments explaining the logic. In a subsequent change I'll start using this new function in blaze_util_windows. This method will also be helpful in tests: we will no longer have to shell out to mklink. See https://github.com/bazelbuild/bazel/issues/2107 -- Change-Id: I7e9b085fdc2ba47be83da5319bded02bd323e71b Reviewed-on: https://cr.bazel.build/8892 PiperOrigin-RevId: 147585207 MOS_MIGRATED_REVID=147585207
* Make Bazel work with Visual Studio 2017 Gravatar Yun Peng2017-02-14
| | | | | | | | | | | | | | | Now Bazel can detect MSVC from Visual Studio 2017 or Visual C++ build tools 2017. Also modified build_windows_jni.sh to make it work with VS 2017. Fixed: https://github.com/bazelbuild/bazel/issues/2440 -- Change-Id: I4afbce809ff74634f32fab87efe5e7f0b3f60c95 Reviewed-on: https://cr.bazel.build/8890 PiperOrigin-RevId: 147467993 MOS_MIGRATED_REVID=147467993
* Windows JNI, refactor: move OpenDirectory to JNIGravatar Laszlo Csomor2017-02-14
| | | | | | | | | | | | Move the OpenDirectory helper method into the JNI library. We'll need it there; a subsequent change will make use of it there. See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 147448792 MOS_MIGRATED_REVID=147448792
* Bazel client, Windows, tests: `rm -rf TEST_TMPDIR`Gravatar Laszlo Csomor2017-02-10
| | | | | | | | | | | | Add test helpers to recursively delete the TEST_TMPDIR in the TearDown method of tests, to ensure each test sees a fresh temp directory. Also add tests for these test helpers. -- PiperOrigin-RevId: 147135561 MOS_MIGRATED_REVID=147135561
* Bazel client, Windows: use more of AutoHandleGravatar Laszlo Csomor2017-02-09
| | | | | | -- PiperOrigin-RevId: 147008328 MOS_MIGRATED_REVID=147008328
* Add quotes to improve space supportGravatar Alexander Chung2017-02-07
| | | | | | | | | | | These changes addresses issues where Windows users have a space in their username. Allows the default output_base path to be used. Closes #2491. -- Reviewed-on: https://github.com/bazelbuild/bazel/pull/2491 PiperOrigin-RevId: 146773331 MOS_MIGRATED_REVID=146773331
* Windows: fix off-by-one errors with MAX_PATHGravatar Laszlo Csomor2017-02-07
| | | | | | | | | | | | | | | | | | In almost every place we compared paths against MAX_PATH, we had it wrong. MAX_PATH is the null-terminated maximum length, so paths exactly MAX_PATH long (not counting the null-terminator) were incorrectly considered short. Also fix the error message in the MSVC python wrapper, because it reported an incorrect path length limit in the warning message. See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 146762382 MOS_MIGRATED_REVID=146762382
* Windows JNI: check and fix the PATHGravatar Laszlo Csomor2017-02-01
| | | | | | | | | | | Also introduce a fail() method and clean up the script a little bit. Fixes https://github.com/bazelbuild/bazel/issues/2464 -- PiperOrigin-RevId: 146225020 MOS_MIGRATED_REVID=146225020
* Windows, JNI, refactor: co-locate all JNI codeGravatar Laszlo Csomor2017-01-20
| | | | | | | | | | | | | | | | | | Move JNI code from windows_file_operations.cc to windows_processes.cc, so all the JNI code is now in the latter. This lets us expose windows_file_operations.* to the Bazel client (via the ":windows_jni_lib" target), so we can finally share file handling logic between the Bazel client and the JNI library. See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 145063140 MOS_MIGRATED_REVID=145063140
* Windows, JNI, refactor: extract WinAPI callGravatar Laszlo Csomor2017-01-20
| | | | | | | | | | | | | | | | Extract a WinAPI call from the JNI method's body. In a subsequent change I'll move all JNI methods to a common location (windows_processes.cc) and that will be the only file dealing with JNI stuff. The rest of the windows_* sources will be exposed in the //src/main/native:windows_jni_util library so the Bazel client can also depend on it later. See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 145062890 MOS_MIGRATED_REVID=145062890
* Windows, JNI: expose IsJunctionOrDirectorySymlinkGravatar Laszlo Csomor2017-01-20
| | | | | | | | | | | | | | | | | | This is a simple refactoring, no change in functionality. Create a windows_file_operations.h file, declare windows_util::IsJunctionOrDirectorySymlink there, We will include this file in the cc_library //src/main/native:windows_jni_lib later and use it from the Bazel client. See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 145062164 MOS_MIGRATED_REVID=145062164
* Windows JNI: refactoringsGravatar Laszlo Csomor2017-01-19
| | | | | | | | | | | | | | | | | | | In this change: - rename //src/main/native:windows_jni_utils to //src/main/native:windows_jni_lib and make it visible to //src/main/cpp:__subpackages__ because we will use some methods there from this library - move AutoHandle into windows_util.h, we'll use it from blaze_util_windows.cc / file_windows.cc later See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 144946842 MOS_MIGRATED_REVID=144946842
* Windows, JNI: add tests for windows_utilGravatar Laszlo Csomor2017-01-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add tests for the AsExecutablePathForCreateProcess method, since its logic is pretty complex. Unfortunately testing it also requires complex logic, as we need to test what exactly happens when the input path is shorter than MAX_PATH or when it's longer than it. To test that reliably, we need a base path that we know will not get shortened. Creating that base path under the temp directory is a nightmare, we need to: (1) retrieve the temp dir, shorten it so we know that it won't be shortened further (2) keep creating subdirectories that have a short name so they also won't get shortened, but keep the entire path below MAX_PATH while leaving enough space for a file name in the end (3) append a file name such that the path is just below MAX_PATH, or is exactly that long, or is longer than it. Because of steps (1) and (2) we can be sure that no other component in the path will get shortened, so we can test exactly what's going on with the shortener logic and its error handling. But oh boy is it complicated. Side note, we need to use the Widechar WinAPI functions to create/delete the directories and files, because the POSIX API on Windows appears to be backed by the ASCII API functions, so attempting to `mkdir` with a path longer than CreateDirectoryA's limit is going to fail. But on the positive side, adding tests caught two bugs in the method, so we have that going for us which is nice. See https://github.com/bazelbuild/bazel/issues/2107 See https://github.com/bazelbuild/bazel/issues/2181 -- PiperOrigin-RevId: 144823029 MOS_MIGRATED_REVID=144823029
* Windows, JNI, refactor: move a methodGravatar Laszlo Csomor2017-01-16
| | | | | | | | | | This change moves AsExecutablePathForCreateProcess to windows_util. This is a follow-up to unknown commit. -- PiperOrigin-RevId: 144623760 MOS_MIGRATED_REVID=144623760
* Windows, JNI, refactor: prepare moving a functionGravatar Laszlo Csomor2017-01-16
| | | | | | | | | | | | | | Prepare moving AsExecutableForCreateProcess into a shared location where the Bazel client code can also access it, since this logic is needed there too. This change is a simple refactor, it doesn't affect any logic. -- PiperOrigin-RevId: 144623656 MOS_MIGRATED_REVID=144623656
* Windows, JNI: make it work with long pathsGravatar Laszlo Csomor2017-01-16
| | | | | | | | | | | | | | When spawning a new process with CreateProcessA, convert argv0 to a 8dot3 style short path so we can support longer paths than MAX_PATH. This is the same approach we did in commit 44ecf9a0c7c25496a43f59f1c8f20df9527e12cb. See https://github.com/bazelbuild/bazel/issues/2107 See https://github.com/bazelbuild/bazel/issues/2181 -- PiperOrigin-RevId: 144613589 MOS_MIGRATED_REVID=144613589
* Windows, JNI: use RAII pattern + clean up gotosGravatar Laszlo Csomor2017-01-13
| | | | | | | | | | | Introduce helper classes whose d'tor automatically release resources (close handles, release Java object handles, etc) and get rid of the "goto cleanup" pattern. -- PiperOrigin-RevId: 144349886 MOS_MIGRATED_REVID=144349886
* Windows, JNI: use CreateFileW for std* redirectionGravatar Laszlo Csomor2017-01-12
| | | | | | | | | | | | | | Use CreateFileW to create the output files for redirected stdout/stderr in nativeCreateProcess. This way we can support long paths for these files. See https://github.com/bazelbuild/bazel/issues/2107 See https://github.com/bazelbuild/bazel/issues/2181 -- PiperOrigin-RevId: 144311729 MOS_MIGRATED_REVID=144311729
* Windows, JNI: arg for argv0 in nativeCreateProcessGravatar Laszlo Csomor2017-01-12
| | | | | | | | | | | | | | | | | | | Add a separate argument to nativeCreateProcess for argv[0] specifically, and another for the rest of the args. In a subsequent change I'll add code to compute the 8dot3 style short name of the argv[0] so we can use longer paths for executables in CreateProcessA than we normally could. This is the same approach as used in commit 44ecf9a0c7c25496a43f59f1c8f20df9527e12cb See https://github.com/bazelbuild/bazel/issues/2107 See https://github.com/bazelbuild/bazel/issues/2181 -- PiperOrigin-RevId: 144311562 MOS_MIGRATED_REVID=144311562
* Windows JNI: remove dead code, extract constantGravatar Laszlo Csomor2016-12-19
| | | | | | -- PiperOrigin-RevId: 142430323 MOS_MIGRATED_REVID=142430323
* Up the MD5-reading buffer size to 8192. This keeps us within a 16K stack ↵Gravatar Googler2016-12-16
| | | | | | | | size while halving the number of syscalls required to get an MD5 of a file. This shaves a few hundred milliseconds off of startup time. -- PiperOrigin-RevId: 142235555 MOS_MIGRATED_REVID=142235555
* Windows, JNI: implement nativeGetLongPathGravatar Laszlo Csomor2016-12-15
| | | | | | | | | | | | | | | | | | | | Implement a JNI method that can resolve 8dot3 style paths. This is necessary because we need to be able to compare 8dot3 style paths and long paths [1], and because implementing this correctly in Java seems to be impossible [2]. This change also adds tests for the JNI isJunction implementation. See https://github.com/bazelbuild/bazel/issues/2101 [1] https://github.com/bazelbuild/bazel/issues/2145 [2] https://github.com/bazelbuild/bazel/issues/2145#issuecomment-266766716 -- PiperOrigin-RevId: 142123750 MOS_MIGRATED_REVID=142123750
* Windows, JNI: build the DLL with /O2 optimizationGravatar Laszlo Csomor2016-12-14
| | | | | | -- PiperOrigin-RevId: 141939490 MOS_MIGRATED_REVID=141939490
* Windows JNI library: prepare for widechar WinAPIGravatar Laszlo Csomor2016-12-06
| | | | | | | | | | | | | | | | | | This change: - renames windows_error_handling.* to windows_util.* - moves most stuff except for the JNI method implementations into the new windows_util namespace - implements a jstring to wchar string converter - uses GetFileAttributesW in windows_file_operations.cc See https://github.com/bazelbuild/bazel/issues/2181 -- PiperOrigin-RevId: 141187291 MOS_MIGRATED_REVID=141187291
* Windows: explicitly use ASCII-version of Win32 APIGravatar Laszlo Csomor2016-12-05
| | | | | | | | | | | This way it's easier to find the functions we need to change to widechar version. See https://github.com/bazelbuild/bazel/issues/2181 -- PiperOrigin-RevId: 141043389 MOS_MIGRATED_REVID=141043389
* Bazel client: platform-specific {Read,Write}FileGravatar Laszlo Csomor2016-11-28
| | | | | | | | | | | | | | | | Move blaze::ReadFile and blaze::WriteFile to file.h and file_platform.h (thus into the blaze_util namespace), and update references. This allows us to implement these methods in a platform-specific way. Also move UnlinkPath. See https://github.com/bazelbuild/bazel/issues/2107 -- MOS_MIGRATED_REVID=140328273
* --watchfs for OSX: use kFSEventStreamCreateFlagNoDefer to receive event as ↵Gravatar Damien Martin-Guillerez2016-10-14
| | | | | | | | | | | | | | | | soon as they arrives See https://developer.apple.com/reference/coreservices/1455376-fseventstreamcreateflags/kfseventstreamcreateflagnodefer?language=objc Also added the integration test now it is no more flaky. Tested with `bazel test src/test/java/com/google/devtools/build/lib/skyframe:SkyframeTests --runs_per_test 10 --test_filter=com.google.devtools.build.lib.skyframe.MacOSXFsEventsDiffAwarenessTest --nocache_test_results` Fixes #1362. -- Change-Id: I42ceebd8c5a2e0156653b140ca049af45d2e1e80 Reviewed-on: https://bazel-review.googlesource.com/6613 MOS_MIGRATED_REVID=136078777
* Patches to compile against muslGravatar Steven Dee2016-10-07
| | | | | | | | | Tested with the alpine:3.4 Docker image. -- Change-Id: I8f3e585051988d8fd437ccd69c9c7bd009fd45d2 Reviewed-on: https://bazel-review.googlesource.com/#/c/5790/ MOS_MIGRATED_REVID=135468656
* Enable exception handing for built-in windows headersGravatar Peter Foley2016-10-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | INFO: From Executing genrule //src/main/native:windows_jni: C:\tools\msys64\tmp\bazel_7uQBlyR9\out\execroot\bazel>call "C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/VCVARSALL.BAT" amd64 windows_error_handling.cc C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\xlocale(341): warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\exception(359): warning C4577: 'noexcept' used with no exception handling mode specified; termination on exception is not guaranteed. Specify /EHsc windows_file_operations.cc C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\xlocale(341): warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\exception(359): warning C4577: 'noexcept' used with no exception handling mode specified; termination on exception is not guaranteed. Specify /EHsc windows_processes.cc C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\xlocale(341): warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\iosfwd(343): warning C4577: 'noexcept' used with no exception handling mode specified; termination on exception is not guaranteed. Specify /EHsc -- Change-Id: I6f93a4dbb1be42fa5bea221402fb71a830960cf6 Reviewed-on: https://bazel-review.googlesource.com/#/c/6130 MOS_MIGRATED_REVID=135458066
* Remove support for using AF_UNIX to communicate between the Bazel cient and ↵Gravatar Lukacs Berki2016-10-07
| | | | | | | | | the Bazel server. RELNOTES[INC]: --command_port=-1 to use AF_UNIX for client/server communications is not supported anymore. -- MOS_MIGRATED_REVID=135355673
* Make cc_configure on Windows more robustGravatar Yun Peng2016-09-28
| | | | | | | | | | | | | 1. Throw an error if Bash-on-Windows is found instead of MSYS bash 2. Introduce BAZEL_VS environment variable 3. Output more information Fix https://github.com/bazelbuild/bazel/issues/1847 -- Change-Id: Ic4571c6c792d9b81df4cd800b8f19d121cc44c33 Reviewed-on: https://bazel-review.googlesource.com/#/c/6330 MOS_MIGRATED_REVID=134531295
* Windows, bootstrapping: do not build JNI library.Gravatar Laszlo Csomor2016-09-28
| | | | | | | | | | Since commit 94d905836c167a21d2321d26c646fde07f5fc522 we no longer need JNI for WindowsFileSystem.isJunction. This is a partial rollback of commit 4a249b6962d32ed4cfd4165dfdae4a555b00bb69. Affects https://github.com/bazelbuild/bazel/issues/1680 -- MOS_MIGRATED_REVID=134506403
* Put stdout and stderr streams into a consistent state when they are redirected.Gravatar Lukacs Berki2016-09-12
| | | | | | | Fixes #1755. -- MOS_MIGRATED_REVID=132861187
* Tentative fix for #1747.Gravatar Lukacs Berki2016-09-12
| | | | | | | The the theory is that the closing the file handle when the process terminates races with the reader threads, and if the closing happens not while a system call is running but between two, nativeReadStream() would return an error. -- MOS_MIGRATED_REVID=132851092
* Windows, JNI: use native isJunction method.Gravatar Laszlo Csomor2016-09-06
| | | | | | | Fixes https://github.com/bazelbuild/bazel/issues/1680 -- MOS_MIGRATED_REVID=132051176
* Windows, JNI: implement native isJunction method.Gravatar Laszlo Csomor2016-09-06
| | | | | | | WindowsFileSystem.java does not yet use it. -- MOS_MIGRATED_REVID=132043739
* Close stdout/stderr pipes when the main process of an action terminates so ↵Gravatar Lukacs Berki2016-09-01
| | | | | | | | | | | | | that we can properly finish reading from it even if it passed them on to a subprocess that did *not* terminate. The alternative would be to rely on job control. Fixes #1708. Hopefully. Tested by running test_cpp 10 times and observing that it doesn't hang. -- MOS_MIGRATED_REVID=131945117
* Windows, JNI: extract error reporting to a file.Gravatar Laszlo Csomor2016-08-31
| | | | | | | | | | | | | This change creates a separate file for GetLastErrorString and updates the BUILD file and windows_jni.dll builder script. A subsequent change will add a new source for file operations implemented in C++, so the BUILD file updates in this change are necessary preparations for that. -- MOS_MIGRATED_REVID=131804375
* Bazel shell scripts: fix links in licence comments.Gravatar Laszlo Csomor2016-08-24
| | | | | | | I suspect they were overwritten by an eager sed "s,//,#,g" command. -- MOS_MIGRATED_REVID=131159373
* Implement timeouts on Windows.Gravatar Lukacs Berki2016-08-22
| | | | | | | Makes #1664 much less acute. -- MOS_MIGRATED_REVID=130750731
* Rollback of commit f107debac45ddf5859b1eb963379769b5815b18f. Also includes ↵Gravatar Janak Ramakrishnan2016-08-12
| | | | | | | | | the logical rollback of commit 67ad82a319ff8959e69e774e7c15d3af904ec23d. RELNOTES[INC]: Bazel supports Unix domain sockets for communication between its client and server again, temporarily, while we diagnose a memory leak. -- MOS_MIGRATED_REVID=130027009
* Remove the AF_UNIX client/server communication protocol.Gravatar Lukacs Berki2016-08-05
| | | | | | | | | It has been superseded by gRPC. RELNOTES[INC]: Blaze doesn't support Unix domain sockets for communication between its client and server anymore. Therefore, the --command_port command line argument doesn't accept -1 as a valid value anymore. -- MOS_MIGRATED_REVID=129424092
* Fix various breakages in Windows process handling that creeped in because we ↵Gravatar Lukacs T. Berki2016-07-20
| | | | | | | | | | | | | | weren't actually running the test: - Call TerminateProcess() only if the process handle is still open - Update the tests so that they expect a return value of 0 when reading a stream from a non-existent process Fixes #1538 . -- Change-Id: I4de28abbba2e2e89f285d7b8fb75bcd9af345f14 Reviewed-on: https://bazel-review.googlesource.com/4100 MOS_MIGRATED_REVID=127935621
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-07 06:17:21 +0000