From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20100519203038.416E85B8A@mail.bitblocks.com> References: <20100519054035.C71DB5B63@mail.bitblocks.com> <20100519171832.72D915B8A@mail.bitblocks.com> <20100519182303.2C04E5B8A@mail.bitblocks.com> <20100519203038.416E85B8A@mail.bitblocks.com> Date: Wed, 19 May 2010 13:38:36 -0700 Message-ID: From: ron minnich To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] system call trace version of 9vx available. Topicbox-Message-UUID: 280eb210-ead6-11e9-9d60-3106f5b1d025 On Wed, May 19, 2010 at 1:30 PM, Bakul Shah wro= te: > You write "startsyscall" to /syscall for every trace > buffer read =A0-- don't quite understand why that is needed. It gives you the option of not restarting the system call until later. There could be more complex usage scenarios. But it's a very good point. We've talked about dumping this data via the trace facility instead. Trace facility is well designed for this type of output -- I've got a proposal in which Sape says is ok for changing the format of the trace records. So, things can still change. One question though -- once you get to the point of really complex examination of system calls, would acid be better? Or do you see a use for ratrace (that name is kind of funny and has the virtue of being typable on my keyboard with one hand) just to dump more data and make all data visible? Your point about lost information is a good one. ron