Autentique para ver os alertas.

Resumo

Site do projeto docs.freebsd.org/en
Licença da tradução BSD 2-Clause "Simplified" License
Processo de tradução
  • As traduções podem ser feitas diretamente.
  • Sugestões de tradução podem ser feitas.
  • Apenas usuários escolhidos podem contribuir.
  • A tradução usa arquivos bilíngues.
Máscara do arquivo documentation/content/*/articles/linux-emulation/_index.po

Estatísticas de textos

Porcentagem de textos Textos hospedados Porcentagem de palavras Palavras hospedadas Porcentagem de caracteres Caracteres hospedados
Total 7.524 232.541 1.470.296
Fonte 396 12.239 77.384
Traduzido 21% 1.638 20% 48.766 20% 308.245
Necessita edição 1% 10 1% 265 1% 1.846
Somente leitura 5% 396 5% 12.239 5% 77.384
Verificações com falha 1% 64 1% 407 1% 3.028
Textos com sugestões 0% 0 0% 0 0% 0
Textos não traduzidos 78% 5.876 78% 183.510 78% 1.160.205
Últimos 12 meses Anterior

Atividade nos últimos 12 meses

60 alterações 399 alterações 403 alterações 0 alteração 2 alterações 0 alteração 2 alterações 1 alteração 0 alteração 403 alterações 0 alteração 23 alterações 399 alterações 7 alterações 0 alteração 734 alterações 0 alteração 2 alterações 0 alteração 10 alterações 0 alteração 99 alterações 0 alteração 2 alterações
Jan Fev Mar Abr Maio Jun Jul Ago Set Out Nov Dez

Números rápidos

232 k
Palavras hospedadas
7.524
Textos hospedados
21%
Traduzido
0
Colaboradores
e 30 dias anteriores

Tendências dos últimos 30 dias

—
Palavras hospedadas
+100%
—
Textos hospedados
+100%
—
Traduzido
+21%
—
Colaboradores
+100%
Avatar do usuário Nenhum

O Commit das alterações foi efetuado

Documentation / articles/linux-emulation/_index — Russo

O Commit das alterações foi efetuado um mês atrás
Avatar do usuário v.popolitov

Pesquisar e substituir

Documentation / articles/linux-emulation/_index — Russo

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). Сравнение основных особенностей каждого подхода:
um mês atrás
Avatar do usuário Nenhum

O Commit das alterações foi efetuado

Documentation / articles/linux-emulation/_index — Russo

O Commit das alterações foi efetuado um mês atrás
Avatar do usuário v.popolitov

Pesquisar e substituir

Documentation / articles/linux-emulation/_index — Russo

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.
um mês atrás
Avatar do usuário v.popolitov

Pesquisar e substituir

Documentation / articles/linux-emulation/_index — Russo

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.
um mês atrás
Avatar do usuário v.popolitov

Pesquisar e substituir

Documentation / articles/linux-emulation/_index — Russo

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, и мы предполагаем, что другие потоки не изменят эти данные. Последнее условие делает критическую секцию избыточно строгим условием для нашего кода.
um mês atrás
Avatar do usuário v.popolitov

Pesquisar e substituir

Documentation / articles/linux-emulation/_index — Russo

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]. Однако важно отметить, что атомарные операции (и барьеры памяти тоже) в идеале должны использоваться только для построения фронтенд-блокировок (например, мьютексов).
um mês atrás
Avatar do usuário v.popolitov

Pesquisar e substituir

Documentation / articles/linux-emulation/_index — Russo

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). Сравнение основных особенностей каждого подхода:
um mês atrás
Avatar do usuário v.popolitov

Pesquisar e substituir

Documentation / articles/linux-emulation/_index — Russo

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).
Еще один возможный способ взаимодействия — использование _прерывания_. Прерывания происходят асинхронно после возникновения определеённого события (деление на ноль, ошибка страницы и т.д.). Прерывание может быть прозрачным для процесса (ошибка страницы) или привести к реакции, например, отправке _сигнала_ (деление на ноль).
um mês atrás
Avatar do usuário Nenhum

O Commit das alterações foi efetuado

Documentation / articles/linux-emulation/_index — Russo

O Commit das alterações foi efetuado um mês atrás
Visualizar todas as alterações de componente