From owner-svn-src-head@freebsd.org Fri Aug 19 07:40:03 2016 Return-Path: Delivered-To: svn-src-head@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 2C7EFBBF080; Fri, 19 Aug 2016 07:40:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BAF0516F1; Fri, 19 Aug 2016 07:40:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u7J7dti7018946 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Aug 2016 10:39:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u7J7dti7018946 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u7J7dt9G018945; Fri, 19 Aug 2016 10:39:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 19 Aug 2016 10:39:55 +0300 From: Konstantin Belousov To: Warner Losh Cc: Julian Elischer , John Baldwin , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Subject: Re: svn commit: r304187 - in head: . share/man/man4 sys/conf sys/dev/mcd sys/modules sys/modules/mcd Message-ID: <20160819073955.GC83214@kib.kiev.ua> References: <201608152038.u7FKc2NL026330@repo.freebsd.org> <2065331.KaGOSftJhd@ralph.baldwin.cx> <0d6c2e45-e4da-9bb7-a50c-212135d9ac4f@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 07:40:03 -0000 On Thu, Aug 18, 2016 at 09:28:57PM -0600, Warner Losh wrote: > On Thu, Aug 18, 2016 at 12:50 AM, Julian Elischer wrote: > > On 16/08/2016 4:54 AM, John Baldwin wrote: > >> > >> On Monday, August 15, 2016 08:38:02 PM John Baldwin wrote: > >>> > >>> Author: jhb > >>> Date: Mon Aug 15 20:38:02 2016 > >>> New Revision: 304187 > >>> URL: https://svnweb.freebsd.org/changeset/base/304187 > >>> > >>> Log: > >>> Remove the mcd(4) driver for Mitsumi CD-ROM players. > >>> This is a driver for a pre-ATAPI ISA CD-ROM adapter. As noted in > >>> the manpage, this driver is only useful as a backend to cdcontrol to > >>> play audio CDs since it doesn't use DMA, so its data performance is > >>> "abysmal" (and that was true in the mid 90's). > >> > >> No one stepped up to test patches for it either when I last posted patches > >> to > >> convert it from timeout(9) to callout(9). I have a few more drivers that > >> are > >> both very old and that people have no business using in 12 (think ISA > >> adapters that don't do DMA and can't be used with pccard) that I will be > >> removing over the next little while. I brought up a list of drivers on > >> arch@ > >> a couple of years ago and the conversation drifted off into the weeds > >> about > >> trimming GENERIC, etc. No one objected to the specific drivers I listed > >> though (and I got a few pleas of "please remove"). If someone shows up > >> desperately clutching an ISA adapter they can always dig up the source > >> from > >> svn and deal with forward porting it for whatever API changes have > >> happened > >> since it was removed. > > > > > > I would imagine any machine still holding one of these probably has not > > enough memory to run FreeBSD. > > > > would we still run in 2MB? > > With insane levels of tuning, we can run in 32MB userland that can do > things. Even 64MB is tight w/o some tuning. 16MB is almost certainly > right out except for very specialized situations. 2MB? We can't even > load the loader in that :(. Oh, and all these memory configs are only > possible if you tweak the loader's block cache... > 32MB is quite usable. Without any tuning, you get slightly less than 10MB for userspace, which is enough to for many things, and plenty if swap is added. Note that you cannot boot on such configurations since loader was broken, but if you do manage to jump to kernel, things were fine several months ago. I tested my relatively recent OOM changes on 32MB qemu config. > Warner