| /kernel/linux/linux-6.6/block/ |
| D | ioprio.c | 69 SYSCALL_DEFINE3(ioprio_set, int, which, int, who, int, ioprio) in SYSCALL_DEFINE3() argument
85 if (!who) in SYSCALL_DEFINE3()
88 p = find_task_by_vpid(who); in SYSCALL_DEFINE3()
93 if (!who) in SYSCALL_DEFINE3()
96 pgrp = find_vpid(who); in SYSCALL_DEFINE3()
110 uid = make_kuid(current_user_ns(), who); in SYSCALL_DEFINE3()
113 if (!who) in SYSCALL_DEFINE3()
130 if (who) in SYSCALL_DEFINE3()
210 SYSCALL_DEFINE2(ioprio_get, int, which, int, who) in SYSCALL_DEFINE2() argument
222 if (!who) in SYSCALL_DEFINE2()
[all …]
|
| /kernel/linux/linux-5.10/block/ |
| D | ioprio.c | 101 SYSCALL_DEFINE3(ioprio_set, int, which, int, who, int, ioprio) in SYSCALL_DEFINE3() argument
117 if (!who) in SYSCALL_DEFINE3()
120 p = find_task_by_vpid(who); in SYSCALL_DEFINE3()
125 if (!who) in SYSCALL_DEFINE3()
128 pgrp = find_vpid(who); in SYSCALL_DEFINE3()
136 uid = make_kuid(current_user_ns(), who); in SYSCALL_DEFINE3()
139 if (!who) in SYSCALL_DEFINE3()
156 if (who) in SYSCALL_DEFINE3()
193 SYSCALL_DEFINE2(ioprio_get, int, which, int, who) in SYSCALL_DEFINE2() argument
205 if (!who) in SYSCALL_DEFINE2()
[all …]
|
| /kernel/linux/linux-6.6/drivers/gpu/drm/i915/selftests/ |
| D | scatterlist.c | 44 const char *who, in expect_pfn_sg() argument
57 __func__, who, pfn, page_to_pfn(page)); in expect_pfn_sg()
63 __func__, who, npages * PAGE_SIZE, sg->length); in expect_pfn_sg()
67 if (igt_timeout(timeout, "%s timed out\n", who)) in expect_pfn_sg()
74 __func__, who, pt->end, pfn); in expect_pfn_sg()
82 const char *who, in expect_pfn_sg_page_iter() argument
94 __func__, who, pfn, page_to_pfn(page)); in expect_pfn_sg_page_iter()
98 if (igt_timeout(timeout, "%s timed out\n", who)) in expect_pfn_sg_page_iter()
105 __func__, who, pt->end, pfn); in expect_pfn_sg_page_iter()
113 const char *who, in expect_pfn_sgtiter() argument
[all …]
|
| /kernel/linux/linux-5.10/drivers/gpu/drm/i915/selftests/ |
| D | scatterlist.c | 44 const char *who, in expect_pfn_sg() argument
57 __func__, who, pfn, page_to_pfn(page)); in expect_pfn_sg()
63 __func__, who, npages * PAGE_SIZE, sg->length); in expect_pfn_sg()
67 if (igt_timeout(timeout, "%s timed out\n", who)) in expect_pfn_sg()
74 __func__, who, pt->end, pfn); in expect_pfn_sg()
82 const char *who, in expect_pfn_sg_page_iter() argument
94 __func__, who, pfn, page_to_pfn(page)); in expect_pfn_sg_page_iter()
98 if (igt_timeout(timeout, "%s timed out\n", who)) in expect_pfn_sg_page_iter()
105 __func__, who, pt->end, pfn); in expect_pfn_sg_page_iter()
113 const char *who, in expect_pfn_sgtiter() argument
[all …]
|
| /kernel/linux/linux-6.6/Documentation/process/ |
| D | 1.Intro.rst | 64 those products attractive to Linux users. Embedded systems vendors, who
67 other software vendors who base their products on Linux have a clear
92 experience behind it. A developer who does not understand the kernel
93 community's ways (or, worse, who tries to flout or circumvent them) will
95 being helpful to those who are trying to learn, has little time for those
96 who will not listen or who do not care about the development process.
98 It is hoped that those who read this document will be able to avoid that
101 community is always in need of developers who will help to make the kernel
102 better; the following text should help you - or those who work for you -
115 Amanda McPherson, who saw the value of this effort and made it all happen.
[all …]
|
| D | 3.Early-stage.rst | 63 - Who are the users affected by this problem? Which use cases should the
125 Who do you talk to?
139 MAINTAINERS file may, in fact, not be the person who is actually acting in
140 that role currently. So, when there is doubt about who to contact, a
141 useful trick is to use git (and "git log" in particular) to see who is
142 currently active within the subsystem of interest. Look at who is writing
143 patches, and who, if anybody, is attaching Signed-off-by lines to those
144 patches. Those are the people who will be best placed to help with a new
156 command line, it will list the maintainers who should probably receive
161 developers who have no real interest in the code you are modifying.
|
| D | 5.Posting.rst | 30 patches which are known to be half-baked, but those who do will come in
110 users who are engaging in the noble work of tracking down problems.
144 enough for a reader who sees it with no other context to figure out the
165 These include subsystem maintainers and reviewers who need to decide
169 chasing, users who want to know how the kernel has changed, and more. A
183 general, the more you can put yourself into the shoes of everybody who will
230 Another kind of tag is used to document who was involved in the development of
261 - Reported-by: names a user who reported a problem which is fixed by this
263 people who test our code and let us know when things do not work
305 When mailing patches, it is important to send copies to anybody who might
[all …]
|
| D | management-style.rst | 7 on who you ask) management style for the linux kernel. It's meant to
18 lead persons, not the people who do traditional management inside
111 This preemptive admission of incompetence might also make the people who
176 trust somebody who is so clearly hiding their true character.
196 Suck up to them, because they are the people who will make your job
225 person who lost their whole 36GB porn-collection because of your
229 Then make the developer who really screwed up (if you can find them) know
232 importantly, they're also likely the person who can fix it. Because, let's
237 glory, because you're the one who gets to say "I screwed up". And if
265 without making it painful to the recipient, who just thinks you're being
|
| D | embargoed-hardware-issues.rst | 35 is a private list of security officers who will help you to coordinate a
47 vendor, we welcome contact from researchers or individuals who have
98 The hardware security team identifies the developers (domain experts) who
138 developers (domain experts) who should be informed initially about the
152 entities who have already been, or should be, informed about the issue.
158 - The disclosed entities can be contacted to name experts who should
246 organizations, who can answer questions about or provide guidance on the
303 Subscription is handled by the response teams. Disclosed parties who want
|
| D | 2.Process.rst | 59 allowed, but such occasions are rare; developers who try to merge new
212 There is exactly one person who can merge patches into the mainline kernel
223 who has overall responsibility for the code within that subsystem. These
225 of the kernel they manage; they are the ones who will (usually) accept a
365 Among the kernel developers who do not use git, the most popular choice is
391 represent a potential hazard to developers, who risk getting buried under a
408 development community comes together as a whole; developers who avoid this
420 without changing the email subject line) and the people who are
434 questions. Some developers can get impatient with people who clearly
447 beginning developers to go wrong. Somebody who asks a networking-related
[all …]
|
| /kernel/linux/linux-5.10/Documentation/process/ |
| D | 1.Intro.rst | 64 those products attractive to Linux users. Embedded systems vendors, who
67 other software vendors who base their products on Linux have a clear
92 experience behind it. A developer who does not understand the kernel
93 community's ways (or, worse, who tries to flout or circumvent them) will
95 being helpful to those who are trying to learn, has little time for those
96 who will not listen or who do not care about the development process.
98 It is hoped that those who read this document will be able to avoid that
101 community is always in need of developers who will help to make the kernel
102 better; the following text should help you - or those who work for you -
115 Amanda McPherson, who saw the value of this effort and made it all happen.
[all …]
|
| D | 5.Posting.rst | 31 patches which are known to be half-baked, but those who do will come in
111 users who are engaging in the noble work of tracking down problems.
145 enough for a reader who sees it with no other context to figure out the
166 These include subsystem maintainers and reviewers who need to decide
170 chasing, users who want to know how the kernel has changed, and more. A
184 general, the more you can put yourself into the shoes of everybody who will
237 - Reported-by: names a user who reported a problem which is fixed by this
239 people who test our code and let us know when things do not work
276 When mailing patches, it is important to send copies to anybody who might
285 - Other developers who have been working in the same area - especially
[all …]
|
| D | 3.Early-stage.rst | 63 - Who are the users affected by this problem? Which use cases should the
125 Who do you talk to?
139 MAINTAINERS file may, in fact, not be the person who is actually acting in
140 that role currently. So, when there is doubt about who to contact, a
141 useful trick is to use git (and "git log" in particular) to see who is
142 currently active within the subsystem of interest. Look at who is writing
143 patches, and who, if anybody, is attaching Signed-off-by lines to those
144 patches. Those are the people who will be best placed to help with a new
156 command line, it will list the maintainers who should probably receive
160 who have no real interest in the code you are modifying.
|
| D | management-style.rst | 7 on who you ask) management style for the linux kernel. It's meant to
18 lead persons, not the people who do traditional management inside
111 This preemptive admission of incompetence might also make the people who
176 trust somebody who is so clearly hiding their true character.
196 Suck up to them, because they are the people who will make your job
225 person who lost their whole 36GB porn-collection because of your
229 Then make the developer who really screwed up (if you can find them) know
232 importantly, they're also likely the person who can fix it. Because, let's
237 glory, because you're the one who gets to say "I screwed up". And if
265 without making it painful to the recipient, who just thinks you're being
|
| D | embargoed-hardware-issues.rst | 35 is a private list of security officers who will help you to coordinate an
47 vendor, we welcome contact from researchers or individuals who have
98 The hardware security team identifies the developers (domain experts) who
138 developers (domain experts) who should be informed initially about the
152 entities who have already been, or should be, informed about the issue.
158 - The disclosed entities can be contacted to name experts who should
241 organizations, who can answer questions about or provide guidance on the
295 Subscription is handled by the response teams. Disclosed parties who want
|
| D | 2.Process.rst | 59 allowed, but such occasions are rare; developers who try to merge new
219 There is exactly one person who can merge patches into the mainline kernel
230 who has overall responsibility for the code within that subsystem. These
232 of the kernel they manage; they are the ones who will (usually) accept a
372 Among the kernel developers who do not use git, the most popular choice is
398 represent a potential hazard to developers, who risk getting buried under a
415 development community comes together as a whole; developers who avoid this
427 without changing the email subject line) and the people who are
441 questions. Some developers can get impatient with people who clearly
453 beginning developers to go wrong. Somebody who asks a networking-related
[all …]
|
| /kernel/linux/linux-6.6/Documentation/filesystems/ |
| D | xfs-maintainer-entry-profile.rst | 31 - **Outside Contributor**: Anyone who sends a patch but is not involved
33 These folks are usually people who work on other filesystems or
36 - **Developer**: Someone who is familiar with the XFS codebase enough to
42 - **Senior Developer**: A developer who is very familiar with at least
51 - **Reviewer**: Someone (most likely also a developer) who reads code
71 - **Bug Triager**: Someone who examines incoming bug reports in just
95 - **LTS Maintainer**: Someone who backports and tests bug fixes from
138 * **Who** will benefit from this solution, and **where** will they
|
| /kernel/linux/linux-5.10/arch/s390/kvm/ |
| D | trace-s390.h | 126 TP_PROTO(__u64 type, __u32 parm, __u64 parm64, int who),
127 TP_ARGS(type, parm, parm64, who),
133 __field(int, who)
140 __entry->who = who;
144 (__entry->who == 1) ? " (from kernel)" :
145 (__entry->who == 2) ? " (from user)" : "",
|
| /kernel/linux/linux-6.6/arch/s390/kvm/ |
| D | trace-s390.h | 126 TP_PROTO(__u64 type, __u32 parm, __u64 parm64, int who),
127 TP_ARGS(type, parm, parm64, who),
133 __field(int, who)
140 __entry->who = who;
144 (__entry->who == 1) ? " (from kernel)" :
145 (__entry->who == 2) ? " (from user)" : "",
|
| /kernel/linux/linux-5.10/Documentation/vm/ |
| D | page_owner.rst | 4 page owner: Tracking about who allocated each page
10 page owner is for the tracking about who allocated each page.
18 using it for analyzing who allocate each page is rather complex. We need
88 See the result about who allocated each page
|
| /kernel/linux/linux-5.10/Documentation/block/ |
| D | ioprio.rst | 90 static inline int ioprio_set(int which, int who, int ioprio)
92 return syscall(__NR_ioprio_set, which, who, ioprio);
95 static inline int ioprio_get(int which, int who)
97 return syscall(__NR_ioprio_get, which, who);
|
| /kernel/linux/linux-6.6/Documentation/block/ |
| D | ioprio.rst | 90 static inline int ioprio_set(int which, int who, int ioprio)
92 return syscall(__NR_ioprio_set, which, who, ioprio);
95 static inline int ioprio_get(int which, int who)
97 return syscall(__NR_ioprio_get, which, who);
|
| /kernel/linux/linux-6.6/tools/perf/pmu-events/arch/x86/sapphirerapids/ |
| D | frontend.json | 34 "BriefDescription": "Retired Instructions who experienced DSB miss.",
45 "BriefDescription": "Retired Instructions who experienced a critical DSB miss.",
56 "BriefDescription": "Retired Instructions who experienced iTLB true miss.",
67 "BriefDescription": "Retired Instructions who experienced Instruction L1 Cache true miss.",
73 …"PublicDescription": "Counts retired Instructions who experienced Instruction L1 Cache true miss.",
78 "BriefDescription": "Retired Instructions who experienced Instruction L2 Cache true miss.",
84 …"PublicDescription": "Counts retired Instructions who experienced Instruction L2 Cache true miss.",
220 "BriefDescription": "Retired Instructions who experienced STLB (2nd level TLB) true miss.",
|
| /kernel/linux/linux-5.10/Documentation/scsi/ |
| D | FlashPoint.rst | 93 caused grief for many people who inadvertently purchased a system expecting
100 made available, and that Linux users who mistakenly ordered systems with
104 assist the people who initially purchased a FlashPoint for a supported
105 operating system and then later decided to run Linux, or those who had
125 are people at BusLogic who would rather not release the details of the
|
| /kernel/linux/linux-6.6/Documentation/scsi/ |
| D | FlashPoint.rst | 93 caused grief for many people who inadvertently purchased a system expecting
100 made available, and that Linux users who mistakenly ordered systems with
104 assist the people who initially purchased a FlashPoint for a supported
105 operating system and then later decided to run Linux, or those who had
125 are people at BusLogic who would rather not release the details of the
|