mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
commit
f33da28c42
@ -1,73 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (What web developers love about the Brackets text editor)
|
||||
[#]: via: (https://opensource.com/article/20/12/brackets)
|
||||
[#]: author: (Seth Kenlon https://opensource.com/users/seth)
|
||||
|
||||
What web developers love about the Brackets text editor
|
||||
======
|
||||
This basic editor is geared toward web developers, supporting multiple
|
||||
programming languages and offering plenty of extensions to make it your
|
||||
own.
|
||||
![Text editor on a browser, in blue][1]
|
||||
|
||||
The Brackets text editor is an editor geared primarily at web developers. Appropriately, its Edit menu is full of functions especially useful to users of web programming languages, with a focus on the classic combination of HTML, CSS, and Javascript.
|
||||
|
||||
However, it supports many languages and formats relevant to the internet, including XML, Markdown, YAML and JSON, PHP, Lua, Java, and Python, as well as some common general languages like C, C++, and even the output of `diff` commands.
|
||||
|
||||
### Installing Brackets
|
||||
|
||||
Brackets can be installed on Linux, Windows, and macOS from the [Brackets website][2].
|
||||
|
||||
Alternatively, on Linux, you can install it as a Flatpak from [flathub.org][3].
|
||||
|
||||
![Brackets editor][4]
|
||||
|
||||
### Using Brackets
|
||||
|
||||
For the most part, Brackets is a "normal" text editor, with features similar to jEdit or Medit. There’s syntax highlighting, configurable tab spacing, character encoding settings, and so on. These are available in the status bar at the bottom of the window.
|
||||
|
||||
From the View menu, there are theme settings, line numbering, word wrapping, and even options to split the window so you can see two files in one window.
|
||||
|
||||
In the Edit menu, however, there are some special functions for programming. Here are some of my favorites:
|
||||
|
||||
* Indent and unindent blocks of text using the **Ctrl+[** or **Ctrl+]** keyboard shortcuts, which are useful not only for keeping HTML, CSS, and Javascript tidy but essential for Python code.
|
||||
* Make a line into a comment with **Ctrl+/**. The way Brackets marks a comment depends on the language you’re using, so this function works whether your document uses slashes, dashes, arrows, hashes, or anything else for commenting.
|
||||
* Move a line up or down in your document with **Shift+Ctrl+Up** or **Shift+Ctrl+Down**.
|
||||
* Delete an entire line with **Shift+Ctrl+D**.
|
||||
* Duplicate a line with **Ctrl+D**.
|
||||
|
||||
|
||||
|
||||
These are all seemingly niche functions you might not think you’ll use often, but once you have them, you come to rely on them.
|
||||
|
||||
### Extensions
|
||||
|
||||
Brackets can also accept extensions so you and other coders can add to its features. To see what extensions are available, click the File menu and select Extension Manager. There’s a wide variety of extensions available, including Beautify to adjust code formatting, multiple support kits for additional languages, a function to go to the beginning or end of a tag, and much more.
|
||||
|
||||
Extensions can make all the difference to an editor and whether it’s right for you, so if you try Brackets and enjoy everything about it, but you’re missing some vital feature, have a browse through the available extensions before you give up on it.
|
||||
|
||||
### Try Brackets
|
||||
|
||||
Brackets is a somewhat subdued editor. While it advertises itself as a "code editor for the web," it’s actually a nice general-purpose editor with some extra features thrown in for common web toolchains. If you like the look of Brackets and what it has to offer, give it a try!
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/12/brackets
|
||||
|
||||
作者:[Seth Kenlon][a]
|
||||
选题:[lujun9972][b]
|
||||
译者:[译者ID](https://github.com/译者ID)
|
||||
校对:[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/seth
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/browser_blue_text_editor_web.png?itok=lcf-m6N7 (Text editor on a browser, in blue)
|
||||
[2]: http://brackets.io/
|
||||
[3]: https://flathub.org/apps/details/io.brackets.Brackets
|
||||
[4]: https://opensource.com/sites/default/files/screenshot_2020-12-02_at_16.26.58.png (Brackets editor)
|
@ -1,5 +1,5 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
|
273
sources/tech/20201216 How to use Kubernetes resource quotas.md
Normal file
273
sources/tech/20201216 How to use Kubernetes resource quotas.md
Normal file
@ -0,0 +1,273 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (How to use Kubernetes resource quotas)
|
||||
[#]: via: (https://opensource.com/article/20/12/kubernetes-resource-quotas)
|
||||
[#]: author: (Mike Calizo https://opensource.com/users/mcalizo)
|
||||
|
||||
How to use Kubernetes resource quotas
|
||||
======
|
||||
Resource quotas prevent resource contention and "land grabs" by
|
||||
controlling how much CPU or memory an application can consume.
|
||||
![Jars with food inside on a shelf][1]
|
||||
|
||||
"Control" is the word that comes to mind when someone mentions they need to manage Kubernetes compute resources, especially CPU and memory. These conversations generally happen after the [Kubernetes][2] platform has been deployed for a while and developers are using the cluster extensively. And most of the time, the topic comes up after a problem happens.
|
||||
|
||||
Resource issues are common when the Kubernetes implementation is deployed without consideration for the cluster's future growth. Issues may also be related to the team's experience level that deploys and manages the Kubernetes cluster.
|
||||
|
||||
Without controls, one rogue application or developer can disrupt business. This inadvertently happens when several developers share a cluster with a fixed number of nodes. These resource constraints can start disagreements, finger-pointing, and "land-grabbing" of available resources among developers. It's a very bad situation for cluster administrators and developers alike.
|
||||
|
||||
There are several ways to manage how applications utilize computing resources in the Kubernetes environment. Most of the time, resource quotas and limit ranges are enough. Note that in Kubernetes, storage management takes an unusual approach by using a Persistent Volume plugin where properties to address and control different storage requirements are defined.
|
||||
|
||||
Kubernetes resource quotas are a way to control how computing resources are used. This article will show you how to use this feature to manage developers' behavior and control application resource consumption.
|
||||
|
||||
### What are resource quotas?
|
||||
|
||||
In short, [resource quotas][3] provide constraints that limit resource consumption per namespace. They can be applied only at the namespace level, which means they can be applied to computing resources and limit the number of objects inside the namespace.
|
||||
|
||||
A Kubernetes resource quota is defined by a `ResourceQuota` object. When applied to a namespace, it can limit computing resources such as CPU and memory as well as the creation of the following objects:
|
||||
|
||||
* Pods
|
||||
* Services
|
||||
* Secrets
|
||||
* Persistent Volume Claims (PVCs)
|
||||
* ConfigMaps
|
||||
|
||||
|
||||
|
||||
Kubernetes supports two types of CPU and memory quotas to manage compute resources. These are controlled via limits and requests, as the [LimitRange][4] documentation explains.
|
||||
|
||||
In short, a _request_ defines the guaranteed CPU or memory resources for containers, while a _limit_ is the memory or CPU threshold that a container can use, depending on what is available based on other containers' usage.
|
||||
|
||||
This image illustrates the difference between requests and limits in Kubernetes resource quotas.
|
||||
|
||||
![Requests and limits in Kubernetes resource quotas][5]
|
||||
|
||||
(Michael Calizo, [CC BY-SA 4.0][6])
|
||||
|
||||
The following exercise demonstrates how to use resource quotas to create constraints that limit an application to certain resources based on a defined threshold. It also shows the usefulness of implementing resource quotas to gain control over your Kubernetes implementation.
|
||||
|
||||
### Prerequisites
|
||||
|
||||
Before starting, make sure you have Kubernetes deployed in your local machine. Here is my configuration:
|
||||
|
||||
* [Minikube][7] v1.14.2
|
||||
* Fedora 33 operating system
|
||||
* Internet access
|
||||
|
||||
|
||||
|
||||
If you need help deploying Minikube on your Linux laptop, you can follow the steps in Bryant Son's [_Getting started with Minikube_][7]. Or, if you're on Windows or macOS, you can follow [these steps][8].
|
||||
|
||||
### Set up a resource quota
|
||||
|
||||
This example creates a CPU quota, but the process is similar for a memory quota or a combination of the two.
|
||||
|
||||
In a real production scenario, CPU resources are usually at the top of the computing resources you need to manage to avoid resource contention. This is true whenever you have multiple applications running on top of your server (compute).
|
||||
|
||||
Start by creating a new namespace where you will apply your CPU quota:
|
||||
|
||||
|
||||
```
|
||||
$ kubectl create namespace quota-test
|
||||
namespace/quota-test created
|
||||
```
|
||||
|
||||
Create a file named `cpu-quota.yaml` and put the following quota (created for this demo) into it:
|
||||
|
||||
|
||||
```
|
||||
apiVersion: v1
|
||||
kind: ResourceQuota
|
||||
metadata:
|
||||
name: test-cpu-quota
|
||||
spec:
|
||||
hard:
|
||||
requests.cpu: "100m"
|
||||
limits.cpu: "200m"
|
||||
```
|
||||
|
||||
Apply the quota to your Kubernetes cluster with:
|
||||
|
||||
|
||||
```
|
||||
$ kubectl apply -f cpu-qouta.yaml
|
||||
resourcequota/test-cpu-quota created
|
||||
```
|
||||
|
||||
Verify that the quota was applied with the `kubectl describe` command:
|
||||
|
||||
|
||||
```
|
||||
$ kubectl describe resourcequota/test-cpu-quota --namespace quota-test
|
||||
Name: test-cpu-quota
|
||||
Namespace: quota-test
|
||||
Resource Used Hard
|
||||
\-------- ---- ----
|
||||
limits.cpu 0 200m
|
||||
requests.cpu 0 100m
|
||||
```
|
||||
|
||||
Notice the `Used resources` column; this value will change as you deploy pods.
|
||||
|
||||
Now that you've defined your quota, test it. For this example, deploy three different pods in the same namespace to see if you can control the resources' usage based on the limits you defined. The three pods are:
|
||||
|
||||
* **PodA:** This pod, the first to be instantiated, will use 50% of the available CPU.
|
||||
* **PodB:** This pod will use the other 50% of the available CPU; it will be the second pod instantiated.
|
||||
* **PodC:** The defined quota should prevent this third pod from being deployed.
|
||||
|
||||
|
||||
|
||||
Now that you know the scenario, deploy the pods.
|
||||
|
||||
#### Deploy the pods
|
||||
|
||||
**PodA:**
|
||||
|
||||
|
||||
```
|
||||
$ kubectl create -n quota-test -f- <<EOF
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: poda
|
||||
spec:
|
||||
containers:
|
||||
- name: quota-test
|
||||
image: busybox
|
||||
imagePullPolicy: IfNotPresent
|
||||
command: ['sh', '-c', 'echo Pod is Running ; sleep 5000']
|
||||
resources:
|
||||
requests:
|
||||
cpu: "50m"
|
||||
limits:
|
||||
cpu: "100m"
|
||||
restartPolicy: Never
|
||||
EOF
|
||||
```
|
||||
|
||||
Verify the CPU use by describing the quota again and noting the `Used CPU` value limits and requests:
|
||||
|
||||
|
||||
```
|
||||
$ kubectl describe resourcequota/test-cpu-quota --namespace quota-test
|
||||
Name: test-cpu-quota
|
||||
Namespace: quota-test
|
||||
Resource Used Hard
|
||||
\-------- ---- ----
|
||||
limits.cpu 100m 200m
|
||||
requests.cpu 50m 100m
|
||||
```
|
||||
|
||||
**PodB:**
|
||||
|
||||
|
||||
```
|
||||
$ kubectl create -n quota-test -f- <<EOF
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: podb
|
||||
spec:
|
||||
containers:
|
||||
- name: quota-test
|
||||
image: busybox
|
||||
imagePullPolicy: IfNotPresent
|
||||
command: ['sh', '-c', 'echo Pod is Running ; sleep 5000']
|
||||
resources:
|
||||
requests:
|
||||
cpu: "50m"
|
||||
limits:
|
||||
cpu: "100m"
|
||||
restartPolicy: Never
|
||||
EOF
|
||||
```
|
||||
|
||||
Check the CPU resource usage again. As expected, PodB can be scheduled because the quota allows it:
|
||||
|
||||
|
||||
```
|
||||
$ kubectl describe resourcequota/test-cpu-quota --namespace quota-test
|
||||
Name: test-cpu-quota
|
||||
Namespace: quota-test
|
||||
Resource Used Hard
|
||||
\-------- ---- ----
|
||||
limits.cpu 200m 200m
|
||||
requests.cpu 100m 100m
|
||||
```
|
||||
|
||||
**PodC:**
|
||||
|
||||
Now, try to instantiate the third pod, even though you know PodA and Pod B maximized the CPU quota threshold you defined:
|
||||
|
||||
|
||||
```
|
||||
$ kubectl create -n quota-test -f- <<EOF
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: podc
|
||||
spec:
|
||||
containers:
|
||||
- name: quota-test
|
||||
image: busybox
|
||||
imagePullPolicy: IfNotPresent
|
||||
command: ['sh', '-c', 'echo Pod is Running ; sleep 5000']
|
||||
resources:
|
||||
requests:
|
||||
cpu: "5m"
|
||||
limits:
|
||||
cpu: "10m"
|
||||
restartPolicy: Never
|
||||
EOF
|
||||
```
|
||||
|
||||
As expected, the third pod will not instantiate because the defined quota prevents creating the pods:
|
||||
|
||||
|
||||
```
|
||||
`Error from server (Forbidden): error when creating "STDIN": pods "podc" is forbidden: exceeded quota: test-cpu-quota, requested: limits.cpu=10m,requests.cpu=5m, used: limits.cpu=200m,requests.cpu=100m, limited: limits.cpu=200m,requests.cpu=100m`
|
||||
```
|
||||
|
||||
As this example shows, properly defined resource quotas are a powerful tool that a Kubernetes admin can utilize to manage developer behavior.
|
||||
|
||||
### Clean up
|
||||
|
||||
Delete the namespace you created (in this case, `quota-test`):
|
||||
|
||||
|
||||
```
|
||||
`$ kubectl delete -n quota-test`
|
||||
```
|
||||
|
||||
### Planning your quotas
|
||||
|
||||
There are many ways to control how users can deploy applications to avoid "land grabbing" in a Kubernetes cluster. Having a sound implementation of quotas, limit ranges, and other native features contributes to a cluster's stability.
|
||||
|
||||
Implementing resource quotas on computing resources is an important design decision that you need to think carefully about—especially when deploying Kubernetes for running business-critical enterprise applications.
|
||||
|
||||
When defining quotas, it's important to include developers in your planning. Because of their application knowledge, they are your best resources for estimating what's required.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/12/kubernetes-resource-quotas
|
||||
|
||||
作者:[Mike Calizo][a]
|
||||
选题:[lujun9972][b]
|
||||
译者:[译者ID](https://github.com/译者ID)
|
||||
校对:[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/mcalizo
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/OSDC_secret_ingredient_520x292.png?itok=QbKzJq-N (Jars with food inside on a shelf)
|
||||
[2]: https://kubernetes.io/
|
||||
[3]: https://kubernetes.io/docs/concepts/policy/resource-quotas
|
||||
[4]: https://kubernetes.io/docs/concepts/policy/limit-range/
|
||||
[5]: https://opensource.com/sites/default/files/uploads/resourcequota_requests-limits.png (Requests and limits in Kubernetes resource quotas)
|
||||
[6]: https://creativecommons.org/licenses/by-sa/4.0/
|
||||
[7]: https://opensource.com/article/18/10/getting-started-minikube
|
||||
[8]: https://www.liquidweb.com/kb/how-to-install-minikube/
|
@ -0,0 +1,251 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Understanding 52-bit virtual address support in the Arm64 kernel)
|
||||
[#]: via: (https://opensource.com/article/20/12/52-bit-arm64-kernel)
|
||||
[#]: author: (Bhupesh Sharma https://opensource.com/users/bhsharma)
|
||||
|
||||
Understanding 52-bit virtual address support in the Arm64 kernel
|
||||
======
|
||||
The introduction of 64-bit hardware increased the need to handle larger
|
||||
address spaces.
|
||||
![Puzzle pieces coming together to form a computer screen][1]
|
||||
|
||||
After 64-bit hardware became available, the need to handle larger address spaces (greater than 232 bytes) became obvious. With some vendors now offering servers with 64TiB (or more) of memory, x86_64 and arm64 now allow addressing adress spaces greater than 248 bytes (available with the default 48-bit address support).
|
||||
|
||||
x86_64 addressed these use cases by enabling support for five-level page tables in both hardware and software. This enables addressing address spaces equal to 257 bytes (see [x86: 5-level paging enabling for v4.12][2] for details). It bumps the limits to 128PiB of virtual address space and 4PiB of physical address space.
|
||||
|
||||
arm64 achieved the same thing by introducing two new architecture extensions—ARMv8.2 LVA (Large Virtual Addressing) and ARMv8.2 LPA (Large Physical Addressing). These allow 4PiB of virtual address space and 4 PiB of physical address space (i.e., 252 bits each, respectively).
|
||||
|
||||
With ARMv8.2 architecture extensions available in new arm64 CPUs, the two new hardware extensions are now supported in open source software.
|
||||
|
||||
Starting with Linux kernel version 5.4, the 52-bit (Large) Virtual Address (VA) and Physical Address (PA) support was introduced for arm64 architecture. Although the [kernel documentation][3] describes these features and how they impact the new kernels running on older CPUs (which don't support 52-bit VA extension in hardware) and newer CPUs (which support 52-bit VA extensions in hardware), it can be complex for average users to understand them and how they can "opt-in" to receiving VAs from a 52-bit space.
|
||||
|
||||
Therefore, I will introduce these relatively new concepts in this article:
|
||||
|
||||
1. How the kernel memory layout got "flipped" for Arm64 after the support for these features was added
|
||||
2. The impact on userspace applications, especially the ones that provide debugging support (e.g., kexec-tools, makedumpfile, and crash-utility)
|
||||
3. How userspace applications can "opt-in" to receiving VAs from a 52-bit space by specifying an mmap hint parameter that is larger than 48 bits
|
||||
|
||||
|
||||
|
||||
### ARMv8.2 architecture LVA and LPA extensions
|
||||
|
||||
The ARMv8.2 architecture provides two important extensions: Large Virtual Addressing (LVA) and Large Physical Addressing (LPA).
|
||||
|
||||
ARMv8.2-LVA supports a larger VA space for each translation table base register of up to 52 bits when using the 64KB translation granule.
|
||||
|
||||
ARMv8.2-LPA allows:
|
||||
|
||||
* A larger intermediate physical address (IPA) and PA space of up to 52 bits when using the 64KB translation granule
|
||||
* A level 1 block size where the block covers a 4TB address range for the 64KB translation granule if the implementation supports 52 bits of PA
|
||||
|
||||
|
||||
|
||||
_Note that these features are supported only in the AArch64 state._
|
||||
|
||||
Currently, the following Arm64 Cortex-A processors support ARMv8.2 extensions:
|
||||
|
||||
* Cortex-A55
|
||||
* Cortex-A75
|
||||
* Cortex-A76
|
||||
|
||||
|
||||
|
||||
For more details, see the [Armv8 Architecture Reference Manual][4].
|
||||
|
||||
### Kernel memory layout on Arm64
|
||||
|
||||
With the ARMv8.2 extension adding support for LVA space (which is only available when running with a 64KB page size), the number of descriptors gets expanded in the first level of translation.
|
||||
|
||||
User addresses have bits 63:48 set to 0, while the kernel addresses have the same bits set to 1. TTBRx selection is given by bit 63 of the virtual address. The `swapper_pg_dir` contains only kernel (global) mappings, while the user `pgd` contains only user (non-global) mappings. The `swapper_pg_dir` address is written to TTBR1 and never written to TTBR0.
|
||||
|
||||
**AArch64 Linux memory layout with 64KB pages plus three levels (52-bit with hardware support):**
|
||||
|
||||
|
||||
```
|
||||
Start End Size Use
|
||||
-----------------------------------------------------------------------
|
||||
0000000000000000 000fffffffffffff 4PB user
|
||||
fff0000000000000 fff7ffffffffffff 2PB kernel logical memory map
|
||||
fff8000000000000 fffd9fffffffffff 1440TB [gap]
|
||||
fffda00000000000 ffff9fffffffffff 512TB kasan shadow region
|
||||
ffffa00000000000 ffffa00007ffffff 128MB bpf jit region
|
||||
ffffa00008000000 ffffa0000fffffff 128MB modules
|
||||
ffffa00010000000 fffff81ffffeffff ~88TB vmalloc
|
||||
fffff81fffff0000 fffffc1ffe58ffff ~3TB [guard region]
|
||||
fffffc1ffe590000 fffffc1ffe9fffff 4544KB fixed mappings
|
||||
fffffc1ffea00000 fffffc1ffebfffff 2MB [guard region]
|
||||
fffffc1ffec00000 fffffc1fffbfffff 16MB PCI I/O space
|
||||
fffffc1fffc00000 fffffc1fffdfffff 2MB [guard region]
|
||||
fffffc1fffe00000 ffffffffffdfffff 3968GB vmemmap
|
||||
ffffffffffe00000 ffffffffffffffff 2MB [guard region]
|
||||
```
|
||||
|
||||
**Translation table lookup with 4KB pages:**
|
||||
|
||||
|
||||
```
|
||||
+--------+--------+--------+--------+--------+--------+--------+--------+
|
||||
|63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
|
||||
+--------+--------+--------+--------+--------+--------+--------+--------+
|
||||
| | | | | |
|
||||
| | | | | v
|
||||
| | | | | [11:0] in-page offset
|
||||
| | | | +-> [20:12] L3 index
|
||||
| | | +-----------> [29:21] L2 index
|
||||
| | +---------------------> [38:30] L1 index
|
||||
| +-------------------------------> [47:39] L0 index
|
||||
+-------------------------------------------------> [63] TTBR0/1
|
||||
```
|
||||
|
||||
**Translation table lookup with 64KB pages:**
|
||||
|
||||
|
||||
```
|
||||
+--------+--------+--------+--------+--------+--------+--------+--------+
|
||||
|63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
|
||||
+--------+--------+--------+--------+--------+--------+--------+--------+
|
||||
| | | | |
|
||||
| | | | v
|
||||
| | | | [15:0] in-page offset
|
||||
| | | +----------> [28:16] L3 index
|
||||
| | +--------------------------> [41:29] L2 index
|
||||
| +-------------------------------> [47:42] L1 index (48-bit)
|
||||
| [51:42] L1 index (52-bit)
|
||||
+-------------------------------------------------> [63] TTBR0/1
|
||||
```
|
||||
|
||||
|
||||
|
||||
![][5]
|
||||
|
||||
opensource.com
|
||||
|
||||
### 52-bit VA support in the kernel
|
||||
|
||||
Since the newer kernels with the LVA support should run well on older CPUs (which don't support LVA extension in hardware) and the newer CPUs (which support LVA extension in hardware), the chosen design approach is to have a single binary that supports 52 bit (and must be able to fall back to 48 bit at early boot time if the hardware feature is not present). That is, the VMEMMAP must be sized large enough for 52-bit VAs and also must be sized large enough to accommodate a fixed `PAGE_OFFSET`.
|
||||
|
||||
This design approach requires the kernel to support the following variables for the new virtual address space:
|
||||
|
||||
|
||||
```
|
||||
VA_BITS constant the *maximum* VA space size
|
||||
|
||||
vabits_actual variable the *actual* VA space size
|
||||
```
|
||||
|
||||
So, while `VA_BITS` denotes the maximum VA space size, the actual VA space supported (depending on the switch made at boot time) is indicated by `vabits_actual`.
|
||||
|
||||
#### Flipping the kernel memory layout
|
||||
|
||||
The design approach of keeping a single kernel binary requires the kernel .text to be in the higher addresses, such that they are invariant to 48/52-bit VAs. Due to the Kernel Address Sanitizer (KASAN) shadow being a fraction of the entire kernel VA space, the end of the KASAN shadow must also be in the higher half of the kernel VA space for both 48 and 52 bit. (Switching from 48 bit to 52 bit, the end of the KASAN shadow is invariant and dependent on `~0UL`, while the start address will "grow" towards the lower addresses).
|
||||
|
||||
To optimize `phys_to_virt()` and `virt_to_phys()`, the `PAGE_OFFSET` is kept constant at `0xFFF0000000000000` (corresponding to 52 bit), this obviates the need for an extra variable read. The `physvirt` and `vmemmap` offsets are computed at early boot to enable this logic.
|
||||
|
||||
Consider the following physical vs. virtual RAM address space conversion:
|
||||
|
||||
|
||||
```
|
||||
/*
|
||||
* The linear kernel range starts at the bottom of the virtual address
|
||||
* space. Testing the top bit for the start of the region is a
|
||||
* sufficient check and avoids having to worry about the tag.
|
||||
*/
|
||||
|
||||
#define virt_to_phys(addr) ({ \
|
||||
if (!(((u64)addr) & BIT(vabits_actual - 1))) \
|
||||
(((addr) & ~PAGE_OFFSET) + PHYS_OFFSET)
|
||||
})
|
||||
|
||||
#define phys_to_virt(addr) ((unsigned long)((addr) - PHYS_OFFSET) | PAGE_OFFSET)
|
||||
|
||||
where:
|
||||
PAGE_OFFSET - the virtual address of the start of the linear map, at the
|
||||
start of the TTBR1 address space,
|
||||
PHYS_OFFSET - the physical address of the start of memory, and
|
||||
vabits_actual - the *actual* VA space size
|
||||
```
|
||||
|
||||
### Impact on userspace applications used to debug kernel
|
||||
|
||||
Several userspace applications are used to debug running/live kernels or analyze the vmcore dump from a crashing system (e.g., to determine the root cause of the kernel crash): kexec-tools, makedumpfile, and crash-utility.
|
||||
|
||||
When these are used for debugging the Arm64 kernel, there is also an impact on them because of the Arm64 kernel memory map getting "flipped." These applications also need to perform a translation table walk for determining a physical address corresponding to a virtual address (similar to how it is done in the kernel).
|
||||
|
||||
Accordingly, userspace applications must be modified as they are broken upstream after the "flip" was introduced in the kernel memory map.
|
||||
|
||||
I have proposed fixes in the three affected userspace applications; while some have been accepted upstream, others are still pending:
|
||||
|
||||
* [Proposed makedumpfile upstream fix][6]
|
||||
* [Proposed kexec-tools upstream fix][7]
|
||||
* [Fix accepted in crash-utility][8]
|
||||
|
||||
|
||||
|
||||
Unless these changes are made in userspace applications, they will remain broken for debugging running/live kernels or analyzing the vmcore dump from a crashing system.
|
||||
|
||||
### 52-bit userspace VAs
|
||||
|
||||
To maintain compatibility with userspace applications that rely on the ARMv8.0 VA space maximum size of 48 bits, the kernel will, by default, return virtual addresses to userspace from a 48-bit range.
|
||||
|
||||
Userspace applications can "opt-in" to receiving VAs from a 52-bit space by specifying an mmap hint parameter larger than 48 bits.
|
||||
|
||||
For example:
|
||||
|
||||
|
||||
```
|
||||
.mmap_high_addr.c
|
||||
\----
|
||||
|
||||
maybe_high_address = mmap(~0UL, size, prot, flags,...);
|
||||
```
|
||||
|
||||
It is also possible to build a debug kernel that returns addresses from a 52-bit space by enabling the following kernel config options:
|
||||
|
||||
|
||||
```
|
||||
` CONFIG_EXPERT=y && CONFIG_ARM64_FORCE_52BIT=y`
|
||||
```
|
||||
|
||||
_Note that this option is only intended for debugging applications and should **not** be used in production._
|
||||
|
||||
### Conclusions
|
||||
|
||||
To summarize:
|
||||
|
||||
1. Starting with Linux kernel version 5.14, the new Armv8.2 hardware extensions LVA and LPA are now well-supported in the Linux kernel.
|
||||
2. Userspace applications like kexec-tools and makedumpfile used for debugging the kernel are broken _right now_ and awaiting acceptance of upstream fixes.
|
||||
3. Legacy userspace applications that rely on Arm64 kernel providing it a 48-bit VA will continue working as-is, whereas newer userspace applications can "opt-in" to receiving VAs from a 52-bit space by specifying an mmap hint parameter that is larger than 48 bits.
|
||||
|
||||
|
||||
|
||||
* * *
|
||||
|
||||
_This article draws on [Memory Layout on AArch64 Linux][9] and [Linux kernel documentation v5.9.12][10]. Both are licensed under GPLv2.0._
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/12/52-bit-arm64-kernel
|
||||
|
||||
作者:[Bhupesh Sharma][a]
|
||||
选题:[lujun9972][b]
|
||||
译者:[译者ID](https://github.com/译者ID)
|
||||
校对:[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/bhsharma
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/puzzle_computer_solve_fix_tool.png?itok=U0pH1uwj (Puzzle pieces coming together to form a computer screen)
|
||||
[2]: https://lwn.net/Articles/716916/
|
||||
[3]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm64/memory.rst
|
||||
[4]: https://developer.arm.com/documentation/ddi0487/latest/
|
||||
[5]: https://opensource.com/sites/default/files/arm64-multi-level-translation_0.png (arm64 Multi-level Translation)
|
||||
[6]: http://lists.infradead.org/pipermail/kexec/2020-September/021372.html
|
||||
[7]: http://lists.infradead.org/pipermail/kexec/2020-September/021333.html
|
||||
[8]: https://github.com/crash-utility/crash/commit/1c45cea02df7f947b4296c1dcaefa1024235ef10
|
||||
[9]: https://www.kernel.org/doc/html/latest/arm64/memory.html
|
||||
[10]: https://elixir.bootlin.com/linux/latest/source/arch/arm64/include/asm/memory.h
|
@ -0,0 +1,115 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Why Vim users will love the Kakoune text editor)
|
||||
[#]: via: (https://opensource.com/article/20/12/kakoune)
|
||||
[#]: author: (Seth Kenlon https://opensource.com/users/seth)
|
||||
|
||||
Why Vim users will love the Kakoune text editor
|
||||
======
|
||||
This editor may be reminiscent of Vim, but it offers plenty of its own
|
||||
unique functions and features.
|
||||
![Typewriter keys in multicolor][1]
|
||||
|
||||
The [Kakoune][2] text editor takes inspiration from Vi. With a minimalistic interface, short keyboard shortcuts, and separate editing and insert modes, it does [look and feel a lot like Vi][3] at first. However, the Kakoune editor has its own unique style both in design and function and is better considered its own editor rather than yet another Vim.
|
||||
|
||||
### Install
|
||||
|
||||
On Linux and BSD, you can install Kakoune from your distribution’s software repository or ports tree. For example, on Fedora, CentOS, or RHEL:
|
||||
|
||||
|
||||
```
|
||||
`$ sudo dnf install kakoune`
|
||||
```
|
||||
|
||||
On Debian, Ubuntu, or similar:
|
||||
|
||||
|
||||
```
|
||||
`$ sudo apt install kakoune`
|
||||
```
|
||||
|
||||
On macOS, you can use Homebrew:
|
||||
|
||||
|
||||
```
|
||||
`$ brew install kakoune`
|
||||
```
|
||||
|
||||
Alternatively, you can [build it from source code][4].
|
||||
|
||||
The command to start Kakoune is `kak`. You can start Kakoune empty, or you can include a file name for it to open upon launch:
|
||||
|
||||
|
||||
```
|
||||
`$ kak example.txt`
|
||||
```
|
||||
|
||||
### Using Kakoune
|
||||
|
||||
When you launch Kakoune (without a file name), it opens a mostly empty buffer in your terminal, except for a small status bar at the bottom of the windows. Like Vim, Kakoune starts in "normal" mode, which accepts key presses as commands and does not enter text into the buffer. To enter _insert_ mode, you must press either **i** (for **insert**) or **a** (for **append**).
|
||||
|
||||
While in insert mode, Kakoune acts mostly like any other editor. You type on your keyboard, and the characters you type show up in the buffer. While in insert mode, you can use the arrow keys to navigate through the buffer.
|
||||
|
||||
### Normal mode
|
||||
|
||||
In normal mode, you can issue navigation and text editing commands. This is the most obvious borrowed feature from the Vi tradition. Editing commands include functions to copy, cut (or "yank," in traditional Unix editing vernacular), and paste words and lines, undo, transform characters to upper or lower case, and so on. Here are some of the basics:
|
||||
|
||||
* **d**: yank and delete current selection ("cut" in modern terminology)
|
||||
* **c**: yank and delete current selection and enter insert mode
|
||||
* **Esc+Alt+d**: delete current selection
|
||||
* **y**: yank selection
|
||||
* **p**: paste
|
||||
* **<**: unindent selected lines
|
||||
* **u**: undo
|
||||
* **U**: redo
|
||||
* **`**: transform to lower case
|
||||
* **~**: transform to upper case
|
||||
|
||||
|
||||
|
||||
### Selection
|
||||
|
||||
In Kakoune, your cursor is a single-character mobile selection. Unless you extend your selection, any commands affecting a selection apply to just your cursor. For instance, if your cursor is hovering over the letter **n**, then the yank command (**c** in normal mode) copies the letter **n** to your clipboard, and the paste command (**p** in normal mode) pastes the letter **n** into the buffer.
|
||||
|
||||
The easiest way to extend a selection from a single character is to enter normal mode and press the **Shift** key while moving your cursor with the arrow keys. There are, however, several methods of extending a selection based on certain criteria. For instance, **Alt+l** extends a selection region from your cursor to the end of the current line.
|
||||
|
||||
Full documentation is available at <https://github.com/mawww/kakoune/blob/master/README.asciidoc>.
|
||||
|
||||
### Functions
|
||||
|
||||
In addition to these basic interactions, you can also issue commands to invoke the built-in functions of Kakoune. To access the Kakoune’s command line, type `:` in normal mode. From the command line, you can issue commands, including the essential **edit** command to open a file, the **write** command to save your buffer to a file, and of course, **quit** to exit the application.
|
||||
|
||||
There are many more functions, including special options for specific programming languages and file formats, an option to use the [Ranger file navigator][5] to browse your file system, change your color theme, search and replace text, and much more.
|
||||
|
||||
![Kakoune][6]
|
||||
|
||||
### Try Kakoune
|
||||
|
||||
If you’re an experienced Vim user or even someone with just a passing competency, you might find Kakoune disorienting at first. It’s just similar enough to Vim to lull you into a false sense of familiarity—everything works exactly like Vim until it’s drastically different. However, if you’re new to Vim-like editors, or you’re a Vim user looking for a new challenge, then Kakoune could be an ideal editor for you.
|
||||
|
||||
Try it for yourself!
|
||||
|
||||
When I started using the vi text editor, I hated it. Now I've been using vi for more than 17 years...
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/12/kakoune
|
||||
|
||||
作者:[Seth Kenlon][a]
|
||||
选题:[lujun9972][b]
|
||||
译者:[译者ID](https://github.com/译者ID)
|
||||
校对:[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/seth
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/osdc-docdish-typewriterkeys-3.png?itok=NyBwMdK_ (Typewriter keys in multicolor)
|
||||
[2]: https://kakoune.org/
|
||||
[3]: https://opensource.com/article/20/12/vi-text-editor
|
||||
[4]: https://github.com/mawww/kakoune
|
||||
[5]: https://opensource.com/article/20/3/ranger-file-navigator
|
||||
[6]: https://opensource.com/sites/default/files/kakoune-screenshot.png (Kakoune)
|
@ -0,0 +1,71 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (What web developers love about the Brackets text editor)
|
||||
[#]: via: (https://opensource.com/article/20/12/brackets)
|
||||
[#]: author: (Seth Kenlon https://opensource.com/users/seth)
|
||||
|
||||
Web 开发人员喜欢 Brackets 文本编辑器的原因
|
||||
======
|
||||
这个编辑器是面向 Web 开发人员的,它支持多种编程语言,并提供了大量的扩展,使其成为你自己的编辑器。
|
||||
![Text editor on a browser, in blue][1]
|
||||
|
||||
Brackets 文本编辑器是主要面向 Web 开发人员的编辑器。恰如其分的是,它的“编辑”菜单中充满了对 Web 编程语言用户特别有用的功能,主要是 HTML、CSS 和 Javascript 的经典组合。
|
||||
|
||||
但是,它还支持许多与互联网相关的语言和格式,包括 XML、Markdown、YAML 和 JSON、PHP、Lua、Java 和 Python,以及一些常见的通用语言,例如 C、C ++,甚至是 `diff` 命令的输出。
|
||||
|
||||
### 安装 Brackets
|
||||
|
||||
Brackets 可以从 [Brackets 网站][2]安装到 Linux、Windows 和 macOS上。
|
||||
|
||||
另外,在 Linux 上,你可以从 [flathub.org][3] 将其作为 Flatpak 安装。
|
||||
|
||||
![Brackets editor][4]
|
||||
|
||||
### 使用 Brackets
|
||||
|
||||
在大多数时候,Brackets 是一个“普通”的文本编辑器,其功能类似于 jEdit 或 Medit。有语法高亮、可配置的 tab 间距、字符编码设置等等。这些都可以在窗口底部的状态栏中找到。
|
||||
|
||||
在“视图”菜单中,有主题设置、行号、自动换行,甚至还有分割窗口的选项,这样你可以在一个窗口中看到两个文件。
|
||||
|
||||
然而,在“编辑”菜单中,有一些编程的特殊功能。以下是我最喜欢的一些功能:
|
||||
|
||||
* 使用 **Ctrl+[** 或 **Ctrl+]** 键盘快捷键来缩进和取消缩进文本块,这不仅对保持 HTML、CSS 和 Javascript 的整洁很有用,而且对 Python 代码也很重要。
|
||||
* 用 **Ctrl+/** 把一行变成注释。Brackets 标记注释的方式取决于你所使用的语言,所以无论你的文档是否使用斜线、破折号、箭头、井号或其他任何类型注释,这个功能都可以使用。
|
||||
* 用 **Shift+Ctrl+Up** 或 **Shift+Ctrl+Down** 在文档中向上或向下移动一行。
|
||||
* 用 **Shift+Ctrl+D** 删除整行。
|
||||
* 用 **Ctrl+D** 复制一行。
|
||||
|
||||
|
||||
|
||||
这些都是看似小众的功能,你可能认为不会经常使用,但一旦你拥有了它们,你就会对它们产生依赖。
|
||||
|
||||
### 扩展
|
||||
|
||||
Brackets 还可以接受扩展,因此你和其他编码者可以添加扩展到功能中。要查看有哪些可用的扩展,请单击“文件”菜单并选择“扩展管理器”。有各种各样的扩展,包括用于调整代码格式的 Beautify、用于其他语言的多个支持包、用于转到标签开头或结尾的功能等等。
|
||||
|
||||
无论编辑器是否适合你,扩展可以使一个编辑器变得不同,所以如果你尝试 Brackets 并享受它的一切,但缺少一些重要的功能,在你放弃它之前,请浏览一下可用的扩展。
|
||||
|
||||
### 尝试 Brackets
|
||||
|
||||
Brackets 是一个有点低调的编辑器。虽然它宣传自己是 “Web 代码编辑器”,但实际上它是一个不错的通用编辑器,并为常见的 Web 工具链加入了一些额外的功能。如果你喜欢 Brackets 的外观和它所提供的功能,不妨一试!
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/12/brackets
|
||||
|
||||
作者:[Seth Kenlon][a]
|
||||
选题:[lujun9972][b]
|
||||
译者:[geekpi](https://github.com/geekpi)
|
||||
校对:[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/seth
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/browser_blue_text_editor_web.png?itok=lcf-m6N7 (Text editor on a browser, in blue)
|
||||
[2]: http://brackets.io/
|
||||
[3]: https://flathub.org/apps/details/io.brackets.Brackets
|
||||
[4]: https://opensource.com/sites/default/files/screenshot_2020-12-02_at_16.26.58.png (Brackets editor)
|
Loading…
Reference in New Issue
Block a user