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<mailto: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.