The updated patch set:
http://people.freebsd.org/~trociny/procstat_core.4.patch
It includes changes discussed with Kostik. New NT_PROCSTAT_PSSTRINGS
and NT_PROCSTAT_AUXV notes are added. libprocstat(3) is extended with
functions to retrieve env, args and auxv (so the patch that started
this threa
On Sun, Mar 31, 2013 at 06:53:00PM +0300, Mikolaj Golub wrote:
> On Sun, Mar 31, 2013 at 04:40:47PM +0300, Konstantin Belousov wrote:
>
> > I inspected imgact_elf.c:parse_note(), imgact_elf.c:putnote() and
> > rtld.c:digest_notes(). Only putnote() uses 8-byte alignment.
> > Every other OS and our
On Sun, Mar 31, 2013 at 04:40:47PM +0300, Konstantin Belousov wrote:
> I inspected imgact_elf.c:parse_note(), imgact_elf.c:putnote() and
> rtld.c:digest_notes(). Only putnote() uses 8-byte alignment.
> Every other OS and our !coredump code assumes 4-byte alignment.
Thanks!
> Does changing the
On Fri, Mar 29, 2013 at 02:31:57PM +0200, Mikolaj Golub wrote:
> On Fri, Mar 29, 2013 at 11:22:45AM +0200, Konstantin Belousov wrote:
> > On Thu, Mar 28, 2013 at 11:18:21PM +0200, Mikolaj Golub wrote:
> > > On Thu, Mar 28, 2013 at 12:51:34PM +0200, Konstantin Belousov wrote:
> > >
> > > > In the g
On Fri, Mar 29, 2013 at 11:22:45AM +0200, Konstantin Belousov wrote:
> On Thu, Mar 28, 2013 at 11:18:21PM +0200, Mikolaj Golub wrote:
> > On Thu, Mar 28, 2013 at 12:51:34PM +0200, Konstantin Belousov wrote:
> >
> > > In the generic Elf 64bit draft specification I have, the notes sections
> > > are
On Thu, Mar 28, 2013 at 11:18:21PM +0200, Mikolaj Golub wrote:
> On Thu, Mar 28, 2013 at 12:51:34PM +0200, Konstantin Belousov wrote:
>
> > In the generic Elf 64bit draft specification I have, the notes sections
> > are specified to consists of entries, each of which is an array of 8-byte
> > word
On Thu, Mar 28, 2013 at 12:51:34PM +0200, Konstantin Belousov wrote:
> In the generic Elf 64bit draft specification I have, the notes sections
> are specified to consists of entries, each of which is an array of 8-byte
> words. I think we are right using the 8-byte alignment.
I have impression ma
On Sun, Mar 24, 2013 at 05:54:28PM +0200, Mikolaj Golub wrote:
> Here is an updated patch set, which I think includes all kib's
> suggestions. It also introduces procstat groups, umask, rlimit, and
> osrel notes.
>
> http://people.freebsd.org/~trociny/procstat_core.3.patch
>
> Sbuf section interf
Here is an updated patch set, which I think includes all kib's
suggestions. It also introduces procstat groups, umask, rlimit, and
osrel notes.
http://people.freebsd.org/~trociny/procstat_core.3.patch
Sbuf section interface looks like below:
/* start a section */
sbuf_start_section(sb, NULL);
/*
On Sun, Mar 17, 2013 at 08:30:33AM +0200, Konstantin Belousov wrote:
> On Sun, Mar 17, 2013 at 12:35:20AM +0200, Mikolaj Golub wrote:
> > A KPI that would be natural for my case:
> >
> > /* start a section that is going to be aligned to sizeof(Elf_Size),
> > using byte '0' for padding */
>
On Sun, Mar 17, 2013 at 12:35:20AM +0200, Mikolaj Golub wrote:
> On Sat, Mar 16, 2013 at 09:16:05PM +0200, Konstantin Belousov wrote:
>
> > IMO sbuf_pad() should be moved to subr_sbuf.c. I find the KPI of
> > the sbuf_pad() wrong. You have two separate number, the amount to
> > pad to, and the cur
On Sun, Mar 17, 2013 at 12:35:20AM +0200, Mikolaj Golub wrote:
> Ah, this is a thing I wanted to discuss but forgot! As I understand
> the idea of the 'ABI hack' is: if the output buffer is less than the
> size of data we have, truncate our data to the last successfully
> written kinfo_file struct
On Sat, Mar 16, 2013 at 09:16:05PM +0200, Konstantin Belousov wrote:
> IMO sbuf_pad() should be moved to subr_sbuf.c. I find the KPI of
> the sbuf_pad() wrong. You have two separate number, the amount to
> pad to, and the current amount. Natural interface would take the
> two numbers separate inst
On Wed, Feb 20, 2013 at 09:58:02PM +0200, Mikolaj Golub wrote:
> On Wed, Feb 20, 2013 at 09:04:14AM -0500, John Baldwin wrote:
>
> > The process should be stopped by the time we dump a core, so running it
> > multiple times should be ok in that the sizes should not change. I would
> > say that yo
On Wed, Feb 20, 2013 at 09:04:14AM -0500, John Baldwin wrote:
> The process should be stopped by the time we dump a core, so running it
> multiple times should be ok in that the sizes should not change. I would
> say that you should try to implement a "determine sizes" pass that doesn't
> allocat
On Tuesday, February 12, 2013 4:50:54 pm Mikolaj Golub wrote:
> On Fri, Jan 25, 2013 at 03:31:43PM -0500, John Baldwin wrote:
>
> > BTW, one off-ball thought I have is that I would like to have a mode where
> > libprocstat operates on a core file (of a process, not a kernel crash
> > dump),
> >
On Fri, Jan 25, 2013 at 03:31:43PM -0500, John Baldwin wrote:
> BTW, one off-ball thought I have is that I would like to have a mode where
> libprocstat operates on a core file (of a process, not a kernel crash dump),
> so it could list the threads from a core dump, and possibly file descriptor
On Fri, 25 Jan 2013 15:31:43 -0500
John Baldwin mentioned:
> On Friday, January 25, 2013 1:37:45 pm Robert N. M. Watson wrote:
> >
> > On 24 Jan 2013, at 16:20, John Baldwin wrote:
> >
> > >>> Hmm, are you going to rewrite ps(1) to use libprocstat? Or rather, is
> that a
> > >>> goal someday?
On Friday, January 25, 2013 1:37:45 pm Robert N. M. Watson wrote:
>
> On 24 Jan 2013, at 16:20, John Baldwin wrote:
>
> >>> Hmm, are you going to rewrite ps(1) to use libprocstat? Or rather, is
that a
> >>> goal someday? That is one current consumer of kvm_getargv/envv. That
might
> >>> be f
On 24 Jan 2013, at 16:20, John Baldwin wrote:
>>> Hmm, are you going to rewrite ps(1) to use libprocstat? Or rather, is that
>>> a
>>> goal someday? That is one current consumer of kvm_getargv/envv. That might
>>> be fine if we want to make more tools use libprocstat instead of using
>>> lib
On Wednesday, January 23, 2013 4:49:50 pm Mikolaj Golub wrote:
> On Wed, Jan 23, 2013 at 11:31:43AM -0500, John Baldwin wrote:
> > On Wednesday, January 23, 2013 2:25:00 am Mikolaj Golub wrote:
> > > IMHO, after adding procstat_getargv and procstat_getargv, the usage of
> > > kvm_getargv() and kvm_
On Wed, Jan 23, 2013 at 11:31:43AM -0500, John Baldwin wrote:
> On Wednesday, January 23, 2013 2:25:00 am Mikolaj Golub wrote:
> > IMHO, after adding procstat_getargv and procstat_getargv, the usage of
> > kvm_getargv() and kvm_getenvv() (at least in the new code) may be
> > deprecated. As this is
On Wednesday, January 23, 2013 2:25:00 am Mikolaj Golub wrote:
> On Tue, Jan 22, 2013 at 02:17:39PM -0800, Stanislav Sedov wrote:
> >
> > On Jan 22, 2013, at 1:48 PM, John Baldwin wrote:
> > >
> > > Well, you could make procstat open a kvm handle in both cases (open a
> > > "live"
> > > handle
On Tue, Jan 22, 2013 at 02:17:39PM -0800, Stanislav Sedov wrote:
>
> On Jan 22, 2013, at 1:48 PM, John Baldwin wrote:
> >
> > Well, you could make procstat open a kvm handle in both cases (open a
> > "live"
> > handle in the procstat_open_sysctl() case). It just seems rather silly to
> > be
On Jan 22, 2013, at 1:48 PM, John Baldwin wrote:
>
> Well, you could make procstat open a kvm handle in both cases (open a "live"
> handle in the procstat_open_sysctl() case). It just seems rather silly to be
> duplicating code in the two interfaces. More a question for Robert: does
> libpr
On Tuesday, January 22, 2013 4:17:43 pm Mikolaj Golub wrote:
> On Tue, Jan 22, 2013 at 12:01:06PM -0500, John Baldwin wrote:
>
> > How is this different from kvm_getargv()? It seems to be a direct copy.
>
> libprocstat(3) is a frontend for sysctl(3) and kvm(3) interfaces, so
> it is good to exte
On Tue, Jan 22, 2013 at 12:01:06PM -0500, John Baldwin wrote:
> How is this different from kvm_getargv()? It seems to be a direct copy.
libprocstat(3) is a frontend for sysctl(3) and kvm(3) interfaces, so
it is good to extend it to cover "getarg/env" functionality.
Yes the functions look simila
On Saturday, January 19, 2013 10:12:54 am Mikolaj Golub wrote:
> Hi,
>
> Some time ago Stanislav Sedov suggested to me extending libprocstat(3)
> with functions to retrieve process command line arguments and
> environment variables.
>
> In the first approach I tried, the newly added functions
> p
28 matches
Mail list logo
