The UNIX system has been in wide use for over 20 years, and has helped to define many areas of computing.
An interface was specified, called mmap(), that
allowed unrelated processes to request a shared mapping of a file into their address spaces. If multiple processes mapped the same file into their address spaces, changes to the file's portion of an address space by one process would be reflected in the area mapped by the other processes, as well as in the file itself.
yeah!!!!! if i explicitly ask for a shared mapping let me have it!!! don't do it for every goddamn file write lmao
The biggest incentives for memory mapping are the needs for accessing big files and for passing large quantities of data between processes.
yes. great. sharing is caring
Demands for dynamic memory allocation in the kernel have increased as more services have been added.
lmao
A generalized memory allocator reduces the
complexity of writing code inside the kernel.
i'm not sure if i like the idea of an unstructured allocator mechanism. what if all kernel pages had a job
oh shit physical memory isn't paged oh fuck that's so dangerous i could just start writing somewhere and no one would know
The basic model of the UNIX I/O system is a sequence of bytes that can be accessed either randomly or sequentially.
already this seems oversimplified. the "bytes" corresponding to mapped pages is really important
looking at their modern aio api https://man.freebsd.org/cgi/man.cgi?query=aio&sektion=3&manpath=NetBSD+9.1
Asynchronous I/O operations are not strictly sequential; operations are carried out in arbitrary order
ok, what about lio_listio, that looks promising https://man.freebsd.org/cgi/man.cgi?query=lio_listio&sektion=3&apropos=0&manpath=NetBSD+9.1
The order in which the requests are carried out is not specified, and there is no guarantee that they will be executed sequentially.
awesome
Different programs expect various levels of structure, but the kernel does not impose structure on I/O.
"impose" structure. yes it fucking does!!!! the structure it imposes is that of a time series of operations based on offset and length, expressed through the syscall interface
ROBERT PIKE JUMPSCARE
An I/O stream from one program can be fed as input to almost any other program.
see i hate this shit because if i want to feed an i/o stream like this the kernel still makes me allocate my own buffer then do a read/write loop. does this build character?
so unserious!!! "splice() is zero-copy hohoho" i literally don't even care it just lets me express my intent to the kernel so it can optimize better this is so obvious ugh
There are different kinds of sockets that support various communication semantics, such as reliable delivery of data, preservation of message ordering, and preservation of
message boundaries.
i think if linux is allowed to make a broken cryptography socket i should be allowed to make an actually working file handle with specified buffering semantics
ok the reason i opened this damn book at all is because i wanted to see if they described the absurd posix requirement to globally share file buffers as mutable memory mappings
A file is a linear array of bytes with at least one name. A file exists until all its names are deleted explicitly and no process holds a descriptor for it.
nope
A process acquires a descriptor for a file by opening that file's name with the open system call. I/O devices are accessed as files.
nope
FIFOs are implemented in 4.4BSD only because they are required by the standard.
guy who spends a whole paragraph hyping up a feature and then blames the "standard"
The socket mechanism requires extensions to the traditional UNIX I/O system calls to provide the associated naming and connection semantics.
i'm 100000% gonna claim sockets as inspo
the filesystem section now. no mention of read() and write() being immediately globally visible
