-
Notifications
You must be signed in to change notification settings - Fork 8.2k
[PoC] lib: os: fdtable: Add syscalls for POSIX read/write/close/ioctl operations #25443
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Changes from all commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
c2bc3fd
lib: os: fdtable: Add syscalls for POSIX read/write/close operations
pfalcon 45f485f
lib: os: fdtable: Add syscall for POSIX ioctl operation
pfalcon e9944b9
tests: net: socket: tcp: Add testcase for write()/read().
pfalcon 3e15b38
lib: os: fdtable: Make ioctl method accept array of args instead of v…
pfalcon 58a19b8
net: sockets: Pass explicit # of arguments to z_fdtable_call_ioctl()
pfalcon File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's important here that the VA argument to ioctl can only ever be a single argument. Older specs took advantage of looser typing rules in C, and this is only really a way of allowing various pointer types to be passed to this function. It is quite reasonable to make this a single pointer argument.
It might also be helpful to look at the Linux implementation (or BSD), which uses various bits of the request to determine exactly how much data is expected in this argument, and even which direction data flows.
We definitely shouldn't be passing n_args/args through the systemcall. A single pointer is fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't try to "lift" implementation from other systems, together with associated copyright and licensing issues. I'm definitely aware of Linux maintainers' dislike for ioctl(), and understand why - just as ioctl() was a nice, clean, clever idea in the original Unix, just as it is unnice and unclear with all the "modern systems".
Someone will need to elaborate in detail on those points.
It's otherwise pretty clear that syscall validation rules will need to be extended for the ioctl() case. That's why I'm questioning @andrewboie for details on both (intended) design and (actual) implementation of them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My point here is that that "..." in the ioctl call is a modern artifact, and that ioctl calls should always have exactly one pointer argument. The "..." is needed because it isn't really possible to get it right as some kind of generic pointer. But, there should never be an instance of 2, or more arguments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@d3zd3z:
Can you elaborate on this a bit more? ("modern artifact")
Regardless of the possible answer to the above question, the reason why ioctl() was brought in here is to exactly allow passing multiple arguments. ioctl() is used both for userspace->kernel and kernel->kernel communication. userspace->kernel subset if really lean so far - as you may imagine, nobody wants to add the complete Linux mess in there. The usecase behind supporting userspace ioctl() is, well, application portability POSIX-ish systems -> Zephyr. I.e. as people will port more apps, they will find ioctl() request types needed, and can implement then, then maybe even contribute upstream (maybe keep out of tree in forks). The ideas is, again, to provide a general interface which would work for any request type (and its params).
Now, kernel->kernel ioctl is used to generically implement some processing between implementations of the same interface (file descriptor) in kernel. E.g., there's a generic implementation of poll(), which uses kernel-ioctl to implement processing sub-steps polymorphically across different file descriptor objects. And ioctl is used there to save on the code size. The more ironically that protected userspace now adds much more overhead to it (i.e. no-split: code size savings comparing to "middle line", split kernel/userspace - code size bloat).
You're looking exactly at the support APIs for kernel->kernel ioctls.
All this may be not ideal, but nothing is ideal here, I look at support infra/docs for syscalls, and find it not ideal. This patch has a specific goal - set framework to allow all this work with kernel/userspace split. It doesn't do any further revolutions, where varargs calls were used before for kernel-kernel ioctl, there they're used now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@d3zd3z indeed, this is obvious from the documentation:
ioctl() never been something you can send lots of arguments, and this is not ambiguous:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, as explained above, ->ioctl() is used to implement both userspace->kernel (let's call it just "ioctl") and kernel->kernel (let's call it "kioctl") functions. While userspace ioctl() accepts only one param, it's a matter of fact that kioctl() accepts of multiple. I explained why this was done - to save on the size of vtable pointers and function prologues/epilogues. Good or bad, that's how it is. If someone wants to change that, go ahead and submit a proposal and prototype refactor.
This patch is concerned with different matter - allowing ioctl() to work across userspace/kernel, while preserving how it works currently for kernel->kernel. (I agree that if userspace # of arg is fixed, the patch can be simplified. If there's something to say, then it's that I shouldn't have started on that while being assigned to other big and deep tasks, and multitasking among them, forgetting and overlooking such points.)