camkes-tool
camkes-tool copied to clipboard
seL4
libsel4camkes: Add markdown documentation
This commit adds documentation written in markdown that explains each part of the libsel4camkes library in more depth.
This appears to be draft documentation started by @kent-mcleod as part of developing the seL4 Device Driver Framework. It looks to be incomplete.
This might assume the API changes from https://github.com/seL4/camkes-tool/pull/84
Incomplete is a lot better than completely absent, so I'm all for that. Let me know if you need help with converting the license headers to SPDX.
Let me know if you need help with converting the license headers to SPDX.
Thanks, seems I didn't push the changes I had already made for that.
@abrandnewusername Are you working on this or did this just get assigned to by accident? (It's fine if not, then somebody can take it over)
@abrandnewusername Are you working on this or did this just get assigned to by accident? (It's fine if not, then somebody can take it over)
Yes, I'm working on this, but I'm currently distracted by other works. I'm happy if anyone wants to contribute to this documentation.
"Gerwin" == Gerwin Klein @.***> writes:
+When sending data over to the device side, it is preferred to use to these two functions.
Gerwin> I don't think we have a decided value for Gerwin> markdown/documentation wrap. We have 120 for C and 100 for Gerwin> Python, so 72 sounds a bit small, but smaller than code wrap Gerwin> is justified for long text, I think.
I would prefer 72-75 for all of them.
Peter C
Gerwin> I don't think we have a decided value for Gerwin> markdown/documentation wrap. We have 120 for C and 100 for Gerwin> Python, so 72 sounds a bit small, but smaller than code wrap Gerwin> is justified for long text, I think.
I would prefer 72-75 for all of them. Peter C
You made my fingers twitch :-) I don't see any reason to change the C or python standards (they do have good reasons), but we can have a discussion about longer text where we don't have any specific rules yet. Should not be on this PR, though. I might start something on discourse later.
Is anything happening with this PR? I'd like it to be completed and merged ...
I have rebased the PR and addressed the review feedback as far as I could (so far in a separate commit, to be squashed before merging).
There are still a small number of open questions/requests. I would relegate these to an issue that people can keep working on. While maybe not complete, merging this PR in the current state is much better than what is there so far, and it doesn't look like anyone has had time to fully complete it in the past 3 years.
@yyshen and @wom-bat are you happy for this to be merged?
Ping: @yyshen and @wom-bat are you happy for this to be merged? (You don't have to do a full re-review -- if you're happy for the open questions to be resolved as issues later, we can merge).