Hi Corey,

If there are cases where an error is ambiguous then extending the errors is definitely desirable. There are however a few things to consider
* If consistency is the only goal and the kernel is exporting enough information, then you should consider writing wrappers / abstractions in user space
* Not all errors have an argument that they can refer to. For example, if you get seL4_RevokeFirst when performing a page unmap because there are still other capabilities, what argument do you attribute that to?
* Alternatively some errors could be related to multiple arguments. Consider getting seL4_DeleteFirst when performing a CNode copy, do you consider it the fault of the index (argument 0) or the bits to decode (argument 1) that the slot was not empty?
In both of those examples the error unambiguously indicates what went wrong, despite there being no clear argument to attribute it to.

That said I would not be surprised if there are cases of ambiguity.

Adrian

On Fri 01-Jan-2016 10:02 PM, Corey Richardson wrote:
For consistency, it seems like it'd beneficial if:

    seL4_RangeError
    seL4_AlignmentError
    seL4_DeleteFirst
    seL4_FailedLookup
    seL4_RevokeFirst

included an indication of which argument the error applies to. For some of
these errors, not every call has a unique argument which can cause the erorr.

This seems like a relatively straightforward change for me to get acquainted
with the full process of modifying and re-verifying the kernel. Are there
tradeoffs hidden here that would make this undesirable?

--
cmr
+16032392210
http://octayn.net/



_______________________________________________
Devel mailing list
Devel@sel4.systems
https://sel4.systems/lists/listinfo/devel



The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.