From owner-svn-src-head@freebsd.org Sat Dec 30 21:27:43 2017 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 39790EAD936 for ; Sat, 30 Dec 2017 21:27:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 F012E6E48C for ; Sat, 30 Dec 2017 21:27:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x235.google.com with SMTP id q188so19866564iod.1 for ; Sat, 30 Dec 2017 13:27:42 -0800 (PST) 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; bh=UsEauzpnF0xTbyTQmFmA3cve/0Nfa/HUrBhmQjSAj0Q=; b=YgEuoi71SqdeMh9zwF3/klGGgJQ8tpngYc18Cqt8tlepl5+dBUhbBGnBJra73nOuLm sMjDm+TY+b86SNwu5o/sNBJ/8c3eTco/vTlpagyti+NqsFn9MPnNbo01qWaH14Qx6rJW bxVD/HuYxVReA0W5woJdBm0TLoVEp/QYqMqYmenRxOuuebE9Oug1o5ZWEqUVVzHKlilG +Q1VkoPxe/ZGrflr0IF/V14/8ekQyqO8eyD6ERtVXVfo6T3fCC40TnH9yd/OZ/OUr0Jl 1hE2z5ZtkjM4KEskmQ9ism0w+aBhlU+wxApIWg7x3P8VcaDovP0tZDgus5negUO/AHxu 8fRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=UsEauzpnF0xTbyTQmFmA3cve/0Nfa/HUrBhmQjSAj0Q=; b=BrEgTvoHSMjZtoyDb36v/K/8/+Dq3NoVG6mLcL2yHKiEGcOVnr9hP9bt+S2Lk6fGla xyDvirkX15MyhE1nhod4dHDD9sbE4z4p+qh2eV0Hlyr1yVdhr3V9wtmfbcHgqtMZwF7T qBKFjxSv8MoZqD9NlnDN0gfkVPXDziNeESEnycKyo1PimtEorj5ahf05vOjhf9UsmIA1 IPXix910nEPYqqCCiRFVlMWGhzXdO3NTuBI9M44950jL9seXS8EJ5Qv6dWfGxSXFWthS tGcIaof1vaXvujaW2IzH1c5UFIHhBOvj27TFBZuQmhO17eLPkDNUKsTBgCJly0y1MSM9 150A== X-Gm-Message-State: AKGB3mJbJrEnBLr8QzFg1ALDlluAqFtiH8xSrce9LCDt3FCOSXcrbL6o ishnhj4DUbs7WEfBAVUYEgVPDSznDn7eGXetkYJEiw== X-Google-Smtp-Source: ACJfBov4nlghbxV+5A44eV74oO2LLYDp+9T2LVr7/vl0I6u4oCJiJbtYPHrPnkl/nItYTNrc2kBP+/BYXmZYS04OyXI= X-Received: by 10.107.175.234 with SMTP id p103mr22569621ioo.63.1514669261955; Sat, 30 Dec 2017 13:27:41 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Sat, 30 Dec 2017 13:27:41 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <201712302056.vBUKuR5L077619@pdx.rh.CN85.dnsmgr.net> References: <201712302056.vBUKuR5L077619@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Sat, 30 Dec 2017 14:27:41 -0700 X-Google-Sender-Auth: 7a3YxOxH62yirBAiDMREwXFs2t4 Message-ID: Subject: Re: svn commit: r327379 - head/sys/isa To: "Rodney W. Grimes" Cc: Warner Losh , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 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: Sat, 30 Dec 2017 21:27:43 -0000 On Sat, Dec 30, 2017 at 1:56 PM, Rodney W. Grimes < freebsd@pdx.rh.cn85.dnsmgr.net> wrote: > > On Sat, Dec 30, 2017 at 10:09 AM, Rodney W. Grimes < > > freebsd@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > [ Charset UTF-8 unsupported, converting... ] > > > > On Sat, Dec 30, 2017 at 8:27 AM, Rodney W. Grimes < > > > > freebsd@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > > > > [ Charset UTF-8 unsupported, converting... ] > > > > > > Author: imp > > > > > > Date: Sat Dec 30 08:16:31 2017 > > > > > > New Revision: 327379 > > > > > > URL: https://svnweb.freebsd.org/changeset/base/327379 > > > > > > > > > > > > Log: > > > > > > On further testing on actual machines with this hardware, we > should > > > > > > only warn for devices that are attached. Add missing \n. > > > > > > > > > > > > Modified: > > > > > > head/sys/isa/isa_common.c > > > > > > > > > > > > Modified: head/sys/isa/isa_common.c > > > > > > ============================================================ > > > > > ================== > > > > > > --- head/sys/isa/isa_common.c Sat Dec 30 07:59:32 2017 > > > (r327378) > > > > > > +++ head/sys/isa/isa_common.c Sat Dec 30 08:16:31 2017 > > > (r327379) > > > > > > @@ -573,9 +573,10 @@ isa_probe_children(device_t dev) > > > > > > > > > > > > err = device_probe_and_attach(child); > > > > > > if (err == 0 && idev->id_vendorid == 0 && > > > > > > - strcmp(kern_ident, "GENERIC") == 0) > > > > > > + strcmp(kern_ident, "GENERIC") == 0 && > > > > > > + device_is_attached(child)) > > > > > > device_printf(child, > > > > > > - "non-PNP ISA device will be removed > from > > > > > GENERIC in FreeBSD 12."); > > > > > > + "non-PNP ISA device will be removed > from > > > > > GENERIC in FreeBSD 12.\n"); > > > > > > > > > > Hat: RE > > > > > > > > > > Do you plan to give this notice in 11.x? (Technically a bit late, > > > > > it should of been in 11.0). > > > > > > > > > > > > > Yes. It will be MFC'd soon. Of course it should have happened in > 11.0, > > > but > > > > it didn't. But this notice is just about things in GENERIC. Not their > > > > actual removal (though most of them will be removed). The notice is > here > > > > because GENERIC is going to be cut to the bone once the PNP stuff I'm > > > > working on makes it viable to have all drivers (well, most) kld > loaded. > > > The > > > > only ones that will affect users, though, are the ones that are for > > > hinted > > > > devices which will have no autoloading. Hence this warning. > > > > > > Thanks for claifying. > > > > > > > > > > > > As giving it in 12.0 wont happen if you remove it in 12. Ie, as > you > > > > > have stated you want to remove this before we branch 12.0, if you > do > > > > > that this notice well never be seen by the users. Or well, they > might > > > > > get the notice, but the drivers well have already been removed. > > > > > > > > > > Or do you want to give notice in 12.* that it is being removed in > 13.0. > > > > > And that is not supporting these for 10 years, as 12.x should be > EOL > > > > > in a bit over 5 years from now if we cut in early 2018 which I > believe > > > > > to be the current target. > > > > > > > > > > > > > No. All non-PNP ISA devices will be removed from GENERIC in 12. That > is, > > > if > > > > they are still in the tree. A number will simply be gone, however. > I'll > > > be > > > > putting warnings in those drivers soon. It would have been ideal had > we > > > > done so earlier, but we didn't. Simple lack of notice, however, isn't > > > going > > > > to keep things in the tree. The following drivers will be removed in > 12: > > > > aha, adv, adw, bt, aic, ct, dpt, ncv, nsp, stg, mse, joy, cm and > likely > > > cx > > > > and rx. arcnet too will be removed. Still need to check on dangling > > > > references old TTY code as well that hasn't built in FreeBSD 8. This > list > > > > has circulated before, and I'll be codifying a run-time warning into > all > > > > these drivers on attach, plus getting a head-start on what to remove > in > > > 13. > > > > > > Many of those listed devices, though they have an ISA device, they also > > > support pci variants. I didnt check all of them, but I know from usage > > > that the bt and dpt drivers support PCI pnp cards just fine. > > > So is this more than just ISA axeing? > > > > > > adv, adw, bt, ncv and stg did have PCI variants. They are all old > parallel > ^^^ do? > > > scsi cards that are no longer relevant. All but adw only supported SCSI 1 > > speeds and an 8-bit width. adw did support wide SCSI (aka 16-bit), but > it's > > still a fairly low-level device, but was an unpopular card back in the > day. > > Um, this is what bothers me when this stuff comes up, claims that are > simply false are often made: > Adapter Bus Commands Description > BT-948 PCI 192 Ultra SCSI-3 > BT-958 PCI 192 Wide Ultra SCSI-3 > BT-958D PCI 192 Wide Differential Ultra SCSI-3 > > I am almost certain that the dpt family also has similiar > capabitlites. I stand corrected. I know I cloned the buslogic driver to make the aha driver, which is definitely isa only. I just wonder how many of these units we have actually deployed still... > This was the list that jhb circulated about a year ago. I'm just trying to > > formalize it in case something that's on it that shouldn't be. > > I am fine with axeing the ISA portions of these drivers, but for at > least the bt and dpt famility I believe that the PCI pnp driver should > continue to live. Fair enough, I guess. I'll remove them from the list to make it go down more easily. > > FreeBSD has grown large. While you can still boot it on that old 32MB > > > > machine, you really want 128MB or more to do anything useful. You > need at > > > > least 2GB or a heck of a lot of swap to self-host. We should simply > be > > > > removing the really old stuff that wouldn't be on a machine that > size. > > > > Expect more announcements like this to be coming soon from the people > > > that > > > > have been taking are of and feeding this old stuff for too long. If > we > > > cut > > > > with the 128MB criteria, the list would be much, much longer, and the > > > cuts > > > > much deeper. > > > > > > I have a large pile of VM's running in 64MB, and only have to bump to > 128MB > > > when I load a GENERIC, which that only became an issue with 11.x. > These > > > 64MB vm's are running with out swap and 12MB of free memory. > > > > > > We get really fun failures trying to boot GENERIC on a 12 snapshot with > > > even 128MB due to the WITNESS/DEBUG bloat. > > > > > > > And a bazillion drivers you don't need taking up 20MB in GENERIC! > Yes, I really do like your devmatch thing that allows us to remove > many of these from GENERIC and just load them. And I think more is > loadable than some realize. Technically since loader can load a > device driver and a filesystem that code doesnt need to be there > either. As a case in point the default ZFS install does not have > ZFS in the kernel, it is loaded at boot time. The same -could- > be done with UFS. > > > PLEASE again, do not dismiss "32MB" as old machines, this is a VERY real > > > and ideal situation for those deploying mass VM instances. > > > > > > 32MB is a very different experience than 64MB. Even with a kernel that's > > stripped to the bone, you're doing good to have 18MB free in single user > > and I've not been able to make it to a login prompt yet.... But a VM is > > quite different than actual hardware.... Please don't get the two > confused. > > -r-xr-xr-x 1 root wheel 6148944 Nov 10 02:01 /boot/kernel/kernel > # uname -a > FreeBSD ns1.rh.CN85.dnsmgr.net 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 > #0: Fri Nov 10 02:01:56 UTC 2017 root@bld-11.0-p1-i386.dnsmgr. > net:/A/src/sys/i386/compile/CUSTOMVB i386 > And this is just stripped, not stripped to the bone. > Right. I have similar (size says 5.6MB), and have 18MB free on my real P150 hardware with 32MB. > Hypervisor: Origin = "bhyve bhyve " > real memory = 67108864 (64 MB) > avail memory = 55230464 (52 MB) > Event timer "LAPIC" quality 600 > > And up multiuser it still has 15MB of free memory, let me boot single > user.... > So that's similar to what I'm seeing. But this is for a 64MB machine. 15 - 32 is a very small number. > Mem: 1156K Active, 2948K Inact, 6964K Wired, 530K Buf, 43M Free > > So, um, 64 - 43M == 21MB need to come up with that kernel single user, > mount ufs file systems, and exec top. > Right. Again, my point: 32M is possible with lots of work. 64MB is possible with some work. 128MB isn't too bad. 256MB is easy. Unless you want to self host, then you need 1-2GB or a boatload of swap and a lot of patience. When I say 128MB is a good 'minimum' I guess it's more a guideline. What machines, as in actual, physical hardware, are out there that can support at least 128MB of RAM. Now what machines don't. Is there a subset of those machines that we can easily trim from the system. Like certain older MIPS boards that can't do more than 32MB or 64MB. Or support for really old ISA cards that only made sense in systems that maxed out at 32MB or 64MB. Or some of the old armv4/5 hardware that can physically only address 64MB. I'm not saying we can't run in less than that, but that our target for 12 should generally be systems that support at least 128MB. For 13, we should double that again to 256MB (or maybe even 512MB): that would leave all the embedded 486 elan class out (since they maxed out at 128MB), would leave more armv4/5 boards out, if not all, more mips designs, etc. But that's not for another 2-3 years (hopefully not 5, that's too long between major releases). Again, when I say 128MB, I'm using it as a design parameter, not trying to take away your 64MB VMs, if they still work for you. I'm trying to narrow the scope of what we have in the base in recognition that support for that stuff buys us nothing, has a cost and is effectively maintainerless. Warner