Date: Mon, 23 Dec 2013 11:18:33 -0500 From: John Baldwin <jhb@freebsd.org> To: Gleb Smirnoff <glebius@freebsd.org> Cc: svn-src-head@freebsd.org, John-Mark Gurney <jmg@funkthat.com>, src-committers@freebsd.org, "Alexander V. Chernikov" <melifaro@freebsd.org>, svn-src-all@freebsd.org Subject: Re: svn commit: r259562 - head/usr.bin/netstat Message-ID: <201312231118.34054.jhb@freebsd.org> In-Reply-To: <20131220002849.GH71033@FreeBSD.org> References: <201312181825.rBIIPR25014515@svn.freebsd.org> <201312191552.04202.jhb@freebsd.org> <20131220002849.GH71033@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, December 19, 2013 7:28:50 pm Gleb Smirnoff wrote:
> John,
>
> On Thu, Dec 19, 2013 at 03:52:03PM -0500, John Baldwin wrote:
> J> > J> Please don't gratuitiously break things that /usr/sbin/crashinfo runs. It's
> J> > J> fine if kvm mode is fragile and requires the binary to be in sync with the
> J> > J> kernel and is only used for crash dumps, but it is very useful to extract
> J> > J> all sorts of info out of a crash dump.
> J> >
> J> > The problem is that these tools (netstat, and some others) prevent us from
> J> > improving the kernel network stack. We can't make improvements that are
> J> > mergeable to stable/x branch, since the tools would be broken.
> J>
> J> No, I explicitly said "it's fine if the kvm mode is fragile and requires the
> J> binary to be in sync and is only used for crash dumps". That means it's
> J> fine to merge changes as long as you merge the whole thing together. It also
> J> means you don't have to support all possible internal kernel ABIs in a branch.
>
> Sorry but this is not true. Yeah, I'm grateful that you personally allow me to
> break ABIs, but the general FreeBSD project policy doesn't allow that anymore
> in stable branches.
No. Not all ABIs have the same guarantee and this has _always_ been true.
ABIs for external symbols in shared libraries: yes. Some ABIs used by kernel
modules (like VFS and things ifnet drivers use, cvdevsw, etc.): yes. Various
other in-kernel ABIs: no. Implementation details of internal data structures
that are only examined by tools using kvm: no.
This isn't a new policy, this is the one we've actually had over the past N
years.
In terms of rewriting this in some other language: you could use CTF to handle
structure layout changes transparently, but recompiling C does that as well.
However, simply writing things in gdb script or D will not magically parse
changes to the data structures themselves. That will require the same level
of work to maintain. And while I can certainly hack on gdb scripts, the
language for it is horrible compared to C. No switch statements, no break or
continue for loops, etc. You can't possibly tell me gdb is comparable to C
in that regard. Take this for example to output the type of a vnode:
# vtypename <type>
# helper function for vprint
define vtypename
if ($arg0 == VNON)
printf "VNON"
else
if ($arg0 == VREG)
printf "VREG"
else
if ($arg0 == VDIR)
printf "VDIR"
else
if ($arg0 == VBLK)
printf "VBLK"
else
if ($arg0 == VCHR)
printf "VCHR"
else
if ($arg0 == VLNK)
printf "VLNK"
else
if ($arg0 == VSOCK)
printf "VSOCK"
else
if ($arg0 == VFIFO)
printf "VFIFO"
else
if ($arg0 == VBAD)
printf "VBAD"
else
if ($arg0 == VMARKER)
printf "VMARKER"
else
printf "V??:%d", $arg0
end
end
end
end
end
end
end
end
end
end
end
I don't imagine anyone hinks that is as readable as the equivalent switch
statement in C.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201312231118.34054.jhb>