I note that the latest (July 2005) Ottawa Linux Symposium materials contain a paper entitled "Locating System Problems Using Dynamic Instrumentation" that describes an effort named "SystemTap" (http://sourceware.org/systemtap/). The paper is contained in the proceedings of the symposium and is also on the Systemtap website. Based on a quick scan this seems to have a very limited subset of what Dtrace offers. It would seem that the Linux vendors are feeling the pressure and that the mantra "System Tap will do it" will be heard far and wide in the near future whenever DTrace is mentioned. In classic Linux tradition, previous work is denigrated by casting it under the rubric of "earlier" (implied to be less capable than the current project). I remain unconvinced by the assertions of safety. The "ability to write arbitrary locations in kernel memory and the ability to invoke aribtrary kernel subroutines" seems a disaster waiting to happen even if it is restricted to "guru mode". Comments from the DTrace community? Jim Litchfield This message posted from opensolaris.org
Hey Jim, On Sat, Jul 30, 2005 at 11:12:27PM -0700, James Litchfield wrote:> I note that the latest (July 2005) Ottawa Linux Symposium materials contain a > paper entitled "Locating System Problems Using Dynamic Instrumentation" that > describes an effort named "SystemTap" (http://sourceware.org/systemtap/). > The paper is contained in the proceedings of the symposium and is also on > the Systemtap website. > > Based on a quick scan this seems to have a very limited subset of what Dtrace > offers. It would seem that the Linux vendors are feeling the pressure and that > the mantra "System Tap will do it" will be heard far and wide in the near future > whenever DTrace is mentioned.Your quick scan is correct -- though I hope that your prediction is not...> In classic Linux tradition, previous work is denigrated by casting it under > the rubric of "earlier" (implied to be less capable than the current project). > > I remain unconvinced by the assertions of safety. The "ability to write arbitrary > locations in kernel memory and the ability to invoke aribtrary kernel subroutines" > seems a disaster waiting to happen even if it is restricted to "guru mode".SystemTap''s problems with safety run even deeper than the presence of the ill-conceived "guru mode"; they have made some fundamentally incorrect architectural decisions when it comes to safety. In particular, they execute user-specified code natively (or rather, they will -- SystemTap hasn''t yet been prototyped to the degree implied by the OLS paper). Executing user-specified code natively is simply the wrong decision for safety, as I described at length here: http://blogs.sun.com/roller/page/bmc?entry=dtrace_safety And this is just the very beginning of the differences between SystemTap and DTrace; SystemTap is a "very limited subset" indeed... - Bryan -------------------------------------------------------------------------- Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc
I read through both dtrace and systemtap white papers and couldn''t really justify your statement about systemtap being a very limited subset of dtrace. As a matter of fact the language used by DTrace for scripting feels a lot limited - no procedures, no loops etc. There also seemed to be a good emphasis on safety in the STP whitepaper. May be what you are saying is right, but I just don''t understand it - STP looks equally interesting to me as DTrace. NO flamewars please, only cold facts if any one wants to comment. This message posted from opensolaris.org
On Fri, Sep 02, 2005 at 09:49:07PM -0700, S Destika wrote:> I read through both dtrace and systemtap white papers and couldn''t really justify your statement about systemtap being a very limited subset of dtrace. As a matter of fact the language used by DTrace for scripting feels a lot limited - no procedures, no loops etc.Those limitations arise from the safety constraint -- the most fundamental constraint in DTrace. If you''re wondering why it''s so important to us, read the perspective of one of the first DTrace users: http://milek.blogspot.com/2005/07/safety-in-dtrace.html> There also seemed to be a good emphasis on safety in the STP whitepaper.DTrace and SystemTap have very different notions of safety. For details on the DTrace idea of safety see: http://blogs.sun.com/roller/page/bmc?entry=dtrace_safety In particular, we believe that you can only provide safety through a virtual machine; SystemTap allows user-specified code to execute natively. We believe that there should be no way -- none whatsoever -- for arbitrary state inconsistencies to be introduced into the system. That is, we believe that notions like the "embedded C" found in SystemTap fundamentally compromise the safety of the system.> May be what you are saying is right, but I just don''t understand it - STP looks equally interesting to me as DTrace. > > NO flamewars please, only cold facts if any one wants to comment.Flameware aren''t necessary; you needn''t agree with us. In particular, you may find that our ideas of safety are too stringent for your liking. And that''s fine -- while production systems are our focus (and system integrity therefore our absolute constraint), we certainly understand if others have a different focus and therefore different priorities. - Bryan -------------------------------------------------------------------------- Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc
> > May be what you are saying is right, but I just don''t understand it - STP looks equally interesting to me as DTrace. > > > > NO flamewars please, only cold facts if any one wants to comment. > > Flameware aren''t necessary; you needn''t agree with us.I meant "flamewars", of course -- not "flameware." (That said, that might be an interesting new moniker for software that violated the integrity of the system...) - Bryan -------------------------------------------------------------------------- Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc
<i> ... in particular, we believe that you can only provide safety through a virtual machine; SystemTap allows user-specified code to execute natively. We believe that there should be no way -- none whatsoever -- for arbitrary state inconsistencies to be introduced into the system. That is, we believe that notions like the "embedded C" found in SystemTap fundamentally compromise the safety of the system. </i> <br> <br> But isn''t that similar to DTrace - SystemTap uses a interpreted language which instead of being compiled to bytecode inside the kernel and then executed, is compiled into C code which the compiler converts to native code (kernel module) which executes directly on the machine. Seems like more of a not re-inventing the wheel case with all added benefits of security - the translator which translates the STP script language can do all safety checks and verifications before generating the C code. <br> <br> <i> I meant "flamewars", of course -- not "flameware." (That said, that might be an interesting new moniker for software that violated the integrity of the system...) </i> <br> <br> Wow! This thread was destined to have the word "Flameware"! Believe me I too mistyped flamewars as flameware (does the Sun keyboard also have S and E located nearby or you use a standard PC keyboard? :) ) in my previous post and unknowingly hit submit - but my wireless connection was dead by that time and I had to go back to edit the message and repost it! <br> <br> I just started playing with S11 build 20 - After trying previously to install S10 on three machines and failing I finally gave up and bought a copy of VMWare - That fortunately succeeded and I am playing with DTrace - Thanks for such a brilliant idea, it surely beats the crap out of anything currently available to do dynamic tracing. This message posted from opensolaris.org
On Sat, 3 Sep 2005, S Destika wrote:> <i> ... in particular, we believe that you can only provide safety through a > virtual machine; SystemTap allows user-specified code to execute natively. > We believe that there should be no way -- none whatsoever -- for arbitrary > state inconsistencies to be introduced into the system. That is, we > believe that notions like the "embedded C" found in SystemTap fundamentally > compromise the safety of the system. </i> > <br> <br>.... reformatted ...> But isn''t that similar to DTrace - SystemTap uses a interpreted language > which instead of being compiled to bytecode inside the kernel and then > executed, is compiled into C code which the compiler converts to native > code (kernel module) which executes directly on the machine. Seems like > more of a not re-inventing the wheel case with all added benefits of > security - the translator which translates the STP script language can do > all safety checks and verifications before generating the C code.You have not grasped the concept. If what you''ve saying is true, then it would be possible to have Perl (an intrepreter) never crash, because the Perl intrepreter would do "all safety checks and verifications before" running the code. Do you think you can modify Perl to be crash proof, regardless of whatever, faulty, code the developer threw at it? Do you think you could write a version of Python that was crash proof? Do you think you could write an STP intrepreter that was crash proof? Do you think you could write *any* intrepreter that was crash proof? If you think you can, then your future financial success is assured! The concept you''re missing is that if you''re running code in the kernel and it crashes, then it crashes the kernel! If you''re running code in a virtual machine and it crashes, it crashes the virtual machine!> <br> <br> > <i> I meant "flamewars", of course -- not "flameware." (That said, that > might be an interesting new moniker for software that violated the > integrity of the system...) </i> > <br> <br> > Wow! This thread was destined to have the word "Flameware"! Believe me I too mistyped flamewars as flameware (does the Sun keyboard also have S and E located nearby or you use a standard PC keyboard? :) ) in my previous post and unknowingly hit submit - but my wireless connection was dead by that time and I had to go back to edit the message and repost it! > <br> <br> > > I just started playing with S11 build 20 - After trying previously to install S10 on three machines and failing I finally gave up and bought a copy of VMWare - That fortunately succeeded and I am playing with DTrace - Thanks for such a brilliant idea, it surely beats the crap out of anything currently available to do dynamic tracing. > This message posted from opensolaris.org > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org >Al Hopper Logical Approach Inc, Plano, TX. al at logical-approach.com Voice: 972.379.2133 Fax: 972.379.2134 OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005
S Destika wrote:> But isn''t that similar to DTrace - SystemTap uses a interpreted language> which instead of being compiled to bytecode inside the kernel and then > executed, is compiled into C code which the compiler converts to native > code (kernel module) which executes directly on the machine. Seems like > more of a not re-inventing the wheel case with all added benefits of > security - the translator which translates the STP script language > can do all safety checks and verifications before generating the C code. There are two major benefits from the dtrace approach: - When you use looping constructs, no amount of code analytics can ensure that the code will ever complete. This is known as the halting problem. It doesn''t matter how thorough the translator for STP might be, it simply can''t solve this problem (no one can). In practical terms, this means that dtrace will never get caught in an infinite loop; with STP, that''s a very real possibility that will leave your kernel spinning . - If, for whatever reason, the D script does do something bad, this is caught in the virtual machine, and an error is safely passed back to dtrace. STP runs as real machine code; if it does something bad, it crashes the kernel. These constraints might seem tough, but they''re worth it; being able to guarantee stability and perform these traces on production machines is mind-blowingly powerful. -- Wez Furlong Senior Systems Engineer OmniTI. Inc, Tel: 410 872 4910 x 211
On Sat 03 Sep 2005 at 06:54AM, S Destika wrote:> > I just started playing with S11 build 20 - After trying previously to > install S10 on three machines and failing I finally gave up and bought > a copy of VMWare - That fortunately succeeded and I am playing with > DTrace - Thanks for such a brilliant idea, it surely beats the crap > out of anything currently available to do dynamic tracing.Slightly off-topic, but it would be helpful to know why the installs were failing. We''re certainly missing some drivers for some H/W, but it would help to know what is causing the most severe problems for people. -dp -- Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp
On my Compaq R3240US laptop - S10GA never proceeds after the "configuring devices..." message during the install. The keyboard is detected on some boots but on most boots it doesn''t detect the keyboard. Moreover I heard there is no PowerNOW! support in Solaris kernels so I would be stuck at 797Mhz even if the install completed - which sucks. On Dell Inspiron 5100 - It installs fine but after installing the third party B44 NIC driver it panics regularly - I sold this laptop recently. Without the NIC driver it works fine so no blame on Solaris - but it''s not exactly useful. On my home made crappy box with 128M RAM Grub B20 doesn''t boot complaining something like out of memory right after I press Enter on Grub prompt. But I am happy with VMware - I have load of memory so I can easily spare 512M for Solaris and it runs there (Albeit that I can''t see anything on the console while booting - it''s always blank but graphical boot works fine.) This message posted from opensolaris.org
On Sat 03 Sep 2005 at 02:09PM, S Destika wrote:> On my Compaq R3240US laptop - S10GA never proceeds after the > "configuring devices..." message during the install. The keyboard is > detected on some boots but on most boots it doesn''t detect the > keyboard.Hmm. Ok. It would be great if you could file a bug on that at http://bugs.opensolaris.org with as much detail as possible. Perhaps try also ''boot -v'' to get verbose boot messages. This might give us a clue about what is hanging. Alternatively, boot with kmdb, and then break in and do $c and note the stack trace. It''s also possible that New Boot has helped to fix this problem. You might see if a recent build (on CD or DVD) properly boots into the installer.> Moreover I heard there is no PowerNOW! support in Solaris > kernels so I would be stuck at 797Mhz even if the install completed - > which sucks.I believe you could use Casper''s experimental PowerNOW! stuff: http://blogs.sun.com/roller/page/casper?entry=first_installment> On Dell Inspiron 5100 - It installs fine but after installing the third party B44 NIC driver it panics regularly - I sold this laptop recently. Without the NIC driver it works fine so no blame on Solaris - but it''s not exactly useful.Too bad we don''t have the crash dumps; we might have been able to diagnose the problem. I take it that this is the bcme driver from BroadCom? It might have also been worthwhile to see if the bcf driver from Masayuki Murayama would help, although I''m not sure which specific Broadcom chip you might have had: http://homepage2.nifty.com/mrym3/taiyodo/eng/index.htm> On my home made crappy box with 128M RAM Grub B20 doesn''t boot complaining something like out of memory right after I press Enter on Grub prompt.Agreed; that''s not enough memory. -dp -- Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp
For the Broadcom NIC I believe I was using Masayuki-san''s bcf driver which was causing panics - nothing to do now since I sold that laptop. <br> <br> I am planning to try to boot B20 (latest express build) on the R3240 - let''s see if it boots. Thanks for the PowerNOW pointer, will try it if boot succeeds. <br> <br> 128M is not enough RAM to just boot the core Solaris kernel? That''s pretty bad I would say. All OS kernels (XP, FreeBSD, Linux) I have tried have booted with that much memory just fine. <br> <br> Can I ask why so much of memory is required by the Kernel? This message posted from opensolaris.org
S Destika wrote:> 128M is not enough RAM to just boot the core Solaris kernel?> That''s pretty bad I would say. All OS kernels (XP, FreeBSD, > Linux) I have tried have booted with that much memory just fine.> > Can I ask why so much of memory is required by the Kernel?It''s not really the kernel that requires so much ram; the current opensolaris boot process throws a pretty big ram disk into memory before attempting to mount the filesystems, so you need to have enough ram to hold it. --Wez.
S Destika
2005-Sep-04 14:25 UTC
[dtrace-discuss] Re: Re: Re: Re: Re: Comments on SystemTap?
Ok. So probably it''s just that some one filled up the RAMDISK with all sorts of unnecessary stuff - Linux too, uses RAMDISK and boots fine with 128M - So I will open up a bug @ bugs.opensolaris.org. This message posted from opensolaris.org
James C. McPherson
2005-Sep-04 23:17 UTC
[dtrace-discuss] Re: Re: Re: Re: Re: Comments on SystemTap?
S Destika wrote:> Ok. So probably it''s just that some one filled up the RAMDISK with > all sorts of unnecessary stuff - Linux too, uses RAMDISK and boots > fine with 128M - So I will open up a bug @ bugs.opensolaris.org.Hi Steve, the reason we have that 256mb hard limit is so that we can support newboot aka grub. Grub is actually quite memory hungry, which is unfortunate. OTOH using Grub allows us to do away with the hideous and much- complained about Device Configuration Assistant. It also gives us an extensible framework for adding new drivers in a very easy fashion, something which the DCA never allowed. You can file whatever bug or RFE you want about this, but I don''t think you''ll get much traction. The benefits of newboot/grub far outweigh the restrictions of a minimum of 256mb of ram. Now as to "all sorts of unnecessary stuff" -- what do you think we put in it? Have you looked? Remember that what you classify as unnecessary is quite probably _required_ for Solaris -- based on our OS design and customer feedback. James C. McPherson -- Pacrim PTS Engineer 828 Pacific Highway Gordon NSW Sun Microsystems Australia 2072
Stefan Parvu
2005-Sep-06 19:41 UTC
[dtrace-discuss] Re: Re: Re: Re: Comments on SystemTap?
OT: Any ideas if 256MB RAM is something which GRUB will requiere as well for the final version of S11 ? Or is it something at the moment needed to install the nv bits ? thanks, Stefan This message posted from opensolaris.org