Units
Translation components API.
See the Weblate's Web API documentation for detailed description of the API.
GET /api/translations/documentation/booksdesign-44bsd_index/zh_TW/units/?format=api&page=3
{ "count": 291, "next": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/units/?format=api&page=4", "previous": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/units/?format=api&page=2", "results": [ { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "The _kernel_ is the part of the system that runs in protected mode and mediates access by all user programs to the underlying hardware (e.g., CPU, disks, terminals, network links) and software constructs (e.g., filesystem, network protocols). The kernel provides the basic system facilities; it creates and manages processes, and provides functions to access the filesystem and communication facilities. These functions, called _system calls_ appear to user processes as library subroutines. These system calls are the only interface that processes have to these facilities. Details of the system-call mechanism are given in Chapter 3, as are descriptions of several kernel mechanisms that do not execute as the direct result of a process doing a system call." ], "previous_source": "", "target": [ "" ], "id_hash": -6081880030967671733, "content_hash": -6081880030967671733, "location": "documentation/content/en/books/design-44bsd/_index.adoc:78", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 13, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 116, "source_unit": "https://translate-dev.freebsd.org/api/units/1177650/?format=api", "priority": 100, "id": 1178890, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=2b98d255c3a1544b", "url": "https://translate-dev.freebsd.org/api/units/1178890/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:05.547907Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "Users ordinarily interact with the system through a command-language interpreter, called a _shell_, and perhaps through additional user application programs. Such programs and the shell are implemented with processes. Details of such programs are beyond the scope of this book, which instead concentrates almost exclusively on the kernel." ], "previous_source": "", "target": [ "" ], "id_hash": -7165180633535336176, "content_hash": -7165180633535336176, "location": "documentation/content/en/books/design-44bsd/_index.adoc:97", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 16, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 48, "source_unit": "https://translate-dev.freebsd.org/api/units/1177656/?format=api", "priority": 100, "id": 1178893, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=1c902a2d329e3110", "url": "https://translate-dev.freebsd.org/api/units/1178893/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:05.568566Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "Sections 2.3 and 2.4 describe the services provided by the 4.4BSD kernel, and give an overview of the latter's design. Later chapters describe the detailed design and implementation of these services as they appear in 4.4BSD." ], "previous_source": "", "target": [ "" ], "id_hash": 7163743591428071303, "content_hash": 7163743591428071303, "location": "documentation/content/en/books/design-44bsd/_index.adoc:100", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 17, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 36, "source_unit": "https://translate-dev.freebsd.org/api/units/1177658/?format=api", "priority": 100, "id": 1178894, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=e36abad75d0d1f87", "url": "https://translate-dev.freebsd.org/api/units/1178894/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:05.576073Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "The largest part of the kernel implements the system services that applications access through system calls. In 4.4BSD, this software has been organized according to the following:" ], "previous_source": "", "target": [ "" ], "id_hash": 3699640649772059138, "content_hash": 3699640649772059138, "location": "documentation/content/en/books/design-44bsd/_index.adoc:112", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 22, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 27, "source_unit": "https://translate-dev.freebsd.org/api/units/1177660/?format=api", "priority": 100, "id": 1178895, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=b357c391c6424a02", "url": "https://translate-dev.freebsd.org/api/units/1178895/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:05.628287Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "The machine-dependent aspects of the kernel are isolated from the mainstream code. In particular, none of the machine-independent code contains conditional code for specific architecture. When an architecture-dependent action is needed, the machine-independent code calls an architecture-dependent function that is located in the machine-dependent code. The software that is machine dependent includes" ], "previous_source": "", "target": [ "" ], "id_hash": -3966018402659461979, "content_hash": -3966018402659461979, "location": "documentation/content/en/books/design-44bsd/_index.adoc:154", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 93, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 52, "source_unit": "https://translate-dev.freebsd.org/api/units/1177662/?format=api", "priority": 100, "id": 1178896, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=48f5df4690d214a5", "url": "https://translate-dev.freebsd.org/api/units/1178896/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:05.717132Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "Only a small part of the kernel is devoted to initializing the system. This code is used when the system is _bootstrapped_ into operation and is responsible for setting up the kernel hardware and software environment (see Chapter 14). Some operating systems (especially those with limited physical memory) discard or _overlay_ the software that performs these functions after that software has been executed. The 4.4BSD kernel does not reclaim the memory used by the startup code because that memory space is barely 0.5 percent of the kernel resources used on a typical machine. Also, the startup code does not appear in one place in the kernel -- it is scattered throughout, and it usually appears in places logically associated with what is being initialized." ], "previous_source": "", "target": [ "" ], "id_hash": 8316801088825560398, "content_hash": 8316801088825560398, "location": "documentation/content/en/books/design-44bsd/_index.adoc:185", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 120, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 124, "source_unit": "https://translate-dev.freebsd.org/api/units/1177666/?format=api", "priority": 100, "id": 1178898, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=f36b3686a7078d4e", "url": "https://translate-dev.freebsd.org/api/units/1178898/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:05.755417Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "The boundary between the kernel- and user-level code is enforced by hardware-protection facilities provided by the underlying hardware. The kernel operates in a separate address space that is inaccessible to user processes. Privileged operations -- such as starting I/O and halting the central processing unit (CPU) -- are available to only the kernel. Applications request services from the kernel with _system calls_. System calls are used to cause the kernel to execute complicated operations, such as writing data to secondary storage, and simple operations, such as returning the current time of day. All system calls appear _synchronous_ to applications: The application does not run while the kernel does the actions associated with a system call. The kernel may finish some operations associated with a system call after it has returned. For example, a _write_ system call will copy the data to be written from the user process to a kernel buffer while the process waits, but will usually return from the system call before the kernel buffer is written to the disk." ], "previous_source": "", "target": [ "" ], "id_hash": 8067613668763138007, "content_hash": 8067613668763138007, "location": "documentation/content/en/books/design-44bsd/_index.adoc:197", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 122, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 172, "source_unit": "https://translate-dev.freebsd.org/api/units/1177668/?format=api", "priority": 100, "id": 1178899, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=eff5ebe33fb677d7", "url": "https://translate-dev.freebsd.org/api/units/1178899/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:05.770185Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "A system call usually is implemented as a hardware trap that changes the CPU's execution mode and the current address-space mapping. Parameters supplied by users in system calls are validated by the kernel before being used. Such checking ensures the integrity of the system. All parameters passed into the kernel are copied into the kernel's address space, to ensure that validated parameters are not changed as a side effect of the system call. System-call results are returned by the kernel, either in hardware registers or by their values being copied to user-specified memory addresses. Like parameters passed into the kernel, addresses used for the return of results must be validated to ensure that they are part of an application's address space. If the kernel encounters an error while processing a system call, it returns an error code to the user. For the C programming language, this error code is stored in the global variable _errno_, and the function that executed the system call returns the value -1." ], "previous_source": "", "target": [ "" ], "id_hash": 6517101041467378982, "content_hash": 6517101041467378982, "location": "documentation/content/en/books/design-44bsd/_index.adoc:206", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 123, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 167, "source_unit": "https://translate-dev.freebsd.org/api/units/1177670/?format=api", "priority": 100, "id": 1178900, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=da7164de3dfdcd26", "url": "https://translate-dev.freebsd.org/api/units/1178900/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:05.810655Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "User applications and the kernel operate independently of each other. 4.4BSD does not store I/O control blocks or other operating-system-related data structures in the application's address space. Each user-level application is provided an independent address space in which it executes. The kernel makes most state changes, such as suspending a process while another is running, invisible to the processes involved." ], "previous_source": "", "target": [ "" ], "id_hash": 7596196441809350847, "content_hash": 7596196441809350847, "location": "documentation/content/en/books/design-44bsd/_index.adoc:211", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 124, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 60, "source_unit": "https://translate-dev.freebsd.org/api/units/1177672/?format=api", "priority": 100, "id": 1178901, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=e96b1c6ade21f0bf", "url": "https://translate-dev.freebsd.org/api/units/1178901/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:05.817583Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "4.4BSD supports a multitasking environment. Each task or thread of execution is termed a _process_. The _context_ of a 4.4BSD process consists of user-level state, including the contents of its address space and the run-time environment, and kernel-level state, which includes scheduling parameters, resource controls, and identification information. The context includes everything used by the kernel in providing services for the process. Users can create processes, control the processes' execution, and receive notification when the processes' execution status changes. Every process is assigned a unique value, termed a _process identifier_ (PID). This value is used by the kernel to identify a process when reporting status changes to a user, and by a user when referencing a process in a system call." ], "previous_source": "", "target": [ "" ], "id_hash": -5820167997960030397, "content_hash": -5820167997960030397, "location": "documentation/content/en/books/design-44bsd/_index.adoc:222", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 126, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 121, "source_unit": "https://translate-dev.freebsd.org/api/units/1177674/?format=api", "priority": 100, "id": 1178902, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=2f3a9c0adc7ef743", "url": "https://translate-dev.freebsd.org/api/units/1178902/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:05.827196Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "The kernel creates a process by duplicating the context of another process. The new process is termed a _child process_ of the original _parent process_ The context duplicated in process creation includes both the user-level execution state of the process and the process's system state managed by the kernel. Important components of the kernel state are described in Chapter 4." ], "previous_source": "", "target": [ "" ], "id_hash": 7385027177903855371, "content_hash": 7385027177903855371, "location": "documentation/content/en/books/design-44bsd/_index.adoc:227", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 127, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 60, "source_unit": "https://translate-dev.freebsd.org/api/units/1177676/?format=api", "priority": 100, "id": 1178903, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=e67ce3173b90970b", "url": "https://translate-dev.freebsd.org/api/units/1178903/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:05.832969Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "Although there are occasions when the new process is intended to be a copy of the parent, the loading and execution of a different program is a more useful and typical action. A process can overlay itself with the memory image of another program, passing to the newly created image a set of parameters, using the system call _execve_. One parameter is the name of a file whose contents are in a format recognized by the system -- either a binary-executable file or a file that causes the execution of a specified interpreter program to process its contents." ], "previous_source": "", "target": [ "" ], "id_hash": 5779328759234417208, "content_hash": 5779328759234417208, "location": "documentation/content/en/books/design-44bsd/_index.adoc:242", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 131, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 98, "source_unit": "https://translate-dev.freebsd.org/api/units/1177680/?format=api", "priority": 100, "id": 1178905, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=d0344ce2e65dd238", "url": "https://translate-dev.freebsd.org/api/units/1178905/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:05.857394Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "A process may terminate by executing an _exit_ system call, sending 8 bits of exit status to its parent. If a process wants to communicate more than a single byte of information with its parent, it must either set up an interprocess-communication channel using pipes or sockets, or use an intermediate file. Interprocess communication is discussed extensively in Chapter 11." ], "previous_source": "", "target": [ "" ], "id_hash": 7025104043464142836, "content_hash": 7025104043464142836, "location": "documentation/content/en/books/design-44bsd/_index.adoc:246", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 132, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 60, "source_unit": "https://translate-dev.freebsd.org/api/units/1177682/?format=api", "priority": 100, "id": 1178906, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=e17e2ee82cd72ff4", "url": "https://translate-dev.freebsd.org/api/units/1178906/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:05.862949Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "A process can suspend execution until any of its child processes terminate using the _wait_ system call, which returns the PID and exit status of the terminated child process. A parent process can arrange to be notified by a signal when a child process exits or terminates abnormally. Using the _wait4_ system call, the parent can retrieve information about the event that caused termination of the child process and about resources consumed by the process during its lifetime. If a process is orphaned because its parent exits before it is finished, then the kernel arranges for the child's exit status to be passed back to a special system process _init_: see Sections 3.1 and 14.6)." ], "previous_source": "", "target": [ "" ], "id_hash": -1654997489636371526, "content_hash": -1654997489636371526, "location": "documentation/content/en/books/design-44bsd/_index.adoc:251", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 133, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 115, "source_unit": "https://translate-dev.freebsd.org/api/units/1177684/?format=api", "priority": 100, "id": 1178907, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=6908448d3e0f93ba", "url": "https://translate-dev.freebsd.org/api/units/1178907/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:05.868607Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "Processes are scheduled for execution according to a _process-priority_ parameter. This priority is managed by a kernel-based scheduling algorithm. Users can influence the scheduling of a process by specifying a parameter (_nice_) that weights the overall scheduling priority, but are still obligated to share the underlying CPU resources according to the kernel's scheduling policy." ], "previous_source": "", "target": [ "" ], "id_hash": -3400413419963812522, "content_hash": -3400413419963812522, "location": "documentation/content/en/books/design-44bsd/_index.adoc:257", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 135, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 54, "source_unit": "https://translate-dev.freebsd.org/api/units/1177686/?format=api", "priority": 100, "id": 1178908, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=50cf4e02bd95f556", "url": "https://translate-dev.freebsd.org/api/units/1178908/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:05.877242Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "The system defines a set of _signals_ that may be delivered to a process. Signals in 4.4BSD are modeled after hardware interrupts. A process may specify a user-level subroutine to be a _handler_ to which a signal should be delivered. When a signal is generated, it is blocked from further occurrence while it is being _caught_ by the handler. Catching a signal involves saving the current process context and building a new one in which to run the handler. The signal is then delivered to the handler, which can either abort the process or return to the executing process (perhaps after setting a global variable). If the handler returns, the signal is unblocked and can be generated (and caught) again." ], "previous_source": "", "target": [ "" ], "id_hash": -306937228086728953, "content_hash": -306937228086728953, "location": "documentation/content/en/books/design-44bsd/_index.adoc:267", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 137, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 120, "source_unit": "https://translate-dev.freebsd.org/api/units/1177688/?format=api", "priority": 100, "id": 1178909, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=7bbd8a379f8c2707", "url": "https://translate-dev.freebsd.org/api/units/1178909/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:05.913356Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "Alternatively, a process may specify that a signal is to be _ignored_, or that a default action, as determined by the kernel, is to be taken. The default action of certain signals is to terminate the process. This termination may be accompanied by creation of a _core file_ that contains the current memory image of the process for use in postmortem debugging." ], "previous_source": "", "target": [ "" ], "id_hash": 972959754580351894, "content_hash": 972959754580351894, "location": "documentation/content/en/books/design-44bsd/_index.adoc:271", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 138, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 62, "source_unit": "https://translate-dev.freebsd.org/api/units/1177690/?format=api", "priority": 100, "id": 1178910, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=8d80a5bde8835b96", "url": "https://translate-dev.freebsd.org/api/units/1178910/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:05.919143Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "Some signals cannot be caught or ignored. These signals include _SIGKILL_, which kills runaway processes, and the job-control signal _SIGSTOP_." ], "previous_source": "", "target": [ "" ], "id_hash": 2314754734690232114, "content_hash": 2314754734690232114, "location": "documentation/content/en/books/design-44bsd/_index.adoc:274", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 139, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 20, "source_unit": "https://translate-dev.freebsd.org/api/units/1177692/?format=api", "priority": 100, "id": 1178911, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=a01fa92ac75d6732", "url": "https://translate-dev.freebsd.org/api/units/1178911/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:05.923959Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "A process may choose to have signals delivered on a special stack so that sophisticated software stack manipulations are possible. For example, a language supporting coroutines needs to provide a stack for each coroutine. The language run-time system can allocate these stacks by dividing up the single stack provided by 4.4BSD. If the kernel does not support a separate signal stack, the space allocated for each coroutine must be expanded by the amount of space required to catch a signal." ], "previous_source": "", "target": [ "" ], "id_hash": -8657923340112699632, "content_hash": -8657923340112699632, "location": "documentation/content/en/books/design-44bsd/_index.adoc:279", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 140, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 80, "source_unit": "https://translate-dev.freebsd.org/api/units/1177694/?format=api", "priority": 100, "id": 1178912, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=07d8e0980404df10", "url": "https://translate-dev.freebsd.org/api/units/1178912/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:05.928711Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "All signals have the same _priority_. If multiple signals are pending simultaneously, the order in which signals are delivered to a process is implementation specific. Signal handlers execute with the signal that caused their invocation to be blocked, but other signals may yet occur. Mechanisms are provided so that processes can protect critical sections of code against the occurrence of specified signals." ], "previous_source": "", "target": [ "" ], "id_hash": 1649527470949024359, "content_hash": 1649527470949024359, "location": "documentation/content/en/books/design-44bsd/_index.adoc:284", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 141, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 62, "source_unit": "https://translate-dev.freebsd.org/api/units/1177696/?format=api", "priority": 100, "id": 1178913, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=96e44c7ec92a4267", "url": "https://translate-dev.freebsd.org/api/units/1178913/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:05.933712Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "The group of processes in a process group is sometimes referred to as a _job_ and is manipulated by high-level system software, such as the shell. A common kind of job created by a shell is a _pipeline_ of several processes connected by pipes, such that the output of the first process is the input of the second, the output of the second is the input of the third, and so forth. The shell creates such a job by forking a process for each stage of the pipeline, then putting all those processes into a separate process group." ], "previous_source": "", "target": [ "" ], "id_hash": -900430907709349180, "content_hash": -900430907709349180, "location": "documentation/content/en/books/design-44bsd/_index.adoc:298", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 145, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 98, "source_unit": "https://translate-dev.freebsd.org/api/units/1177700/?format=api", "priority": 100, "id": 1178915, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=738106dc3133a2c4", "url": "https://translate-dev.freebsd.org/api/units/1178915/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:05.949832Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "A user process can send a signal to each process in a process group, as well as to a single process. A process in a specific process group may receive software interrupts affecting the group, causing the group to suspend or resume execution, or to be interrupted or terminated." ], "previous_source": "", "target": [ "" ], "id_hash": 2846215556938543608, "content_hash": 2846215556938543608, "location": "documentation/content/en/books/design-44bsd/_index.adoc:301", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 146, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 49, "source_unit": "https://translate-dev.freebsd.org/api/units/1177702/?format=api", "priority": 100, "id": 1178916, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=a77fc9f8198331f8", "url": "https://translate-dev.freebsd.org/api/units/1178916/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:05.954645Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "A terminal has a process-group identifier assigned to it. This identifier is normally set to the identifier of a process group associated with the terminal. A job-control shell may create a number of process groups associated with the same terminal; the terminal is the _controlling terminal_ for each process in these groups. A process may read from a descriptor for its controlling terminal only if the terminal's process-group identifier matches that of the process. If the identifiers do not match, the process will be blocked if it attempts to read from the terminal. By changing the process-group identifier of the terminal, a shell can arbitrate a terminal among several different jobs. This arbitration is called _job control_ and is described, with process groups, in Section 4.8." ], "previous_source": "", "target": [ "" ], "id_hash": 6860888637697278524, "content_hash": 6860888637697278524, "location": "documentation/content/en/books/design-44bsd/_index.adoc:309", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 147, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 126, "source_unit": "https://translate-dev.freebsd.org/api/units/1177704/?format=api", "priority": 100, "id": 1178917, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=df36c5dd8d75c23c", "url": "https://translate-dev.freebsd.org/api/units/1178917/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:05.961012Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "Each process has its own private address space. The address space is initially divided into three logical segments: _text_, _data_, and _stack_. The text segment is read-only and contains the machine instructions of a program. The data and stack segments are both readable and writable. The data segment contains the initialized and uninitialized data portions of a program, whereas the stack segment holds the application's run-time stack. On most machines, the stack segment is extended automatically by the kernel as the process executes. A process can expand or contract its data segment by making a system call, whereas a process can change the size of its text segment only when the segment's contents are overlaid with data from the filesystem, or when debugging takes place. The initial contents of the segments of a child process are duplicates of the segments of a parent process." ], "previous_source": "", "target": [ "" ], "id_hash": -5552971193940808918, "content_hash": -5552971193940808918, "location": "documentation/content/en/books/design-44bsd/_index.adoc:324", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 150, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 144, "source_unit": "https://translate-dev.freebsd.org/api/units/1177708/?format=api", "priority": 100, "id": 1178919, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=32efe21eb92e6b2a", "url": "https://translate-dev.freebsd.org/api/units/1178919/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:05.977223Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "The entire contents of a process address space do not need to be resident for a process to execute. If a process references a part of its address space that is not resident in main memory, the system _pages_ the necessary information into memory. When system resources are scarce, the system uses a two-level approach to maintain available resources. If a modest amount of memory is available, the system will take memory resources away from processes if these resources have not been used recently. Should there be a severe resource shortage, the system will resort to _swapping_ the entire context of a process to secondary storage. The _demand paging_ and _swapping_ done by the system are effectively transparent to processes. A process may, however, advise the system about expected future memory utilization as a performance aid." ], "previous_source": "", "target": [ "" ], "id_hash": -4669498594761235306, "content_hash": -4669498594761235306, "location": "documentation/content/en/books/design-44bsd/_index.adoc:332", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 151, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 136, "source_unit": "https://translate-dev.freebsd.org/api/units/1177710/?format=api", "priority": 100, "id": 1178920, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=3f329bc4a4122496", "url": "https://translate-dev.freebsd.org/api/units/1178920/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:06.010607Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "The support of large sparse address spaces, mapped files, and shared memory was a requirement for 4.2BSD. 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. Ultimately, 4.2BSD was shipped without the _mmap_ interface, because of pressure to make other features, such as networking, available." ], "previous_source": "", "target": [ "" ], "id_hash": 7168356909774130972, "content_hash": 7168356909774130972, "location": "documentation/content/en/books/design-44bsd/_index.adoc:339", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 153, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 99, "source_unit": "https://translate-dev.freebsd.org/api/units/1177712/?format=api", "priority": 100, "id": 1178921, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=e37b1ea13e4dcf1c", "url": "https://translate-dev.freebsd.org/api/units/1178921/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:06.022469Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "Once again, time pressure prevented 4.3BSD from providing an implementation of the interface. Although the latter could have been built into the existing 4.3BSD virtual-memory system, the developers decided not to put it in because that implementation was nearly 10 years old. Furthermore, the original virtual-memory design was based on the assumption that computer memories were small and expensive, whereas disks were locally connected, fast, large, and inexpensive. Thus, the virtual-memory system was designed to be frugal with its use of memory at the expense of generating extra disk traffic. In addition, the 4.3BSD implementation was riddled with VAX memory-management hardware dependencies that impeded its portability to other computer architectures. Finally, the virtual-memory system was not designed to support the tightly coupled multiprocessors that are becoming increasingly common and important today." ], "previous_source": "", "target": [ "" ], "id_hash": -4419787927558144467, "content_hash": -4419787927558144467, "location": "documentation/content/en/books/design-44bsd/_index.adoc:353", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 155, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 131, "source_unit": "https://translate-dev.freebsd.org/api/units/1177716/?format=api", "priority": 100, "id": 1178923, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=42a9c24c03563e2d", "url": "https://translate-dev.freebsd.org/api/units/1178923/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:06.032744Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "Another issue with the virtual-memory system is the way that information is passed into the kernel when a system call is made. 4.4BSD always copies data from the process address space into a buffer in the kernel. For read or write operations that are transferring large quantities of data, doing the copy can be time consuming. An alternative to doing the copying is to remap the process memory into the kernel. The 4.4BSD kernel always copies the data for several reasons:" ], "previous_source": "", "target": [ "" ], "id_hash": -7885829830996106678, "content_hash": -7885829830996106678, "location": "documentation/content/en/books/design-44bsd/_index.adoc:370", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 157, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 81, "source_unit": "https://translate-dev.freebsd.org/api/units/1177720/?format=api", "priority": 100, "id": 1178925, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=128fe78cb44c624a", "url": "https://translate-dev.freebsd.org/api/units/1178925/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:06.042773Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "The biggest incentives for memory mapping are the needs for accessing big files and for passing large quantities of data between processes. The _mmap_ interface provides a way for both of these tasks to be done without copying." ], "previous_source": "", "target": [ "" ], "id_hash": 6434913585645710601, "content_hash": 6434913585645710601, "location": "documentation/content/en/books/design-44bsd/_index.adoc:378", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 162, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 38, "source_unit": "https://translate-dev.freebsd.org/api/units/1177722/?format=api", "priority": 100, "id": 1178926, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=d94d67d000bf6d09", "url": "https://translate-dev.freebsd.org/api/units/1178926/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:06.060501Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "The kernel often does allocations of memory that are needed for only the duration of a single system call. In a user process, such short-term memory would be allocated on the run-time stack. Because the kernel has a limited run-time stack, it is not feasible to allocate even moderate-sized blocks of memory on it. Consequently, such memory must be allocated through a more dynamic mechanism. For example, when the system must translate a pathname, it must allocate a 1-Kbyte buffer to hold the name. Other blocks of memory must be more persistent than a single system call, and thus could not be allocated on the stack even if there was space. An example is protocol-control blocks that remain throughout the duration of a network connection." ], "previous_source": "", "target": [ "" ], "id_hash": -3465736560582183065, "content_hash": -3465736560582183065, "location": "documentation/content/en/books/design-44bsd/_index.adoc:388", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 164, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 125, "source_unit": "https://translate-dev.freebsd.org/api/units/1177724/?format=api", "priority": 100, "id": 1178927, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=4fe73af5dd6a3767", "url": "https://translate-dev.freebsd.org/api/units/1178927/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:06.067790Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "The basic model of the UNIX I/O system is a sequence of bytes that can be accessed either randomly or sequentially. There are no _access methods_ and no _control blocks_ in a typical UNIX user process." ], "previous_source": "", "target": [ "" ], "id_hash": 4941077594084429450, "content_hash": 4941077594084429450, "location": "documentation/content/en/books/design-44bsd/_index.adoc:404", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 167, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 36, "source_unit": "https://translate-dev.freebsd.org/api/units/1177728/?format=api", "priority": 100, "id": 1178929, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=c4923be4930b4e8a", "url": "https://translate-dev.freebsd.org/api/units/1178929/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:06.121620Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "UNIX processes use _descriptors_ to reference I/O streams. Descriptors are small unsigned integers obtained from the _open_ and _socket_ system calls. The _open_ system call takes as arguments the name of a file and a permission mode to specify whether the file should be open for reading or for writing, or for both. This system call also can be used to create a new, empty file. A _read_ or _write_ system call can be applied to a descriptor to transfer data. The _close_ system call can be used to deallocate any descriptor." ], "previous_source": "", "target": [ "" ], "id_hash": 5084254627859770233, "content_hash": 5084254627859770233, "location": "documentation/content/en/books/design-44bsd/_index.adoc:421", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 170, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 92, "source_unit": "https://translate-dev.freebsd.org/api/units/1177732/?format=api", "priority": 100, "id": 1178931, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=c68ee6a58137ab79", "url": "https://translate-dev.freebsd.org/api/units/1178931/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:06.137878Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "Descriptors represent underlying objects supported by the kernel, and are created by system calls specific to the type of object. In 4.4BSD, three kinds of objects can be represented by descriptors: files, pipes, and sockets." ], "previous_source": "", "target": [ "" ], "id_hash": 6332281000216172192, "content_hash": 6332281000216172192, "location": "documentation/content/en/books/design-44bsd/_index.adoc:424", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 171, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 35, "source_unit": "https://translate-dev.freebsd.org/api/units/1177734/?format=api", "priority": 100, "id": 1178932, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=d7e0c80513d716a0", "url": "https://translate-dev.freebsd.org/api/units/1178932/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:06.143324Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "The kernel keeps for each process a _descriptor table_, which is a table that the kernel uses to translate the external representation of a descriptor into an internal representation. (The descriptor is merely an index into this table.) The descriptor table of a process is inherited from that process's parent, and thus access to the objects to which the descriptors refer also is inherited. The main ways that a process can obtain a descriptor are by opening or creation of an object, and by inheritance from the parent process. In addition, socket IPC allows passing of descriptors in messages between unrelated processes on the same machine." ], "previous_source": "", "target": [ "" ], "id_hash": -8010742574462135971, "content_hash": -8010742574462135971, "location": "documentation/content/en/books/design-44bsd/_index.adoc:436", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 176, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 106, "source_unit": "https://translate-dev.freebsd.org/api/units/1177736/?format=api", "priority": 100, "id": 1178933, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=10d420123e16115d", "url": "https://translate-dev.freebsd.org/api/units/1178933/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:06.160898Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "Every valid descriptor has an associated _file offset_ in bytes from the beginning of the object. Read and write operations start at this offset, which is updated after each data transfer. For objects that permit random access, the file offset also may be set with the _lseek_ system call. Ordinary files permit random access, and some devices do, as well. Pipes and sockets do not." ], "previous_source": "", "target": [ "" ], "id_hash": -2250891460091408470, "content_hash": -2250891460091408470, "location": "documentation/content/en/books/design-44bsd/_index.adoc:442", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 177, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 65, "source_unit": "https://translate-dev.freebsd.org/api/units/1177738/?format=api", "priority": 100, "id": 1178934, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=60c33a248d4a8faa", "url": "https://translate-dev.freebsd.org/api/units/1178934/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:06.167319Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "When a process terminates, the kernel reclaims all the descriptors that were in use by that process. If the process was holding the final reference to an object, the object's manager is notified so that it can do any necessary cleanup actions, such as final deletion of a file or deallocation of a socket." ], "previous_source": "", "target": [ "" ], "id_hash": -5017270074681122502, "content_hash": -5017270074681122502, "location": "documentation/content/en/books/design-44bsd/_index.adoc:445", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 178, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 54, "source_unit": "https://translate-dev.freebsd.org/api/units/1177740/?format=api", "priority": 100, "id": 1178935, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=3a5f1373206f213a", "url": "https://translate-dev.freebsd.org/api/units/1178935/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:06.173297Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "Most processes expect three descriptors to be open already when they start running. These descriptors are 0, 1, 2, more commonly known as _standard input_, _standard output_, and _standard error_, respectively. Usually, all three are associated with the user's terminal by the login process (see Section 14.6) and are inherited through _fork_ and _exec_ by processes run by the user. Thus, a program can read what the user types by reading standard input, and the program can send output to the user's screen by writing to standard output. The standard error descriptor also is open for writing and is used for error output, whereas standard output is used for ordinary output." ], "previous_source": "", "target": [ "" ], "id_hash": 6477209726931753542, "content_hash": 6477209726931753542, "location": "documentation/content/en/books/design-44bsd/_index.adoc:453", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 180, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 111, "source_unit": "https://translate-dev.freebsd.org/api/units/1177742/?format=api", "priority": 100, "id": 1178936, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=d9e3abedcd78da46", "url": "https://translate-dev.freebsd.org/api/units/1178936/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:06.214859Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "These (and other) descriptors can be mapped to objects other than the terminal; such mapping is called _I/O redirection_, and all the standard shells permit users to do it. The shell can direct the output of a program to a file by closing descriptor 1 (standard output) and opening the desired output file to produce a new descriptor 1. It can similarly redirect standard input to come from a file by closing descriptor 0 and opening the file." ], "previous_source": "", "target": [ "" ], "id_hash": 4326462360726125545, "content_hash": 4326462360726125545, "location": "documentation/content/en/books/design-44bsd/_index.adoc:457", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 181, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 78, "source_unit": "https://translate-dev.freebsd.org/api/units/1177744/?format=api", "priority": 100, "id": 1178937, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=bc0aae98312dbbe9", "url": "https://translate-dev.freebsd.org/api/units/1178937/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:06.221034Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "Pipes allow the output of one program to be input to another program without rewriting or even relinking of either program. Instead of descriptor 1 (standard output) of the source program being set up to write to the terminal, it is set up to be the input descriptor of a pipe. Similarly, descriptor 0 (standard input) of the sink program is set up to reference the output of the pipe, instead of the terminal keyboard. The resulting set of two processes and the connecting pipe is known as a _pipeline_. Pipelines can be arbitrarily long series of processes connected by pipes." ], "previous_source": "", "target": [ "" ], "id_hash": 1850710152944980779, "content_hash": 1850710152944980779, "location": "documentation/content/en/books/design-44bsd/_index.adoc:463", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 182, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 101, "source_unit": "https://translate-dev.freebsd.org/api/units/1177746/?format=api", "priority": 100, "id": 1178938, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=99af0b14207e932b", "url": "https://translate-dev.freebsd.org/api/units/1178938/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:06.227048Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "The _open_, _pipe_, and _socket_ system calls produce new descriptors with the lowest unused number usable for a descriptor. For pipelines to work, some mechanism must be provided to map such descriptors into 0 and 1. The _dup_ system call creates a copy of a descriptor that points to the same file-table entry. The new descriptor is also the lowest unused one, but if the desired descriptor is closed first, _dup_ can be used to do the desired mapping. Care is required, however: If descriptor 1 is desired, and descriptor 0 happens also to have been closed, descriptor 0 will be the result. To avoid this problem, the system provides the _dup2_ system call; it is like _dup_, but it takes an additional argument specifying the number of the desired descriptor (if the desired descriptor was already open, _dup2_ closes it before reusing it)." ], "previous_source": "", "target": [ "" ], "id_hash": 7025745462131518991, "content_hash": 7025745462131518991, "location": "documentation/content/en/books/design-44bsd/_index.adoc:470", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 183, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 144, "source_unit": "https://translate-dev.freebsd.org/api/units/1177748/?format=api", "priority": 100, "id": 1178939, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=e180764618a96e0f", "url": "https://translate-dev.freebsd.org/api/units/1178939/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:06.233002Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "Hardware devices have filenames, and may be accessed by the user via the same system calls used for regular files. The kernel can distinguish a _device special file_ or _special file_, and can determine to what device it refers, but most processes do not need to make this determination. Terminals, printers, and tape drives are all accessed as though they were streams of bytes, like 4.4BSD disk files. Thus, device dependencies and peculiarities are kept in the kernel as much as possible, and even in the kernel most of them are segregated in the device drivers." ], "previous_source": "", "target": [ "" ], "id_hash": 8150960245929055148, "content_hash": 8150960245929055148, "location": "documentation/content/en/books/design-44bsd/_index.adoc:477", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 185, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 96, "source_unit": "https://translate-dev.freebsd.org/api/units/1177750/?format=api", "priority": 100, "id": 1178940, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=f11e072874ee93ac", "url": "https://translate-dev.freebsd.org/api/units/1178940/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:06.241843Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "Hardware devices can be categorized as either _structured_ or _unstructured_; they are known as _block_ or _character_ devices, respectively. Processes typically access devices through _special files_ in the filesystem. I/O operations to these files are handled by kernel-resident software modules termed _device drivers_. Most network-communication hardware devices are accessible through only the interprocess-communication facilities, and do not have special files in the filesystem name space, because the _raw-socket_ interface provides a more natural interface than does a special file." ], "previous_source": "", "target": [ "" ], "id_hash": -5837261363745296449, "content_hash": -5837261363745296449, "location": "documentation/content/en/books/design-44bsd/_index.adoc:482", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 186, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 79, "source_unit": "https://translate-dev.freebsd.org/api/units/1177752/?format=api", "priority": 100, "id": 1178941, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=2efde1b780d96fbf", "url": "https://translate-dev.freebsd.org/api/units/1178941/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:06.247756Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "Structured or block devices are typified by disks and magnetic tapes, and include most random-access devices. The kernel supports read-modify-write-type buffering actions on block-oriented structured devices to allow the latter to be read and written in a totally random byte-addressed fashion, like regular files. Filesystems are created on block devices." ], "previous_source": "", "target": [ "" ], "id_hash": 5681470026282106756, "content_hash": 5681470026282106756, "location": "documentation/content/en/books/design-44bsd/_index.adoc:486", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 187, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 50, "source_unit": "https://translate-dev.freebsd.org/api/units/1177754/?format=api", "priority": 100, "id": 1178942, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=ced8a2e31e92ff84", "url": "https://translate-dev.freebsd.org/api/units/1178942/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:06.253650Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "Unstructured devices are those devices that do not support a block structure. Familiar unstructured devices are communication lines, raster plotters, and unbuffered magnetic tapes and disks. Unstructured devices typically support large block I/O transfers." ], "previous_source": "", "target": [ "" ], "id_hash": -5603936777554409383, "content_hash": -5603936777554409383, "location": "documentation/content/en/books/design-44bsd/_index.adoc:490", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 188, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 34, "source_unit": "https://translate-dev.freebsd.org/api/units/1177756/?format=api", "priority": 100, "id": 1178943, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=323ad131161f4859", "url": "https://translate-dev.freebsd.org/api/units/1178943/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:06.258993Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "Unstructured files are called _character devices_ because the first of these to be implemented were terminal device drivers. The kernel interface to the driver for these devices proved convenient for other devices that were not block structured." ], "previous_source": "", "target": [ "" ], "id_hash": -3908563789064167819, "content_hash": -3908563789064167819, "location": "documentation/content/en/books/design-44bsd/_index.adoc:493", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 189, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 37, "source_unit": "https://translate-dev.freebsd.org/api/units/1177758/?format=api", "priority": 100, "id": 1178944, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=49c1fdf13ae01e75", "url": "https://translate-dev.freebsd.org/api/units/1178944/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:06.264483Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "Device special files are created by the _mknod_ system call. There is an additional system call, _ioctl_, for manipulating the underlying device parameters of special files. The operations that can be done differ for each device. This system call allows the special characteristics of devices to be accessed, rather than overloading the semantics of other system calls. For example, there is an _ioctl_ on a tape drive to write an end-of-tape mark, instead of there being a special or modified version of _write_." ], "previous_source": "", "target": [ "" ], "id_hash": 728859439133977356, "content_hash": 728859439133977356, "location": "documentation/content/en/books/design-44bsd/_index.adoc:499", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 190, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 83, "source_unit": "https://translate-dev.freebsd.org/api/units/1177760/?format=api", "priority": 100, "id": 1178945, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=8a1d6dcc58c56b0c", "url": "https://translate-dev.freebsd.org/api/units/1178945/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:06.269634Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "The 4.2BSD kernel introduced an IPC mechanism more flexible than pipes, based on _sockets_. A socket is an endpoint of communication referred to by a descriptor, just like a file or a pipe. Two processes can each create a socket, and then connect those two endpoints to produce a reliable byte stream. Once connected, the descriptors for the sockets can be read or written by processes, just as the latter would do with a pipe. The transparency of sockets allows the kernel to redirect the output of one process to the input of another process residing on another machine. A major difference between pipes and sockets is that pipes require a common parent process to set up the communications channel. A connection between sockets can be set up by two unrelated processes, possibly residing on different machines." ], "previous_source": "", "target": [ "" ], "id_hash": -3569518996703711751, "content_hash": -3569518996703711751, "location": "documentation/content/en/books/design-44bsd/_index.adoc:509", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 192, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 137, "source_unit": "https://translate-dev.freebsd.org/api/units/1177762/?format=api", "priority": 100, "id": 1178946, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=4e76856276776df9", "url": "https://translate-dev.freebsd.org/api/units/1178946/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:06.312879Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "System V provides local interprocess communication through FIFOs (also known as _named pipes_). FIFOs appear as an object in the filesystem that unrelated processes can open and send data through in the same way as they would communicate through a pipe. Thus, FIFOs do not require a common parent to set them up; they can be connected after a pair of processes are up and running. Unlike sockets, FIFOs can be used on only a local machine; they cannot be used to communicate between processes on different machines. FIFOs are implemented in 4.4BSD only because they are required by the POSIX.1 standard. Their functionality is a subset of the socket interface." ], "previous_source": "", "target": [ "" ], "id_hash": 1089101875515484377, "content_hash": 1089101875515484377, "location": "documentation/content/en/books/design-44bsd/_index.adoc:516", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 193, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 111, "source_unit": "https://translate-dev.freebsd.org/api/units/1177764/?format=api", "priority": 100, "id": 1178947, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=8f1d4462ae4fe8d9", "url": "https://translate-dev.freebsd.org/api/units/1178947/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:06.323511Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "The socket mechanism requires extensions to the traditional UNIX I/O system calls to provide the associated naming and connection semantics. Rather than overloading the existing interface, the developers used the existing interfaces to the extent that the latter worked without being changed, and designed new interfaces to handle the added semantics. The _read_ and _write_ system calls were used for byte-stream type connections, but six new system calls were added to allow sending and receiving addressed messages such as network datagrams. The system calls for writing messages include _send_, _sendto_, and _sendmsg_. The system calls for reading messages include _recv_, _recvfrom_, and _recvmsg_. In retrospect, the first two in each class are special cases of the others; _recvfrom_ and _sendto_ probably should have been added as library interfaces to _recvmsg_ and _sendmsg_, respectively." ], "previous_source": "", "target": [ "" ], "id_hash": 2739974862608080549, "content_hash": 2739974862608080549, "location": "documentation/content/en/books/design-44bsd/_index.adoc:523", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 194, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 133, "source_unit": "https://translate-dev.freebsd.org/api/units/1177766/?format=api", "priority": 100, "id": 1178948, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=a606589edb411ea5", "url": "https://translate-dev.freebsd.org/api/units/1178948/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:06.330242Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/booksdesign-44bsd_index/zh_TW/?format=api", "source": [ "In addition to the traditional _read_ and _write_ system calls, 4.2BSD introduced the ability to do scatter/gather I/O. Scatter input uses the _readv_ system call to allow a single read to be placed in several different buffers. Conversely, the _writev_ system call allows several different buffers to be written in a single atomic write. Instead of passing a single buffer and length parameter, as is done with _read_ and _write_, the process passes in a pointer to an array of buffers and lengths, along with a count describing the size of the array." ], "previous_source": "", "target": [ "" ], "id_hash": 179016063984276728, "content_hash": 179016063984276728, "location": "documentation/content/en/books/design-44bsd/_index.adoc:530", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 196, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 93, "source_unit": "https://translate-dev.freebsd.org/api/units/1177768/?format=api", "priority": 100, "id": 1178949, "web_url": "https://translate-dev.freebsd.org/translate/documentation/booksdesign-44bsd_index/zh_TW/?checksum=827bfe2966df14f8", "url": "https://translate-dev.freebsd.org/api/units/1178949/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:37:06.340908Z" } ] }