[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology


Thread archived.
You cannot reply anymore.


[Advertise on 4chan]


File: 1740572551810801.jpg (49 KB, 554x554)
49 KB
49 KB JPG
previous: >>108301681

#define __NR_getdents            78
#define __NR_getdents64 217

https://man7.org/linux/man-pages/man2/getdents.2.html
https://man7.org/linux/man-pages/man3/readdir.3.html

tl;dr:
retrieve information about entries in a directory

honestly what the fuck even is this syscall? first of all, let's take a peek at the manpage
> These are not the interfaces you are interested in.
thank you, obi-wan. very cool
and what the fuuuuuck is this api? you provide it a buffer of length count (but in the non-64 one, you have to cast to either
struct linux_dirent *
(which you'd have to define yourself, since it isn't included in any standard headers), or void *)
and look at this struct???
struct linux_dirent {
unsigned long d_ino; /* Inode number */
unsigned long d_off; /* Not an offset; see below */
unsigned short d_reclen; /* Length of this linux_dirent */
char d_name[]; /* Filename (null-terminated) */
/* length is actually */
/* (d_reclen - 2 - offsetof(struct linux_dirent, d_name)) */
/*
char pad; // Zero padding byte
char d_type; // File type (only since Linux 2.6.4);
// offset is (d_reclen - 1)
*/
}

genuinely i have no idea what these zany fucks were thinking with some of these.
you can also see an unhinged ternary chain in the example program, since C for some reason refuses to implement switch assignments. that's one of my biggest gripes with the language
anyway, yeah, this one is icky. pic related is how i feel looking at some of these syscalls that were clearly not ever meant to actually see the light of day

relevant resources:
man man

man syscalls

https://man7.org/linux/man-pages/
https://linux.die.net/man/
https://elixir.bootlin.com/linux/
https://elixir.bootlin.com/musl/
https://elixir.bootlin.com/glibc/
>>
>>108310106
i just know you have nice perky tits.
>>
So, am I getting this right? This is to no use to userland programs and all it does is to be a helper function to the kernel?
>>
>>108310122
this is not how you talk to women, anon!
>>108310126
no, it's useful to userspace. it's just saying you probably ought to use a libc wrapper, since the kernel API is psychotic
>>
And the best part is that you still want to use getdents over readdir for the same reason you want to use NtQueryDirectoryFileEx over FindFirstFileExW:
>if you want to avoid mode switches and kernel locks you want to read as much data in one call as possible
>which requires memory
>which requires a memory allocation
>probably a hidden, an internal one
>and which you cannot reuse safely after use because muh contract

>meanwhile with getdents/NtQueryDirectoryFileEx you provide the memory directly
>and get to decide when and how to reuse it, if
>>
File: memcpy.png (50 KB, 1630x720)
50 KB
50 KB PNG
>>108310300
Actually correction, now that I think about it:
>you want to read as much data in one call as possible
That's ... not always quite true actually because kernels *love* to copy stuff around. Problem with copies are that, over a certain threshold (depends on the machine) you start evicting data you previously copied from your cache, meaning it would've been better if you had never put it in the cache in the first place. I have actually seen *humongous* speedups - in the area of *several orders of magnitude* - by actively *limiting* the amount of data the kernel is allowed to write in one go.

>but you still don't want readdir/FindFirstFileExW to make those decisions
>because they have no idea what they're doing either
>>
>>108310106
beautiful syscall.
>>
>>108310106
I remember that cartoon. I don't remember what it was, but I remember it wasn't bad.

Keep up the good work on those syscalls, fren. Don't mind me, this is a just a bump.
>>
>>108310374
Are those italic | or normal / ? What happens if you make an italicized table and use \ on the verticals? So many questions.
>>
>>108312702
Mate.

Seriously?

Seriously.
>>
>>108310106
I actually found out something really cursed about this syscall the other day. The manpage says it returns EINVAL if your buffer is too small, but it doesn't say it'll also return EINVAL in other, extremely obscure cases too and there's no way to tell them apart. The one I found is trying to do getdents64 on
/proc/<pid>/net
of a zombie process. Not sure if this is a bug in the kernel or if they just didn't think it important enough to put in the manpage.
If your code naively doubles the buffer on EINVAL and hits one of those dirs, it'll double until it runs out of memory and that's no good.
>>108310300
Yep, if you're trying to traverse the filesystem as fast as possible, getdents64 is how you do it on Linux. NtQueryDirectoryFileEx is way better though since you can get more than just the filetype and avoid statx calls if you need more detail.
>>
>>108312742
Yes, I'm serious. I'm pretty sure some of them are /, but it wouldn't make sense to have + in the horizontal lines above them, but there is! I'm confused.
>>
>>108312936
>NtQueryDirectoryFileEx is way better though
In terms of specifying the output format, maybe. But it was NT that exhibited the "the more free memory you provide the slower the syscall becomes" behavior. Not necessarily on NtQueryDirectoryFileEx - haven't tested that one yet - but it's definitely a thing.

>if I had to take a guess: the kernel allocated its own static memory block for the output, and zeroed it all out
>then wrote the output into its kernel buffer
>then copied the kernel buffer into the userspace buffer
>>
>>108313006
... just look into the VMOVDQX column.
>33 / 1
>66 / 2
>131 / 4
Definitive slashes. Now compare them to the pipes right next to them.
>>
File: file.png (3 KB, 82x129)
3 KB
3 KB PNG
>>108313020
Exactly! But does it make sense to have the pluses?

+---+---+
| / |
| / |
| / |
+---+---+


And still, what would the table look like with italic \ ? Just did some testing with inspect element, and looks better than I imagined, ngl.
>>
>>108313073
Just noticed my font doesn't italicize the pipes or pluses, so the table would still work with them.
>>
>>108312692
kaiju no. 8 (she is LITERALLY me)
>>108313006
it's pipes in a font that angles them
>>108312936
you should always sanity check loops like that, but yeah, that's really interesting
>>
bampu
>>
>>108313088
>you should always sanity check loops like that, but yeah, that's really interesting
I indeed learned that lesson. Glibc caps the maximum getdents64 buffer at 1 megabyte, so ended up allocating a buffer that big and threw out the resizing.
>>
one final bampu
>>
>>108313852
lol that feels like such an arbitrary cap
>>
>>108316736
What else can you really do though? In theory, no file should have a name greater than NAME_MAX bytes (256), so one megabyte is more than enough.



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.