{"id":17305936,"url":"https://github.com/s8sg/branching-in-faas-flow","last_synced_at":"2026-01-11T23:57:13.393Z","repository":{"id":83013946,"uuid":"192318997","full_name":"s8sg/branching-in-faas-flow","owner":"s8sg","description":"Super simple branching examples for faas-flow (https://github.com/s8sg/faas-flow)","archived":false,"fork":false,"pushed_at":"2019-10-17T06:04:24.000Z","size":28543,"stargazers_count":2,"open_issues_count":0,"forks_count":1,"subscribers_count":1,"default_branch":"master","last_synced_at":"2025-07-05T02:45:03.433Z","etag":null,"topics":["branching","condition","dynamic","example","faas-flow","foreach"],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/s8sg.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2019-06-17T09:44:05.000Z","updated_at":"2023-08-22T10:50:05.000Z","dependencies_parsed_at":null,"dependency_job_id":"f78bc7a9-b231-4c0a-880c-00f7de82a1be","html_url":"https://github.com/s8sg/branching-in-faas-flow","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/s8sg/branching-in-faas-flow","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/s8sg%2Fbranching-in-faas-flow","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/s8sg%2Fbranching-in-faas-flow/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/s8sg%2Fbranching-in-faas-flow/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/s8sg%2Fbranching-in-faas-flow/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/s8sg","download_url":"https://codeload.github.com/s8sg/branching-in-faas-flow/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/s8sg%2Fbranching-in-faas-flow/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":265205685,"owners_count":23727511,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["branching","condition","dynamic","example","faas-flow","foreach"],"created_at":"2024-10-15T11:57:07.274Z","updated_at":"2026-01-11T23:57:13.355Z","avatar_url":"https://github.com/s8sg.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Building `sys/unix`\n\nThe sys/unix package provides access to the raw system call interface of the\nunderlying operating system. See: https://godoc.org/golang.org/x/sys/unix\n\nPorting Go to a new architecture/OS combination or adding syscalls, types, or\nconstants to an existing architecture/OS pair requires some manual effort;\nhowever, there are tools that automate much of the process.\n\n## Build Systems\n\nThere are currently two ways we generate the necessary files. We are currently\nmigrating the build system to use containers so the builds are reproducible.\nThis is being done on an OS-by-OS basis. Please update this documentation as\ncomponents of the build system change.\n\n### Old Build System (currently for `GOOS != \"Linux\" || GOARCH == \"sparc64\"`)\n\nThe old build system generates the Go files based on the C header files\npresent on your system. This means that files\nfor a given GOOS/GOARCH pair must be generated on a system with that OS and\narchitecture. This also means that the generated code can differ from system\nto system, based on differences in the header files.\n\nTo avoid this, if you are using the old build system, only generate the Go\nfiles on an installation with unmodified header files. It is also important to\nkeep track of which version of the OS the files were generated from (ex.\nDarwin 14 vs Darwin 15). This makes it easier to track the progress of changes\nand have each OS upgrade correspond to a single change.\n\nTo build the files for your current OS and architecture, make sure GOOS and\nGOARCH are set correctly and run `mkall.sh`. This will generate the files for\nyour specific system. Running `mkall.sh -n` shows the commands that will be run.\n\nRequirements: bash, perl, go\n\n### New Build System (currently for `GOOS == \"Linux\" \u0026\u0026 GOARCH != \"sparc64\"`)\n\nThe new build system uses a Docker container to generate the go files directly\nfrom source checkouts of the kernel and various system libraries. This means\nthat on any platform that supports Docker, all the files using the new build\nsystem can be generated at once, and generated files will not change based on\nwhat the person running the scripts has installed on their computer.\n\nThe OS specific files for the new build system are located in the `${GOOS}`\ndirectory, and the build is coordinated by the `${GOOS}/mkall.go` program. When\nthe kernel or system library updates, modify the Dockerfile at\n`${GOOS}/Dockerfile` to checkout the new release of the source.\n\nTo build all the files under the new build system, you must be on an amd64/Linux\nsystem and have your GOOS and GOARCH set accordingly. Running `mkall.sh` will\nthen generate all of the files for all of the GOOS/GOARCH pairs in the new build\nsystem. Running `mkall.sh -n` shows the commands that will be run.\n\nRequirements: bash, perl, go, docker\n\n## Component files\n\nThis section describes the various files used in the code generation process.\nIt also contains instructions on how to modify these files to add a new\narchitecture/OS or to add additional syscalls, types, or constants. Note that\nif you are using the new build system, the scripts cannot be called normally.\nThey must be called from within the docker container.\n\n### asm files\n\nThe hand-written assembly file at `asm_${GOOS}_${GOARCH}.s` implements system\ncall dispatch. There are three entry points:\n```\n  func Syscall(trap, a1, a2, a3 uintptr) (r1, r2, err uintptr)\n  func Syscall6(trap, a1, a2, a3, a4, a5, a6 uintptr) (r1, r2, err uintptr)\n  func RawSyscall(trap, a1, a2, a3 uintptr) (r1, r2, err uintptr)\n```\nThe first and second are the standard ones; they differ only in how many\narguments can be passed to the kernel. The third is for low-level use by the\nForkExec wrapper. Unlike the first two, it does not call into the scheduler to\nlet it know that a system call is running.\n\nWhen porting Go to an new architecture/OS, this file must be implemented for\neach GOOS/GOARCH pair.\n\n### mksysnum\n\nMksysnum is a script located at `${GOOS}/mksysnum.pl` (or `mksysnum_${GOOS}.pl`\nfor the old system). This script takes in a list of header files containing the\nsyscall number declarations and parses them to produce the corresponding list of\nGo numeric constants. See `zsysnum_${GOOS}_${GOARCH}.go` for the generated\nconstants.\n\nAdding new syscall numbers is mostly done by running the build on a sufficiently\nnew installation of the target OS (or updating the source checkouts for the\nnew build system). However, depending on the OS, you make need to update the\nparsing in mksysnum.\n\n### mksyscall.pl\n\nThe `syscall.go`, `syscall_${GOOS}.go`, `syscall_${GOOS}_${GOARCH}.go` are\nhand-written Go files which implement system calls (for unix, the specific OS,\nor the specific OS/Architecture pair respectively) that need special handling\nand list `//sys` comments giving prototypes for ones that can be generated.\n\nThe mksyscall.pl script takes the `//sys` and `//sysnb` comments and converts\nthem into syscalls. This requires the name of the prototype in the comment to\nmatch a syscall number in the `zsysnum_${GOOS}_${GOARCH}.go` file. The function\nprototype can be exported (capitalized) or not.\n\nAdding a new syscall often just requires adding a new `//sys` function prototype\nwith the desired arguments and a capitalized name so it is exported. However, if\nyou want the interface to the syscall to be different, often one will make an\nunexported `//sys` prototype, an then write a custom wrapper in\n`syscall_${GOOS}.go`.\n\n### types files\n\nFor each OS, there is a hand-written Go file at `${GOOS}/types.go` (or\n`types_${GOOS}.go` on the old system). This file includes standard C headers and\ncreates Go type aliases to the corresponding C types. The file is then fed\nthrough godef to get the Go compatible definitions. Finally, the generated code\nis fed though mkpost.go to format the code correctly and remove any hidden or\nprivate identifiers. This cleaned-up code is written to\n`ztypes_${GOOS}_${GOARCH}.go`.\n\nThe hardest part about preparing this file is figuring out which headers to\ninclude and which symbols need to be `#define`d to get the actual data\nstructures that pass through to the kernel system calls. Some C libraries\npreset alternate versions for binary compatibility and translate them on the\nway in and out of system calls, but there is almost always a `#define` that can\nget the real ones.\nSee `types_darwin.go` and `linux/types.go` for examples.\n\nTo add a new type, add in the necessary include statement at the top of the\nfile (if it is not already there) and add in a type alias line. Note that if\nyour type is significantly different on different architectures, you may need\nsome `#if/#elif` macros in your include statements.\n\n### mkerrors.sh\n\nThis script is used to generate the system's various constants. This doesn't\njust include the error numbers and error strings, but also the signal numbers\nan a wide variety of miscellaneous constants. The constants come from the list\nof include files in the `includes_${uname}` variable. A regex then picks out\nthe desired `#define` statements, and generates the corresponding Go constants.\nThe error numbers and strings are generated from `#include \u003cerrno.h\u003e`, and the\nsignal numbers and strings are generated from `#include \u003csignal.h\u003e`. All of\nthese constants are written to `zerrors_${GOOS}_${GOARCH}.go` via a C program,\n`_errors.c`, which prints out all the constants.\n\nTo add a constant, add the header that includes it to the appropriate variable.\nThen, edit the regex (if necessary) to match the desired constant. Avoid making\nthe regex too broad to avoid matching unintended constants.\n\n\n## Generated files\n\n### `zerror_${GOOS}_${GOARCH}.go`\n\nA file containing all of the system's generated error numbers, error strings,\nsignal numbers, and constants. Generated by `mkerrors.sh` (see above).\n\n### `zsyscall_${GOOS}_${GOARCH}.go`\n\nA file containing all the generated syscalls for a specific GOOS and GOARCH.\nGenerated by `mksyscall.pl` (see above).\n\n### `zsysnum_${GOOS}_${GOARCH}.go`\n\nA list of numeric constants for all the syscall number of the specific GOOS\nand GOARCH. Generated by mksysnum (see above).\n\n### `ztypes_${GOOS}_${GOARCH}.go`\n\nA file containing Go types for passing into (or returning from) syscalls.\nGenerated by godefs and the types file (see above).\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fs8sg%2Fbranching-in-faas-flow","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fs8sg%2Fbranching-in-faas-flow","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fs8sg%2Fbranching-in-faas-flow/lists"}