This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: safety paper - please send feedback!


Here are my quick comments

In G1 you mentioned " A "safety" mode would impose additional safety constraints" I am not sure which ones are you referring to in the above sentence.

I am not sure if G2 is a concern if the language implements G3. I am o.k for G3 provided we have constructs like iterator in the language that allow us to GENERATE loops even if user is not allowed to SPECIFY loops directly. I don't like the Dtrace approach of not allowing loops at all in their language.

G4: I am not sure it is worth generating runtime checks to prevent levels of recursion beyond so many levels, instead it might be easy to have code that prevents stack overrun's using a guard mechanism. Since this is a simple scripting language without complications of the complete "C" kind of language i think we might be able to prevent
recursive calls using static code analysis, if we choose not to allow recursion.


G5: I am not convinced yet why we should not allow simple procedures in our language definition. How we generate the code for these procedures is entirely up to the translator. I am thinking we will still allow our generator to generate procedures, right.

G6: I think the static portal way of specifying what calls are allowed from systemTAP scripts is a major maintenance overhead with kernel code changing at rapid pace. A simpler approach would be if you are running in safe mode only function calls allowed to make are the exported tapset interfaces, which is what Dtrace does. In Guru mode you are on your own. I would think it is not that difficult to implement a system where a script
written for guru mode will not be allowed in safe mode.


G9: I am not sure how easy to implement this. We probably should understand what is the real goal of G9 and see what alternative ways might be employed to achieve the same.

G10: The only restriction should be it should be same architecture and running in the required Guru or Safe mode otherwise any generated module should be allowed to run including backward compatibility or when not possible fail safely. This is very important for the success of systemtap.


This is what i have so far, rest we can discuss in the call or i will follow up in my next review mail.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]