Date: Fri, 19 Aug 2016 11:50:35 +0300 From: Toomas Soome <tsoome@me.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Warner Losh <imp@bsdimp.com>, Julian Elischer <julian@freebsd.org>, John Baldwin <jhb@freebsd.org>, src-committers <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: r304187 - in head: . share/man/man4 sys/conf sys/dev/mcd sys/modules sys/modules/mcd Message-ID: <50AAF049-C8A7-4C69-A206-C3983FFA7867@me.com> In-Reply-To: <20160819073955.GC83214@kib.kiev.ua> References: <201608152038.u7FKc2NL026330@repo.freebsd.org> <2065331.KaGOSftJhd@ralph.baldwin.cx> <0d6c2e45-e4da-9bb7-a50c-212135d9ac4f@freebsd.org> <CANCZdfpY9S8ErwD6b7pHeH%2BRVF9JEszBb7zJ9m-wybfBr1ujAg@mail.gmail.com> <20160819073955.GC83214@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 19. aug 2016, at 10:39, Konstantin Belousov <kostikbel@gmail.com> = wrote: >=20 > On Thu, Aug 18, 2016 at 09:28:57PM -0600, Warner Losh wrote: >> On Thu, Aug 18, 2016 at 12:50 AM, Julian Elischer = <julian@freebsd.org> wrote: >>> On 16/08/2016 4:54 AM, John Baldwin wrote: >>>>=20 >>>> On Monday, August 15, 2016 08:38:02 PM John Baldwin wrote: >>>>>=20 >>>>> Author: jhb >>>>> Date: Mon Aug 15 20:38:02 2016 >>>>> New Revision: 304187 >>>>> URL: https://svnweb.freebsd.org/changeset/base/304187 >>>>>=20 >>>>> 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). >>>>=20 >>>> 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. >>>=20 >>>=20 >>> I would imagine any machine still holding one of these probably has = not >>> enough memory to run FreeBSD. >>>=20 >>> would we still run in 2MB? >>=20 >> 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... >>=20 >=20 > 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. >=20 > 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 >=20 If the target is to go as low memory as possible, sure, you can strip = all 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, assuming it wont need any special configuration from loader = config) etc etc. This means highly specialized build and has nothing to = do with generic all purpose system. 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 becoming impossible and even keeping reasonable code base in all of = the #if #else #endif spaghetti is getting quite hard and error prone. =46rom developers point of view, it is not really encouraging to have = possible feedback like =E2=80=9Coh, but you did break my 32MB system = boot=E2=80=9D ;) This does bring back some memories however. For first 2 = unix systems I was dealing with, one had 8MB and another had 12MB of = memory=E2=80=A6 it was ~ 1992-1993;) Right now the loader and stage2 are set to use 64MB heap to make it = possible to implement zfs feature support and later on, for more = features. Also note that UEFI setups are much harder to deal with regard of memory = management, because as long as BS are in control, you can not really = control the memory management there and can end up with fragmented = unusable (for kernel loading) layout. This is especially nasty as = apparently some (buggy) systems actually have runtime services using = boot services memory areas, so you can end up in setup where you can not = re-use BS memory and those chunks can be all over the low memory address = space=E2=80=A6=20 rgds, toomas=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50AAF049-C8A7-4C69-A206-C3983FFA7867>