Date: Fri, 14 Apr 2017 23:42:04 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net> To: Mark Johnston <markj@freebsd.org> Cc: rgrimes@freebsd.org, Alan Somers <asomers@freebsd.org>, Ngie Cooper <ngie@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r316938 - head/sbin/savecore Message-ID: <201704150642.v3F6g41p010449@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <20170415053729.GA76139@raichu>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Fri, Apr 14, 2017 at 06:30:17PM -0700, Rodney W. Grimes wrote: > > > The patch to add compression support is here and should largely still > > > work: > > > https://people.freebsd.org/~markj/patches/core-compression/20141110-kern_dump.diff > > > > > > I've been hesitant about pushing it forward: > > > - The dump_write* APIs need some simplification after the addition of > > > encrypted dump support and support for dumping to 4Kn drives. > > > - I'm not sure how encryption should compose with compression. It seems > > > intuitively obvious that we should compress before encrypting if the > > > compression is to be of any use, but I don't know enough to know > > > whether the compression might somehow compromise the effectiveness of > > > the encryption. > > > > > > If anyone has some insight on the second of these two points, I'd > > > appreciate hearing it. > > > > I have a large amount of reworking and modulization of the dump code > > incuding intergration of your (markj) compressed dumps. Layer isnt > > implemented but is in the plan. I should not of held off on the net > > dump code as it got smashed by encrypted dumps, then again by > > the libif'ing for all the Intel drives that had been netdump modified. > > > > Basically now starting over :-( > > Could you post your patches somewhere? I've been sitting on this (and > the netdump patches, for which I have quite a few modifications) for far > too long, and would like to finish them and get them in soon. I'll note > that the netdump code posted a few years ago had some problems that are > fixed in Isilon's version, which I'm working on rebasing on HEAD. In Isnt the code I rebaed in December to -12 your code from Isiolon???? Or tell me you handed me your patches to upstream, and then continued to evolved the code without letting me know? Are YOUR patckes some place public? I dont think mine are, but I do have a link in http://people.freebsd.org/~rgrimes pointing to the other Netdump version that I think is an old version of your code. > particular, I simplified the driver integration a bit, changed the code > to avoid allocating mbufs from UMA after a panic, plumbed a > configuration interface through dumpon, and fixed some problems with > netdumpd. I'm working on integrating netdump with Isilon's internal > infrastructure at the moment. The conversion of em and igb to iflib does > complicate things a bit; I haven't yet looked at how hard it would be > to support netdump in iflib'ed drivers. > > > Minidump is an lkm for me, and main dump is almost an lkm for me too. > > Does "lkm" mean "loadable kernel module"? If so, why? Yes, so you dont have to reboot to write and debug new versions, so you can have a kernel without minidump if you want, and I am sure there are others. More importantly, why not? Modules are good, staticially linked rarely used code is bad. I also have a version of minidump that can be asked, if I panicked right now how big would hte dump be? -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201704150642.v3F6g41p010449>