Hi, I am trying to determine a fbt probe to trace packets as they flow into IP from the lower layers. ip_input() seemed to be a logical function as it is called directly and from ip_rput for streams. However, there does not seem to be a probe for this function in Sun''s S10 GA. I can see probe for ip_rput and for ip_tcp_input, etc. Was ip_input specifically left out for a reason? Any suggestions for alternate mechanisms? Thanks, Ashwani This message posted from opensolaris.org
On Thu, 15 Sep 2005, Ashwani Wason wrote:> Hi, >> I am trying to determine a fbt probe to trace packets as they flow into > IP from the lower layers. ip_input() seemed to be a logical function as > it is called directly and from ip_rput for streams. However, there does > not seem to be a probe for this function in Sun''s S10 GA. I can see > probe for ip_rput and for ip_tcp_input, etc. Was ip_input specifically > left out for a reason?Probably an oversight. I can see it in snv_22: % dtrace -n fbt::: -l | grep '' ip_input'' 29863 fbt ip ip_input_proc_set entry 29864 fbt ip ip_input_proc_set return 32047 fbt ip ip_input entry 32048 fbt ip ip_input return Bye, Dragan -- Dragan Cvetkovic, To be or not to be is true. G. Boole No it isn''t. L. E. J. Brouwer
On Thu, Sep 15, 2005 at 10:33:25AM -0700, Ashwani Wason wrote:> Hi, > > I am trying to determine a fbt probe to trace packets as they > flow into IP from the lower layers. ip_input() seemed to be a > logical function as it is called directly and from ip_rput for > streams. However, there does not seem to be a probe for this function > in Sun''s S10 GA. I can see probe for ip_rput and for ip_tcp_input, > etc. Was ip_input specifically left out for a reason?ip_input() doesn''t exist in S10; it was added as part of the "Nemo" project in snv_12. Unfortunately, I''m not an IP expert, so I don''t know what the equivalent S10 routine would be called; perhaps ''ip_rput''? Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development
Hi Dragan, Not an oversight: on *Solaris 10 GA from Sun* it is indeed missing on both amd64 and sparcv9: [amd64]> uname -a SunOS manu 5.10 Generic i86pc i386 i86pc [amd64]> dtrace -n fbt::: -l | grep '' ip_input'' 17971 fbt ip ip_input_proc_set entry 17972 fbt ip ip_input_proc_set return [sparcv9]> uname -a SunOS superposition 5.10 Generic_118822-17 sun4u sparc SUNW,Sun-Blade-100 [sparcv9]> dtrace -n fbt::: -l | grep '' ip_input'' 20807 fbt ip ip_input_proc_set entry 20808 fbt ip ip_input_proc_set return Thanks for checking, Ashwani This message posted from opensolaris.org
On Thu, 2005-09-15 at 13:33, Ashwani Wason wrote:> Was ip_input specifically left out for a reason?yes. ip_input, and the direct function call path into IP, didn''t exist in S10 GA -- it was introduced by the "Nemo"/"GLDv3", which landed in Nevada before the first public opensolaris snapshot. In S10 GA ip_rput would be your best bet. - Bill
Hi Jonathan,>From what I can read in ip.c, ip_rput() would be called by STREAMS lower layers as they push data through IP. "GLDv3" drivers can call ip_input() directly, which I assume is the work that the folks at Sun did on adding function-call based interface in the stack. Further, ip_rput() calls ip_input() after some basic processing. So ip_input() seems to be a logical function from which data would go into IP. In any case, thanks for verifying that it was added after S10 GA.Ashwani This message posted from opensolaris.org
On Thu, Sep 15, 2005 at 10:58:32AM -0700, Ashwani Wason wrote:> Hi Jonathan, > > From what I can read in ip.c, ip_rput() would be called by STREAMS > lower layers as they push data through IP. "GLDv3" drivers can call > ip_input() directly, which I assume is the work that the folks at Sun > did on adding function-call based interface in the stack. Further, > ip_rput() calls ip_input() after some basic processing. So ip_input() > seems to be a logical function from which data would go into IP. In > any case, thanks for verifying that it was added after S10 GA.That''s only true post-Nemo; so ip_rput should catch everything in Solaris 10. Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development
This conversation is a good illustration of two things: The fbt provider''s probes are Private for good reason -- kernel functions do not represent an interface of any sort of stability. Scripts that rely on particular function names or semantics can break from release to release or even in patches. We need a network provider -- and it ain''t going to be easy. Adam On Thu, Sep 15, 2005 at 11:10:14AM -0700, Jonathan Adams wrote:> On Thu, Sep 15, 2005 at 10:58:32AM -0700, Ashwani Wason wrote: > > Hi Jonathan, > > > > From what I can read in ip.c, ip_rput() would be called by STREAMS > > lower layers as they push data through IP. "GLDv3" drivers can call > > ip_input() directly, which I assume is the work that the folks at Sun > > did on adding function-call based interface in the stack. Further, > > ip_rput() calls ip_input() after some basic processing. So ip_input() > > seems to be a logical function from which data would go into IP. In > > any case, thanks for verifying that it was added after S10 GA. > > That''s only true post-Nemo; so ip_rput should catch everything in Solaris > 10. > > Cheers, > - jonathan > > -- > Jonathan Adams, Solaris Kernel Development > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl