The UNIX system has been in wide use for over 20 years, and has helped to define many areas of computing.
Post
Replies:
15
Boosts:
14
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
Within their home directories, users can create directories as easily as they can regular files. Thus, a user can build arbitrarily complex subhierarchies.
they lean on the user and perms system here but you can't really build a subhierarchy safely without interference because everything is always globally visible lmao
A three-level access-control mechanism is provided for the protection of files.
pathetic
there is half a page on how path length limitations lead to breakage
the long filenames first introduced in 4.2BSD practically eliminate it.
PATH_MAX still exists
