From owner-freebsd-hackers@freebsd.org Wed Oct 28 23:21:28 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 190F5A2096D for ; Wed, 28 Oct 2015 23:21:28 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B628B13D1 for ; Wed, 28 Oct 2015 23:21:27 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190d-f79766d000002fec-ec-56315870e858 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 2A.D0.12268.07851365; Wed, 28 Oct 2015 19:21:20 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t9SNLJ9S025101; Wed, 28 Oct 2015 19:21:19 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t9SNLEV0026036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Oct 2015 19:21:18 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t9SNLElR028926; Wed, 28 Oct 2015 19:21:14 -0400 (EDT) Date: Wed, 28 Oct 2015 19:21:14 -0400 (EDT) From: Benjamin Kaduk To: Koert van der Veer cc: freebsd-hackers@freebsd.org Subject: Re: ABI stability for loadable modules In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrVsQYRhmMHExl8X2zf8YLQ59jXZg 8nj/cDGTx4xP81kCmKK4bFJSczLLUov07RK4Mh6tvcNa0MJVsez5SZYGxj6OLkYODgkBE4lT 13m6GDmBTDGJC/fWs3UxcnEICSxmkpj6r5kdwtnIKPHgxQYmCOcQk8TGjh8sEE4Do0Tnq3+M IP0sAtoSe9/tZgKx2QRUJGa+2cgGYosAxX+eWwcWZxaQl7iw+RBYvbCAvsTNpufMIDanQKDE 4XvX2UFsXgFHiVtdu8DiQgIBErv332IBsUUFdCRW75/CAlEjKHFy5hMWiJlaEsunb2OZwCg4 C0lqFpLUAkamVYyyKblVurmJmTnFqcm6xcmJeXmpRbpGermZJXqpKaWbGMGBKsm7g/HdQaVD jAIcjEo8vB4GhmFCrIllxZW5hxglOZiURHmvBACF+JLyUyozEosz4otKc1KLDzFKcDArifBK swDleFMSK6tSi/JhUtIcLErivJt+8IUICaQnlqRmp6YWpBbBZGU4OJQkeKPDgRoFi1LTUyvS MnNKENJMHJwgw3mAhk8FqeEtLkjMLc5Mh8ifYlSUEue1BUkIgCQySvPgesGJZDeT6itGcaBX hHmPg1TxAJMQXPcroMFMQIPdr+iCDC5JREhJNTC6tefmXa+92ZDfvoCxJU3unMi8ibUq/C7/ 5t2WWMVzVkogMjmspSDYImqNsvgH9Rv3Dp55smZyssjJvW6t3q9VbvotvmrbxDBl9sETmjFP ghIqPnHe+f/KyOpMSUTH5sly4f33E2JOnLS+N10hYDvT4rsPg+bo1f13vvLpev3FlRsbj0d2 OKoqsRRnJBpqMRcVJwIARiZF2f8CAAA= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 23:21:28 -0000 On Wed, 28 Oct 2015, Koert van der Veer wrote: > TL;DR: Can I safely load a kernel module compiled against a slightly > different kernel? > > > I maintain a fleet of FreeBSD machines. We've encountered a problem with > one of the modules (iscsi doesn't allow passwords > 16 chars). I've > determined that patching the module solves the problem for us, and doesn't > affect any other kernel component. I'd like to distribute the patched > module and user-space components. My use-case allows me to unload the iscsi > module, but doesn't allow me to reboot the machine. > > > However, we're running an array of different kernels (10.0-RELEASE, > 10.0-RELEASE-p9, 10.0-STABLE, 10.1-RELEASE, 10.1-RELEASE-p6). I'd like to > minimize the number of distinct binaries being distributed, so preferably > I'd compile only one or two. My preliminary tests on VMs show me that this > does not cause any immediate problems. Is this actually safe, or do I need > to make distinct sets of binaries for each minor version and patchlevel of > kernel in production? Kernel ABI stability is guaranteed(*) within a major release branch. -Ben (*) there are occasional exceptions involving portions of the network stack, but 10.x is probably better than 9.x in this regard