Date: Thu, 3 Mar 2011 16:22:37 +0000 From: "Robert N. M. Watson" <rwatson@FreeBSD.org> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Dmitry Chagin <dchagin@FreeBSD.org> Subject: Re: svn commit: r219138 - head/usr.bin/kdump Message-ID: <C9435552-1B2D-4BB9-96AF-83E6EF939F01@FreeBSD.org> In-Reply-To: <20110303141458.10926vfwryvbcgg8@webmail.leidinger.net> References: <201103011642.p21GgTaH041022@svn.freebsd.org> <alpine.BSF.2.00.1103031112230.91619@fledge.watson.org> <20110303141458.10926vfwryvbcgg8@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3 Mar 2011, at 13:14, Alexander Leidinger wrote: > Quoting Robert Watson <rwatson@FreeBSD.org> (from Thu, 3 Mar 2011 = 11:14:59 +0000 (GMT)): >=20 >> On Tue, 1 Mar 2011, Dmitry Chagin wrote: >>=20 >>> Teach kdump to decode linux syscalls names too. >>>=20 >>> Fix bug introduced in my previous commit: the kernel always dump = native >>> signal numbers, so no need to check the ABI in ktrpsig(). >>=20 >> Does this mean that we're eliminating the need for the long-broken = linux_kdump? >=20 > For the linux parts there is (L?)GPLed code in linux_kdump (the main = reason that it is a port, I think), it is unlikely that someone sits = there and will do a clean-room implementation of those linux-kernel = derived things (I like to get proven wrong, anyone out there accepts the = challenge? ;-) ). Dmitry provided an updated linux-kdump which contains = preprocessed things (no need to have a non-default linuxulator setup). I = have the corresponding PR assigned to me, but from his comments it looks = like his new version depends upon his changes and does not DTRT without = them (I am awaiting confirmation, and I asked about changes to let it = DTRT if this is true). On a related note, the solution for handling different OS ABIs and calls = for OpenBSM was to have a file format that (a) expressed a superset of = the capabilities of each platform and (b) attempted to provide common = terms to describe their intersections. This has its limitations, but = works fairly well in practice: you can generally have a single piece of = software that makes pretty good use of BSM streams generated on Solaris, = Mac OS X, or FreeBSD across those platforms and also Linux (on which = OpenBSM compiles and runs, but whose kernel audit stack differs). Robert=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C9435552-1B2D-4BB9-96AF-83E6EF939F01>