From owner-freebsd-stable@FreeBSD.ORG Tue Apr 17 14:17:16 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B9014106564A; Tue, 17 Apr 2012 14:17:16 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (r2b9.nsu.ru [212.192.164.39]) by mx1.freebsd.org (Postfix) with ESMTP id 5B46B8FC0C; Tue, 17 Apr 2012 14:17:16 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1SK9Cm-0003Qj-AN; Tue, 17 Apr 2012 21:16:28 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id q3HEJJdu072797; Tue, 17 Apr 2012 21:19:19 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id q3HEJE5b072711; Tue, 17 Apr 2012 21:19:14 +0700 (NOVT) (envelope-from danfe) Date: Tue, 17 Apr 2012 21:19:13 +0700 From: Alexey Dokuchaev To: Eugene Grosbein Message-ID: <20120417141913.GA70796@regency.nsu.ru> References: <20120416042645.GA53074@regency.nsu.ru> <20120416070646.GA78414@regency.nsu.ru> <4F8BD14D.8050206@rdtc.ru> <201204170840.37631.jhb@freebsd.org> <4F8D6B58.7010902@rdtc.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F8D6B58.7010902@rdtc.ru> User-Agent: Mutt/1.4.2.1i Cc: stable@freebsd.org, John Baldwin Subject: Re: RELENG_8 kernel as of Apr 14 does not boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 14:17:16 -0000 On Tue, Apr 17, 2012 at 08:08:40PM +0700, Eugene Grosbein wrote: > I guess, Alexey just tries to make smallest possible kernel just for fun :-) You are correct. Not for the size reasons though, but I want to be able to change as much as possible on the fly, without a reboot, and I cannot "kldunload kernel" yet. ;-) Another thing is that, while this is kinda unsupported configuration, it should work, even being an edge case. So it's a good test if our kernel has no hidden dependencies which would inhibit use of a module when it exists. Personally I do not see much benefits in having mem/io as modules, but if they are provided, I should be able to load them from the loader. If they must be compiled in, I suggest we stop shipping them as modules so not to confuse people (even that one must specially use "nodevice" to exclude them). ./danfe