git: fa54965290 - main - Whitespace fixes at the end of some lines

The branch main has been updated by bcr:

URL: https://cgit.FreeBSD.org/doc/commit/?id=fa549652903da7e23e93fca258b4786a74904213

commit fa549652903da7e23e93fca258b4786a74904213
Author:     Benedict Reuschling <bcr@FreeBSD.org>
AuthorDate: 2023-12-29 12:08:42 +0000
Commit:     Benedict Reuschling <bcr@FreeBSD.org>
CommitDate: 2023-12-29 12:08:42 +0000

    Whitespace fixes at the end of some lines
---
 .../content/en/articles/linux-emulation/_index.adoc        | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/documentation/content/en/articles/linux-emulation/_index.adoc b/documentation/content/en/articles/linux-emulation/_index.adoc
index daf9c0ff1d..a252df5f54 100644
--- a/documentation/content/en/articles/linux-emulation/_index.adoc
+++ b/documentation/content/en/articles/linux-emulation/_index.adoc
@@ -61,7 +61,7 @@ toc::[]
 
 In the last few years the open source UNIX(R) based operating systems started to be widely deployed on server and client machines.
 Among these operating systems I would like to point out two: FreeBSD, for its BSD heritage, time proven code base and many interesting features and Linux(R) for its wide user base, enthusiastic open developer community and support from large companies.
-FreeBSD tends to be used on server class machines serving heavy duty networking tasks with less usage on desktop class machines for ordinary users. 
+FreeBSD tends to be used on server class machines serving heavy duty networking tasks with less usage on desktop class machines for ordinary users.
 While Linux(R) has the same usage on servers, but it is used much more by home based users.
 This leads to a situation where there are many binary only programs available for Linux(R) that lack support for FreeBSD.
 
@@ -219,7 +219,7 @@ The parameters to the actual syscall handler are passed in the form of `struct t
 Handling of traps in FreeBSD is similar to the handling of syscalls.
 Whenever a trap occurs, an assembler handler is called.
 It is chosen between alltraps, alltraps with regs pushed or calltrap depending on the type of the trap.
-This handler prepares arguments for a call to a C function `trap()` (defined in [.filename]#sys/i386/i386/trap.c#), which then processes the occurred trap. 
+This handler prepares arguments for a call to a C function `trap()` (defined in [.filename]#sys/i386/i386/trap.c#), which then processes the occurred trap.
 After the processing it might send a signal to the process and/or exit to userland using `userret()`.
 
 [[freebsd-exits]]
@@ -793,7 +793,7 @@ Also `PT_SYSCALL` is not implemented.
 [[traps]]
 === Traps
 
-Whenever a Linux(R) process running in the emulation layer traps the trap itself is handled transparently with the only exception of the trap translation. 
+Whenever a Linux(R) process running in the emulation layer traps the trap itself is handled transparently with the only exception of the trap translation.
 Linux(R) and FreeBSD differs in opinion on what a trap is so this is dealt with here.
 The code is actually very short:
 
@@ -851,7 +851,7 @@ Then we talk briefly about some syscalls.
 One of the major areas of progress in development of Linux(R) 2.6 was threading.
 Prior to 2.6, the Linux(R) threading support was implemented in the linuxthreads library.
 The library was a partial implementation of POSIX(R) threading.
-The threading was implemented using separate processes for each thread using the `clone` syscall to let them share the address space (and other things). 
+The threading was implemented using separate processes for each thread using the `clone` syscall to let them share the address space (and other things).
 The main weaknesses of this approach was that every thread had a different PID, signal handling was broken (from the pthreads perspective), etc.
 Also the performance was not very good (use of `SIGUSR` signals for threads synchronization, kernel resource consumption, etc.) so to overcome these problems a new threading system was developed and named NPTL.
 
@@ -954,7 +954,7 @@ More about locking later.
 [[pid-mangling]]
 ==== PID mangling
 
-As there is a difference in view as what to the idea of a process ID and thread ID is between FreeBSD and Linux(R) we have to translate the view somehow. 
+As there is a difference in view as what to the idea of a process ID and thread ID is between FreeBSD and Linux(R) we have to translate the view somehow.
 We do it by PID mangling.
 This means that we fake what a PID (=TGID) and TID (=PID) is between kernel and userland.
 The rule of thumb is that in kernel (in Linuxulator) PID = PID and TGID = shared -> group pid and to userland we present `PID = shared -> group_pid` and `TID = proc -> p_pid`.
@@ -1006,7 +1006,7 @@ Newer glibc in a case of 2.6 kernel uses `clone` to implement man:fork[2] and ma
 ==== Locking
 
 The locking is implemented to be per-subsystem because we do not expect a lot of contention on these.
-There are two locks: `emul_lock` used to protect manipulating of `linux_emuldata` and `emul_shared_lock` used to manipulate `linux_emuldata_shared`. 
+There are two locks: `emul_lock` used to protect manipulating of `linux_emuldata` and `emul_shared_lock` used to manipulate `linux_emuldata_shared`.
 The `emul_lock` is a nonsleepable blocking mutex while `emul_shared_lock` is a sleepable blocking `sx_lock`.
 Due to of the per-subsystem locking we can coalesce some locks and that is why the em find offers the non-locking access.
 
@@ -1392,7 +1392,7 @@ We are able to run the most used applications like package:www/linux-firefox[],
 Some of the programs exhibit bad behavior under 2.6 emulation but this is currently under investigation and hopefully will be fixed soon.
 The only big application that is known not to work is the Linux(R) Java(TM) Development Kit and this is because of the requirement of `epoll` facility which is not directly related to the Linux(R) kernel 2.6.
 
-We hope to enable 2.6.16 emulation by default some time after FreeBSD 7.0 is released at least to expose the 2.6 emulation parts for some wider testing. 
+We hope to enable 2.6.16 emulation by default some time after FreeBSD 7.0 is released at least to expose the 2.6 emulation parts for some wider testing.
 Once this is done we can switch to Fedora Core 6 linux_base, which is the ultimate plan.
 
 [[future-work]]