> On 19. aug 2016, at 10:39, Konstantin Belousov <kostik...@gmail.com> wrote: > > On Thu, Aug 18, 2016 at 09:28:57PM -0600, Warner Losh wrote: >> On Thu, Aug 18, 2016 at 12:50 AM, Julian Elischer <jul...@freebsd.org> 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 >
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. From developers point of view, it is not really encouraging to have possible feedback like “oh, but you did break my 32MB system boot” ;) 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… 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… rgds, toomas _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
