From owner-svn-src-all@freebsd.org Fri Aug 19 14:27:03 2016 Return-Path: Delivered-To: svn-src-all@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 B8458BBE7BF for ; Fri, 19 Aug 2016 14:27:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7BE6612C6 for ; Fri, 19 Aug 2016 14:27:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x229.google.com with SMTP id 38so49820349iol.0 for ; Fri, 19 Aug 2016 07:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=dRNBAs+LP5n3I7fl627FF2bmDIn0xYhOgVBikW6pGFw=; b=DhWQBOWKkV0fy4eFhioznjwdUQOQa/IRQt5GXdAAnDO+eRpQpIAQcwRu3gSYuD3Te+ WLZHWNNSHqgMJE8yyxE9hL2UWKdR0FzEOZg2OceS6guhVwq6IP/KpFWtBtGY4LBPWJsp Ajdgyu601YU6paKeAZl28Pe8T4mLUeiQ71tSrfibWH9KgAseFhp/gdf37JuY2Yr88kH5 ONj/Bq0w2zplTUpKbPtSGWDXkewgydIiBFlj/rnjgQQdZok1SfDhCQwNdDYDdpsmQQNa zODvb3WvP0XNJfXqHaEOlfiSrHu+m/NoolZxAjuezX3RHCI7k26BupsXxKOtB3Pol6hF fuPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=dRNBAs+LP5n3I7fl627FF2bmDIn0xYhOgVBikW6pGFw=; b=AtHtbEKnrQWhN+Tnn8q8U3POq6KK+Jbd4kI7n4fAZeDMxlvDzQWup/jV9/kg9Q9pBc HVJyqf9Ls6hO5rWe7qQfSU7WBOU+LvhjJGn7rFv2wy8PhuzL5IMRLRzIaEgIn5tvnfS1 crQnGi5Kmu05zcNN0SKtiQGA7w4y+3k95KJ9xuB2fVvHrHGvjkyO9cFDCYrXgNDVXUlY /gJqtsstH9HMU3OAUu2iCtnHjAdeY9+biZaAa2Ju657H7fG/KsFrakcz2pEYW0cr8AAr j8yblNxQiEBsHqqtejCKQbS9YPJ4xmD3qfSQvStp99FNNaveugsEdtQI3KEnbKgKOHd+ 2bWQ== X-Gm-Message-State: AEkoouuVB/uElQ7AyygeF8tRdBGROOMItVh6QlIIe3S8xOE+EuJvtsv5VJWrWiQTFRBg0Wr+0C1JOjRuJKHDPA== X-Received: by 10.107.145.214 with SMTP id t205mr9805219iod.135.1471616822697; Fri, 19 Aug 2016 07:27:02 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.36.65.7 with HTTP; Fri, 19 Aug 2016 07:27:02 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <514987E4-B953-467C-B53B-824B172A5211@me.com> References: <201608152038.u7FKc2NL026330@repo.freebsd.org> <2065331.KaGOSftJhd@ralph.baldwin.cx> <0d6c2e45-e4da-9bb7-a50c-212135d9ac4f@freebsd.org> <20160819073955.GC83214@kib.kiev.ua> <50AAF049-C8A7-4C69-A206-C3983FFA7867@me.com> <20160819092424.GE83214@kib.kiev.ua> <514987E4-B953-467C-B53B-824B172A5211@me.com> From: Warner Losh Date: Fri, 19 Aug 2016 08:27:02 -0600 X-Google-Sender-Auth: bWHWVvzGc435-D3-ZAwd_VO3p4E Message-ID: Subject: Re: svn commit: r304187 - in head: . share/man/man4 sys/conf sys/dev/mcd sys/modules sys/modules/mcd To: Toomas Soome Cc: Konstantin Belousov , Julian Elischer , John Baldwin , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 14:27:03 -0000 On Fri, Aug 19, 2016 at 3:35 AM, Toomas Soome wrote: > >> On 19. aug 2016, at 12:24, Konstantin Belousov wro= te: >> >> On Fri, Aug 19, 2016 at 11:50:35AM +0300, Toomas Soome wrote: >>> >>>> On 19. aug 2016, at 10:39, Konstantin Belousov w= rote: >>>> >>>> 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 i= s >>>>>>>> "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 driver= s that >>>>>>> are >>>>>>> both very old and that people have no business using in 12 (think I= SA >>>>>>> adapters that don't do DMA and can't be used with pccard) that I wi= ll be >>>>>>> removing over the next little while. I brought up a list of driver= s on >>>>>>> arch@ >>>>>>> a couple of years ago and the conversation drifted off into the wee= ds >>>>>>> about >>>>>>> trimming GENERIC, etc. No one objected to the specific drivers I l= isted >>>>>>> though (and I got a few pleas of "please remove"). If someone show= s up >>>>>>> desperately clutching an ISA adapter they can always dig up the sou= rce >>>>>>> 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 brok= en, >>>> but if you do manage to jump to kernel, things were fine several month= s >>>> ago. I tested my relatively recent OOM changes on 32MB qemu config. >>>>> Warner >>>> >>> >>> If the target is to go as low memory as possible, sure, you can strip a= ll off, from boot loader point, you should load kernel from stage2 and not = use loader at all (you can load and jump kernel even now from stage2, assum= ing it wont need any special configuration from loader config) etc etc. Thi= s means highly specialized build and has nothing to do with generic all pur= pose system. >>> >> Why you describe this as an 'alternative' ? Before that loader changes, >> I regularly tested on 32MB qemy i386 image and 64MB amd64 image. I do >> not see anything extreme in these configs. They use normal boot path, >> which provides kernels with debugging symbols, metadata, loaded modules >> etc. Why should I use deficient boot2-only loading, which, additionally, >> cannot work on amd64 ? >> >> More, this is the only reasonable way for most developers to ensure that >> system is still usable on tiny configs found on embedded devices. Right >> now the min which I have to set up is 128MB, and VM changes are simply n= ot >> tested on anything smaller. It is guaranteed that small systems will gro= w >> regressions fast. And I will not jump through the hoops to mitigate >> breakage induced by other people' changes. >> >>> Also at some point, there is an question about how reasonable it is to = have such configuration as part of generic code base for special bits like = boot loader itself, as the problem is, testing all those variants is becomi= ng impossible and even keeping reasonable code base in all of the #if #else= #endif spaghetti is getting quite hard and error prone. >>> >>>> From developers point of view, it is not really encouraging to have po= ssible feedback like ???oh, but you did break my 32MB system boot??? ;) Thi= s does bring back some memories however. For first 2 unix systems I was dea= ling with, one had 8MB and another had 12MB of memory??? it was ~ 1992-1993= ;) >>> >> Not mine, but you (?) indirectly broke system for people who do use 32MB >> on other arches, since low memory config on dev systems become 128MB. >> I cared about 32MB before, but not any longer. > > > Yep, I did set it to 64MB. And this is exactly why I wrote that small sys= tems do need special approaches, because getting updates for new features a= nd keeping tiny systems functional are conflicting options. So far freebsd = boot loader has managed this in some extent by massive amount of preprocess= or conditions and the result is insane list of different boot programs in There's only one boot program that's bloated recently, and that's /boot/loader. the static allocation of large buffers because malloc isn't working well is the problem. This isn't a small system vs large system problem, but a convenience vs complexity problem. Installing the base boot loader (that loads /boot/loader or kernel) is and always will be system dependent with very real constraints. Warner