![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
---
lua libs/frameworks/etc:
https://love2d.org/ https://github.com/kikito/middleclass (oop) https://github.com/mikelovesrobots/lua-enumerable A port of ruby's Enumerable module to Lua https://github.com/makotok/Hanappe/tree/master/projects/hanappe-framework/src/hp/lang http://moonscript.org/ a dynamic scripting language that compiles into Lua http://leafo.net/lapis/ web framework for lua or moonscript https://github.com/leafo/moonlisp Lisp variant that compiles directly to Lua ; written in MoonScript? and depends on the MoonScript? runtime
---
Rust has a small, platform-independent library 'libcore', and a larger 'libstd':
" The largest new feature in 1.6 is that libcore is now stable! Rust’s standard library is two-tiered: there’s a small core library, libcore, and the full standard library, libstd, that builds on top of it. libcore is completely platform agnostic, and requires only a handful of external symbols to be defined. Rust’s libstd builds on top of libcore, adding support for memory allocation, I/O, and concurrency. Applications using Rust in the embedded space, as well as those writing operating systems, often eschew libstd, using only libcore. "
---
check out Rust's crates versioning spec:
" [dependencies] glob = "0.0.3" num = "0.0.4"
The string value for each key in this table is a semver version requirement.
Caret requirements allow SemVer? compatible updates to a specified version.
^1.2.3 is an example of a caret requirement.
When considering “compatible” versions, 0.1 and 0.2 are not considered compatible, but 1.0 and 1.1 are for example. If no operator is specified, this is the default requirement (e.g. 1.3 is the same as ^1.3).
0.0.x is not considered compatible with any other version. Missing minor and patch versions are desugared to 0 but allow flexibility for that value.
^1.2.3 := >=1.2.3 <2.0.0 ^0.2.3 := >=0.2.3 <0.3.0 ^0.0.3 := >=0.0.3 <0.0.4 ^0.0 := >=0.0.0 <0.1.0 ^0 := >=0.0.0 <1.0.0
Tilde requirements specify a minimal version with some ability to update.
~1.2.3 is an example of a tilde requirement.
~1.2.3 := >=1.2.3 <1.3.0 ~1.2 := >=1.2.0 <1.3.0 ~1 := >=1.0.0 <2.0.0 "
you can also use '=' to specify an exact version
-- [1]
---
"
sizeof(seq)/sizeof(seq[0]), C, statically allocated;
strlen(seq), C, null terminated;
len(seq), Python;
length seq, Haskell;
(count seq), Clojure;
seq.length, JavaScript lists, Java arrays;
seq.size(), Java sequences, jQuery expressions (deprecated)
seq.count(), Django querysets; and
SeqType'Length, Ada arraysI've probably forgotten some, but please excuse me if I don't remember the ones I need when I need them. "
---
"After a few years of using and abusing Ruby's meta-programming, I've come to understand it as an anti-pattern, you incur technical debt when you use it and should refactor it away as soon as you know what you're trying to do with it. It's one thing to enshrine it as a part of the language, like C++ templates and the C preprocessor, because that forces you (hopefully!) to think about things like maintainability and concern separation. It's quite another to ad-hoc what amounts to a language extension to paper over quick-and-dirty design. And there's not much middle ground between the two. I'll ask myself the question, "do I want to extract this into a gem and maintain it separately?" and run pretty quickly into the normal coding equivalent of "am I making a game engine or a game?" My vision has to be pretty darned awesome for the answer to be "both."..Meta-programming is great to have, having access to a credit card is way better than not having one if you have the discipline to use it properly. " [2]
---
" The Lua standard library uses the POSIX C library, making it portable; but that also means that you can’t use sockets, it doesn’t support signals or timers, and all OS calls block the thread. Using the POSIX C library is like going backwards in time.
Enter libuv. Libuv is a fully asynchronous, multi-platform library that was originally written to support node.js but is now being used to power many languages. Tim Caswell (aka creationix) wrote a binding to this library called “luv”. He then went on to create a lightweight “base” executable, called “luvi”, that is composed of various C libraries with Lua interfaces. All of this can be linked statically into a binary that is less than 5 megabytes and includes libuv, zlib, openssl, pcre, and, of course, the Lua runtime with bindings to the aforementioned libraries.
You can use luvi to run Lua code, but it also comes with built-in support for bundling your code directly into the binary. This makes it super-easy to ship your Lua code. I found out about this project in November 2014, and started following its progress. "
---
http://davidvgalbraith.com/how-i-fixed-atom/ gives an example of a recursive 'regex':
(?<m>[^()]*\((?:\g<m>
| [^()]*)\)[^()]*)* |
in this language, '(?<m>...)' is a named capture group with name 'm', and '(?:\g<m>...)' is a recursive 'call' to regex <m>
---
https://github.com/electronicarts/EASTL/blob/master/doc/EASTL%20Quick%20Reference.pdf
pcwalton 2 days ago
We on the Rust team got to speak about the lessons learned from the EASTL with Paul Pedriana (the author of much of it) while designing the Rust standard library. It's a significant influence on the proposed allocators API currently in RFC. The EASTL is worth looking at for anyone interested in designing libraries that work well in low-memory environments. (Much of this library was written with devices like the Nintendo DS in mind, which had 4 MB--4 MB!--of RAM as I recall.)
reply
CyberDildonics? 2 days ago
What parts of the EASTL are faster than the normal STL? Does it have better maps?
Edit: From a look at the source it definitely at least has some extra map classes for more specialized uses.
reply
corysama 2 days ago
One goal of EASTL is to be faster in non-optimized builds compared to other variants. If a game is running too slow to be playable, it can become impossible to debug! This was especially a problem on consoles with no OOE. It achieves this by sacrificing a lot of encapsulation and accepting non-DRY, manually inlined function implementations.
reply
to3m 1 day ago
I didn't realise this was a goal, but it's good that it was. C++'s prime faults tend to be spiteful iteration time (common cause: too many templates) and appalling performance in unoptimized builds (common cause: too many function calls, possibly due to overloaded operators and overly-finely-grained code that relies on inlining not to run like shit).
The famous maxim about how much cleverer you have to be to debug code than to write it always applies! No need to make things worse by forcing yourself to debug the optimized build.
reply
JohnLeTigre 2 hours ago
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n227... search for "20 - Performance comparison"
reply
United857 2 days ago
Writeup on the key design and advantages of EASTL for their target platforms (game consoles): http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n227...
reply
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html
---
albertzeyer 2 days ago
STL is maybe a bit missleading because it doesn't seem like it is a drop-in replacement for the STL.
However, this is certainly interesting because the emphasis on speed (and thus also on simplicity) is what I'm sometimes missing in the real STL or in Boost. That's exactly what you need in a game but also in much other performance critical code.
As far as I remember, Chrome has used the STL earlier. But I looked now and I see this: https://chromium.googlesource.com/chromium/blink/+/master/So...
Gecko also seem to have a lot of custom stuff: https://github.com/mozilla/gecko-dev/tree/master/xpcom/strin...
Doom3 idLib: https://github.com/id-Software/DOOM-3-BFG/tree/master/neo/id...
Unreal engine: https://answers.unrealengine.com/questions/2695/rocket-and-t...
You'll find much more similar libs when you search in some of the big games.
reply
pcwalton 2 days ago
> As far as I remember, Chrome has used the STL earlier. But I looked now and I see this:
The WTF (Web Template Framework) is actually inherited from WebKit? and used in the core rendering engine. I'm not sure how widely it's used in the Google parts of Chromium.
> Gecko also seem to have a lot of custom stuff
That's the old XPCOM stuff. While those string types continue to get a lot of use, the closest analogue to the STL is MFBT: https://github.com/mozilla/gecko-dev/tree/master/mfbt
reply
---
operatorIdentity should explicitly take a type:
operatorIdentity int (+) == 0
---
https://godoc.org/golang.org/x/tools/go/types
---
we shouldn't need python's namedtuples b/c everything should be implicitly overridable by getters/setters
---
---
One guy's current advice on Haskell libraries:
http://www.stephendiehl.com/posts/production.html : "
Prefer to import libraries as qualified. Typically this is just considered good practice for business logic libraries, it makes it easier to locate the source of symbol definitions. The only point of ambiguity I’ve seen is disagreement amongst developers on which core libraries are common enough to import unqualified and how to handle symbols. This ranges the full spectrum from fully qualifying everything (Control.Monad.>>=) to common things like (Data.Maybe.maybe) or just disambiguating names like (Map.lookup).
Consider rolling an internal prelude. As we’ve all learned the hard way, the Prelude is not your friend. The consensus historically has favored the “Small Prelude Assumption” which presupposes that tools get pushed out into third party modules, even the core tools that are necessary to do anything (text, bytestring, vector, etc). This makes life easier for library authors at the cost of some struggle for downstream users.
In practice any non-trivial business logic module can very easily have 100+ lines just of imports, and frankly it gets tiring. One common way of abstracting this is by rolling a custom prelude using module reexports. Consider a minimal use case like the following:
module MegaCorpPrelude? ( module Exports, ) where
import Data.Int as Exports import Data.Tuple as Exports import Data.Maybe as Exports import Data.String as Exports import Data.Foldable as Exports import Data.Traversable as Exports
import Control.Monad.Trans.Except as Exports (ExceptT?(ExceptT?), Except, except, runExcept, runExceptT, mapExcept, mapExceptT, withExcept, withExceptT)
This can be put into a cabal package which transitively pulls in the core dependencies and then is used in our downstream module.
{-# LANGUAGE NoImplicitPrelude? #-}
import MegaCorpPrelude?
There are several custom preludes that are available on Hackage in the Prelude category.
Haskell has world class libraries. There is an abundance of riches on Hackage in libraries like quickcheck, mtl, pipes, conduit, tasty, attoparsec, sbv and many more. Knowing where to start with the ecosystem can be a little tricky, and there are sometimes multiple competing solutions. A conservative start to a library might consist of something like the following build-depends in our cabal file:
build-depends:
base >= 4.6 && <4.9,
deepseq >= 1.3 && <1.5,
hashable >= 1.2.2 && <1.3, text >= 1.1 && <1.3,
bytestring >= 0.10 && <0.11,
split >= 0.2 && <0.3, unordered-containers >= 0.2 && <0.3,
containers >= 0.5 && <0.6,
vector >= 0.11 && <0.12 mtl >= 2.2 && <3.0,
transformers >= 0.4 && <0.6, time >= 1.6 && <1.7,
process >= 1.1 && <1.3,
directory >= 1.2 && <1.3,
optparse-applicative >= 0.10 && <0.13""
Configuration For configuration Bryan’s configurator library is invaluable. The library specifies an external configuration flat file which can hold credentials, connections and cluster topology information. A typical pattern is to embed this in a ReaderT? and then asks for any field necessary in downstream logic.
newtype ConfigM? a = ConfigM? (ReaderT? ConnectInfo? a) deriving (Monad, MonadReader? ConnectInfo?)
handleConfig :: FilePath? -> IO ConnectInfo? handleConfig config_filename = do config <- Config.load [ Config.Required config_filename ]
hostname <- Config.require config "database.hostname"
username <- Config.require config "database.username"
database <- Config.require config "database.database"
password <- Config.require config "database.password" return $ ConnectInfo
{ connectHost = hostname
, connectUser = username
, connectDatabase = database
, connectPort = 5432
, connectPassword = fromMaybe "" password
}The configuration file might look like the following:
database { hostname = "mydb.rds.amazonaws.com" database = "employees" username = "stephen" password = "hunter2" } "
" For large multi-package builds, I can’t speak highly enough of Neil Mitchell’s build system shake which is itself written in Haskell. The shake build uses Shakefiles which are monadic description of a graph of dependencies to resolve and their artifacts. For a contrived example consider running a Markdown file through Pandoc.
import Development.Shake import Development.Shake.FilePath?
main = shakeArgs shakeOptions $ do want ["book.html"] "book.html" *> \out -> do need ["book.md"] system' "pandoc" ["book.md","-o","book.html"] "
" Testing and building. For development builds using cabal sandboxes it’s usually essential to be able to pull in internal libraries that are not on Hackage. To do with cabal sandboxes this can be achieved with either a script to provision the dependencies.
$ git clone https://github.com/bscarlet/llvm-general $ cd llvm-general $ git checkout ca6489fdddde5c956a4032956e28099ff890a80b $ cd .. $ cabal sandbox add-source vendor/llvm-general-pure
With stack this can actually all be configured in the stack.yaml file.
packages:
Private TravisCI? or Codeship are not worth the trouble of setting up if one ever envisions the project spanning multiple repos. Getting their virtual machine provisioned with the proper credentials to pull from multiple Github repos is still a source of trouble. For build slaves and continuous integration I’ve used BuildBot? successfully to work with the usual cabal and stack toolchain. "
" Strings The strings types are mature, but unwieldy to work with in practice. It’s best to just make peace with the fact that in literally every module we’ll have boilerplate just to do simple manipulation and IO. OverloadedStrings? overcomes some of the issues, but it’s still annoying that you’ll end up playing string type-tetris a lot.
If you end up rolling a custom prelude it’s worth just correcting putStrLn and print to what they should be in a just world:
-- IO putStr :: MonadIO? m => Text -> m () putStr = liftIO . Data.Text.IO.putStr
putStrLn :: MonadIO? m => Text -> m () putStrLn = liftIO . Data.Text.IO.putStrLn
print :: (MonadIO? m, Show a) => a -> m () print = liftIO . Prelude.print
A common pattern is to use a multiparamter typeclass to do string conversions between all the common (Data.Text.Text, Data.Text.Lazy, Data.ByteString?.UTF8 Data.ByteString?.Lazy.UTF8, [Char]) types. You’ll end up eating at least one typeclass dictionary lookup per call to s but this is fairly benign in most cases.
class StringConvert? a b where s :: a -> b
instance (ToString? a, FromString? b) => StringConvert? a b where s = fromString . toString
instance FromString? UTF8.ByteString? where fromString = UTF8.fromString
instance FromString? LUTF8.ByteString? where fromString = LUTF8.fromString
instance ToString? UTF8.ByteString? where toString = UTF8.toString
instance ToString? LUTF8.ByteString? where toString = LUTF8.toString "
curated list of Haskell libraries:
https://github.com/Gabriel439/post-rfc/blob/master/sotu.md
another one (with other stuff mixed in):
http://dev.stephendiehl.com/hask/
a 2015 update: http://www.stephendiehl.com/posts/haskell_2016.html
a poll:
http://www.stephendiehl.com/posts/poll.html
---
https://godoc.org/golang.org/x/net/context
recc. by http://www.jtolds.com/writing/2016/03/go-channels-are-bad-and-you-should-feel-bad/ and https://news.ycombinator.com/item?id=11211222
---
Apple concurrency libs, XPC (high-level) and Grand Central Dispatch (low-level):
http://stackoverflow.com/questions/10373331/nsoperation-vs-grand-central-dispatch https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html http://nshipster.com/inter-process-communication/ (section XPC)
XPC primitive types:
-- [3]
---
order of params convention in Haskell:
Fargren 1 day ago
Does the order of the parameters matter? It's been a while since I've touched Haskell, so maybe it's obvious that this isn't [a] -> a -> Bool for some idiomatic reason. I guess that would be `isContained` instead of `contains`, so it probably wouldn't be the first thing I search for, but there's at least some potential for ambiguity.
reply
cormacrelf 23 hours ago
It's almost a convention in Haskell. The idea is, since currying functions is easy and common, you stick the argument that you'd want the least in a curried version last. So if you wanted to find out if x was in ten lists, you'd just:
map (elem x) [list1, list2, ..., list10]
or, for folds, the function is the one least likely to change, so you put it first, and the list is most likely to change, so you put it last:
foldl (+) 0 [1,2,3] map (foldl (-) 100) [[1,2],[2,3],[4,19]]
Of course, it's always debatable if you can find some situation where you wanted to curry in a different order, but generally you pick in order to reduce forced named lambda parameters. As far as I can tell, that's how it's done.
Edit: if you saw the sneaky edit, you'll know that this particular convention isn't easy to follow!
reply
eru 17 hours ago
There are a bunch of rules of thumbs that help you decide faster. Like `needle before haystack'.
reply
---
a set of coreutils:
https://github.com/uutils/coreutils
---
http://magic.io/blog/uvloop-blazing-fast-python-networking/
" The asyncio module, introduced by PEP 3156, is a collection of network transports, protocols, and streams abstractions, with a pluggable event loop. The event loop is the heart of asyncio. It provides APIs for:
scheduling calls,
transmitting data over the network,
performing DNS queries,
handling OS signals,
convenient abstractions to create servers and connections,
working with subprocesses asynchronously.uvloop is a drop-in replacement of the built-in asyncio event loop. "
---
some ES6 features mentioned in http://v8project.blogspot.com/2016/04/es6-es7-and-beyond.html: modules, classes, arrow functions, promises, iterators / generators, proxies, well-known symbols, ES6 RegExp? sticky flag.
proper tail calls
Some ES7 features mentioned in http://v8project.blogspot.com/2016/04/es6-es7-and-beyond.html : exponentiation operator Array.prototype.includes() async / await keywords, Object.values() / Object.entries(), String.prototype.padStart() / String.prototype.padEnd() and RegExp? lookbehind a mechanism for capturing unhandled Promise rejections like uncaught errors.
---
apparently this open source project implemented a bunch of Java libraries:
https://en.wikipedia.org/wiki/Apache_Harmony
(recc. by https://news.ycombinator.com/item?id=11679982 )
---
https://github.com/SamSaffron/fast_blank
---
example of some lib functionality we eventually need:
http://wiki.gkbrk.com/Hotel_Music.htm
---
https://github.com/andlabs/libui
---
a great study sheds light on which parts of POSIX are most used, which parts are unused, and which parts are being bypassed by higher level libraries due to their missing something: POSIX Abstractions in Modern Operating Systems: The Old, the New, and the Missing
"usage is driven by high-level frameworks...((in the areas of))...IPC, thread pool management, relational databases, and graphics support"
"extension APIs, namely ioctl , dominate mod- ern POSIX usage patterns as OS developers resort to them to build support for abstractions missing from the POSIX standard"
"For example, the ioctl interface is now regularly used to mediate complex graphics commands be- tween the high-level OpenGL? library and the graphics driver."
"new abstractions are arising driven by the same POSIX limitations across the three OSes, but the new ab- stractions are not converging"
"Traditional POSIX threading models, IPC interfaces, and file system access are being replaced by platform and vendor-specific APIs and frameworks such as Grand Central Dispatch [18], Binder [29], DBus [25], and SQLite [1]."
"The trend away from POSIX in each of these areas has followed different, and often divergent, paths on different platforms. The changes likely stem from POSIX’s limitations in supporting modern workloads, which are increasingly graphical, latency-sensitive, and memory- constrained (particularly on mobile devices). "
What is implemented?
Table 3: POSIX compliance of modern OSes. Modern OSes are not fully POSIX compliant.
Category Funcs Android OS X Ubuntu Example Algorithms 12 5 12 12 bsearch Proc. / Signals 98 67 98 98 fork, sigaction Args 19 7 19 19 uname Strings 200 127 200 200 strlen, strcmp Extensions 1 1 1 1 ioctl Terminals 21 19 21 21 isatty File Systems 180 138 180 172 fopen,fread Threads 102 69 102 102 pthread_create IPC 34 11 34 34 pipe Time / Date 29 27 29 29 time Math 285 242 285 285 srand, logf Users / Groups 32 18 32 32 getuid,getgid Memory 28 23 28 25 [cm]alloc Misc 80 23 80 29 sysconf Network 56 44 56 56 send, recv POSIX: 1,177 functions; Android: 821 functions (69.7%); OS X: 1,177 functions (100%); Ubuntu: 1,115 functions (94.7%).
" analysis of the POSIX implementa- tions, focusing on the omissions
IPC: Android implements only a small subset (32%) of the POSIX IPC functions; it is the single, lowest-coverage subsystem in the Android implementation. It partially im- plements two traditional abstractions: pipes and semaphores; and it omits all functions related to shared memory and mes- sage queues. The reason for these omissions, discussed in detail later, is that Android replaces traditional IPC abstrac- tions in favor of newer, platform-specific IPC abstractions. Although OS X and Ubuntu also come with their own IPC abstractions, these OSes implement the complete POSIX IPC subsystem.
FS: Android implements 76% of the FS POSIX sub- system, while OS X and Ubuntu cover the entire subsystem. Android omits in particular all of POSIX’s asynchronous I/O functions ( aio
Threads: Android implements 67% of threading in- terfaces, omitting for example pthread barrier* and pthread spin* utilities, and partially omitting pthread - mutexatr* utilities. OS X and Ubuntu implement the com- plete threading subsystem.
Memory: All OSes largely implement the memory sub- system, with one exception: neither Android nor Ubuntu implement typed memory objects. POSIX typed memory objects are being substituted by new memory sharing and memory mapped files schemas.
Other: Neither Android nor Ubuntu implement the POSIX tracing standard. Since tracing functionality required for debugging and logging is vital for the ecosystem of mod- ern applications, a plethora of tools exist (e.g., [3, 11, 28]) that go beyond the capabilities of POSIX tracing subsystem. Overall, the omission of some core POSIX interfaces in modern OSes, and the phasing out of traditional IPC, async I/O, and DB calls in Android, provide us with initial insights into which POSIX abstractions are exhibiting limitations or are unnecessary for modern workloads. "
What is linked (used statically)?
Top 5 funcs by linkage, in Android: memcpy: 99% abort: 97% malloc: 92% free: 92% memset: 90%
Top 5 funcs by linkage, in Ubuntu: memcpy: 50% strlen: 49% free: 48% malloc: 42% strcmp: 30%
" Overall, in Android, of the 821 POSIX functions imple- mented, 114 of them are never dynamically linked from any native library, and approximately half (364 functions) are dy- namically linked from 1% or fewer of the apps. Furthermore, our static analysis of Ubuntu packages shows that desktop Linux has a similar, albeit less definitive, trend with An- droid: phasing out traditional IPC and FS POSIX abstrac- tions. Focusing on a few rarely linked subsystems that are of particular relevance for subsequent discussions, we remark:
IPC: In Android, we observe particularly low linkage for named pipe functions ( mkfifo ). This decreases the al- ready narrow POSIX IPC support in Android. Similarly, in Ubuntu, we observe that message queues ( mq* ) – a set of ab- stractions not implemented in Android – are being linked by less than 0.3% of Ubuntu packages.
FS: In Android, we observe that file lock functions are extremely rarely linked: flockfile and funlockfile are linked from only 0.7% of the apps. Also, async I/O calls ( aio* not implemented in Android) are being linked by less than 0.1% of Ubuntu packages. "
What is used dynamically?
top 30 most frequently called:
Popular POSIX interface in Android POSIX function Invocations Time memset 25% (66.0M) 14% (100s) pthr_getspec 20% (52.8M) 12% (81.5s) memcpy 20% (52.1M) 13% (87.8s) free 9% (24.9M) 8% (57.7s) malloc 8% (20.9M) 9% (61.1s) pthr_self 3% (10.1M) 0% (0.0s) memcmp 3% (8.6M) 2% (16.3s) memmove 1% (3.6M) 1% (6.8s) clock_gettime 1% (3.3M) 0% (0.0s) realloc 0.8% (2.1M) 1% (8.0s) pthr_once 0.6% (1.7M) 0.7% (4.6s) gettimeofday 0.5% (1.4M) 0.6% (4.2s) ioctl 0.5% (1.3M) 16% (108s) mprotect 0.4% (1.1M) 3% (26.1s) fread 0.4% (1.0M) 0.8% (5.3s) write 0.4% (926K) 2% (16.1s) pthr_cond_sig 0.3% (697K) 0.7% (4.9s) memchr 0.3% (686K) 0.6% (3.9s) pthr_cond_brd 0.2% (608K) 0.6% (4.0s) getpid 0.2% (593K) 0.2% (1.6s) bsearch 0.2% (493K) 0.2% (1.5s) pth_mtx_destr 0.2% (455K) 0.1% (0.4s) calloc 0.2% (393K) 0.2% (1.3s) getuid 0.2% (393K) 0.1% (1.0s) recv 0.1% (367K) 0.9% (6.1s) fclose 0.1% (298K) 0.1% (0.6s) setjmp 0.1% (287K) 0.3% (1.9s) pthr_mtx_init 0.1% (275K) 0.1% (0.4s) read 0.1% (234K) 0.9% (5.8s) pthr_equal 0.1% (183K) 0.1% (0.4s) Total: 259.6M 674.7s
Popular POSIX interface in OS X POSIX function Invocations Time malloc 27% (6.9M) 36% (31.7s) pthr_getspec 19% (4.9M) 7% (6.2s) calloc 18% (4.6M) 30% (26.7s) pthr_self 11% (3.0M) 4% (3.7s) pthr_equal 11% (2.9M) 3% (3.5s) pthr_once 5% (1.4M) 2% (1.9s) gettimeofday 1% (386K) 2% (1.8s) realloc 1.0% (250K) 2% (2.1s) bsearch 1.0% (242K) 2% (2.1s) memcpy 0.5% (115K) 0.3% (0.3s) pthr_mattrset 0.4% (94K) 0.2% (0.2s) pthr_mattrinit 0.4% (94K) 0.2% (0.2s) pthr_mattrdest 0.4% (92K) 0.2% (0.2s) pthr_setspec 0.3% (65K) 0.1% (0.1s) getenv 0.1% (31K) 0.1% (0.1s) recv 0.1% (29K) 0.1% (0.0s) send 0.1% (29K) 0.1% (0.0s) nanosleep 0.1% (16K) 0.8% (0.7s) fcntl 0.1% (16K) 0.1% (0.1s) fgets 0.1% (16K) 0.3% (0.2s) mmap 0.1% (14K) 0.4% (0.3s) munmap 0.1% (12K) 0.2% (0.1s) qsort 0.1% (11K) 0.1% (.0s) geteuid 0.1% (11K) 0.1% (.0s) setjmp 0.1% (10K) 0.1% (.0s) read 0.1% (9K) 0.2% (0.2s) pread 0.1% (7K) 0.1% (0.1s) close 0.1% (6K) 0.2% (0.2s) write 0.1% (6K) 0.1% (0.1s) getuid 0.1% (2K) 0.1% (0.0s) Total: 25M 87s
Popular POSIX interface in Ubuntu POSIX function Invocations Time memcpy 24% (23.7M) 17% (9.7s) free 20% (19.1M) 14% (8.2s) malloc 18% (17.3M) 16% (9.0s) memcmp 6% (6.1M) 3% (2.2s) memmove 4% (4.8M) 3% (2.0s) memset 4% (4.6M) 3% (2.1s) realloc 3% (3.5M) 3% (2.1s) calloc 2% (2.8M) 3% (1.7s) gettimeofday 1% (1.3M) 0% (0.0s) pthr_cnd_sig 0.9% (869K) 3% (1.7s) pthr_cnd_twait 0.8% (801K) 0.0% (0.0s) getpid 0.8% (767K) 0.7% (0.4s) pthr_cnd_brd 0.8% (748K) 0.7% (0.4s) pthr_equal 0.8% (735K) 0.4% (0.2s) sched_yield 0.8% (725K) 0.0% (0.0s) ffs 0.7% (679K) 0.5% (0.3s) read 0.7% (643K) 1% (1.1s) nanosleep 0.6% (603K) 0.0% (0.0s) poll 0.6% (602K) 3% (1.8s) memchr 0.6% (584K) 0.4% (0.2s) fread 0.6% (532K) 0.5% (0.3s) ioctl 0.4% (425K) 0.7% (0.4s) recvmsg 0.4% (386K) 3% (1.7s) fgets 0.3% (320K) 0.3% (0.2s) write 0.3% (276K) 0.9% (0.5s) recv 0.3% (272K) 1% (0.6s) send 0.2% (231K) 2% (1.4s) pthr_cnd_wait 0.2% (200K) 0.0% (.0s) sem_wait 0.2% (179K) 0.0% (.0s) select 0.2% (160K) 0.9% (0.5s) Total: 95M 56s
" Memory: The memory subsystem contains some of the most heavily invoked functions, many of which are among the top-10 across all OSes. User-space utilities for memory handling (e.g., memset , memcpy , and memcmp ) and system- call backed POSIX calls for (de)allocation of memory arenas (i.e., [cm]alloc and free ) are the most popular interfaces of this subsystem. Also, the function mprotect is ranked 14th in Android. This function is usually invoked with ar- gument PROT READ
| PROT |
Threads: POSIX user-space threads are also very pop- ular across all OSes. In Android and OS X, Thread Local Storage (TLS) operations are extensively used. pthread - getspecific , a function that retrieves the value bound to a TLS key, is the second most popular call in Android and OS X. This user-space routine is used to retrieve TLS keys that help applications map between high-level threads and low-level native pthreads . In Ubuntu, conditional variables are heavily used (e.g., pthread cond signal range). The ubiquity of threading operations is again due to high-level frameworks and programming languages, which make ex- tensive use of multi-threading, particularly to obtain asyn- chrony, as shown in Section 5.5.
IPC We observe across all three OSes that no POSIX calls belonging to traditional POSIX IPC are among the fre- quently invoked operations. As discussed earlier, Android departs from the traditional IPC in favor of higher-level IPC abstractions, namely Binder , the core Android message pass- ing system. Similarly, OS X supports higher-level IPC primi- tives built atop Mach IPC , which diverged from POSIX since its inception. Finally, Ubuntu also provides applications with message passing capabilities based on D-Bus.
FS: Similarly to IPC, FS abstractions are invoked, but are not comparatively as popular in terms of invocations. More important, most an analysis of the stack traces of these calls reveals that most of the FS invocations, such as file read and write, mainly serve higher-level storage abstractions, such as SQLite in Android and CoreData? in OS X. The rationale behind this departure from the traditional FS (and IPC) primitives in favor of higher-level abstractions is further described in subsequent sections.
Other: Other heavily invoked POSIX calls belong to the Time POSIX subsystem. For example, gettimeofday is ranked 12th in Android, 7th in OS X, and 9th in Ubuntu. This system call is essential for implementing timers to support periodic tasks, such as garbage collection.
Extension APIs ( ioctl ): Finally, we observe the unex- pected popularity of ioctl , an extension API that lets ap- plications and libraries bypass well-defined abstractions and interact directly with the kernel. "
Why Is IOCTL Invoked So Often?
Graphics li- braries and network functionality are the main sources of ioctl invocations ...
OS 1st Lib 2nd Lib 3rd Lib Android: Graphics (74%) (e.g., libnvrm ), Binder (24%) (e.g., libbinder ) OS X: Network (99%) (e.g., net.dylib ) Loader (0.6%) (e.g., dyld ) Ubuntu: Graphics (52%) (e.g., libgtk ) Network (47%) (e.g., libQtNet )
As soon as we add one trivial UI element to the app (bench2), ioctl ’s cost becomes dominant over the cost of complete POSIX sub- systems. The two specific libraries that invoke ioctl in this case are the libnvrm and libnvrm graphics graphics li- braries. These userspace graphics libraries resort to ioctl to bypass the POSIX API, and directly talk to NVDIA’s pro- prietary drivers in the Linux kernel. ... . In Android, graph- ics libraries ( libnvrm and libnvrm graphics ) lead to the lion’s share of ioctl invocations. Next comes Binder , An- droid’s core IPC mechanism, whose functionality is split be- tween a Linux kernel module and a userspace library. In OS X, the majority of ioctl invocations come from network li- braries. In Ubuntu, graphics libraries trigger approximately half of ioctl invocations and the remaining part is mainly due to libraries providing network functionality.
Does POSIX Lack Abstractions Needed by Modern Workloads?
we investigate graphics and networking functionality in modern OSes, which rely signif- icantly on ioctl signaling that such abstractions are missing in POSIX. ... Graphics. POSIX explicitly omits graphics as a point of standardization ... OpenGL? ... PTask ... Using opaque input and output tokens, the ioctl call can be general purpose, but it was never intended for the complicated, high-bandwidth interface GPUs require. Graphics library writers must either use ioctl as a funnel into which all GPU command and control is sent via opaque data blobs, or they must design a vendor-specific demux in- terface akin to the syscall system call. This is unfortunate and unnecessary work for both library and driver developers
Interestingly, in OS X, graphics functionality does not ac- count for any significant portion of ioctl invocations. The reason is that the driver model in OS X, IOKit , is more structured than in Android or Ubuntu. It uses a well-defined Mach IPC interface that can effectively marshal parameters and graphics data across the user-kernel boundary
Networking. Although POSIX has a set of 56 APIs to sup- port network operations, Table 5 shows that developers reg- 99% of ioctl ’s invocations in OS X and 47% in Ubuntu, were low-level socket operations. The particular use of ioctl appeared to be in an attempt to circumvent around POSIX restrictions on exactly what appears in headers files for operations like [set
| get]sockopt |
What POSIX Abstractions Are Being Replaced?
we next discuss ab- stractions that exist in POSIX but appear to be replaced by new abstractions ...
Inter-Process Communication. A central IPC abstraction in POSIX is the message queue API ( mq_* ). On all platforms we studied, applications used some alternate form of IPC. In fact, Android is missing the mq_* APIs altogether. IPC on all of these platforms has divergently evolved beyond (in some cases parallel to) POSIX.
IPC on Android: Binder. In Android, Binder is the standard method of IPC. Binder APIs are exposed to apps through highly abstracted classes and interface definition files that give structure and meaning to all communica- tion. Some of the insurmountable limitation of traditional POSIX IPC that urge for new IPC mechanism include: (i) Filesystem-based IPC mechanisms, e.g., named pipes, can- not be used in Android (and other similarly sandboxed sys- tems) due to a global security policy that eliminates world- writable directories. (ii) Message queues and pipes can- not be used to pass file descriptors between processes. (iii) POSIX IPC primitives do not support the context manage- ment necessary for service handle discovery. (iv) Message queues have no support for authorization or credential man- agement between senders and recipients. (v) There is no support for resource referencing and automatic release of in-kernel structures.
Binder overcomes POSIX IPC limitations and serves as the backbone of Android inter-process communication. Us- ing a custom kernel module, Binder IPC supports file de- scriptor passing between processes, implements object refer- ence counting, and uses a scalable multi-threaded model that allows a process to consume many simultaneous requests. In addition, Binder leverages its access to processes’ address space and provides fast, single-copy transactions. When a message is sent from one process to another, the in-kernel Binder module allocates space in the destination process’ ad- dress space and copies the message directly from the source process’ address space.
Binder exposes IPC abstractions to higher layers of soft- ware in appropriately abstract APIs that easily support ser- vice discovery (through the Service Manager ), and regis- tration of RPCs and intent filtering. Android apps can focus on logical program flow and interact with Binder, and other processes, through what appear to be standard Java objects and methods, without the need to manage low-level IPC de- tails. Because no existing API supported all the necessary functionality, Binder was implemented using ioctl as the singular kernel interface. Binder IPC is used in every An- droid application, and accounts for nearly 25% of the to- tal measured POSIX CPU time which funnels through the ioctl call.
IPC on Linux: D-Bus and KD-Bus. In Ubuntu, the D- Bus protocol [25] provides apps with high-level IPC abstrac- tions. D-Bus describes an IPC messaging bus system that implements (i) a system daemon monitoring system-wide events, e.g., attaching or detaching a removable media de- vice, and (ii) a per-user login session daemon for communi- cation between applications within the same session. There are several implementations of D-Bus available in Ubuntu. The applications we inspect use mostly the libdbus imple- mentation (38 out of 45 apps). This library is, at the low level, implemented using traditional Unix domain sockets, and it accounts for less than 1% of the total CPU time mea- sured across our Ubuntu workloads. Another recent evolution in IPC is called the Linux Ker- nel D-Bus, or kdbus.. an in-kernel implementation of D-Bus that uses Linux kernel features to overcome inherent limitations of user space D-Bus implementations.... supports zero-copy message passing between pro- cesses. ... IPC on OS X: Mach IPC. IPC in OS X diverged from POSIX (and its Android/Linux contemporaries) since its in- ception. Apple’s XNU kernel uses an optimized descendant of CMU’s Mach IPC [16, 44, 61] as the backbone for inter- process communication. Mach comprises a flexible API that supports high-level concepts such as: object-based APIs ab- stracting communication channels as ports , real-time com- munication, shared memory regions, RPC, synchronization, and secure resource management. Although flexible and ex- tensible, the complexity of Mach has led Apple to develop a simpler higher-level API called XPC [17]. Most apps use XPC APIs that integrate with other high-level APIs, such as Grand Central Dispatch [18], and launchd the Mach IPC based init program providing global IPC service discovery. ... Both Binder and Mach IPC leverage fast, single-copy and zero-copy mechanisms re- spectively after a particular message size (1 page in Binder, 2 pages in Mach IPC). Large messages in both Binder and Mach IPC are sent in near-constant time. In contrast, tradi- tional POSIX mechanisms on all platforms suffer from large variation and scale linearly with message size.
...
File System. Several papers have already identified the migration of modern applications away from traditional file system abstractions into higher-level storage abstrac- tions, such as relational databases or object-relational man- agers [30, 52]....there is a clear trend of transitioning from regular unstructured data files into structured data. In Android, 35 of the 45 apps we checked depend on structured data stored in sqlite . Typical Android applications that depended on struc- tured data included Media & Video, Accessories & Develop- ment, and Games applications. On the other hand, in Ubuntu, the transitioning to structured data is less definite. Only 12 of the 45 applications are using structured data – mainly the web-oriented apps
Second, all the Android applications we checked issue file system-related POSIX calls through libsqlite. The use of this library causes five expensive fsync calls for every single INSERT/UPDATE/DELETE operation ...
Asynchronous I/O. Our experiments reveal another inter- esting evolutionary trend: the replacement of POSIX APIs for asynchronous I/O with new abstractions built on multi- threading abstractions. The nature and purpose of threads has been a debate in OS research for a long time [21, 37, 41]. POSIX makes no attempt to prioritize a threading model over an event-based model; it simply outlines APIs neces- sary for both. Our study revealed that while POSIX lock- ing primitives are still extremely popular and useful, new trends in application abstractions are blurring the line be- tween event and thread by combining high-level language semantics with pools of threads fed by event-based loops. This new abstraction or programming paradigm has evolved directly from the unique operating environment of mobile devices. The intimate nature of interacting with a computer via touch intuitively drives low-latency and fast response time requirements for application GUIs. While an event- based model may seem the obvious solution, event pro- cessing in the input or GUI context quickly leads to sub- optimal user experience, especially when display refresh rates require < 16 ms intra-frame processing time to main- tain smooth and responsive GUIs. Dispatching event-driven work to a queue backed by a pool of pre-initialized threads has become a de facto standard programming model in An- droid, OS X, and Ubuntu. Although this paradigm appears in all the OSes we studied, the implementations are extremely divergent.
Asynchrony in Android: Thread Pools and Event Loops. Android defines several Java classes which abstract the concepts of creating, destroying, and managing threads ( ThreadPool? ), looping on events ( Looper ), and asyn- chronous work dispatching ( ThreadPoolExecutor? ). A Looper class can dispatch bits of work based on input events to a ThreadPoolExecutor? that manages a set of threads. For
example, one can use Looper to asynchronously dispatch file downloads for processing into a ThreadPool?.
Asynchrony in Ubuntu: Thread Pools and Event Loops. Ubuntu applications can choose from a variety of libraries providing similar functionality, but through vastly differ- ent interfaces. The libglib , libQtCore , and libnspr all provide high-level thread abstractions based on the GNOME [27] desktop environment, and account for more than 13% of all measured POSIX CPU time. In particu- lar, libglib provides the GSource , GThreadPool? , and GAsyncQueue? C-structure based APIs that perform concep- tually similar functions to their Android Java counterparts. In addition, the libQtCore library implements threading abstractions for Qt-based Ubuntu applications.
Asynchrony in OS X: Grand Central Dispatch. In OS X the APIs are, yet again, different. The vast majority of event-driven programming in OS X is done through Mach IPC, and corresponding kernel system calls comprise the majority of system CPU time [20]. Apple has written C, Objective-C, and Swift based APIs around event handling, thread pool management, and asynchronous task dispatch. Most of these APIs are enabled through Grand Central Dis- patch [18] (GCD). GCD manages a pool of threads, and even defines POSIX alternatives to semaphores, memory barriers, and asynchronous I/O. Low-level objects such as dispatch queue t and dispatch source t are managed by functions such as dispatch async and dispatch - source set event handler . The GCD functionality is exported to even higher levels of abstraction in classes such as NSOperation [19]. Apple has even written a tutorial [4] for developers on how to migrate away from POSIX threads
A fascinating practical result of exposing high-level event and thread management APIs to app developers is that the number of threads in the system increases. In our measure- ments we found that our idle Android tablet had 690 instan- tiated threads, our idle MacBook? Air laptop had 580 instan- tiated threads, and our idle Ubuntu laptop had 292 instanti- ated threads. Particularly for Android, more than 100 instan- tiated threads were directly tied to custom Binder, Looper, and ThreadPool? management APIs. ...
some unused POSIX calls in various implementations:
syslog in Android select in iOS unlockpt ptsname
links to similar papers:
http://research.cs.wisc.edu/wind/Publications/ibench-sosp11.pdf T. Harter, C. Dragga, M. Vaughn, A. C. Arpaci-Dusseau, and R. H. Arpaci-Dusseau. A file is not a file: understanding the I/O behavior of Apple desktop applications. In Proceedings of the 2 rd ACM Symposium on Operating Systems Principles (SOSP 2011) , pages 10:1–10:39, Cascais, Portugal, Oct. 2011
" A file is not a file. Modern applications manage large databases of information organized into complex directory trees. Even simple word-processing documents, which appear to users as a “file”, are in actuality small file systems containing many sub-files ( e.g. , a Microsoft .doc file is actually a FAT file system containing pieces of the document). ... Sequential access is not sequential. Building on the trend no- ticed by Vogels for Windows NT [39], we observe that even for streaming media workloads, “pure” sequential access is increas- ingly rare. Since file formats often include metadata in headers, applications often read and re-read the first portion of a file before streaming through its contents ... Auxiliary files dominate. Applications help users create, mod- ify, and organize content, but user files represent a small fraction of the files touched by modern applications. Most files are helper files that applications use to provide a rich graphical experience, support multiple languages, and record history and other metadata ... Writes are often forced. As the importance of home data in- creases ( e.g. , family photos), applications are less willing to simply write data and hope it is eventually flushed to disk. We find that most written data is explicitly forced to disk by the application; for example, iPhoto calls fsync thousands of times in even the sim- plest of tasks. ... Renaming is popular . Home-user applications commonly use atomic operations, in particular rename , to present a consistent view of files to users ... Multiple threads perform I/O. Virtually all of the applications we study issue I/O requests from a number of threads; a few ap- plications launch I/Os from hundreds of threads. Part of this us- age stems from the GUI-based nature of these applications; it is well known that threads are required to perform long-latency oper- ations in the background to keep the GUI responsive ...
A substantial number of tasks contain purely sequen- tial accesses. When the definition of a sequential access is loosened such that only 95% of bytes must be consecutive, then even more tasks contain primarily sequential accesses. These “nearly sequen- tial” accesses result from metadata stored at the beginning of com- plex multimedia files: tasks frequently touch bytes near the begin- ning of multimedia files before sequentially reading or writing the bulk of the file .. Although preallocation has the potential to be use- ful, few tasks use it to provide hints, and a significant number of the hints that are provided are useless. ... At the highest level, the figure indicates that half the tasks syn- chronize close to 100% of their written data while approximately two-thirds synchronize more than 60%....some of the tasks synchronize small amounts of data frequently, presenting a challenge for file systems ... Many of our tasks write data atomically, generally doing so by calling rename . The bulk of atomic writes result from API calls; while some of these hide the underlying nature of the write, others make it clear that they act atomically ... "
http://www3.cs.stonybrook.edu/~porter/pubs/syspop16.pdf
C.-C. Tsai, B. J. Nafees, A. Abdul, and D. E. Porter. A Study of Modern Linux API Usage and Compatibility: What to Support When You’ re Supporting. In Proceedings of the 11th European Conference on Computer Systems (EuroSys? 2016) , London, United Kingdom, Apr. 2015
" security-relevant API changes, such as re- placing 'access' with 'faccessat' ...
'stat'..'open'..'rename'..'chmod' ...
a range of security problems arise from the ill-specifiedbehavior of the signal system call [1, 55]. Despite 15 years of warnings to move to the more secure sigaction call, signal has not been removed from 32-bit x86 Linux, because many legacy applications use signal ...
Many experimental operating systems add a rough Unix or Linux compatibility layer to increase the number of sup- ported applications [13, 15, 27, 56]. Such systems generally support a fraction of Linux system calls, often just enough to run a few target workloads....OS researchers would bene- fit from the ability to translate a set of supported system calls to the fraction of applications that can be directly supported without recompilation. Similarly, it is useful to know which additional APIs would enable the largest range of additional applications to run on the system ... the system API “footprint” of each bi- nary. This paper combines the footprint data with data about how frequently each package is installed, which is measured from the Ubuntu and Debian “popularity contest” survey data ... nearly 40% of libc APIs are used by less than one percent of applications on a typical installation ...This paper considers system APIs (“APIs”) broadly: this includes system calls, as well as any other means by which OS kernel functionality is requested, such as a pseudo-file system ( /proc ).
...
not all APIs are equally important: some are indis- pensable (e.g., 'read' and 'write' ), whereas others are very rarely used (e.g., 'preadv' and 'delete_module' ). A sim- ple count of system calls is easily skewed by system calls that are variations on a theme (e.g., 'setuid' , 'seteuid' , and 'setresuid' ). Moreover, some system calls, such as 'ioctl' , export widely varying operations—some used by by all applications and many that are essentially never used ( x 3.3).
... Figure 1. Percentage of ELF inaries and applications writ- ten in interpreted languages among all executables in the Ubuntu/Debian Linux repository, categorized by in- terpreters...:
ELF binary: 60% sell (dash): 15% python: 9% perl: 8% shell (bash): 6% ruby: 1% others: 1%
Types of ELF binaries: dynamically-linked executables: 48% linkable shared libraries: 52% static binaries: 0.38%
...
Of particular note is that the OS interface required by essentially all applications is substantially larger than the roughly 300 Linux system calls—the required interface also includes several vectored system call operations, such as ioctl , and special filesys- tem interfaces like /sys and /proc . We also note that a number of system calls and other APIs are so rarely used that they can be deprecated with little disruption or effort
...
Over two-thirds ( 224 of 320 ) of system calls on Linux are indispensable: required by at least one application on every installation. Among the rest, 33 system calls are important on more than ten percent of the installations. 44 system calls have very low API importance: less than ten percent of the installations include at least one application that uses these system calls.
...
Among the 44 system calls with a API importance above zero but less than ten percent, some are cases where a more popular alternative is available. For instance, Linux sup- ports both POSIX and System V message queues. The five APIs for POSIX message queues have a lower API im- portance than System V message queues. We believe this is attributable to System V message queues being more portable to other UNIX systems. Similarly, we observed that epoll wait (100%) has a higher API importance than epoll pwait (3%), even though epoll pwait is commonly considered more robust for the same purpose— waiting on file descriptor events.
In some cases, system calls are effectively offloaded to a file in /proc or /sys . For instance, some of the infor- mation that was formerly available via query module can be obtained from /proc/modules , /proc/kallsyms and the files under the directory /sys/module ... We also found five system calls uselib , nfsservctl , afs syscall , vserver and security system calls that are officially retired, but still have a low, but non- zero, API importance. For instance nfsservctl is re- moved from Linux kernel 3.1 but still has API importance of seven percent, because it is tried by NFS utilities such as exportfs . These utilities still attempt the old calls for backward-compatibility with older kernels.
Table 1. System calls which are only directly used by par- ticular libraries, and their API importance (“Imp.”). Only system calls with API importance larger than ten percent are shown. These system calls are wrapped by library APIs, thus they are easy to deprecate by modifying the libraries.
System Calls Imp. Packages clock_settime, iopl , ioperm , signalfd4 100% libc mbind 36.0% libnuma, libopenblasp addkey 27.2% libkeyutils keyctl 27.2% pam keyutil,libkeyutils,requestkey 14.4% libkeyutils preadv,pwritev 11.7% libc
Table 2. System calls with usage dominated by particular package(s), and their API importance (“Imp.”). This table excludes system calls that are officially retired.
System Calls Imp. Packages seccomp,sched_setattr,sched_getattr 1% coop-computing-tools kexec_load 1% kexec-tools clock_adjtime 4% systemd renameat2 4% systemd,coop-computing-tools mq_timedsend,mq_getsetattr 1% qemu-user io_getevent 1% ioping, zfs-fuse getcpu 4% valgrind, rt-tests
Table 3. Unused system calls and explanation for disuse Unused System Calls Reason for Disuse set_thread_area,tuxcall,create_module, and 6 more. Officially retired. sysfs replaced by /proc/filesystems rt_tgsigqueueinfo,get_robust_list Unused by applications. remap_file_pages No non-sequential ordered mapping; repeated calls to mmap preferred. mq_notify Unused: Asynchronous message delivery. lookup_dcookie Unused: for profiling. restart_syscall Transparent to applications ((but used by kernel)) move_pages Unused: for NUMA usage
...
Essentially, one cannot run even the most simple pro- grams without at least 40 system calls. After this, the num- ber of additional applications one can support by adding an- other system call increases steadily until an inflection point at 125 system calls, or supporting extended attributes on files, where weighted completeness jumps to 25%. To sup- port roughly half of Ubuntu/Debian Linux applications, one must have 145 system calls, and the curve plateaus around 202 system calls. On the most extreme end, qemu’s MIPS emulator (on an x86-64 host) requires 270 system calls
Table 4. Five stages of implementing system calls based on the API importance ranking. For each stage, a set of system calls is listed, with the work needed to accomplish (# of system calls) and the weighted completeness that can be reached.
Stage, Weighted Completeness ((reached)), # of calls needed, Sample calls:
I: 1% completeness via 40 calls eg mmap,vfork,exit,read,gettid,fcntl,getcwd,sched_yield,kill,dup2 II: 11% completeness via 41 more calls (81 total) eg mremap,ioctl,access,socket,poll,recvmsg,dup,unlink,wait4,select,chdir,pipe III: 50% completeness via 64 more calls (145 total) eg sigaltstack,shutdown,symlink,alarm,listen,pread64,getxattr,shmget,epollwait,chroot,sync,getrusage IV: 90% completeness via 57 more calls (202 total) eg flock,semget,ppoll,mount,brk,pause,clockgettime,getpgid,settimeofday,capset,reboot,unshare,tkill V: 100% completeness via the remaining 70 calls (272 total)
the complete list is available from http://oscar.cs.stonybrook.edu/api-compat-study/
wrt 'study on users',
the first 202, eg stages I through IV, from most important to least, are: I: mmap(9), vfork(58), exit(60), exit_group(231), write(1), read(0), open(2), gettid(186), madvise(28), munmap(11), futex(202), rt_sigprocmask(14), fcntl(72), close(3), getuid(102), mprotect(10), getgid(104), sched_yield(24), getpid(39), stat(4), fstat(5), lstat(6), lseek(8), tgkill(234), getdents(78), writev(20), getcwd(79), clock_getres(229), getrlimit(97), newfstatat(262), openat(257), dup2(33), clone(56), execve(59), kill(62), setresuid(117), setresgid(119), setpgid(109), sched_setscheduler(144), sched_setparam(142)
II: mremap(25), ioctl(16), access(21), socket(41), connect(42), poll(7), sendto(44), recvmsg(47), dup(32), unlink(87), uname(63), nanosleep(35), wait4(61), readv(19), geteuid(107), readlink(89), bind(49), pipe(22), getsockname(51), mkdir(83), select(23), rename(82), chdir(80), getegid(108), chmod(90), setsockopt(54), fchmod(91), statfs(137), recvfrom(45), sendmsg(46), fsync(74), sched_get_priority_max(146), sched_get_priority_min(147), ftruncate(77), umask(95), rmdir(84), pipe2(293), getsockopt(55), chown(92), link(86), fchown(93)
III: sigaltstack(131), shutdown(48), getppid(110), setuid(105), getresuid(118), getresgid(120), symlink(88), fstatfs(138), getpeername(52), utimes(235), socketpair(53), alarm(37), setsid(112), getxattr(191), lchown(94), fallocate(285), pread64(17), eventfd2(290), inotify_add_watch(254), fgetxattr(193), getgroups(115), shmctl(31), pwrite64(18), inotify_init(253), lgetxattr(192), setxattr(188), shmat(30), prctl(157), inotify_rm_watch(255), listen(50), inotify_init1(294), setgid(106), accept(43), shmdt(67), fadvise64(221), shmget(29), llistxattr(195), listxattr(194), flistxattr(196), splice(275), setrlimit(160), setgroups(116), epoll_ctl(233), utime(132), epoll_wait(232), epoll_create1(291), setpriority(141), dup3(292), sched_getparam(143), mknod(133), sched_getscheduler(145), chroot(161), sync(162), fchdir(81), creat(85), mlock(149), getpgrp(111), utimensat(280), getpriority(140), setitimer(38), times(100), pselect6(270), getrusage(98), faccessat(269), setreuid(113)
IV: flock(73), semget(64), semctl(66), ppoll(271), msync(26), capget(125), sendmmsg(307), fdatasync(75), sched_getaffinity(204), unlinkat(263), readlinkat(267), setregid(114), rt_sigsuspend(130), mount(165), brk(12), clock_gettime(228), name_to_handle_at(303), semop(65), lsetxattr(189), futimesat(261), pause(34), getpgid(121), getsid(124), fsetxattr(190), sysinfo(99), munlock(150), settimeofday(164), umount2(166), rt_sigtimedwait(128), timerfd_create(283), timerfd_settime(286), ptrace(101), ioprio_set(251), fchmodat(268), fchownat(260), accept4(288), linkat(265), mlockall(151), sync_file_range(277), mincore(27), sethostname(170), removexattr(197), capset(126), personality(135), iopl(172), sched_setaffinity(203), reboot(169), clock_settime(227), unshare(272), symlinkat(266), getitimer(36), ioperm(173), renameat(264), tkill(200), mkdirat(258), lremovexattr(198)
wrt 'study on application developers', the first 202 are, with some 'unweighted API importance' scores, are:
first 40 (unweighted API importances from 0.997320 to 0.994528): exit(60), mmap(9), write(1), exit_group(231), open(2), read(0), madvise(28), gettid(186), futex(202), munmap(11), rt_sigprocmask(14), clone(56), close(3), sched_yield(24), mprotect(10), getuid(102), fcntl(72), getgid(104), lseek(8), getcwd(79), lstat(6), getdents(78), tgkill(234), getpid(39), stat(4), writev(20), clock_getres(229), fstat(5), getrlimit(97), newfstatat(262), openat(257), execve(59), dup2(33), kill(62), setpgid(109), sched_setscheduler(144), vfork(58), setresgid(119), setresuid(117), sched_setparam(142)
next 41 (unweighted API importances from 0.844779 to 0.361027): ioctl(16), mremap(25), access(21), socket(41), connect(42), sendto(44), poll(7), recvmsg(47), dup(32), uname(63), unlink(87), nanosleep(35), rt_sigreturn(15), rt_sigaction(13), set_tid_address(218), set_robust_list(273), readv(19), select(23), wait4(61), bind(49), setsockopt(54), sched_get_priority_max(146), getsockname(51), sched_get_priority_min(147), geteuid(107), recvfrom(45), mkdir(83), pipe(22), getegid(108), readlink(89), shutdown(48), chdir(80), rename(82), sendmsg(46), pipe2(293), chmod(90), ftruncate(77), statfs(137), getsockopt(55), rmdir(84), getresuid(118)
next 64 (unweighted API importances from 0.360581 to 0.056728): getresgid(120), getpeername(52), shmdt(67), fchmod(91), shmctl(31), shmat(30), sigaltstack(131), fsync(74), listen(50), eventfd2(290), accept(43), link(86), fstatfs(138), pread64(17), fchown(93), getppid(110), pwrite64(18), umask(95), chown(92), inotify_init(253), inotify_add_watch(254), inotify_rm_watch(255), shmget(29), inotify_init1(294), fadvise64(221), symlink(88), socketpair(53), setsid(112), fallocate(285), sched_getscheduler(145), sched_getparam(143), prctl(157), times(100), utimes(235), lchown(94), getxattr(191), lgetxattr(192), setxattr(188), llistxattr(195), fgetxattr(193), splice(275), listxattr(194), flistxattr(196), setuid(105), alarm(37), setgid(106), setrlimit(160), getrusage(98), getgroups(115), semget(64), dup3(292), semctl(66), utime(132), epoll_ctl(233), epoll_wait(232), clock_gettime(228), semop(65), sched_getaffinity(204), getpgrp(111), setgroups(116), setpriority(141), sync(162), mknod(133), setitimer(38)
next 57 (unweighted API importances from 0.052596 to 0.004020): msync(26), epoll_create1(291), sendmmsg(307), mlock(149), epoll_create(213), getpriority(140), fdatasync(75), pselect6(270), brk(12), ppoll(271), rt_sigsuspend(130), chroot(161), rt_sigtimedwait(128), munlock(150), creat(85), pause(34), flock(73), mlockall(151), truncate(76), fchdir(81), mbind(237), sched_setaffinity(203), timerfd_create(283), rt_sigpending(127), timerfd_settime(286), setreuid(113), getitimer(36), getpgid(121), mincore(27), utimensat(280), timer_delete(226), sendfile(40), getsid(124), setregid(114), timer_settime(223), timer_create(222), munlockall(152), mount(165), capget(125), sysinfo(99), accept4(288), name_to_handle_at(303), get_mempolicy(239), set_mempolicy(238), migrate_pages(256), lsetxattr(189), arch_prctl(158), signalfd4(289), ioprio_set(251), faccessat(269), fsetxattr(190), ptrace(101), tkill(200), unlinkat(263), readlinkat(267), iopl(172), rt_sigqueueinfo(129)
Vectored System Call Opcodes Some system calls, such as ioctl , fcntl , and prctl , es- sentially export a secondary system call table, using the first argument as an operation code. These vectored system calls significantly expand the system API, dramatically increasing the effort to realize full API compatibility. It is also difficult to enforce robust security policies on these interfaces, as the arguments to each operation are highly variable. ... Compared to system calls, ioctl has a much longer tail of infrequently used operations. Out of 635 ioctl opera- tion codes defined by modules or drivers hosted in Linux kernel 3.19, only 188 have API importance more than one percent, and for only 280 we can find usage of the operations in at least one application binary.
developers of a new system prototype should sup- port these 47 most important ioctl operations, about half of the fcntl opcodes, and only 9–20 prcntl operations. ...
the 'about half' of the fcntl opcodes with API importance > 0.01:
F_(GET
| SET)FD, F_(GET | SET)FL, F_SETLKW(0x7), F_GETOWN_EX(0x10), F_DUPFD(0x0), F_(GET | SET)LK, F_(GET | SET)OWN(0x8), F_SETSIG(0xa) |
(note: F_SETOWN_EX and F_GETSIG both exist but are apparently relatively unused; there is no GETLKW, and DUPFD is also unpaired; note: in the 'application developer' dataset F_GETOWN is also unimportant, otherwise it's unchanged)
the most used 20 prcntl operations, with some 'API importance's, are:
PR_GET_DUMPABLE(0x3) (1.000000), PR_SET_NAME(0xf), PR_SET_KEEPCAPS(0x8), PR_GET_NAME(0x10), PR_SET_DUMPABLE(0x4), PR_SET_PTRACER(0x59616d61) (1.000000), PR_CAPBSET_DROP(0x18) (0.999811), PR_SET_PDEATHSIG(0x1), PR_GET_KEEPCAPS(0x7) (0.999536), PR_SET_NO_NEW_PRIVS(0x26) (0.956747), PR_SET_TIMERSLACK(0x1d), PR_SET_CHILD_SUBREAPER(0x24), PR_SET_SECCOMP(0x16) (0.904748), PR_GET_SECCOMP(0x15) (0.868218), PR_GET_TIMERSLACK(0x1e) (0.760611), PR_SET_SECUREBITS(0x1c) (0.617493), PR_GET_SECUREBITS(0x1b) (0.310459), PR_CAPBSET_READ(0x17) (0.230737), PR_MCE_KILL(0x21) (0.023592), PR_GET_PDEATHSIG(0x2) (0.005751)
and for the 'application developer' dataset: PR_SET_NAME(0xf) (0.113456), PR_GET_DUMPABLE(0x3) (0.068677), PR_SET_PTRACER(0x59616d61) (0.032831), PR_GET_NAME(0x10) (0.014405), PR_SET_KEEPCAPS(0x8) (0.008152), PR_SET_DUMPABLE(0x4) (0.007929), PR_SET_PDEATHSIG(0x1) (0.004020), PR_SET_NO_NEW_PRIVS(0x26) (0.002903), PR_CAPBSET_DROP(0x18) (0.002457), PR_SET_SECCOMP(0x16) (0.002010), PR_GET_KEEPCAPS(0x7) (0.001675), PR_CAPBSET_READ(0x17) (0.001005), PR_MCE_KILL(0x21) (0.000782), PR_GET_TIMERSLACK(0x1e) (0.000782), PR_SET_SECUREBITS(0x1c) (0.000558), PR_SET_TIMERSLACK(0x1d) (0.000558), PR_SET_MM(0x23) (0.000447), PR_GET_SECUREBITS(0x1b) (0.000447), PR_GET_PDEATHSIG(0x2) (0.000335), PR_SET_CHILD_SUBREAPER(0x24),0.000335
the 47 most used ioctl operations are:
TCGETS(0x5401), TCSETS(0x5402), FIONREAD(0x541b), TIOCGWINSZ(0x5413), TIOCGPGRP(0x540f), TIOCSWINSZ(0x5414), TIOCSCTTY(0x540e), FIONBIO(0x5421), TIOCGPTN(0x80045430), TIOCSPTLCK(0x40045431), BLKGETSIZE(0x1260), BLKGETSIZE64(0x80081272), TIOCSPGRP(0x5410), BLKSSZGET(0x1268), FDGETPRM(0x80200204), BLKPBSZGET(0x127b), TIOCSETD(0x5423), BLKRRPART(0x125f), TIOCMGET(0x5415), TCSBRK(0x5409), TIOCNOTTY(0x5422), BLKFLSBUF(0x1261), FDFLUSH(0x24b), BLKALIGNOFF(0x127a), FIBMAP(0x1), TIOCMSET(0x5418), BLKRAGET(0x1263), FIGETBSZ(0x2), TIOCLINUX(0x541c), USBDEVFS_RELEASEINTERFACE(0x80045510), BLKROGET(0x125e), USBDEVFS_CLAIMINTERFACE(0x8004550f), USBDEVFS_CONNECTINFO(0x40085511), USBDEVFS_CLEAR_HALT(0x80045515), BLKDISCARD(0x1277), TIOCGSID(0x5429), BLKPG(0x1269), BLKBSZGET(0x80081270), TIOCGLCKTRMIOS(0x5456), TIOCSLCKTRMIOS(0x5457), BLKSECDISCARD(0x127d), WDIOC_GETTIMEOUT(0x80045707), FDFMTBEG(0x247), FDFMTEND(0x249), FDFMTTRK(0x400c0248), TIOCMBIS(0x5416), TIOCCONS(0x541d),
and for the 'application developer' dataset, with some 'unweighted API importance's:
TCGETS(0x5401) (0.639978), FIONREAD(0x541b) (0.317811), TCSETS(0x5402) (0.208822), TIOCGWINSZ(0x5413) (0.119821), FIONBIO(0x5421) (0.063987), TIOCGPGRP(0x540f) (0.047795), TIOCGPTN(0x80045430) (0.038191), TIOCSPTLCK(0x40045431) (0.037744), TIOCSWINSZ(0x5414) (0.027359), TIOCSCTTY(0x540e) (0.020882), TIOCMGET(0x5415) (0.017644), TCSBRK(0x5409) (0.016527), TIOCMSET(0x5418) (0.014182), TIOCNOTTY(0x5422) (0.012395), BLKGETSIZE64(0x80081272) (0.011949), TIOCSPGRP(0x5410) (0.010162), TIOCOUTQ(0x5411) (0.009380), BLKGETSIZE(0x1260) (0.008599), USBDEVFS_RELEASEINTERFACE(0x80045510) (0.007929), USBDEVFS_CLAIMINTERFACE(0x8004550f) (0.007929), TIOCCBRK(0x5428) (0.007929), BLKSSZGET(0x1268) (0.007817), USBDEVFS_CONNECTINFO(0x40085511) (0.007817), TIOCSBRK(0x5427) (0.007817), TUNSETIFF(0x400454ca) (0.007147), FIBMAP(0x1) (0.006588), FDGETPRM(0x80200204) (0.004578), USBDEVFS_SETCONFIGURATION(0x80045505) (0.004132), USBDEVFS_SETINTERFACE(0x80085504) (0.003573), BLKDISCARD(0x1277) (0.003350), TIOCMBIS(0x5416) (0.003238), TIOCMBIC(0x5417) (0.003127), TIOCLINUX(0x541c) (0.003015), VIDIOC_QUERYCAP(0x80685600) (0.002903), TCGETA(0x5405) (0.002903), VIDIOC_RESERVED(0x5601) (0.002680), TIOCSTI(0x5412) (0.002680), FIGETBSZ(0x2) (0.002680), TIOCCONS(0x541d) (0.002568), BLKFLSBUF(0x1261) (0.002568), TIOCGSERIAL(0x541e) (0.002345), USBDEVFS_RESET(0x5514) (0.002345), BLKROGET(0x125e) (0.002233), USBDEVFS_CLEAR_HALT(0x80045515) (0.002233), USBDEVFS_GETDRIVER(0x41045508) (0.002122), TIOCSETD(0x5423) (0.002010), BLKRAGET(0x1263) (0.001898)
most important interfaces in /dev and /proc: /dev/null /proc/cpuinfo /proc/meminfo /dev/urandom /dev/random /dev/zero /proc/vmstat /dev/srandom /proc/cgroups /proc/syst/kernel/random /dev/parport* /proc/irq
...
However, it is plausible to provide the same functionality in simpler ways. For instance, /proc/cpuinfo provides a formatted wrapper for the cpuinfo instruction...Similarly, /dev/zero or /dev/null are convenient for use on the command line,but it is surprising that a significant number of applications issue read or write system calls, rather than simply zero- ing a buffer or skipping the write
...
In the case of the /dev file system, the most commonly used files are pseudo-devices, such as accessing the virtual terminal ( /dev/tty , /dev/console , and /dev/pts ), or other functionality such as the random number generator ( /dev/urandom ). Even among pseudo-devices, features such as accessing one’s standard in and out, or a process’s TTY via the /dev/ interface are not heavily used.
...
Figure 7 shows the API importance of the global func- tion symbols exported by libc—1,274 in total. Among these APIs, 42.8% have a API importance of 100%, 50.6% have a API importance of less than 50%, and 39.7% have a API importance of less than one percent, including some that are not used at all. In other words, about 40% of the APIs inside libc are either not used or only used by few applications. ... We analyzed the space savings of a GNU libc 2.21 which removed any APIs with API importance lower than 90%. In total, libc would retain 889 APIs and the size would be re- duced to 63% of its original size. The probability an applica- tion would need a missing function and load it from another library is less than 9.3%(equivalent to 90.7% weighted com- pleteness for the stripped libc). "
"In several cases, such as set tid address , how- ever, libc or libpthread may be the only binaries using these interfaces directly, indicating that changes to some important system interfaces would only require changes in one or two low-level libraries."
Table 5. Ubiquitous system call usage caused by initializa- tion or finalization of libc family. System Calls Libraries ld.so: access,arch_prctl,mprotect libc: clone,execve,getuid,gettid,kill,getrlimit,setresuid libc, ld.so: close,exit,exitgroup,getcwd,getdents,getpid,lseek,lstat,mmap,munmap,madvise,mprotect,mremap,newfsstat,read libpthread: rt_sigreturn,set_robust_list,set_tid_address librt: rt_sigprocmask libc, ld.so, libpthread: futex
We evaluate the weighted completeness of four Linux- compatible systems or emulation layers: User-Mode-Linux [25], L4Linux [32], FreeBSD?
UML 3.19: 284 calls, 93.1% L4Linux 4.3: 286 calls, 99.3% FreeBSD?-emu 10.2: 225 calls, 62.3% Graphene: 143 calls, 0.42% Graphene, plus sched_setscheduler, sched_setparam: 145 calls, 21.2%
This study also uses ((normalized)) weighted completeness to evaluate the compatibility of several libc variants — eglibc [4], uClibc [8], musl [6] and dietlibc:
eglibc 2.19: 2198 symbols, 100% uClibc 0.9.33: 1867 symbols, 41.9% musl 1.1.14: 1890 symbols, 43.2% dietlibc 0.33: 962 symbols, 0% (most needs: memalign,stpcpy,cxa_finalize)
...
One family of APIs prone to security problems are the set
...
Directory operations have a long history of exploitable race conditions [20, 21, 54], or time-of-check-to-time-of- use (TOCTTOU) vulnerabilities. In a privileged application, one system call (e.g., access ) checks the user’s permis- sion, and a second call operates on the file. There are coun- termeasures that effectively walk the directory hierarchy in user space [50]. This approach replaces calls like access with faccessat , and similar variants ...
insecure vs secure: setuid, setreuid vs setresuid setgid, setregid vs setresgid getuid, geteuid vs getresuid getgid, egtegid vs getresgid
nonatomic vs atomic directory operations:
access vs faccessat mkdir vs mkdirat rename vs renameat readlink vs readlinkat chown vs fchownat chmod vs fchmodat
wait4 system call is considered obsolete [9], and the alternative waitid is preferred, as it more precisely specifies which child state changes to wait for. ...
deprecated vs replacement:
getdents vs getdents64 utime vs utimes fork,vfork vs clone tkill vs tgkill wait4 vs waitid
most developers prefer portable or generic APIs more than Linux-specific APIs. Except pipe2 , most API variants that are Linux-specific have un- weighted API importance lower than 10 percent.
Linux Specific, Unweighted API importance Portable / Generic, Unweighted API importance preadv 0.15%, readv 62.23% pwritev 0.16%, writev 99.80% accept4 0.93%, accept 29.35% ppoll 3.90%, poll 71.07% recvmmsg 0.11%, recvmsg 68.82% sendmmsg 5.17%, sendmsg 42.49% pipe2 40.33%, pipe 50.33%
Finally, we consider system calls with multiple variants where one version has increased functionality. Table 11 shows the difference between these system calls. Interest- ingly, more developers chose the less powerful variants, such as using select over pselect6 , or dup2 over dup3 . This indicates that more often than not, developers choose simplicity unless a task demands the functionality of a more powerful API variant.
Table 11. The unweighted API importance among similar API variants. Higher is more important.
read 99.88%, pread64 27.23% dup3 8.72%, dup2 99.75%, dup 66.64% recvmsg 68.82%, recvfrom 53.80% sendmsg 42.49%, sendto 71.71% select 61.53%, pselect6 4.13% chdir 44.61%, fchdir 2.20%
"
"Cycada [7] is a binary compatibility framework for An- droid and iOS applications. Given that both Android and iOS implement similar POSIX functionality, we initially thought that building Cycada would be relatively straight- forward compared to previous Windows-UNIX compatibil- ity efforts. However, achieving compatibility even between Android and iOS turned out to be a herculean task. A main obstacle was the extensive use of POSIX’s ioctl exten- sion API, which is highly platform-specific and loosely de- fined. To address this challenge, we elevated the level of abstraction at which we constructed binary compatibility from POSIX to newer, high-level abstractions used by ap- plications, such as graphics and sound libraries. With this approach, and intuitively assuming that most applications leverage these abstractions, we were able to translate be- tween well-defined interfaces and run unmodified iOS ap- plications on Android."
---
http://www.w3schools.com/js/js_timing.asp
---
linux syscalls implemented in Windows lxcore.sys build 14342 (circa 2016/6/9):
%rax Name Entry point (Linux) Implementation (Linux) Lxss implementation? Lxss debug string 0 read sys_read fs/read_write.c Yes READ - %u, {%p}, %u 1 write sys_write fs/read_write.c Yes WRITE - %d, {%p}, %u 2 open sys_open fs/open.c Yes OPEN - {%p}, 0x%x, 0x%x 3 close sys_close fs/open.c Yes CLOSE - %u 4 stat sys_newstat fs/stat.c Yes STAT64 - {%p}, {%p} 5 fstat sys_newfstat fs/stat.c Yes FSTAT64 - %u, {%p} 6 lstat sys_newlstat fs/stat.c Yes LSTAT64 - {%p}, {%p} 7 poll sys_poll fs/select.c Yes POLL - {%p}, %u, %d 8 lseek sys_lseek fs/read_write.c Yes LSEEK - %u, %u, %u 9 mmap sys_mmap arch/x86/kernel/sys_x86_64.c Yes MMAP - {%p}, 0x%x, %Iu, 0x%x, %d, %Iu 10 mprotect sys_mprotect mm/mprotect.c Yes MPROTECT - {%p}, 0x%x, 0x%x 11 munmap sys_munmap mm/mmap.c Yes MUNMAP - {%p}, 0x%x 12 brk sys_brk mm/mmap.c Yes BRK - {%p} 13 rt_sigaction sys_rt_sigaction kernel/signal.c Yes RT_SIGACTION - %u, {%p}, {%p} %lu 14 rt_sigprocmask sys_rt_sigprocmask kernel/signal.c Yes RT_SIGPROCMASK - %u, {%p}, {%p}, %lu 15 rt_sigreturn stub_rt_sigreturn arch/x86/kernel/signal.c Yes RT_SIGRETURN 16 ioctl sys_ioctl fs/ioctl.c Yes IOCTL - %d, 0x%x, {%p} 17 pread64 sys_pread64 fs/read_write.c Yes PREAD64 - %d, {%p}, %u, %u, %u 18 pwrite64 sys_pwrite64 fs/read_write.c Yes PWRITE64 - %d, {%p}, %u, %u, %u 19 readv sys_readv fs/read_write.c Yes READV - %d, {%p}, %u 20 writev sys_writev fs/read_write.c Yes WRITEV - %d, {%p}, %u 21 access sys_access fs/open.c Yes ACCESS - {%p}, %u 22 pipe sys_pipe fs/pipe.c Yes PIPE - {%p} 23 select sys_select fs/select.c Yes SELECT - %d, {%p}, {%p}, {%p}, {%p} 24 sched_yield sys_sched_yield kernel/sched/core.c Yes SCHED_YIELD 25 mremap sys_mremap mm/mmap.c Yes MREMAP - {%p}, 0x%Ix, 0x%Ix, 0x%x, {%p} 26 msync sys_msync mm/msync.c Yes MSYNC - {%p}, 0x%x, 0x%x
28 madvise sys_madvise mm/madvise.c Yes MADVISE - {%p}, 0x%x, %u
32 dup sys_dup fs/file.c Yes DUP - %u 33 dup2 sys_dup2 fs/file.c Yes DUP2 - %d, %d 34 pause sys_pause kernel/signal.c Yes PAUSE 35 nanosleep sys_nanosleep kernel/hrtimer.c Yes NANOSLEEP - {%p}, {%p}
37 alarm sys_alarm kernel/timer.c Yes ALARM - %u 38 setitimer sys_setitimer kernel/itimer.c Yes SETITIMER %d, {%p}, {%p} 39 getpid sys_getpid kernel/sys.c Yes GETPID
41 socket sys_socket net/socket.c Yes SOCKET - %d, %d, %d 42 connect sys_connect net/socket.c Yes CONNECT - %d, {%p}, %d 43 accept sys_accept net/socket.c Yes ACCEPT - %d, {%p}, {%p} 44 sendto sys_sendto net/socket.c Yes SENDTO - %d, {%p}, %Iu, %d, {%p}, %d 45 recvfrom sys_recvfrom net/socket.c Yes RECVFROM - %d, {%p}, %Iu, %d, {%p}, {%p} 46 sendmsg sys_sendmsg net/socket.c Yes SENDMSG - %d, {%p}, %d 47 recvmsg sys_recvmsg net/socket.c Yes RECVMSG - %d, {%p}, %d 48 shutdown sys_shutdown net/socket.c Yes SHUTDOWN - %d, %d 49 bind sys_bind net/socket.c Yes BIND - %d, {%p}, %d 50 listen sys_listen net/socket.c Yes LISTEN - %d, %d 51 getsockname sys_getsockname net/socket.c Yes GETSOCKNAME - %d, {%p}, {%p}
53 socketpair sys_socketpair net/socket.c Yes SOCKETPAIR - %d, %d, %d, {%p} 54 setsockopt sys_setsockopt net/socket.c Yes SETSOCKOPT - %d, %d, %d, {%p}, %d 55 getsockopt sys_getsockopt net/socket.c Yes GETSOCKOPT - %d, %d, %d, {%p}, {%p} 56 clone stub_clone kernel/fork.c Yes CLONE - 0x%x, {%p}, {%p}, {%p}, {%p} 57 fork stub_fork kernel/fork.c Yes FORK 58 vfork stub_vfork kernel/fork.c Yes VFORK 59 execve stub_execve fs/exec.c Yes EXECVE - {%p}, {%p}, {%p} 60 exit sys_exit kernel/exit.c Yes EXIT - %x 61 wait4 sys_wait4 kernel/exit.c Yes WAIT4 - %u, {%p}, %u, {%p} 62 kill sys_kill kernel/signal.c Yes KILL - 0x%x, %u 63 uname sys_newuname kernel/sys.c Yes NEWUNAME - {%p}
72 fcntl sys_fcntl fs/fcntl.c Yes FCNTL64 - %u, %u, 0x%x 73 flock sys_flock fs/locks.c Yes FLOCK - %u %u 74 fsync sys_fsync fs/sync.c Yes FSYNC - %u 75 fdatasync sys_fdatasync fs/sync.c Yes FDATASYNC - %u 76 truncate sys_truncate fs/open.c Yes TRUNCATE64 - {%p}, %d, %d 77 ftruncate sys_ftruncate fs/open.c Yes FTRUNCATE64 - %d, %I64 78 getdents sys_getdents fs/readdir.c Yes GETDENTS - %d, {%p}, %u 79 getcwd sys_getcwd fs/dcache.c Yes GETCWD - {%p}, %u 80 chdir sys_chdir fs/open.c Yes CHDIR - {%p} 81 fchdir sys_fchdir fs/open.c Yes FCHDIR - %u 82 rename sys_rename fs/namei.c Yes RENAME - {%p}, {%p} 83 mkdir sys_mkdir fs/namei.c Yes MKDIR - {%p}, 0x%x 84 rmdir sys_rmdir fs/namei.c Yes RMDIR - {%p} 85 creat sys_creat fs/open.c Yes CREAT - {%p}, 0x%x 86 link sys_link fs/namei.c Yes LINK - {%p}, {%p} 87 unlink sys_unlink fs/namei.c Yes UNLINK - {%p} 88 symlink sys_symlink fs/namei.c Yes SYMLINK - {%p}, {%p} 89 readlink sys_readlink fs/stat.c Yes READLINK - {%p}, {%p}, %Iu 90 chmod sys_chmod fs/open.c Yes CHMOD - {%p}, %u 91 fchmod sys_fchmod fs/open.c Yes FCHMOD - {%d}, %u 92 chown sys_chown fs/open.c Yes CHOWN - {%p}, %u, %u 93 fchown sys_fchown fs/open.c Yes FCHOWN - %u, %u, %u 94 lchown sys_lchown fs/open.c Yes LCHOWN - {%p}, %u, %u 95 umask sys_umask kernel/sys.c Yes UMASK - 0%o 96 gettimeofday sys_gettimeofday kernel/time.c Yes GETTIMEOFDAY - {%p}, {%p}
98 getrusage sys_getrusage kernel/sys.c Yes GETRUSAGE%d, {%p}
100 times sys_times kernel/sys.c Yes TIMES - {%p}
102 getuid sys_getuid kernel/sys.c Yes GETUID
104 getgid sys_getgid kernel/sys.c Yes GETGID 105 setuid sys_setuid kernel/sys.c Yes SETUID - %u 106 setgid sys_setgid kernel/sys.c Yes SETGID - %u 107 geteuid sys_geteuid kernel/sys.c Yes GETEUID 108 getegid sys_getegid kernel/sys.c Yes GETEGID 109 setpgid sys_setpgid kernel/sys.c Yes SETPGID - %u, %u 110 getppid sys_getppid kernel/sys.c Yes GETPPID 111 getpgrp sys_getpgrp kernel/sys.c Yes GETPGRP 112 setsid sys_setsid kernel/sys.c Yes SETSID 113 setreuid sys_setreuid kernel/sys.c Yes SETREUID - %u, %u 114 setregid sys_setregid kernel/sys.c Yes SETREGID - %u, %u 115 getgroups sys_getgroups kernel/groups.c Yes GETGROUPS%d, {%p}
117 setresuid sys_setresuid kernel/sys.c Yes SETRESUID - %u, %u, %u 118 getresuid sys_getresuid kernel/sys.c Yes GETRESUID - {%p}, {%p}, {%p} 119 setresgid sys_setresgid kernel/sys.c Yes SETRESGID - %u, %u, %u 120 getresgid sys_getresgid kernel/sys.c Yes GETRESGID - {%p}, {%p}, {%p} 121 getpgid sys_getpgid kernel/sys.c Yes GETPGID - 0x%x 122 setfsuid sys_setfsuid kernel/sys.c Yes SETFSUID - %u 123 setfsgid sys_setfsgid kernel/sys.c Yes SETFSGID - %u 124 getsid sys_getsid kernel/sys.c Yes GETSID - 0x%x 125 capget sys_capget kernel/capability.c Yes CAPGET - {%p}, {%p} 126 capset sys_capset kernel/capability.c Yes CAPSET - {%p}, {%p} 127 rt_sigpending sys_rt_sigpending kernel/signal.c Yes RT_SIGPENDING - {%p}, %lu
130 rt_sigsuspend sys_rt_sigsuspend kernel/signal.c Yes RT_SIGSUSPEND - {%p}, %lu
132 utime sys_utime fs/utimes.c Yes UTIME - {%p}, {%p}
135 personality sys_personality kernel/exec_domain.c Yes PERSONALITY - 0x%Ix
137 statfs sys_statfs fs/statfs.c Yes STATFS64 - {%p}, %u, {%p} 138 fstatfs sys_fstatfs fs/statfs.c Yes FSTATFS64- %u %u {%p}
140 getpriority sys_getpriority kernel/sys.c Yes GETPRIORITY - %d, %d 141 setpriority sys_setpriority kernel/sys.c Yes SETPRIORITY - %d, %d, %d 142 sched_setparam sys_sched_setparam kernel/sched/core.c Yes SCHED_SETPARAM - %u, {%p} 143 sched_getparam sys_sched_getparam kernel/sched/core.c Yes SCHED_GETPARAM - %u, {%p} 144 sched_setscheduler sys_sched_setscheduler kernel/sched/core.c Yes SCHED_SETSCHEDULER - %u, %d, {%p} 145 sched_getscheduler sys_sched_getscheduler kernel/sched/core.c Yes SCHED_GETSCHEDULER - %u 146 sched_get_priority_max sys_sched_get_priority_max kernel/sched/core.c Yes SCHED_GET_PRIORITY_MAX - %u 147 sched_get_priority_min sys_sched_get_priority_min kernel/sched/core.c Yes SCHED_GET_PRIORITY_MIN - %u
157 prctl sys_prctl kernel/sys.c Yes PRCTL - %u, 0x%x, 0x%x, 0x%x, 0x%x 158 arch_prctl sys_arch_prctl arch/x86/um/syscalls_64.c Yes ARCH_PRCTL - %d, {%p}
162 sync sys_sync fs/sync.c Yes SYNC
164 settimeofday sys_settimeofday kernel/time.c Yes SETTIMEOFDAY - {%p}, {%p}
169 reboot sys_reboot kernel/reboot.c Yes REBOOT - %x, %x, %d, {%p} 170 sethostname sys_sethostname kernel/sys.c Yes SETHOSTNAME - {%p}, %u 171 setdomainname sys_setdomainname kernel/sys.c Yes SETDOMAINNAME - {%p}, %u
186 gettid sys_gettid kernel/sys.c Yes GETTID
188 setxattr sys_setxattr fs/xattr.c Yes SETXATTR - {%p}, {%p}, {%p}, 0x%x, %d
190 fsetxattr sys_fsetxattr fs/xattr.c Yes FSETXATTR - %d, {%p}, {%p}, 0x%x, %d
201 time sys_time kernel/time.c Yes TIME - {%p} 202 futex sys_futex kernel/futex.c Yes FUTEX - {%p}, 0x%x, 0x%x, {%p}, {%p}, 0x%x
204 sched_getaffinity sys_sched_getaffinity kernel/sched/core.c Yes SCHED_GETAFFINITY - %u, %u, {%p} 205 set_thread_area arch/x86/kernel/tls.c Yes SET_THREAD_AREA - {%p}
213 epoll_create sys_epoll_create fs/eventpoll.c Yes EPOLL_CREATE - %d
217 getdents64 sys_getdents64 fs/readdir.c Yes GETDENTS64 - %d, {%p}, %u 218 set_tid_address sys_set_tid_address kernel/fork.c Yes SET_TID_ADDRESS - {%p}
228 clock_gettime sys_clock_gettime kernel/posix-timers.c Yes CLOCK_GETTIME - %u, {%p} 229 clock_getres sys_clock_getres kernel/posix-timers.c Yes CLOCK_GETRES - %u, {%p} 230 clock_nanosleep sys_clock_nanosleep kernel/posix-timers.c Yes CLOCK_NANOSLEEP - %u, 0x%x, {%p}, {%p} 231 exit_group sys_exit_group kernel/exit.c Yes EXIT_GROUP - %x 232 epoll_wait sys_epoll_wait fs/eventpoll.c Yes EPOLL_WAIT - %d, {%p}, %d, %d 233 epoll_ctl sys_epoll_ctl fs/eventpoll.c Yes EPOLL_CTL - %d, %d, %d, {%p}
235 utimes sys_utimes fs/utimes.c Yes UTIMES - {%p}, {%p}
250 keyctl sys_keyctl security/keys/keyctl.c Yes KEYCTL - 0x%x, 0x%x, 0x%x, 0x%x, 0x%x
257 openat sys_openat fs/open.c Yes OPENAT - %u {%p}, 0x%x, 0x%x 258 mkdirat sys_mkdirat fs/namei.c Yes MKDIRAT - %u, {%p}, 0x%x
260 fchownat sys_fchownat fs/open.c Yes FCHOWNAT - %d, {%p}, %u, %u, %d
262 newfstatat sys_newfstatat fs/stat.c Yes FSTATAT64 - %u {%p} {%p} %u 263 unlinkat sys_unlinkat fs/namei.c Yes UNLINKAT - %u, {%p}, 0x%x 264 renameat sys_renameat fs/namei.c Yes RENAMEAT - %d, {%p}, %d, {%p} 265 linkat sys_linkat fs/namei.c Yes LINKAT - %d, {%p}, %d, {%p}, %d 266 symlinkat sys_symlinkat fs/namei.c Yes SYMLINKAT - {%p}, %d, {%p} 267 readlinkat sys_readlinkat fs/stat.c Yes READLINKAT - %d, {%p}, {%p}, %Iu 268 fchmodat sys_fchmodat fs/open.c Yes FCHMODAT - {%d}, {%p}, %u 269 faccessat sys_faccessat fs/open.c Yes FACCESSAT - %d, {%p}, %d, %d 270 pselect6 sys_pselect6 fs/select.c Yes PSELECT6 - %d, {%p}, {%p}, {%p}, {%p}, {%p} 271 ppoll sys_ppoll fs/select.c Yes PPOLL - {%p}, %u, {%p}, {%p}, %u
275 splice sys_splice fs/splice.c Yes SPLICE - %u, {%p}, %u, {%p}, %d, %d 276 tee sys_tee fs/splice.c Yes TEE - %d, %d, %u, %d
280 utimensat sys_utimensat fs/utimes.c Yes UTIMENSAT - %u, {%p} {%p} 0x%x
283 timerfd_create sys_timerfd_create fs/timerfd.c Yes TIMERFD_CREATE - {%d} {%d}
286 timerfd_settime sys_timerfd_settime fs/timerfd.c Yes TIMERFD_SETTIME - {%d}, {%d}, {%p}, {%p} 287 timerfd_gettime sys_timerfd_gettime fs/timerfd.c Yes TIMERFD_GETTIME - {%d}, {%p} 288 accept4 sys_accept4 net/socket.c Yes ACCEPT4 - %d, {%p}, {%p}, %d
291 epoll_create1 sys_epoll_create1 fs/eventpoll.c Yes EPOLL_CREATE1 - %d 292 dup3 sys_dup3 fs/file.c Yes DUP3 - %d, %d, %d
307 sendmmsg sys_sendmmsg net/socket.c Yes SENDMMSG - %d, {%p}, %u, %u
310 process_vm_readv sys_process_vm_readv mm/process_vm_access.c Yes PROCESS_VM_READV - %u, {%p}, %u, {%p}, %u, %u 311 process_vm_writev sys_process_vm_writev mm/process_vm_access.c Yes PROCESS_VM_WRITEV - %u, {%p}, %u, {%p}, %u, %u
and the ones with stub support:
%rax Name Entry point (Linux) Implementation (Linux) Lxss implementation? Lxss debug string 52 getpeername sys_getpeername net/socket.c Yes (stub) GETPEERNAME (stub) - %d, {%p}, {%p} 97 getrlimit sys_getrlimit kernel/sys.c Yes (stub) GETRLIMIT (stub) - %u, {%p} 99 sysinfo sys_sysinfo kernel/sys.c Yes (stub) SYSINFO (stub) - {%p} 101 ptrace sys_ptrace kernel/ptrace.c Yes (stub) PTRACE (stub) - %u, %u, {%p}, {%p} 116 setgroups sys_setgroups kernel/groups.c Yes (stub) SETGROUPS (stub) - %u, {%p} 128 rt_sigtimedwait sys_rt_sigtimedwait kernel/signal.c Yes (stub) RT_SIGTIMEDWAIT (stub-err) - {%p}, {%p}, {%p}, %lu 131 sigaltstack sys_sigaltstack kernel/signal.c Yes (stub) SIGALTSTACK (stub) {%p}, {%p} 133 mknod sys_mknod fs/namei.c Yes (stub) MKNOD (stub) - {%p}, %x, %x 149 mlock sys_mlock mm/mlock.c Yes (stub) MLOCK (stub) - {%p}, %u 150 munlock sys_munlock mm/mlock.c Yes (stub) MUNLOCK (stub) - {%p}, %u 160 setrlimit sys_setrlimit kernel/sys.c Yes (stub) SETRLIMIT (stub) - %d, {%p} 165 mount sys_mount fs/namespace.c Yes (stub) MOUNT (stub) - {%p}, {%p}, {%p}, 0x%x, {%p}66 umount2 sys_umount fs/namespace.c Yes (stub) UMOUNT2 (stub) - {%p}, 0x%x 191 getxattr sys_getxattr fs/xattr.c Yes (stub) GETXATTR(stub) - {%p}, {%p}, {%p}, %Iu 200 tkill sys_tkill kernel/signal.c Yes (stub) TKILL (stub) - 0x%x, %u 203 sched_setaffinity sys_sched_setaffinity kernel/sched/core.c Yes (stub) SCHED_SETAFFINITY (stub) - %u, %u, {%p} 211 get_thread_area arch/x86/kernel/tls.c Yes (stub) GET_THREAD_AREA (stub) - {%p} 221 fadvise64 sys_fadvise64 mm/fadvise.c Yes (stub) FADVISE64 (stub) - %d, %lld, %lu, %d 234 tgkill sys_tgkill kernel/signal.c Yes (stub) TGKILL (stub) - 0x%x, 0x%x, %u 251 ioprio_set sys_ioprio_set fs/ioprio.c Yes (stub) IOPRIO_SET (stub) - 0x%x 0x%x 0x%x 252 ioprio_get sys_ioprio_get fs/ioprio.c Yes (stub) IOPRIO_GET (stub) - 0x%x 0x%x53 inotify_init sys_inotify_init fs/notify/inotify/inotify_user.c Yes (stub) INOTIFY_INIT (stub) 254 inotify_add_watch sys_inotify_add_watch fs/notify/inotify/inotify_user.c Yes (stub) INOTIFY_ADD_WATCH (stub) - %u {%p} %d 255 inotify_rm_watch sys_inotify_rm_watch fs/notify/inotify/inotify_user.c Yes (stub) INOTIFY_RM_WATCH (stub) - %u %u
272 unshare sys_unshare kernel/fork.c Yes (stub) UNSHARE (stub) - 0x%x 273 set_robust_list sys_set_robust_list kernel/futex.c Yes (stub) SET_ROBUST_LIST (stub) - {%p}, %Iu 274 get_robust_list sys_get_robust_list kernel/futex.c Yes (stub) GET_ROBUST_LIST (stub) - %u {%p}, {%p} 277 sync_file_range sys_sync_file_range fs/sync.c Yes (stub) SYNC_FILE_RANGE (stub) - %d, %x%08x, %x%08x, %d 284 eventfd sys_eventfd fs/eventfd.c Yes (stub) EVENTFD (stub) - 0x%x 290 eventfd2 sys_eventfd2 fs/eventfd.c Yes (stub) EVENTFD2 (stub) - 0x%x 0x%x 293 pipe2 sys_pipe2 fs/pipe.c Yes (stub) PIPE2 (stub) - %p %u 298 perf_event_open sys_perf_event_open kernel/events/core.c Yes (stub) PERF_EVENT_OPEN (stub) - {%p}, %u, %u, %u, 0x%Ix 309 getcpu sys_getcpu kernel/sys.c Yes (stub) GETCPU (stub) - {%p}, {%p}, {%p}
and the ones NOT implemented:
%rax Name Entry point (Linux) Implementation (Linux) Lxss implementation? Lxss debug string 27 mincore sys_mincore mm/mincore.c No 29 shmget sys_shmget ipc/shm.c No 30 shmat sys_shmat ipc/shm.c No 31 shmctl sys_shmctl ipc/shm.c No 36 getitimer sys_getitimer kernel/itimer.c No 40 sendfile sys_sendfile64 fs/read_write.c No 64 semget sys_semget ipc/sem.c No 65 semop sys_semop ipc/sem.c No 66 semctl sys_semctl ipc/sem.c No 67 shmdt sys_shmdt ipc/shm.c No 68 msgget sys_msgget ipc/msg.c No 69 msgsnd sys_msgsnd ipc/msg.c No 70 msgrcv sys_msgrcv ipc/msg.c No 71 msgctl sys_msgctl ipc/msg.c No 103 syslog sys_syslog kernel/printk/printk.c No 129 rt_sigqueueinfo sys_rt_sigqueueinfo kernel/signal.c No 134 uselib fs/exec.c No 136 ustat sys_ustat fs/statfs.c No 139 sysfs sys_sysfs fs/filesystems.c No 148 sched_rr_get_interval sys_sched_rr_get_interval kernel/sched/core.c No 151 mlockall sys_mlockall mm/mlock.c No 152 munlockall sys_munlockall mm/mlock.c No 153 vhangup sys_vhangup fs/open.c No 154 modify_ldt sys_modify_ldt arch/x86/um/ldt.c No 155 pivot_root sys_pivot_root fs/namespace.c No 156 _sysctl sys_sysctl kernel/sysctl_binary.c No 159 adjtimex sys_adjtimex kernel/time.c No 161 chroot sys_chroot fs/open.c No 163 acct sys_acct kernel/acct.c No 167 swapon sys_swapon mm/swapfile.c No 168 swapoff sys_swapoff mm/swapfile.c No 172 iopl stub_iopl arch/x86/kernel/ioport.c No 173 ioperm sys_ioperm arch/x86/kernel/ioport.c No 174 create_module NOT IMPLEMENTED No 175 init_module sys_init_module kernel/module.c No 176 delete_module sys_delete_module kernel/module.c No 177 get_kernel_syms NOT IMPLEMENTED No 178 query_module NOT IMPLEMENTED No 179 quotactl sys_quotactl fs/quota/quota.c No 180 nfsservctl NOT IMPLEMENTED No 181 getpmsg NOT IMPLEMENTED No 182 putpmsg NOT IMPLEMENTED No 183 afs_syscall NOT IMPLEMENTED No 184 tuxcall NOT IMPLEMENTED No 185 security NOT IMPLEMENTED No 187 readahead sys_readahead mm/readahead.c No 189 lsetxattr sys_lsetxattr fs/xattr.c No 192 lgetxattr sys_lgetxattr fs/xattr.c No 193 fgetxattr sys_fgetxattr fs/xattr.c No 194 listxattr sys_listxattr fs/xattr.c No 195 llistxattr sys_llistxattr fs/xattr.c No 196 flistxattr sys_flistxattr fs/xattr.c No 197 removexattr sys_removexattr fs/xattr.c No 198 lremovexattr sys_lremovexattr fs/xattr.c No 199 fremovexattr sys_fremovexattr fs/xattr.c No 206 io_setup sys_io_setup fs/aio.c No 207 io_destroy sys_io_destroy fs/aio.c No 208 io_getevents sys_io_getevents fs/aio.c No 209 io_submit sys_io_submit fs/aio.c No 210 io_cancel sys_io_cancel fs/aio.c No 212 lookup_dcookie sys_lookup_dcookie fs/dcookies.c No 214 epoll_ctl_old NOT IMPLEMENTED No 215 epoll_wait_old NOT IMPLEMENTED No 216 remap_file_pages sys_remap_file_pages mm/fremap.c No 219 restart_syscall sys_restart_syscall kernel/signal.c No 220 semtimedop sys_semtimedop ipc/sem.c No 222 timer_create sys_timer_create kernel/posix-timers.c No 223 timer_settime sys_timer_settime kernel/posix-timers.c No 224 timer_gettime sys_timer_gettime kernel/posix-timers.c No 225 timer_getoverrun sys_timer_getoverrun kernel/posix-timers.c No 226 timer_delete sys_timer_delete kernel/posix-timers.c No 227 clock_settime sys_clock_settime kernel/posix-timers.c No 236 vserver NOT IMPLEMENTED No 237 mbind sys_mbind mm/mempolicy.c No 238 set_mempolicy sys_set_mempolicy mm/mempolicy.c No 239 get_mempolicy sys_get_mempolicy mm/mempolicy.c No 240 mq_open sys_mq_open ipc/mqueue.c No 241 mq_unlink sys_mq_unlink ipc/mqueue.c No 242 mq_timedsend sys_mq_timedsend ipc/mqueue.c No 243 mq_timedreceive sys_mq_timedreceive ipc/mqueue.c No 244 mq_notify sys_mq_notify ipc/mqueue.c No 245 mq_getsetattr sys_mq_getsetattr ipc/mqueue.c No 246 kexec_load sys_kexec_load kernel/kexec.c No 247 waitid sys_waitid kernel/exit.c No 248 add_key sys_add_key security/keys/keyctl.c No 249 request_key sys_request_key security/keys/keyctl.c No 256 migrate_pages sys_migrate_pages mm/mempolicy.c No 259 mknodat sys_mknodat fs/namei.c No 261 futimesat sys_futimesat fs/utimes.c No 278 vmsplice sys_vmsplice fs/splice.c No 279 move_pages sys_move_pages mm/migrate.c No 281 epoll_pwait sys_epoll_pwait fs/eventpoll.c No 282 signalfd sys_signalfd fs/signalfd.c No 285 fallocate sys_fallocate fs/open.c No 289 signalfd4 sys_signalfd4 fs/signalfd.c No 294 inotify_init1 sys_inotify_init1 fs/notify/inotify/inotify_user.c No 295 preadv sys_preadv fs/read_write.c No 296 pwritev sys_pwritev fs/read_write.c No 297 rt_tgsigqueueinfo sys_rt_tgsigqueueinfo kernel/signal.c No 299 recvmmsg sys_recvmmsg net/socket.c No 300 fanotify_init sys_fanotify_init fs/notify/fanotify/fanotify_user.c No 301 fanotify_mark sys_fanotify_mark fs/notify/fanotify/fanotify_user.c No 302 prlimit64 sys_prlimit64 kernel/sys.c No 303 name_to_handle_at sys_name_to_handle_at fs/fhandle.c No 304 open_by_handle_at sys_open_by_handle_at fs/fhandle.c No 305 clock_adjtime sys_clock_adjtime kernel/posix-timers.c No 306 syncfs sys_syncfs fs/sync.c No 308 setns sys_setns kernel/nsproxy.c No 312 kcmp sys_kcmp kernel/kcmp.c No 313 finit_module sys_finit_module kernel/module.c No
and an alphabetized list of supported calls from the docs [7]:
ACCEPT, ACCEPT4, ACCESS, ALARM, ARCH_PRCTL, BIND, BRK, CAPGET, CAPSET, CHDIR, CHMOD, CHOWN, CLOCK_GETRES, CLOCK_GETTIME, CLOCK_NANOSLEEP, CLONE, CLOSE, CONNECT, CREAT, DUP, DUP2, DUP3, EPOLL_CREATE, EPOLL_CREATE1, EPOLL_CTL, EPOLL_WAIT, EVENTFD, EVENTFD2, EXECVE, EXIT, EXIT_GROUP, FACCESSAT, FADVISE64, FCHDIR, FCHMOD, FCHMODAT, FCHOWN, FCHOWNAT, FCNTL64, FDATASYNC, FLOCK, FORK, FSETXATTR, FSTAT64, FSTATAT64, FSTATFS64, FSYNC, FTRUNCATE, FTRUNCATE64, FUTEX, GETCPU, GETCWD, GETDENTS, GETDENTS64, GETEGID, GETEGID16, GETEUID, GETEUID16, GETGID, GETGID16, GETGROUPS, GETPEERNAME, GETPGID, GETPGRP, GETPID, GETPPID, GETPRIORITY, GETRESGID, GETRESGID16, GETRESUID, GETRESUID16, GETRLIMIT, GETRUSAGE, GETSID, GETSOCKNAME, GETSOCKOPT, GETTID, GETTIMEOFDAY, GETUID, GETUID16, GETXATTR, GET_ROBUST_LIST, GET_THREAD_AREA, INOTIFY_ADD_WATCH, INOTIFY_INIT, INOTIFY_RM_WATCH, IOCTL, IOPRIO_GET, IOPRIO_SET, KEYCTL, KILL, LCHOWN, LINK, LINKAT, LISTEN, LLSEEK, LSEEK, LSTAT64, MADVISE, MKDIR, MKDIRAT, MKNOD, MLOCK, MMAP, MMAP2, MOUNT, MPROTECT, MREMAP, MSYNC, MUNLOCK, MUNMAP, NANOSLEEP, NEWUNAME, OPEN, OPENAT, PAUSE, PERF_EVENT_OPEN, PERSONALITY, PIPE, PIPE2, POLL, PPOLL, PRCTL, PREAD64, PROCESS_VM_READV, PROCESS_VM_WRITEV, PSELECT6, PTRACE, PWRITE64, READ, READLINK, READV, REBOOT, RECV, RECVFROM, RECVMSG, RENAME, RMDIR, RT_SIGACTION, RT_SIGPENDING, RT_SIGPROCMASK, RT_SIGRETURN, RT_SIGSUSPEND, RT_SIGTIMEDWAIT, SCHED_GETAFFINITY, SCHED_GETPARAM, SCHED_GETSCHEDULER, SCHED_GET_PRIORITY_MAX, SCHED_GET_PRIORITY_MIN, SCHED_SETAFFINITY, SCHED_SETPARAM, SCHED_SETSCHEDULER, SCHED_YIELD, SELECT, SEND, SENDMMSG, SENDMSG, SENDTO, SETDOMAINNAME, SETGID, SETGROUPS, SETHOSTNAME, SETITIMER, SETPGID, SETPRIORITY, SETREGID, SETRESGID, SETRESUID, SETREUID, SETRLIMIT, SETSID, SETSOCKOPT, SETTIMEOFDAY, SETUID, SETXATTR, SET_ROBUST_LIST, SET_THREAD_AREA, SET_TID_ADDRESS, SHUTDOWN, SIGACTION, SIGALTSTACK, SIGPENDING, SIGPROCMASK, SIGRETURN, SIGSUSPEND, SOCKET, SOCKETCALL, SOCKETPAIR, SPLICE, STAT64, STATFS64, SYMLINK, SYMLINKAT, SYNC, SYSINFO, TEE, TGKILL, TIME, TIMERFD_CREATE, TIMERFD_GETTIME, TIMERFD_SETTIME, TIMES, TKILL, TRUNCATE, TRUNCATE64, UMASK, UMOUNT, UMOUNT2, UNLINK, UNLINKAT, UNSHARE, UTIME, UTIMENSAT, UTIMES, VFORK, WAIT4, WAITPID, WRITE, WRITEV
---
browsix implements some Linux syscalls in the browser (!):
https://github.com/plasma-umass/browsix/blob/master/src/kernel/kernel.ts
sync syscalls: read, write, open, close, unlink, execve, chdir, getpid, access, kill, rename, mkdir, rmdir, dup, pipe2, ioctl, getppid, wait4, llseek, t_sigaction, getcwd, stat64, lstat64, fstat64, getdents64, fcntl64, exit_group, dup3
async syscalls:
getcwd, personality, fork, kill, execve, fcntl64, exit, chdir, wait4, getpid, getppid, getdents, llseek, socket, bind, getsockname, getpeername, listen, accept, connect, spawn, pread, pwrite, pipe2, getpriority, setpriority, readdir, rename, open, dup, dup3, unlink, utimes, futimes, rmdir, mkdir, close, access, fstat, lstat, stat, readlink
the class Syscalls:
getcwd, personality, fork, execve, exit, kill, chdir, wait4, getpid, getppid, getdents, llseek, socket, bind, getsockname, getpeername, listen, accept, connect, spawn, pread, pwrite, pipe2, getpriority, setpriority, readdir, rename, open, dup, dup3, unlink, utimes, futimes, rmdir, mkdir, close, access, fstat, lstat, stat, readlink, ioctl
---
