Shulou(Shulou.com)06/01 Report--

This article introduces why the Linux kernel often uses Unsigned Long instead of pointers, the content is very detailed, interested friends can refer to, I hope it can be helpful to you.

Yesterday I made a mistake to "confuse" the pointer with the integer. Fortunately, my teammate Wang Tongshe corrected it. When I got up this morning, it took me a little time to write it down.

Mastering a skill or knowledge is probably in these three stages:

I don't know. I don't know.

I know I don't know.

I know. I know.

What is more difficult to break through is the stage of "don't know you don't know". Because you "don't know you don't know," you tend to be very confident and feel that "Laozi is the best in the world." Basically, a small point to be recorded in this article is also a process from "I don't know I don't know" to "I know I know".

We all know that pointers and integers have two different meanings in C language:

Pointer: mainly for convenient reference (Dereferencing) a memory address, Dereferencing is used to access or manipulate data contained in memory location pointed to by a pointer. So the purpose of the pointer is to read and write like this:

* p = a; b = * p

Integer: an integer is a numeric value whose main purpose is to add or subtract, to compare, to subscript an array, to index, and so on. Its purpose is not to reference a memory. Pointers and integers (in this case, mainly unsigned long, because the number of bits of unsigned long is generally equal to the number of CPU addressable memory address bits) cannot be hit by eight poles themselves, but an interesting connection between them is:

If we only care about the value of this address, not about accessing memory through this address, the kernel often likes to use unsigned long instead of pointers.

Let's take a look at two different scenarios:

A pointer is a pointer?

Copy_from_user (void * to, const void _ user * from, unsigned long n); copy_to_user (void _ user * to, const void * from, unsigned long n)

In both functions, void _ _ user * from,void _ _ user * to clearly indicates that the virtual address of user space is a pointer. The reason why these two functions do this is very clear. I just want to go to the address of the Dereference user space to copy the memory, so its purpose is to access the memory through the pointer.

Similar examples such as read and write in file_operations:

Is the pointer an integer?

/ * get_user_pages ()-pin user pages in memory * @ start: starting user address * * / long get_user_pages (unsigned long start, unsigned long nr_pages, unsigned int gup_flags, struct page * * pages, struct vm_area_struct * * vmas)

The comment clearly states that start is the starting address of the user state: @ start: starting user address

So, in essence, it's the same as void _ _ user * from in copy_from_user (), but here it uses unsigned long start!! Not void _ _ user * start!

The reason is clear: get_user_pages () is only concerned with the value start itself, which is used to calculate, find, and compare. It's not meant to:

* start = 100

Similar examples include:

Long pin_user_pages (unsigned long start, unsigned long nr_pages, unsigned int gup_flags, struct page * * pages, struct vm_area_struct * * vmas)

Not to mention the famous find_vma ():

/ * Look up the first VMA which satisfies addr

< vm_end, NULL if none. */ struct vm_area_struct *find_vma( struct mm_struct *mm, unsigned long addr)； 它根据addr用户态地址，在进程的mm里面去找到addr位于的VMA。显然，这个时候，它的目的是为了完成addr与进程每个VMA起始和结束地址的比多。 这个时候，我们来看看VMA结构体的长相，就更加有意思了。我们都知道，VMA是为了记录进程每一段虚拟地址空间的(比如代码段、数据段、堆、栈、mmap等)：

Then let's look at the definition of VMA:

See, vm_start and vm_end are both proper unsigned long!

So I tried to figure out the scientific basis for doing so, and found this paragraph written in LDD3 (LDD3 11: 289):

Its scientific basis is, since you are not for dereferencing, I will not let you dereferencing, lest you run to dereferencing, which leads to bug. Some people say that if I force the unsigned long to be a pointer, I can access it.

You still need to cast, don't you? Before you cast, you will think, why is the pointer in this place an integer? If you figure it out, maybe you won't go to visit. In this way, it actually achieves the effect of deterring the mind.

So far, we are all talking about virtual addresses, so let's talk about physical addresses.

Is the physical address a pointer?

In a system with MMU, the physical address is never a pointer. The physical address is an integer from the bone! I remember that people used to send patch to the kernel, using a pointer to the physical address.

* p to describe, this is wrong to the root of the thing, so every time was scolded bloodshot.

Because you can't use a physical address to Dereferencing anything. The physical address is described in the kernel as follows:

It is either a 32-bit integer or a 64-bit integer.

So, when is the physical address a pointer? When I was a kid playing "Chinese Paladin" and "Xuanyuan Sword: the scar of Heaven" in college, I played with single-chip microcomputer at that time, and there was no MMU in it, so there was no concept of virtual address, all of which accessed memory properly through the physical address "pointer".

Therefore, if a person, all his life is playing with single-chip microcomputer, it will certainly think that my article is nonsense, because he is still a "do not know I do not know" stage.

Blurred zone

There are still some ambiguous zones, such as API such as _ _ get_free_page () and _ _ get_free_pages (), which also returns a unsigned long instead of a pointer:

Even if you go to hell, you have to turn it into a unsigned longevity!

In fact, the kernel sometimes needs to access the memory returned by _ _ get_free_page (), which needs to be cast:

Does this look particularly "refined"? Tossing and turning, what the heck are you messing about? This article has an explanation: An (unsigned) long story about page allocation

Https://lwn.net/Articles/669015/

Statistics show that in more than 90% of cases, the unsigned long returned by _ _ get_free_page () will be forcibly converted to a pointer! But this return to unsigned long is on the first day of history, and Linux's 0.01 is like this. Al Viro

Https://lwn.net/Articles/668852/

But there are too many changes. Nearly 600documents have been changed. Linus's attitude towards this is:

"No way in hell do we suddenly change the semantics of an interface that has been around from basically day # 1."

So Linus's advice is that when you really need a pointer, you should call kmalloc ():

* kmalloc (size_t size, gfp_t flags)

Excellent code

Many engineers like to be serious, that is, they have to make a choice between 0 and 1. This choice is really difficult sometimes, so what Linus means is, don't step on the ground with zero or one. I won't argue with you about the problem of zero and one. I'll give you a third way. Here, I can see the wisdom of Linus.

Personally, I don't like the argument about meaningless zeros and ones in the project, and I feel like I'm wasting my time. My view of things is that it would be OK to fight for 0. 7 or 0. 3. 0.7 is the true direction and 0.3 is the false direction.

On why the Linux kernel often uses Unsigned Long instead of pointers to share here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.