BranchesTags

Latest commit

History

42 Commits

Folders and files

NameName
Last commit message
Last commit date
.cargo
.cargo
src
src
.gitignore
.gitignore
Cargo.lock
Cargo.lock
Cargo.toml
Cargo.toml
LICENSE
LICENSE
README.md
README.md

Repository files navigation

system_platform

Linux syscalls in inline assembly from Rust (instead of using libc)-- just for fun.

This is primarily a learning exercise for me, I recently discovered a bunch of other crates that have already done this.

Current small feature set is supported on ARM64, ARM32, and x86_64.

Features

  • a syscall! macro which factors out the syscall calling conventions for the major architectures.
  • light wrapping functions for the syscalls above at the would-be-libc level of abstraction

Interesting effects of this approach

  1. This can be used to write #![no_std] programs that run on Linux.
  • To try this out, build the binary provided with the following cargo options: cargo build --target x86_64-unknown-none --no-default-features.
  • This works only when using relocation-model=static, which has been added to .cargo/config.toml
  • TODO: what does it take to support PIC? I believe the PLT / GOT runtime stuff would have to be implemented.
  1. As a result of 1, these executables would not depend on libc and might be a little more portable. From what I understand, Go uses this approach.

Future directions

Given infinite time and a better source of documentation, this could be used to provide std & alloc support for the x86_64-unknown-linux-none target.

Usefulness or lack thereof

This project is only for fun. If you want the benefits of this library with stability and support, statically link musl.

I will say though, that if a similar implementation were created for MacOS (perhaps some or even most of these syscalls are the same given shared Unix heritage), it could solve the horrendous headache of cross-compilation for a Mac, which can only currently be done by jumping through licensing hoops and copying the MacOS SDK out of Xcode... yada yada. However, I looked into this a little more and Apple claims that the syscall interface is unstable and to use all the MacOS SDK crap. Big suprise there. But should we listen?

About

Syscalls in inline assembly from Rust (instead of using libc)-- just for fun.

Resources

Readme
Unlicense
Activity

Stars

0 stars

Watchers

1 watching

Forks

0 forks
Report repository

Releases

Packages

Used by

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
BranchesTags
Latest commit
History
42 Commits
Folders and files
NameName
Last commit message
Last commit date
.cargo
.cargo
src
src
.gitignore
.gitignore
Cargo.lock
Cargo.lock
Cargo.toml
Cargo.toml
LICENSE
LICENSE
README.md
README.md
Repository files navigation
system_platform
Linux syscalls in inline assembly from Rust (instead of using libc)-- just for fun.
This is primarily a learning exercise for me, I recently discovered a bunch of
other crates that have already done this.
Current small feature set is supported on ARM64, ARM32, and x86_64.
Features
  • a syscall! macro which factors out the syscall calling conventions for the
major architectures.
  • light wrapping functions for the syscalls above at the would-be-libc level of
abstraction
Interesting effects of this approach
  1. This can be used to write #![no_std] programs that run on Linux.
  • To try this out, build the binary provided with the following cargo options:
cargo build --target x86_64-unknown-none --no-default-features.
  • This works only when using relocation-model=static, which has been added
to .cargo/config.toml
  • TODO: what does it take to support PIC? I believe the PLT / GOT runtime
stuff would have to be implemented.
  1. As a result of 1, these executables would not depend on libc and might be a
little more portable. From what I understand, Go uses this approach.
Future directions
Given infinite time and a better source of documentation, this could be used to
provide std & alloc support for the
x86_64-unknown-linux-none target.
Usefulness or lack thereof
This project is only for fun. If you want the benefits of this library with
stability and support, statically link musl.
I will say though, that if a similar implementation were created for MacOS
(perhaps some or even most of these syscalls are the same given shared Unix
heritage), it could solve the horrendous headache of cross-compilation for a
Mac, which can only currently be done by jumping through licensing hoops and
copying the MacOS SDK out of Xcode... yada yada. However, I looked into this a
little more and Apple claims that the syscall interface is unstable and to use
all the MacOS SDK crap. Big suprise there. But should we listen?
About
Syscalls in inline assembly from Rust (instead of using libc)-- just for fun.
Resources
Readme
Unlicense
Activity
Stars
0 stars
Watchers
1 watching
Forks
0 forks
Report repository
Releases
Packages
Used by
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Latest commit
History
42 Commits
Folders and files
NameName
Last commit message
Last commit date
.cargo
.cargo
src
src
.gitignore
.gitignore
Cargo.lock
Cargo.lock
Cargo.toml
Cargo.toml
LICENSE
LICENSE
README.md
README.md
Repository files navigation
system_platform
Linux syscalls in inline assembly from Rust (instead of using libc)-- just for fun.
This is primarily a learning exercise for me, I recently discovered a bunch of
other crates that have already done this.
Current small feature set is supported on ARM64, ARM32, and x86_64.
Features
  • a syscall! macro which factors out the syscall calling conventions for the
major architectures.
  • light wrapping functions for the syscalls above at the would-be-libc level of
abstraction
Interesting effects of this approach
  1. This can be used to write #![no_std] programs that run on Linux.
  • To try this out, build the binary provided with the following cargo options:
cargo build --target x86_64-unknown-none --no-default-features.
  • This works only when using relocation-model=static, which has been added
to .cargo/config.toml
  • TODO: what does it take to support PIC? I believe the PLT / GOT runtime
stuff would have to be implemented.
  1. As a result of 1, these executables would not depend on libc and might be a
little more portable. From what I understand, Go uses this approach.
Future directions
Given infinite time and a better source of documentation, this could be used to
provide std & alloc support for the
x86_64-unknown-linux-none target.
Usefulness or lack thereof
This project is only for fun. If you want the benefits of this library with
stability and support, statically link musl.
I will say though, that if a similar implementation were created for MacOS
(perhaps some or even most of these syscalls are the same given shared Unix
heritage), it could solve the horrendous headache of cross-compilation for a
Mac, which can only currently be done by jumping through licensing hoops and
copying the MacOS SDK out of Xcode... yada yada. However, I looked into this a
little more and Apple claims that the syscall interface is unstable and to use
all the MacOS SDK crap. Big suprise there. But should we listen?
About
Syscalls in inline assembly from Rust (instead of using libc)-- just for fun.
Resources
Readme
Unlicense
Activity
Stars
0 stars
Watchers
1 watching
Forks
0 forks
Report repository
Releases
Packages
Used by
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Latest commit
History
42 Commits
Folders and files
NameName
Last commit message
Last commit date
.cargo
.cargo
src
src
.gitignore
.gitignore
Cargo.lock
Cargo.lock
Cargo.toml
Cargo.toml
LICENSE
LICENSE
README.md
README.md
Repository files navigation
system_platform
Linux syscalls in inline assembly from Rust (instead of using libc)-- just for fun.
This is primarily a learning exercise for me, I recently discovered a bunch of
other crates that have already done this.
Current small feature set is supported on ARM64, ARM32, and x86_64.
Features
  • a syscall! macro which factors out the syscall calling conventions for the
major architectures.
  • light wrapping functions for the syscalls above at the would-be-libc level of
abstraction
Interesting effects of this approach
  1. This can be used to write #![no_std] programs that run on Linux.
  • To try this out, build the binary provided with the following cargo options:
cargo build --target x86_64-unknown-none --no-default-features.
  • This works only when using relocation-model=static, which has been added
to .cargo/config.toml
  • TODO: what does it take to support PIC? I believe the PLT / GOT runtime
stuff would have to be implemented.
  1. As a result of 1, these executables would not depend on libc and might be a
little more portable. From what I understand, Go uses this approach.
Future directions
Given infinite time and a better source of documentation, this could be used to
provide std & alloc support for the
x86_64-unknown-linux-none target.
Usefulness or lack thereof
This project is only for fun. If you want the benefits of this library with
stability and support, statically link musl.
I will say though, that if a similar implementation were created for MacOS
(perhaps some or even most of these syscalls are the same given shared Unix
heritage), it could solve the horrendous headache of cross-compilation for a
Mac, which can only currently be done by jumping through licensing hoops and
copying the MacOS SDK out of Xcode... yada yada. However, I looked into this a
little more and Apple claims that the syscall interface is unstable and to use
all the MacOS SDK crap. Big suprise there. But should we listen?
About
Syscalls in inline assembly from Rust (instead of using libc)-- just for fun.
Resources
Readme
Unlicense
Activity
Stars
0 stars
Watchers
1 watching
Forks
0 forks
Report repository
Releases
Packages
Used by
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
BranchesTags
Latest commit
History
42 Commits
Folders and files
NameName
Last commit message
Last commit date
.cargo
.cargo
src
src
.gitignore
.gitignore
Cargo.lock
Cargo.lock
Cargo.toml
Cargo.toml
LICENSE
LICENSE
README.md
README.md
Repository files navigation
system_platform
Linux syscalls in inline assembly from Rust (instead of using libc)-- just for fun.
This is primarily a learning exercise for me, I recently discovered a bunch of
other crates that have already done this.
Current small feature set is supported on ARM64, ARM32, and x86_64.
Features
  • a syscall! macro which factors out the syscall calling conventions for the
major architectures.
  • light wrapping functions for the syscalls above at the would-be-libc level of
abstraction
Interesting effects of this approach
  1. This can be used to write #![no_std] programs that run on Linux.
  • To try this out, build the binary provided with the following cargo options:
cargo build --target x86_64-unknown-none --no-default-features.
  • This works only when using relocation-model=static, which has been added
to .cargo/config.toml
  • TODO: what does it take to support PIC? I believe the PLT / GOT runtime
stuff would have to be implemented.
  1. As a result of 1, these executables would not depend on libc and might be a
little more portable. From what I understand, Go uses this approach.
Future directions
Given infinite time and a better source of documentation, this could be used to
provide std & alloc support for the
x86_64-unknown-linux-none target.
Usefulness or lack thereof
This project is only for fun. If you want the benefits of this library with
stability and support, statically link musl.
I will say though, that if a similar implementation were created for MacOS
(perhaps some or even most of these syscalls are the same given shared Unix
heritage), it could solve the horrendous headache of cross-compilation for a
Mac, which can only currently be done by jumping through licensing hoops and
copying the MacOS SDK out of Xcode... yada yada. However, I looked into this a
little more and Apple claims that the syscall interface is unstable and to use
all the MacOS SDK crap. Big suprise there. But should we listen?
About
Syscalls in inline assembly from Rust (instead of using libc)-- just for fun.
Resources
Readme
Unlicense
Activity
Stars
0 stars
Watchers
1 watching
Forks
0 forks
Report repository
Releases
Packages
Used by
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Latest commit
History
42 Commits
Folders and files
NameName
Last commit message
Last commit date
.cargo
.cargo
src
src
.gitignore
.gitignore
Cargo.lock
Cargo.lock
Cargo.toml
Cargo.toml
LICENSE
LICENSE
README.md
README.md
Repository files navigation
system_platform
Linux syscalls in inline assembly from Rust (instead of using libc)-- just for fun.
This is primarily a learning exercise for me, I recently discovered a bunch of
other crates that have already done this.
Current small feature set is supported on ARM64, ARM32, and x86_64.
Features
  • a syscall! macro which factors out the syscall calling conventions for the
major architectures.
  • light wrapping functions for the syscalls above at the would-be-libc level of
abstraction
Interesting effects of this approach
  1. This can be used to write #![no_std] programs that run on Linux.
  • To try this out, build the binary provided with the following cargo options:
cargo build --target x86_64-unknown-none --no-default-features.
  • This works only when using relocation-model=static, which has been added
to .cargo/config.toml
  • TODO: what does it take to support PIC? I believe the PLT / GOT runtime
stuff would have to be implemented.
  1. As a result of 1, these executables would not depend on libc and might be a
little more portable. From what I understand, Go uses this approach.
Future directions
Given infinite time and a better source of documentation, this could be used to
provide std & alloc support for the
x86_64-unknown-linux-none target.
Usefulness or lack thereof
This project is only for fun. If you want the benefits of this library with
stability and support, statically link musl.
I will say though, that if a similar implementation were created for MacOS
(perhaps some or even most of these syscalls are the same given shared Unix
heritage), it could solve the horrendous headache of cross-compilation for a
Mac, which can only currently be done by jumping through licensing hoops and
copying the MacOS SDK out of Xcode... yada yada. However, I looked into this a
little more and Apple claims that the syscall interface is unstable and to use
all the MacOS SDK crap. Big suprise there. But should we listen?
About
Syscalls in inline assembly from Rust (instead of using libc)-- just for fun.
Resources
Readme
Unlicense
Activity
Stars
0 stars
Watchers
1 watching
Forks
0 forks
Report repository
Releases
Packages
Used by
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Latest commit
History
42 Commits
Folders and files
NameName
Last commit message
Last commit date
.cargo
.cargo
src
src
.gitignore
.gitignore
Cargo.lock
Cargo.lock
Cargo.toml
Cargo.toml
LICENSE
LICENSE
README.md
README.md
Repository files navigation
system_platform
Linux syscalls in inline assembly from Rust (instead of using libc)-- just for fun.
This is primarily a learning exercise for me, I recently discovered a bunch of
other crates that have already done this.
Current small feature set is supported on ARM64, ARM32, and x86_64.
Features
  • a syscall! macro which factors out the syscall calling conventions for the
major architectures.
  • light wrapping functions for the syscalls above at the would-be-libc level of
abstraction
Interesting effects of this approach
  1. This can be used to write #![no_std] programs that run on Linux.
  • To try this out, build the binary provided with the following cargo options:
cargo build --target x86_64-unknown-none --no-default-features.
  • This works only when using relocation-model=static, which has been added
to .cargo/config.toml
  • TODO: what does it take to support PIC? I believe the PLT / GOT runtime
stuff would have to be implemented.
  1. As a result of 1, these executables would not depend on libc and might be a
little more portable. From what I understand, Go uses this approach.
Future directions
Given infinite time and a better source of documentation, this could be used to
provide std & alloc support for the
x86_64-unknown-linux-none target.
Usefulness or lack thereof
This project is only for fun. If you want the benefits of this library with
stability and support, statically link musl.
I will say though, that if a similar implementation were created for MacOS
(perhaps some or even most of these syscalls are the same given shared Unix
heritage), it could solve the horrendous headache of cross-compilation for a
Mac, which can only currently be done by jumping through licensing hoops and
copying the MacOS SDK out of Xcode... yada yada. However, I looked into this a
little more and Apple claims that the syscall interface is unstable and to use
all the MacOS SDK crap. Big suprise there. But should we listen?
About
Syscalls in inline assembly from Rust (instead of using libc)-- just for fun.
Resources
Readme
Unlicense
Activity
Stars
0 stars
Watchers
1 watching
Forks
0 forks
Report repository
Releases
Packages
Used by
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
BranchesTags
Latest commit
History
42 Commits
Folders and files
NameName
Last commit message
Last commit date
.cargo
.cargo
src
src
.gitignore
.gitignore
Cargo.lock
Cargo.lock
Cargo.toml
Cargo.toml
LICENSE
LICENSE
README.md
README.md
Repository files navigation
system_platform
Linux syscalls in inline assembly from Rust (instead of using libc)-- just for fun.
This is primarily a learning exercise for me, I recently discovered a bunch of
other crates that have already done this.
Current small feature set is supported on ARM64, ARM32, and x86_64.
Features
  • a syscall! macro which factors out the syscall calling conventions for the
major architectures.
  • light wrapping functions for the syscalls above at the would-be-libc level of
abstraction
Interesting effects of this approach
  1. This can be used to write #![no_std] programs that run on Linux.
  • To try this out, build the binary provided with the following cargo options:
cargo build --target x86_64-unknown-none --no-default-features.
  • This works only when using relocation-model=static, which has been added
to .cargo/config.toml
  • TODO: what does it take to support PIC? I believe the PLT / GOT runtime
stuff would have to be implemented.
  1. As a result of 1, these executables would not depend on libc and might be a
little more portable. From what I understand, Go uses this approach.
Future directions
Given infinite time and a better source of documentation, this could be used to
provide std & alloc support for the
x86_64-unknown-linux-none target.
Usefulness or lack thereof
This project is only for fun. If you want the benefits of this library with
stability and support, statically link musl.
I will say though, that if a similar implementation were created for MacOS
(perhaps some or even most of these syscalls are the same given shared Unix
heritage), it could solve the horrendous headache of cross-compilation for a
Mac, which can only currently be done by jumping through licensing hoops and
copying the MacOS SDK out of Xcode... yada yada. However, I looked into this a
little more and Apple claims that the syscall interface is unstable and to use
all the MacOS SDK crap. Big suprise there. But should we listen?
About
Syscalls in inline assembly from Rust (instead of using libc)-- just for fun.
Resources
Readme
Unlicense
Activity
Stars
0 stars
Watchers
1 watching
Forks
0 forks
Report repository
Releases
Packages
Used by
Contributors
Languages