Re: Article on Sun's DTrace

2004-07-24 Thread Ingo

 But if you *do* happen to know 60 good programmers who are willing
 to work on FreeBSD full time for very little money, let me know
 and I'll see what I can do about that baby thing.

the great idea:
get a bank account, ask users if they throw an 1$ (1eur) on it and let
some indian (or something else) work on it.

i think the idea is not as bad.


bye, Ingo

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Article on Sun's DTrace

2004-07-13 Thread Dag-Erling Smørgrav
Steven Smith [EMAIL PROTECTED] writes:
 I don't know enough about Sparcs to even speculate how it's done
 there.

The UltraSparc is a RISC processor, which amongst other things implies
constant instruction size.  Memory barriers take care of any cache
coherence issues that may arise.

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Article on Sun's DTrace

2004-07-13 Thread Andrey Simonenko
On Mon, Jul 12, 2004 at 07:09:33PM +0100, Steven Smith wrote:
  On their DTrace support forum there is the article about the problem
  with different byte patterns of movl %esp, %ebp produced by
  different assemblers.
 Do you have an URL for that?  I can't seem to find it.

http://forum.sun.com/thread.jsp?forum=211thread=19877

  Also modifying functions on-the-fly require some sort of
  synchronization: noone should run function which currently is being
  modified (fbt provider).
 I suspect that the actual probe trigger is an int3 instruction, rather
 than a call, since that's a single byte and can therefore be
 atomically copied in over the start of any instruction.

Having read that bug report I began to think that they change several
continues bytes in a function, probably they just search for well known
commands sequence and atomically change one of them.  I think it is possible
to change almost any instruction on x86, just because changed instruction
should be emulated after return from DTrace probe (this very actual for
probes in userspace).  Yes, you are right, using classic debugging
technique for activating DTrace trampoline should work.

One can find description of probe's activating for x86 in the 4.1
paragraph of the DTrace Usenix report.  They talked about IDT and
interrupt handler.

I know that you know this, but...

If an interrupt call for activating probe is used on x86, then this
explains how it is possible to get offset of ret command (cs:eip from
trap frame) and how probes work in the userspace (control goes to kernel,
where it works with script's variables).

Again, if every ret instructions or instructions before ret instructions
are changed in a function (because an offset of ret instruction is
available in :return probe), then to speed up instruction changing, it
is possible to save offsets of probes entries in some well known sections
of object files (during compilation phase for example) and if there isn't
such section, then try to find probes entries on-the-fly by disassembling
binary code.  Wildcard probes can require changing at least two instructions
in every of tens of thousands functions.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Article on Sun's DTrace

2004-07-13 Thread Eitarou Kamo
Hi Andrey,
(B
(BAndrey Simonenko wrote:
(B
(B
(B Having read that bug report I began to think that they change several
(B continues bytes in a function, probably they just search for well known
(B commands sequence and atomically change one of them. I think it is
(B possible
(B to change almost any instruction on x86, just because changed instruction
(B should be emulated after return from DTrace probe (this very actual for
(B probes in userspace). Yes, you are right, using classic debugging
(B technique for activating DTrace trampoline should work.
(B
(B One can find description of probe's activating for x86 in the 4.1
(B paragraph of the DTrace Usenix report. They talked about IDT and
(B interrupt handler.
(B
(B I know that you know this, but...
(B
(B If an interrupt call for activating probe is used on x86, then this
(B explains how it is possible to get offset of "ret" command (cs:eip from
(B trap frame) and how probes work in the userspace (control goes to kernel,
(B where it works with script's variables).
(B
(B Again, if every "ret" instructions or instructions before "ret"
(B instructions
(B are changed in a function (because an offset of "ret" instruction is
(B available in :return probe), then to speed up instruction changing, it
(B is possible to save offsets of probes entries in some well known sections
(B of object files (during compilation phase for example) and if there isn't
(B such section, then try to find probes entries on-the-fly by disassembling
(B binary code. Wildcard probes can require changing at least two
(B instructions
(B in every of tens of thousands functions.
(B ___
(B
(B
(BYou seem to know well about DTrace. I was taught a lot by you
(Bon the off line too. By the way, Are you plan to port DTrace like
(Btool to FreeBSD? or are you Sun or DTrace developer? Sorry,
(BI'm not sure who and what you are, and I'm not old-timer on this list.
(B
(BEitarou
(B
(B-- 
(B  
(B***
(BEitarou Kamo
(B
(BTel. +81 75 7035997
(BFax  +81 75 7035997
(BVoIP   050 10585997(domestic only)
(Be$B!>(Bmail   [EMAIL PROTECTED]
(B
(BFor business:
(BFeel free to mail me(above), please.
(B
(BDonation   http://www.PayPal.Com
(B
(BGPG FingerPrint:
(B032D FDF9 D27B 23F7 9A81 BF4C 626C FBAA BC3A 9895 
(B
(B
(B
(B
(B
(B
(B___
(B[EMAIL PROTECTED] mailing list
(Bhttp://lists.freebsd.org/mailman/listinfo/freebsd-hackers
(BTo unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Article on Sun's DTrace

2004-07-12 Thread Andrey Simonenko
On Sat, 10 Jul 2004 20:45:14 +0100 in lucky.freebsd.hackers, Steven Smith wrote:
 
  It's also possible to put probes on the return instruction of the
  function.  I'm not sure how they're actually finding that, though.
 I think the return probe is done by adding a call probe that changes the 
 return address.
 Yeah, I thought that when I first saw it, but the probe is passed the
 address of the return instruction when it fires, and I can't see how
 you could get that if it was just invoked by modifying the return
 address on the call stack.

Don't you think that they disassemble functions on-the-fly to find
out prolog and return sequence of a function?  On their DTrace
support forum there is the article about the problem with different
byte patterns of movl %esp, %ebp produced by different assemblers.

(As an optimization fbt:::entry and fbt:::return probes' entry points
can be found before and be placed in well known section.)

At least if the control goes from the target function to some DTrace
probe dispatch function, then this DTrace function should know which
commands to emulate before returning to the target function, and it is
impossible to run original function's commands without knowing
their size, I mean that DTrace function should copy exactly complete
sequence of commands from target function, not some bytes.

I haven't opportunity to test DTrace, but there is another interesting
question.  fbt:::entry probe (or similar so called wild card probe) can
create tens of thousands entry points on-the-fly.  How does this
creation affect on whole system?  Also modifying functions on-the-fly
require some sort of synchronization: noone should run function
which currently is being modified (fbt provider).
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Article on Sun's DTrace

2004-07-12 Thread Steven Smith
   It's also possible to put probes on the return instruction of the
   function.  I'm not sure how they're actually finding that, though.
  I think the return probe is done by adding a call probe that changes the 
  return address.
  Yeah, I thought that when I first saw it, but the probe is passed the
  address of the return instruction when it fires, and I can't see how
  you could get that if it was just invoked by modifying the return
  address on the call stack.
 Don't you think that they disassemble functions on-the-fly to find
 out prolog and return sequence of a function?
That is entirely plausible.

 On their DTrace support forum there is the article about the problem
 with different byte patterns of movl %esp, %ebp produced by
 different assemblers.
Do you have an URL for that?  I can't seem to find it.

 Also modifying functions on-the-fly require some sort of
 synchronization: noone should run function which currently is being
 modified (fbt provider).
I suspect that the actual probe trigger is an int3 instruction, rather
than a call, since that's a single byte and can therefore be
atomically copied in over the start of any instruction.  Any other
processor either sees the value before the probe was activated (which
is fine; it's just equivalent to the probe activating a split second
later) ot afterwards (which is also fine).  The x86 memory model is (I
think; someone with more knowledge may want to correct me) strong
enough to make that perfectly safe.

(So the push %ebp part of the prolog becomes an int3 instruction in a
single atomic operation, rather than just the first byte of a call
instruction).

I don't know enough about Sparcs to even speculate how it's done
there.

Steven.



pgpp87t1IesDg.pgp
Description: PGP signature


Re: Article on Sun's DTrace

2004-07-10 Thread Steven Smith
  It's also possible to put probes on the return instruction of the
  function.  I'm not sure how they're actually finding that, though.
 I think the return probe is done by adding a call probe that changes the 
 return address.
Yeah, I thought that when I first saw it, but the probe is passed the
address of the return instruction when it fires, and I can't see how
you could get that if it was just invoked by modifying the return
address on the call stack.

Steven.


pgpicSF3SLP7i.pgp
Description: PGP signature


Re: Article on Sun's DTrace

2004-07-08 Thread Daniel Ellard
On Wed, 7 Jul 2004, David Schultz wrote:

 The page referenced earlier in this thread pointed out that 6
 staff-years went into DTrace.  That's accurate, and we're not
 talking about part-time employees or people who don't know what
 they're doing.  The D compiler aside, this is not a small matter
 of programming that can just be ported to a new OS or machine
 architecture in a few months.

I don't doubt that DTrace took a long time to do.  However, in most
projects the design phase consumes a lot of time, and it is often the
case that unforeseen problems or changes in the feature set cost the
developers a lot of time.  So while it might have taken six years to
write DTrace the first time, I suspect it would take a fraction of
that time to re-implement.  (It certainly might be longer than a few
months and I'm not going to quibble.  We won't know the precise
number until someone does the port.)

-Dan

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Article on Sun's DTrace

2004-07-08 Thread Julian Elischer


On Thu, 8 Jul 2004, Steven Smith wrote:

 It's also possible to put probes on the return instruction of the
 function.  I'm not sure how they're actually finding that, though.

I think the return probe is done by adding a call probe that changes the 
return address.



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Article on Sun's DTrace

2004-07-08 Thread Avleen Vig
On Thu, Jul 08, 2004 at 03:46:24AM -0400, Daniel Ellard wrote:
 I don't doubt that DTrace took a long time to do.  However, in most
 projects the design phase consumes a lot of time, and it is often the
 case that unforeseen problems or changes in the feature set cost the
 developers a lot of time.  So while it might have taken six years to
 write DTrace the first time, I suspect it would take a fraction of
 that time to re-implement.  (It certainly might be longer than a few
 months and I'm not going to quibble.  We won't know the precise
 number until someone does the port.)

They said 6 staff-years. This means if they have 6 people working on
it full time, it took 1 year to complete. If they had 60 people full
time, it took just over 5 weeks (technically, i doubt that would work
practically).

From speaking to a friend at sun, I do know it took a long time and a
lot of effort, and was *not* a simple thing to implement.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Article on Sun's DTrace

2004-07-08 Thread Eitarou Kamo
Hi Julian,
Julian Elischer wrote:
On Thu, 8 Jul 2004, Steven Smith wrote:
 

It's also possible to put probes on the return instruction of the
function.  I'm not sure how they're actually finding that, though.
   

I think the return probe is done by adding a call probe that changes the 
return address.

 

The pointer to function seems to be the key word. return_p is
the pointer to function. In case of normal mode return _p points the
dummy address or Null pointer. In case of DTrace mode return_p
points the address of probe. This may be magic of the DTrace.
What all the DTrace do are to know the address of probe. If DTrace
get the pointer of probes return_ps via structure or else, lang D
would get the return value of the probe from memory.
--
   
***
	Eitarou Kamo

Tel. +81 75 7035997
Fax  +81 75 7035997
VoIP   050 10585997(domestic only)
e-mail   [EMAIL PROTECTED]
For business:
Feel free to mail me(above), please.
Donation   http://www.PayPal.Com
GPG FingerPrint:
032D FDF9 D27B 23F7 9A81 BF4C 626C FBAA BC3A 9895 


   


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Article on Sun's DTrace

2004-07-08 Thread Eitarou Kamo
Hi,
Avleen Vig wrote:
They said 6 staff-years. This means if they have 6 people working on
it full time, it took 1 year to complete. If they had 60 people full
time, it took just over 5 weeks (technically, i doubt that would work
practically).
From speaking to a friend at sun, I do know it took a long time and a
lot of effort, and was *not* a simple thing to implement.
 

They may say so to add value-added. But I have never run it.
So I don't know what it is. They ought to finish Solaris10 itself before
DTrace...
Say hello to Sun guys.
Eitarou
--
   
***
	Eitarou Kamo

Tel. +81 75 7035997
Fax  +81 75 7035997
VoIP   050 10585997(domestic only)
e-mail   [EMAIL PROTECTED]
For business:
Feel free to mail me(above), please.
Donation   http://www.PayPal.Com
GPG FingerPrint:
032D FDF9 D27B 23F7 9A81 BF4C 626C FBAA BC3A 9895 


   


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Article on Sun's DTrace

2004-07-08 Thread Dag-Erling Smørgrav
Avleen Vig [EMAIL PROTECTED] writes:
 They said 6 staff-years.

No, they said three engineers working full-time for two years.

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Article on Sun's DTrace

2004-07-08 Thread David Schultz
On Thu, Jul 08, 2004, Wilko Bulte wrote:
 On Thu, Jul 08, 2004 at 01:23:04AM -0700, Avleen Vig wrote:
  On Thu, Jul 08, 2004 at 03:46:24AM -0400, Daniel Ellard wrote:
   I don't doubt that DTrace took a long time to do.  However, in most
   projects the design phase consumes a lot of time, and it is often the
   case that unforeseen problems or changes in the feature set cost the
   developers a lot of time.  So while it might have taken six years to
   write DTrace the first time, I suspect it would take a fraction of
   that time to re-implement.  (It certainly might be longer than a few
   months and I'm not going to quibble.  We won't know the precise
   number until someone does the port.)
  
  They said 6 staff-years. This means if they have 6 people working on
  it full time, it took 1 year to complete. If they had 60 people full
  time, it took just over 5 weeks (technically, i doubt that would work
  practically).
 
 It works about as well as having 3 women deliver a baby in 3 months.

;-)  See also Fred Brooks' book _The_Mythical_Man-Month_.

But if you *do* happen to know 60 good programmers who are willing
to work on FreeBSD full time for very little money, let me know
and I'll see what I can do about that baby thing.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Article on Sun's DTrace

2004-07-07 Thread Eitarou Kamo
Hi Dan,
Daniel Ellard wrote:
In a nutshell, here is what DTrace is about:
- It has no impact on the system when it is not used.  So you can
leave it in all the time, instead of having a debug kernel and
a production kernel.
	[I don't know how they achieve the no impact but they claim
	that they really mean no, not just negligible.]
 

snip
/snip
Thanks good comment. This is the one everyone, of course me too,
wants to know. I wanted to get brief instruction.

So, you could think of it as a million debugging printf's magically
inserted into the kernel for you along with a tool to analyze the
output, but it's really much more sophisticated than that.
It looks very nice.  I wish I'd had it during my forays into the
FreeBSD kernel.  Is it hopelessly solaris-specific?  Well, I was at
the presentation that Bryan Cantrill gave at USENIX, where he was
asked about the possibility of porting DTrace to linux.  His response
was something like well, we're really trying to encourage people to
use the *best* possible operating system, so no. (Of course, one
might argue that this means that a FreeBSD port is imminent, but I
don't think that's what he meant.)
-Dan
 

FreeBSD has good features such as jail, chroot e.t.c. which can controll
process or resources in parallel. So you need not port DTrace entirely.
You can implement DTrace like one from scratch. Using legacy system
sometimes makes new system feature. I would rather expect new one than
porting. DTrace is one of example, I think. You may be able to fork new 
debug
process in parallel in the future. If I dare name it, It's B(SD)Trace? 
But it's up to
your effort. DTrace is a pioneer work. And for the people like me who 
bothers
to put the debug lines in kernel this must be powerful tool.

Eitarou
--
   
***
	Eitarou Kamo

Tel. +81 75 7035997
Fax  +81 75 7035997
VoIP   050 10585997(domestic only)
e-mail   [EMAIL PROTECTED]
For business:
Feel free to mail me(above), please.
Donation   http://www.PayPal.Com
GPG FingerPrint:
032D FDF9 D27B 23F7 9A81 BF4C 626C FBAA BC3A 9895 


   


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Article on Sun's DTrace

2004-07-07 Thread Nicolas Bérard Nault
 FreeBSD has good features such as jail, chroot e.t.c. which can controll
 process or resources in parallel. So you need not port DTrace entirely.

I think the control of ressources in a jail is very limited right now. I
don't know if some work in that direction is in progress but it would be a
great project for the future.

 You can implement DTrace like one from scratch. Using legacy system
 sometimes makes new system feature. I would rather expect new one than
 porting. DTrace is one of example, I think. You may be able to fork new
 debug
 process in parallel in the future. If I dare name it, It's B(SD)Trace?
 But it's up to
 your effort. DTrace is a pioneer work. And for the people like me who
 bothers
 to put the debug lines in kernel this must be powerful tool.

Dtrace is (seems, at least) to be a very powerful tool. Eventual coders
could/should get their inspiration out of the work of Sun engineers. But
remember, the volunteers of the FreeBSD project aren't paid to do what
they do. 2 years and 3 full-time engineers were needed to accomplish
Dtrace so I think seeing a similar utility in the near future for FreeBSD
is very hopeless.

-- 
Nicolas Bérard Nault ([EMAIL PROTECTED])
http://www.quebecbsd.org
http://www.xeatech.net
http://staff.xeatech.net/nicobn

Je ne sais pas avec quelles armes se combattra la troisième guerre
mondiale mais je peux vous assurer que la quatrième se combattra avec des
pierres et des bâtons. -- Albert Einstein.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Article on Sun's DTrace

2004-07-07 Thread Eitarou Kamo
Hi Nicpolas,
Nicolas Bérard Nault wrote:
I think the control of ressources in a jail is very limited right now. I
don't know if some work in that direction is in progress but it would be a
great project for the future.
 

If you attend the prj, You can tweak as you like, I think.

Dtrace is (seems, at least) to be a very powerful tool. Eventual coders
could/should get their inspiration out of the work of Sun engineers. But
remember, the volunteers of the FreeBSD project aren't paid to do what
they do. 2 years and 3 full-time engineers were needed to accomplish
Dtrace so I think seeing a similar utility in the near future for FreeBSD
is very hopeless.
 

So what?
--
   
***
	Eitarou Kamo

Tel. +81 75 7035997
Fax  +81 75 7035997
VoIP   050 10585997(domestic only)
e-mail   [EMAIL PROTECTED]
For business:
Feel free to mail me(above), please.
Donation   http://www.PayPal.Com
GPG FingerPrint:
032D FDF9 D27B 23F7 9A81 BF4C 626C FBAA BC3A 9895 


   


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Article on Sun's DTrace

2004-07-07 Thread Nicolas Bérard Nault
Dtrace is (seems, at least) to be a very powerful tool. Eventual coders
could/should get their inspiration out of the work of Sun engineers. But
remember, the volunteers of the FreeBSD project aren't paid to do what
they do. 2 years and 3 full-time engineers were needed to accomplish
Dtrace so I think seeing a similar utility in the near future for FreeBSD
is very hopeless.

 So what?

Don't you think this is a candidate for funding from the FreeBSD foundation ?

-- 
Nicolas Bérard Nault ([EMAIL PROTECTED])
http://staff.xeatech.net/nicobn
PGP public key: 0x64159509
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Article on Sun's DTrace

2004-07-07 Thread Eitarou Kamo
Hi Nicolas,
(B
(BNicolas Be'rard Nault wrote:
(B
(B Dtrace is (seems, at least) to be a very powerful tool. Eventual coders
(B could/should get their inspiration out of the work of Sun engineers.
(B But
(B remember, the volunteers of the FreeBSD project aren't paid to do what
(B they do. 2 years and 3 full-time engineers were needed to accomplish
(B Dtrace so I think seeing a similar utility in the near future for
(B FreeBSD
(B is very hopeless.
(B
(B
(B So what?
(B
(B
(B Don't you think this is a candidate for funding from the FreeBSD
(B foundation ?
(B
(B
(B
(BDo you think it is worth for that?
(B
(BBTW, don't you know my previous post which was not received to this list
(Bbut you quoted.
(B
(B-- 
(B
(B
(B***
(BEitarou Kamo
(B
(BTel. +81 75 7035997
(BFax  +81 75 7035997
(BVoIP   050 10585997(domestic only)
(Be$B!>(Bmail   [EMAIL PROTECTED]
(B
(BFor business:
(BFeel free to mail me(above), please.
(B
(BDonation   http://www.PayPal.Com
(B
(BGPG FingerPrint:
(B032D FDF9 D27B 23F7 9A81 BF4C 626C FBAA BC3A 9895 
(B
(B
(B
(B
(B
(B
(B___
(B[EMAIL PROTECTED] mailing list
(Bhttp://lists.freebsd.org/mailman/listinfo/freebsd-hackers
(BTo unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Article on Sun's DTrace

2004-07-07 Thread David Schultz
On Wed, Jul 07, 2004, Eitarou Kamo wrote:
 FreeBSD has good features such as jail, chroot e.t.c. which can controll

Solaris 10 has these features, too, but I'm not sure what that has
to do with DTrace.

 process or resources in parallel. So you need not port DTrace entirely.
 You can implement DTrace like one from scratch. Using legacy system
 sometimes makes new system feature. I would rather expect new one than
 porting. DTrace is one of example, I think. You may be able to fork new 
 debug
 process in parallel in the future. If I dare name it, It's B(SD)Trace? 
 But it's up to
 your effort. DTrace is a pioneer work. And for the people like me who 
 bothers
 to put the debug lines in kernel this must be powerful tool.

The page referenced earlier in this thread pointed out that 6
staff-years went into DTrace.  That's accurate, and we're not
talking about part-time employees or people who don't know what
they're doing.  The D compiler aside, this is not a small matter
of programming that can just be ported to a new OS or machine
architecture in a few months.

That said, there is prior work in this area, such as:
http://oss.software.ibm.com/developer/opensource/linux/projects/dprobes/
But these other efforts don't come close to DTrace.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Article on Sun's DTrace

2004-07-07 Thread Eitarou Kamo
Hi David,
David Schultz wrote:
On Wed, Jul 07, 2004, Eitarou Kamo wrote:
 

FreeBSD has good features such as jail, chroot e.t.c. which can controll
   

Solaris 10 has these features, too, but I'm not sure what that has
to do with DTrace.
 

If You use the feature with DTrace like tool, You can operate
it in parallel. This is just a idea. I know Sol10 has chroot or zfs
which behave like jail. What I'd like to say is that you need not
insist on just DTrace you can develop original one.

 

The page referenced earlier in this thread pointed out that 6
staff-years went into DTrace.  That's accurate, and we're not
talking about part-time employees or people who don't know what
they're doing.  The D compiler aside, this is not a small matter
of programming that can just be ported to a new OS or machine
architecture in a few months.
 

I think so. If you develop the DTrace like tool, you need the resources 
at least
equivalent with DTrace team, I guess. If you do, your develop team will make
any action to get a resources.

That said, there is prior work in this area, such as:
http://oss.software.ibm.com/developer/opensource/linux/projects/dprobes/
But these other efforts don't come close to DTrace.
 

--
   
***
	Eitarou Kamo

Tel. +81 75 7035997
Fax  +81 75 7035997
VoIP   050 10585997(domestic only)
e-mail   [EMAIL PROTECTED]
For business:
Feel free to mail me(above), please.
Donation   http://www.PayPal.Com
GPG FingerPrint:
032D FDF9 D27B 23F7 9A81 BF4C 626C FBAA BC3A 9895 


   


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Article on Sun's DTrace

2004-07-07 Thread Dan Nelson
In the last episode (Jul 07), David Schultz said:
 The page referenced earlier in this thread pointed out that 6
 staff-years went into DTrace.  That's accurate, and we're not talking
 about part-time employees or people who don't know what they're
 doing.  The D compiler aside, this is not a small matter of
 programming that can just be ported to a new OS or machine
 architecture in a few months.

Pawel Jakub Dawidek has already written a C-like language for his
Cerber project that looks like it could be used for a FreeBSD DTrace. 
It doesn't support associative arrays for stat collecting like D does,
but it's got just about everything else.  If you just wanted to track
syscalls, you could almost use Cerber as-is.

http://cerber.sourceforge.net/

-- 
Dan Nelson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Article on Sun's DTrace

2004-07-07 Thread Eitarou Kamo
Hi Dan N,
Dan Nelson wrote:
In the last episode (Jul 07), David Schultz said:
 

Pawel Jakub Dawidek has already written a C-like language for his
Cerber project that looks like it could be used for a FreeBSD DTrace. 
It doesn't support associative arrays for stat collecting like D does,
but it's got just about everything else.  If you just wanted to track
syscalls, you could almost use Cerber as-is.

http://cerber.sourceforge.net/
 

Indeed, he have already made a action.
Eitarou
--
   
***
	Eitarou Kamo

Tel. +81 75 7035997
Fax  +81 75 7035997
VoIP   050 10585997(domestic only)
e-mail   [EMAIL PROTECTED]
For business:
Feel free to mail me(above), please.
Donation   http://www.PayPal.Com
GPG FingerPrint:
032D FDF9 D27B 23F7 9A81 BF4C 626C FBAA BC3A 9895 


   


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


closefrom (was Re: Article on Sun's DTrace)

2004-07-06 Thread pfgshield-pedro
Hi;

The article suggests we should learn from Solaris and implement closefrom(3C):

http://www.freebsd.org/cgi/man.cgi?query=closefromapropos=0sektion=0manpath=SunOS+5.9format=html

And make sure we use it in sendmail (and Javac).

cheers,

Pedro.







Yahoo! Companion - Scarica gratis la toolbar di Ricerca di Yahoo! 
http://companion.yahoo.it
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Article on Sun's DTrace

2004-07-06 Thread Daniel Ellard

In a nutshell, here is what DTrace is about:

- It has no impact on the system when it is not used.  So you can
leave it in all the time, instead of having a debug kernel and
a production kernel.

[I don't know how they achieve the no impact but they claim
that they really mean no, not just negligible.]

- It allows you to analyze pretty much any aspect of the kernel that
you like, and it has hooks into userland as well.  So if you
have strange behaviors happening due to a badly-written
process, you can track down what that process is doing.

They demonstrate some nice examples of this.

- The D language is what you use to specify how the trace info is
filtered/processed/presented to you.

D is not a complete programming language.  It is highly
constrained (i.e.  no loops, no recursion, etc) in order to
make sure that every path through a D program completes in
finite time (otherwise, a bug in your D program might
effectively hang the kernel, which is a no-no).

So, you could think of it as a million debugging printf's magically
inserted into the kernel for you along with a tool to analyze the
output, but it's really much more sophisticated than that.

It looks very nice.  I wish I'd had it during my forays into the
FreeBSD kernel.  Is it hopelessly solaris-specific?  Well, I was at
the presentation that Bryan Cantrill gave at USENIX, where he was
asked about the possibility of porting DTrace to linux.  His response
was something like well, we're really trying to encourage people to
use the *best* possible operating system, so no. (Of course, one
might argue that this means that a FreeBSD port is imminent, but I
don't think that's what he meant.)

-Dan

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Article on Sun's DTrace

2004-07-05 Thread David Schultz
On Wed, Jun 30, 2004, Bruce M Simpson wrote:
 This recently caught my eye:
 http://www.samag.com/documents/s=9171/sam0406h/0406h.htm
 
 There are a number of good sounding suggestions in there.

DTrace is pure magic.  It would be well worth your time to install
Solaris 10 just to try out DTrace for a day.  Keep in mind,
however, that it took them several man-years to develop just for
sparc64 and x86, so we're not talking about a port of it any time
soon...
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Article on Sun's DTrace

2004-07-05 Thread Eitarou Kamo
HI Schultz and all,
(B
(BDavid Schultz wrote:
(B
(B On Wed, Jun 30, 2004, Bruce M Simpson wrote:
(B
(B
(B This recently caught my eye:
(B http://www.samag.com/documents/s=9171/sam0406h/0406h.htm
(B
(B There are a number of good sounding suggestions in there.
(B
(B
(B DTrace is pure magic. It would be well worth your time to install
(B Solaris 10 just to try out DTrace for a day. Keep in mind,
(B however, that it took them several man-years to develop just for
(B sparc64 and x86, so we're not talking about a port of it any time
(B soon...
(B
(B
(BIs DTrace open source? I know presence of DTrace. But
(BSun's products usually aren't open source especially OS
(Bitself. Recently JS(Sun's COO and president) announced
(BSolaris might be open source in the near future. But he often
(Btells a lie, sorry this may be unsuitable, tells a something uncertain.
(B
(BEitarou
(B
(B
(B
(B-- 
(B
(B
(B***
(BEitarou Kamo
(B
(BTel. +81 75 7035997
(BFax  +81 75 7035997
(BVoIP   050 10585997(domestic only)
(Be$B!>(Bmail   [EMAIL PROTECTED]
(B
(BFor business:
(BFeel free to mail me(above), please.
(B
(BDonation   http://www.PayPal.Com
(B
(BGPG FingerPrint:
(B032D FDF9 D27B 23F7 9A81 BF4C 626C FBAA BC3A 9895 
(B
(B
(B
(B
(B
(B
(B___
(B[EMAIL PROTECTED] mailing list
(Bhttp://lists.freebsd.org/mailman/listinfo/freebsd-hackers
(BTo unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Article on Sun's DTrace

2004-07-05 Thread Eitarou Kamo
Hi,
David Schultz wrote:
On Wed, Jun 30, 2004, Bruce M Simpson wrote:
 

This recently caught my eye:
http://www.samag.com/documents/s=9171/sam0406h/0406h.htm
There are a number of good sounding suggestions in there.
   

DTrace is pure magic.  It would be well worth your time to install
Solaris 10 just to try out DTrace for a day.  Keep in mind,
however, that it took them several man-years to develop just for
sparc64 and x86, so we're not talking about a port of it any time
soon...
 

See also,
http://www.sun.com/bigadmin/content/dtrace/
I haven't seen above well yet. But A article says that DTrace sounds
like 30,000 lines of debug print. I have written about 50 lines
of debug print in my 4.10-R kernel to chase my umass issue.
If the output of it exists on a trace log file, It may be one of
DTrace feature. I saw the some sort of debug print lines in the
kernel source of 4.10-R. If you enable them and gather the information
to a file, it may be nearly equal DTrace. But I can't warrant or guarantee
you the performance. DTrace may be a kinda elegant debug mode
kernel, I guess.
Eitarou
--
   
***
	Eitarou Kamo

Tel. +81 75 7035997
Fax  +81 75 7035997
VoIP   050 10585997(domestic only)
e-mail   [EMAIL PROTECTED]
For business:
Feel free to mail me(above), please.
Donation   http://www.PayPal.Com
GPG FingerPrint:
032D FDF9 D27B 23F7 9A81 BF4C 626C FBAA BC3A 9895 


   


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Article on Sun's DTrace

2004-07-05 Thread Volker Stolz
In local.freebsd-hackers, you wrote:
 I haven't seen above well yet. But A article says that DTrace sounds
 like 30,000 lines of debug print. 

No, already the first article tells you that they use a VM with byte-code
for the C-like language D. And it's not compiled into the kernel but
hooked in and removed on-the-fly.

Volker
-- 
http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME
Neu! Ändern Sie den Anfangstag Ihrer Woche
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Article on Sun's DTrace

2004-07-05 Thread Eitarou Kamo
Hi Volker and all,
Volker Stolz wrote:
In local.freebsd-hackers, you wrote:
 

I haven't seen above well yet. But A article says that DTrace sounds
like 30,000 lines of debug print. 
   

No, already the first article tells you that they use a VM with byte-code
for the C-like language D. And it's not compiled into the kernel but
hooked in and removed on-the-fly.
Volker
 

I don't know langage D well. But my guess is that they trim the info
valuable from the debug print outputs. Sorry I haven't read the
articles compleately yet.
Eitarou
--
   
***
	Eitarou Kamo

Tel. +81 75 7035997
Fax  +81 75 7035997
VoIP   050 10585997(domestic only)
e-mail   [EMAIL PROTECTED]
For business:
Feel free to mail me(above), please.
Donation   http://www.PayPal.Com
GPG FingerPrint:
032D FDF9 D27B 23F7 9A81 BF4C 626C FBAA BC3A 9895 


   


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Article on Sun's DTrace

2004-07-05 Thread Eitarou Kamo
Hi,
Eitarou Kamo wrote:

No, already the first article tells you that they use a VM with 
byte-code
for the C-like language D. And it's not compiled into the kernel but
hooked in and removed on-the-fly.


I don't know langage D well. But my guess is that they trim the info
valuable from the debug print outputs. Sorry I haven't read the
articles compleately yet.
Eitarou
Again DTrace seems to observe the resources via system analyze tool
and command. But language D seems to be great enough to call C/C++
function or even assembler.
--
   
***
	Eitarou Kamo

Tel. +81 75 7035997
Fax  +81 75 7035997
VoIP   050 10585997(domestic only)
e-mail   [EMAIL PROTECTED]
For business:
Feel free to mail me(above), please.
Donation   http://www.PayPal.Com
GPG FingerPrint:
032D FDF9 D27B 23F7 9A81 BF4C 626C FBAA BC3A 9895 


   


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Article on Sun's DTrace

2004-06-29 Thread John Baldwin
On Tuesday 29 June 2004 09:16 pm, Bruce M Simpson wrote:
 This recently caught my eye:
 http://www.samag.com/documents/s=9171/sam0406h/0406h.htm

 There are a number of good sounding suggestions in there.

They gave a paper on it at USENIX ATC as well.

-- 
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve  =  http://www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]