Pro zobrazení upozornění se prosím přihlaste.

Přehled

Stránky projektu docs.freebsd.org/en
Licence překladu BSD 2-Clause "Simplified" License
Proces překladu
  • Je možné překládat přímo.
  • Je možné dávat návrhy překladu.
  • Přispívat mohou pouze zvolení uživatelé.
  • Překlad používá dvojjazyčné soubory.
Maska souborů documentation/content/*/articles/linux-emulation/_index.po

Statistiky řetězců

Procento řetězců Hostovaných řetězců Procento slov Hostovaných slov Procento znaků Hostovaných znaků
Celkem 7 524 232 541 1 470 296
Zdrojových 396 12 239 77 384
Přeložených 21 % 1 638 20 % 48 766 20 % 308 245
Potřebuje upravit 1 % 10 1 % 265 1 % 1 846
Pouze ke čtení 5 % 396 5 % 12 239 5 % 77 384
Selhavší kontroly 1 % 64 1 % 407 1 % 3 028
Řetězce s návrhy 0 % 0 0 % 0 0 % 0
Nepřeložené řetězce 78 % 5 876 78 % 183 510 78 % 1 160 205
Posledních 12 měsíců Předchozích

Aktivita za posledních 12 měsíců

403 změn 0 změn 2 změny 0 změn 2 změny 1 změna 0 změn 403 změn 0 změn 23 změn 399 změn 7 změn 0 změn 734 změn 0 změn 2 změny 0 změn 10 změn 0 změn 99 změn 0 změn 2 změny 399 změn 0 změn
Úno Bře Dub Kvě Čer Čec Srp Zář Říj Lis Pro Led

Rychlá čísla

232 k
Hostovaných slov
7 524
Hostovaných řetězců
21 %
Přeloženo
0
Přispěvatelé
a předchozích 30 dní

Trendy posledních 30 dní

—
Hostovaných slov
+100 %
—
Hostovaných řetězců
+100 %
—
Přeloženo
+21 %
—
Přispěvatelé
+100 %
Avatar uživatele Žádný

Zapsány změny

Documentation / articles/linux-emulation/_index — Ruština

Zapsány změny před 2 měsíci
Avatar uživatele v.popolitov

Vyhledat a nahradit

Documentation / articles/linux-emulation/_index — Ruština

Traditional UNIX(R) does not define any API nor implementation for threading, while POSIX(R) defines its threading API but the implementation is undefined. Traditionally there were two ways of implementing threads. Handling them as separate processes (1:1 threading) or envelope the whole thread group in one process and managing the threading in userspace (1:N threading). Comparing main features of each approach:
Традиционный UNIX(R) не определяет никакого API или реализации для потоков, в то время как POSIX(R) определяет свой API для потоков, но реализация остается неопределённой. Традиционно существовало два способа реализации потоков: обработка их как отдельных процессов (потоки 1:1) или обеёртывание всей группы потоков в один процесс с управлением потоками в пользовательском пространстве (потоки 1:N). Сравнение основных особенностей каждого подхода:
před 2 měsíci
Avatar uživatele Žádný

Zapsány změny

Documentation / articles/linux-emulation/_index — Ruština

Zapsány změny před 2 měsíci
Avatar uživatele v.popolitov

Vyhledat a nahradit

Documentation / articles/linux-emulation/_index — Ruština

Loading of TLS for the current thread happens by calling `set_thread_area` while loading TLS for a second process in `clone` is done in the separate block in `clone`. Those two functions are very similar. The only difference being the actual loading of the GDT segment, which happens on the next context switch for the newly created process while `set_thread_area` must load this directly. The code basically does this. It copies the Linux(R) form segment descriptor from the userland. The code checks for the number of the descriptor but because this differs between FreeBSD and Linux(R) we fake it a little. We only support indexes of 6, 3 and -1. The 6 is genuine Linux(R) number, 3 is genuine FreeBSD one and -1 means autoselection. Then we set the descriptor number to constant 3 and copy out this to the userspace. We rely on the userspace process using the number from the descriptor but this works most of the time (have never seen a case where this did not work) as the userspace process typically passes in 1. Then we convert the descriptor from the Linux(R) form to a machine dependant form (i.e. operating system independent form) and copy this to the FreeBSD defined segment descriptor. Finally we can load it. We assign the descriptor to threads PCB (process control block) and load the `%gs` segment using `load_gs`. This loading must be done in a critical section so that nothing can interrupt us. The `CLONE_SETTLS` case works exactly like this just the loading using `load_gs` is not performed. The segment used for this (segment number 3) is shared for this use between FreeBSD processes and Linux(R) processes so the Linux(R) emulation layer does not add any overhead over plain FreeBSD.
Загрузка TLS для текущего потока происходит путем вызова `set_thread_area`, тогда как загрузка TLS для второго процесса в `clone` выполняется в отдельном блоке в `clone`. Эти две функции очень похожи. Единственное различие заключается в фактической загрузке сегмента GDT, которая происходит при следующем переключении контекста для вновь созданного процесса, в то время как `set_thread_area` должен загрузить его напрямую. Код в основном делает следующее. Он копирует дескриптор сегмента в формате Linux(R) из пользовательского пространства. Код проверяет номер дескриптора, но поскольку он различается между FreeBSD и Linux(R), мы немного имитируем его. Мы поддерживаем только индексы 6, 3 и -1. Число 6 — это оригинальный номер Linux(R), 3 — оригинальный номер FreeBSD, а -1 означает авто-выбор. Затем мы устанавливаем номер дескриптора на константу 3 и копируем его обратно в пользовательское пространство. Мы полагаемся на то, что процесс в пользовательском пространстве использует номер из дескриптора, но это работает в большинстве случаев (никогда не встречалось ситуации, когда это не срабатывало), так как процесс в пользовательском пространстве обычно передаёт 1. Затем мы преобразуем дескриптор из формата Linux(R) в машинозависимую форму (т.е. независимую от операционной системы) и копируем его в дескриптор сегмента, определеённый FreeBSD. Наконец, мы можем загрузить его. Мы назначаем дескриптор PCB потока (блок управления процессом) и загружаем сегмент `%gs` с помощью `load_gs`. Эта загрузка должна выполняться в критической секции, чтобы ничто не могло нас прервать. Случай `CLONE_SETTLS` работает точно так же, только загрузка с помощью `load_gs` не выполняется. Сегмент, используемый для этого (сегмент номер 3), разделяется между процессами FreeBSD и Linux(R), поэтому слой эмуляции Linux(R) не добавляет накладных расходов по сравнению с обычным FreeBSD.
před 2 měsíci
Avatar uživatele v.popolitov

Vyhledat a nahradit

Documentation / articles/linux-emulation/_index — Ruština

Every NPTL thread is created by a call to the `clone` syscall with a specific set of flags (more in the next subsection). The NPTL implements strict 1:1 threading.
Каждый поток NPTL создается вызовом системного вызова `clone` с определеённым набором флагов (подробнее в следующем подразделе). NPTL реализует строгую модель потоков 1:1.
před 2 měsíci
Avatar uživatele v.popolitov

Vyhledat a nahradit

Documentation / articles/linux-emulation/_index — Ruština

Another way to deal with preemption is the `sched_pin()` interface. If a piece of code is closed in the `sched_pin()` and `sched_unpin()` pair of functions it is guaranteed that the respective thread, even if it can be preempted, it will always be executed on the same CPU. Pinning is very effective in the particular case when we have to access at per-cpu datas and we assume other threads will not change those data. The latter condition will determine a critical section as a too strong condition for our code.
Еще один способ работы с вытеснением — это интерфейс `sched_pin()`. Если участок кода заключен между функциями `sched_pin()` и `sched_unpin()`, гарантируется, что соответствующий поток, даже если он может быть вытеснен, всегда будет выполняться на том же CPU. Закрепление очень эффективно в частном случае, когда нам необходимо обращаться к данным, привязанным к определеённым CPU, и мы предполагаем, что другие потоки не изменят эти данные. Последнее условие делает критическую секцию избыточно строгим условием для нашего кода.
před 2 měsíci
Avatar uživatele v.popolitov

Vyhledat a nahradit

Documentation / articles/linux-emulation/_index — Ruština

Atomic operations are implemented through a set of functions performing simple arithmetics on memory operands in an atomic way with respect to external events (interrupts, preemption, etc.). Atomic operations can guarantee atomicity just on small data types (in the magnitude order of the `.long.` architecture C data type), so should be rarely used directly in the end-level code, if not only for very simple operations (like flag setting in a bitmap, for example). In fact, it is rather simple and common to write down a wrong semantic based on just atomic operations (usually referred as lock-less). The FreeBSD kernel offers a way to perform atomic operations in conjunction with a memory barrier. The memory barriers will guarantee that an atomic operation will happen following some specified ordering with respect to other memory accesses. For example, if we need that an atomic operation happen just after all other pending writes (in terms of instructions reordering buffers activities) are completed, we need to explicitly use a memory barrier in conjunction to this atomic operation. So it is simple to understand why memory barriers play a key role for higher-level locks building (just as refcounts, mutexes, etc.). For a detailed explanatory on atomic operations, please refer to man:atomic[9]. It is far, however, noting that atomic operations (and memory barriers as well) should ideally only be used for building front-ending locks (as mutexes).
Атомарные операции реализуются через набор функций, выполняющих простые арифметические действия над операндами в памяти атомарным образом по отношению к внешним событиям (прерываниям, вытеснению и т. д.). Атомарные операции могут гарантировать атомарность только для небольших типов данных (порядка величины типа `.long` в архитектуре C), поэтому их следует редко использовать напрямую в конечном коде, разве что для очень простых операций (например, установки флага в битовой карте). На самом деле довольно просто и часто можно допустить семантическую ошибку, полагаясь только на атомарные операции (обычно называемые lock-less). Ядро FreeBSD предоставляет способ выполнения атомарных операций в сочетании с барьерами памяти. Барьеры памяти гарантируют, что атомарная операция произойдет в определеённом порядке относительно других обращений к памяти. Например, если нам нужно, чтобы атомарная операция выполнилась только после завершения всех ожидающих операций записи (с точки зрения переупорядочивания буферов инструкций), нам необходимо явно использовать барьер памяти вместе с этой атомарной операцией. Таким образом, легко понять, почему барьеры памяти играют ключевую роль в построении высокоуровневых блокировок (таких как refcounts, мьютексы и т. д.). Для подробного объяснения атомарных операций обратитесь к man:atomic[9]. Однако важно отметить, что атомарные операции (и барьеры памяти тоже) в идеале должны использоваться только для построения фронтенд-блокировок (например, мьютексов).
před 2 měsíci
Avatar uživatele v.popolitov

Vyhledat a nahradit

Documentation / articles/linux-emulation/_index — Ruština

Traditional UNIX(R) does not define any API nor implementation for threading, while POSIX(R) defines its threading API but the implementation is undefined. Traditionally there were two ways of implementing threads. Handling them as separate processes (1:1 threading) or envelope the whole thread group in one process and managing the threading in userspace (1:N threading). Comparing main features of each approach:
Традиционный UNIX(R) не определяет никакого API или реализации для потоков, в то время как POSIX(R) определяет свой API для потоков, но реализация остается неопределеённой. Традиционно существовало два способа реализации потоков: обработка их как отдельных процессов (потоки 1:1) или обертывание всей группы потоков в один процесс с управлением потоками в пользовательском пространстве (потоки 1:N). Сравнение основных особенностей каждого подхода:
před 2 měsíci
Avatar uživatele v.popolitov

Vyhledat a nahradit

Documentation / articles/linux-emulation/_index — Ruština

Another possible way to communicate is by using a _trap_. Traps occur asynchronously after some event occurs (division by zero, page fault etc.). A trap can be transparent for a process (page fault) or can result in a reaction like sending a _signal_ (division by zero).
Еще один возможный способ взаимодействия — использование _прерывания_. Прерывания происходят асинхронно после возникновения определеённого события (деление на ноль, ошибка страницы и т.д.). Прерывание может быть прозрачным для процесса (ошибка страницы) или привести к реакции, например, отправке _сигнала_ (деление на ноль).
před 2 měsíci
Avatar uživatele Žádný

Zapsány změny

Documentation / articles/linux-emulation/_index — Ruština

Zapsány změny před 2 měsíci
Procházet všechny změny v součásti