sys/linux: fix errors in dev_loop.txt

[ZHYfeng]

No description provided.

[codecov]

Codecov Report

Merging #3121 (14af96a) into master (2df221f) will increase coverage by 0.0%.
The diff coverage is n/a.

Impacted Files	Coverage Δ
prog/checksum.go	74.1% <0.0%> (-13.6%)	⬇️
dashboard/app/main.go	71.4% <0.0%> (+0.7%)	⬆️
prog/any.go	84.5% <0.0%> (+1.0%)	⬆️
prog/mutation.go	88.8% <0.0%> (+1.0%)	⬆️
prog/hints.go	92.5% <0.0%> (+1.9%)	⬆️

[ZHYfeng]

Sorry that I try to have two merge requests because they are different things but Github directly adds the second commit.
What can I do about this?

[dvyukov]

Sorry that I try to have two merge requests because they are different things but Github directly adds the second commit. What can I do about this?

We can merge 2 unrelated in a single PR as well as long as both commits are good.
But it's possible to send them as separate PRs as well. You need to have each commit in a separate branch in your fork. And then send PR from each branch.

[ZHYfeng]

Thanks a lot. I have fixed them.

[dvyukov]

It does not seem to return a loop fd.
It returns i:
https://elixir.bootlin.com/linux/v5.18-rc5/source/drivers/block/loop.c#L2073
which is assigned here:
https://elixir.bootlin.com/linux/v5.18-rc5/source/drivers/block/loop.c#L1997
which comes from idr_alloc for loop indices:
https://elixir.bootlin.com/linux/v5.18-rc5/source/drivers/block/loop.c#L1988
So it seems to be a loop index rather than a file descriptor.
If you agree, please revert this change.

[ZHYfeng]

I agree. But I find another question.
I think the return value should be "fd_loop_num", which is the same as "ioctl$LOOP_CTL_GET_FREE()":
https://elixir.bootlin.com/linux/v5.18-rc5/source/drivers/block/loop.c#L2186
https://elixir.bootlin.com/linux/v5.18-rc5/source/drivers/block/loop.c#L2175
However, I do not find how the number are decided in "resource fd_loop_num[intptr]: 0, 1, 2, 10, 11, 12".
Not sure whether should we keep those numbers.

[dvyukov]

I think the return value should be "fd_loop_num"

You are right. Looks good now.

However, I do not find how the number are decided in "resource fd_loop_num[intptr]: 0, 1, 2, 10, 11, 12".
Not sure whether should we keep those numbers.

I don't remember now as well.
Probably the intention was to have some existing and non-existing loop numbers, or some that can be auto-allocated and some that are large enough to not be auto-allocated in most cases.
If we change it, I am not sure what would be a better set...

[ZHYfeng]

Thanks for the reasons.
By the way, would it be possible to accept the syscall descriptions which is just better than nothing?
We generate a lot of syscall descriptions and I am working on automatically giving them some meaningful names as you suggested.
However, they just have basic things (e.g., the file name of open(), cmd value and argument type of ioctl()) without the additional things (e.g., values of some fileds llike "const[0, int64]" or fd_loop_num).

[dvyukov]

Oh, interesting. We wanted that for a long time (#590). Can you upload them as a PR, or as a commit in your fork? Then it will be easier to asses if/how they can be merged and how they can cohabit with existing descriptions.

[ZHYfeng]

Thanks, and I learn a lot from (#590).

I will upload them as a PR directly without any human modifications so that we can know what other automated steps are needed.