From owner-freebsd-arch@freebsd.org Mon May 8 18:33:47 2017 Return-Path: Delivered-To: freebsd-arch@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 B3A76D63C23 for ; Mon, 8 May 2017 18:33:47 +0000 (UTC) (envelope-from vladimir@kondratyev.su) Received: from corp.infotel.ru (corp.infotel.ru [195.170.219.3]) by mx1.freebsd.org (Postfix) with ESMTP id 519E61F47 for ; Mon, 8 May 2017 18:33:46 +0000 (UTC) (envelope-from vladimir@kondratyev.su) Received: from corp (corp.infotel.ru [195.170.219.3]) by corp.infotel.ru (Postfix) with ESMTP id C583E1B882 for ; Mon, 8 May 2017 21:33:38 +0300 (MSK) X-Virus-Scanned: amavisd-new at corp.infotel.ru Received: from corp.infotel.ru ([195.170.219.3]) by corp (corp.infotel.ru [195.170.219.3]) (amavisd-new, port 10024) with ESMTP id 6K-anMc9zx41 for ; Mon, 8 May 2017 21:33:37 +0300 (MSK) Received: from mail.cicgroup.ru (unknown [195.170.219.74]) by corp.infotel.ru (Postfix) with ESMTP id C2AE61B87C for ; Mon, 8 May 2017 21:33:37 +0300 (MSK) Received: from mail.cicgroup.ru (localhost [127.0.0.1]) by mail.cicgroup.ru (Postfix) with ESMTP id E7D70574ABD for ; Mon, 8 May 2017 21:33:36 +0300 (MSK) X-Virus-Scanned: amavisd-new at cicgroup.ru Received: from mail.cicgroup.ru ([127.0.0.1]) by mail.cicgroup.ru (mail.cicgroup.ru [127.0.0.1]) (amavisd-new, port 10024) with SMTP id gNKNKmKYjVwM for ; Mon, 8 May 2017 21:33:34 +0300 (MSK) Received: from localhost (localhost [127.0.0.1]) by mail.cicgroup.ru (Postfix) with ESMTPA id 63D58574A91 for ; Mon, 8 May 2017 21:33:34 +0300 (MSK) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 08 May 2017 21:33:34 +0300 From: Vladimir Kondratyev To: freebsd-arch@freebsd.org Subject: psm(4) & atkbdc(4) locking Message-ID: X-Sender: vladimir@kondratyev.su User-Agent: Roundcube Webmail/1.2.2 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 18:33:47 -0000 Hi All In order to implement evdev support in psm(4) driver I`m going to add mutexes to psm and atkbdc drivers and mark psm interrupt and cdev handlers MPSAFE. Atkbd(4) is depending on Giant like before. Locking of these drivers seems to be low-hanging fruit as spl() calls are still in place but it has not occurred. Does someone know why it is not done yet? For reasons other than "Nobody took care of it"? Any hidden traps? Patches can be found here: https://reviews.freebsd.org/D10263 (atkbdc, serialize hw registers access) https://reviews.freebsd.org/D10264 (psm, serialize softc access, mark interrupt and cdev handlers MPSAFE) -- WBR Vladimir Kondratyev From owner-freebsd-arch@freebsd.org Mon May 8 18:39:04 2017 Return-Path: Delivered-To: freebsd-arch@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 19276D63E8B for ; Mon, 8 May 2017 18:39:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 BDD0A16F2 for ; Mon, 8 May 2017 18:39:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x230.google.com with SMTP id f102so55450521ioi.2 for ; Mon, 08 May 2017 11:39: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; bh=1IdFQODmytpB5aaEH+kz8LNe/Q2cM/B9T6GU+br1lZE=; b=G/FgTCn7nC5dioRJGgBSyDR8wc8J92gmT4EFtCzkkFXAFotkAbL80laGTcLYZnAJxu ni+5+yWH/r3EjddKpfdms45PvjfnX1IrR0AIuK900XKbGDpGQn6iN0We1E9RBYqujp73 MNRUHd5/LcOQvNRXYXyKK+jZhcyPsZNaq49gVV+ngC+9wtsJ7ICjJE4r0Sslxipwshn9 oxcq86fpDFRPOd8n3+k5Hyhsue66HlgUYANLoQfTPahRS7lhU6LhMLv/YrYCVIwMWKJz MTIT7uU2P0raEAn2bk5XVMdepZpqfnpxj1/n8gJXB2U6JGSAxH7LHJ5eLUGTkmAMKfmC pqIw== 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=1IdFQODmytpB5aaEH+kz8LNe/Q2cM/B9T6GU+br1lZE=; b=E+BSWu2SVcvjB1JF8ohkba5zE+wLssKWCKh1ENe/XnMkWd4H/uf2s6HI22V644NOgu syImTcN/rvymWd/xOWjJxPI5TWU1NFGOb/m+Kv7rmY8PKTX7PE1+7znv7ldUq0VZjspN ymtN+obTqs0qUHPxPLKxe1kkc6OWRD3ydxpQeX9JpLkp5ntlmKusGYJKydXHCkbpxyKW u/C/u9upZkbAdbJ3d1Bn71ryoxclDnGZgdZqlBChvmdpvlPGmCMJdE8OeVP64gxh+u9W RqqI3HYOjlXggryvE8HqEfA/62DrmyoKzfe+sswD3yuV1X54rxcTz0JFB+jCTmMNpc3I zPmQ== X-Gm-Message-State: AN3rC/4qkocqESv+XZE3AwVlqrcap6CwqX6sy/H00C09YNQ3t4vnmXpk D052R1qaP28nelZOh5Pr4aMVoqTKXg== X-Received: by 10.107.188.69 with SMTP id m66mr26719924iof.148.1494268742964; Mon, 08 May 2017 11:39:02 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.126.6 with HTTP; Mon, 8 May 2017 11:39:02 -0700 (PDT) X-Originating-IP: [2607:fb10:7021:1::333f] In-Reply-To: References: From: Warner Losh Date: Mon, 8 May 2017 12:39:02 -0600 X-Google-Sender-Auth: nUP--lUujce5_qy6bStK30QQCxE Message-ID: Subject: Re: psm(4) & atkbdc(4) locking To: Vladimir Kondratyev Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 18:39:04 -0000 On Mon, May 8, 2017 at 12:33 PM, Vladimir Kondratyev wrote: > Hi All > > In order to implement evdev support in psm(4) driver I`m going to add > mutexes to psm and atkbdc drivers and mark psm interrupt and cdev handlers > MPSAFE. > Atkbd(4) is depending on Giant like before. > > Locking of these drivers seems to be low-hanging fruit as spl() calls are > still in place but it has not occurred. > > Does someone know why it is not done yet? For reasons other than "Nobody > took care of it"? > Any hidden traps? Working rock-solid reliably in ddb(4) is what tripped me up when I started down this path 10 years ago. Understanding all the rules for that was a bridge too far for me given the time I had for the project then. If you have that covered (I haven't looked at the diffs yet), you're golden. Warner > Patches can be found here: > https://reviews.freebsd.org/D10263 (atkbdc, serialize hw registers access) > https://reviews.freebsd.org/D10264 (psm, serialize softc access, mark > interrupt and cdev handlers MPSAFE) > > -- > WBR > Vladimir Kondratyev > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Mon May 8 18:58:56 2017 Return-Path: Delivered-To: freebsd-arch@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 03BAED6368E; Mon, 8 May 2017 18:58:56 +0000 (UTC) (envelope-from vladimir@kondratyev.su) Received: from corp.infotel.ru (corp.infotel.ru [195.170.219.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8F3E51315; Mon, 8 May 2017 18:58:55 +0000 (UTC) (envelope-from vladimir@kondratyev.su) Received: from corp (corp.infotel.ru [195.170.219.3]) by corp.infotel.ru (Postfix) with ESMTP id 7CDAF1B98D; Mon, 8 May 2017 21:58:52 +0300 (MSK) X-Virus-Scanned: amavisd-new at corp.infotel.ru Received: from corp.infotel.ru ([195.170.219.3]) by corp (corp.infotel.ru [195.170.219.3]) (amavisd-new, port 10024) with ESMTP id q9bdRV5_3aNd; Mon, 8 May 2017 21:58:35 +0300 (MSK) Received: from mail.cicgroup.ru (unknown [195.170.219.74]) by corp.infotel.ru (Postfix) with ESMTP id 4ADA01B987; Mon, 8 May 2017 21:58:35 +0300 (MSK) Received: from mail.cicgroup.ru (localhost [127.0.0.1]) by mail.cicgroup.ru (Postfix) with ESMTP id 50D2B574ABD; Mon, 8 May 2017 21:58:34 +0300 (MSK) X-Virus-Scanned: amavisd-new at cicgroup.ru Received: from mail.cicgroup.ru ([127.0.0.1]) by mail.cicgroup.ru (mail.cicgroup.ru [127.0.0.1]) (amavisd-new, port 10024) with SMTP id VlOhyAJvWf2z; Mon, 8 May 2017 21:58:27 +0300 (MSK) Received: from localhost (localhost [127.0.0.1]) by mail.cicgroup.ru (Postfix) with ESMTPA id 15C0A574A91; Mon, 8 May 2017 21:58:27 +0300 (MSK) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 08 May 2017 21:58:27 +0300 From: Vladimir Kondratyev To: Warner Losh Cc: freebsd-arch@freebsd.org, owner-freebsd-arch@freebsd.org Subject: Re: psm(4) & atkbdc(4) locking In-Reply-To: References: Message-ID: <80600e8d3da7725a66e2a1e24cbfd916@kondratyev.su> X-Sender: vladimir@kondratyev.su User-Agent: Roundcube Webmail/1.2.2 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 18:58:56 -0000 On 2017-05-08 21:39, Warner Losh wrote: > On Mon, May 8, 2017 at 12:33 PM, Vladimir Kondratyev > wrote: >> Hi All >> >> In order to implement evdev support in psm(4) driver I`m going to add >> mutexes to psm and atkbdc drivers and mark psm interrupt and cdev >> handlers >> MPSAFE. >> Atkbd(4) is depending on Giant like before. >> >> Locking of these drivers seems to be low-hanging fruit as spl() calls >> are >> still in place but it has not occurred. >> >> Does someone know why it is not done yet? For reasons other than >> "Nobody >> took care of it"? >> Any hidden traps? > > Working rock-solid reliably in ddb(4) is what tripped me up when I > started down this path 10 years ago. I tried to avoid atkbd changes as much as possible. Patch adds atkbdc mutex acquisition before each hardware access and nothing more. I think mutexes should be ignored in ddb mode. > Understanding all the rules for > that was a bridge too far for me given the time I had for the project > then. If you have that covered (I haven't looked at the diffs yet), > you're golden. I`m not familiar with ddb internals, that is why i wrote first mail. > > Warner >> Patches can be found here: >> https://reviews.freebsd.org/D10263 (atkbdc, serialize hw registers >> access) >> https://reviews.freebsd.org/D10264 (psm, serialize softc access, mark >> interrupt and cdev handlers MPSAFE) >> -- WBR Vladimir Kondratyev From owner-freebsd-arch@freebsd.org Mon May 8 19:39:43 2017 Return-Path: Delivered-To: freebsd-arch@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 AD79DD638D5; Mon, 8 May 2017 19:39:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DCEABBF; Mon, 8 May 2017 19:39:43 +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 v48JdZOt081087 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 8 May 2017 22:39:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v48JdZOt081087 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v48JdZrV081086; Mon, 8 May 2017 22:39:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 8 May 2017 22:39:35 +0300 From: Konstantin Belousov To: Vladimir Kondratyev Cc: Warner Losh , owner-freebsd-arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: psm(4) & atkbdc(4) locking Message-ID: <20170508193935.GE1622@kib.kiev.ua> References: <80600e8d3da7725a66e2a1e24cbfd916@kondratyev.su> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80600e8d3da7725a66e2a1e24cbfd916@kondratyev.su> User-Agent: Mutt/1.8.2 (2017-04-18) 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: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 19:39:43 -0000 On Mon, May 08, 2017 at 09:58:27PM +0300, Vladimir Kondratyev wrote: > On 2017-05-08 21:39, Warner Losh wrote: > > On Mon, May 8, 2017 at 12:33 PM, Vladimir Kondratyev > > wrote: > >> Hi All > >> > >> In order to implement evdev support in psm(4) driver I`m going to add > >> mutexes to psm and atkbdc drivers and mark psm interrupt and cdev > >> handlers > >> MPSAFE. > >> Atkbd(4) is depending on Giant like before. > >> > >> Locking of these drivers seems to be low-hanging fruit as spl() calls > >> are > >> still in place but it has not occurred. > >> > >> Does someone know why it is not done yet? For reasons other than > >> "Nobody > >> took care of it"? > >> Any hidden traps? > > > > Working rock-solid reliably in ddb(4) is what tripped me up when I > > started down this path 10 years ago. > > I tried to avoid atkbd changes as much as possible. Patch adds atkbdc > mutex acquisition > before each hardware access and nothing more. I think mutexes should be > ignored in ddb mode. Locks are not ignored in kdb_active mode, and this is reasonable. Instead, kdb should not acquire locks at all. Consider a situation where you need to send a composite command to the hardware, which consists of several registers accesses, and the whole sequence of accesses is covered by a lock to ensure atomicity. Kdb may be entered at arbitrary moment, including the middle of the lock-protected section. This means that kdb might be entered with the lock owned by some thread, not neccessary the thread which was executing when entrance occured. More, the hardware state is some intermediate state of being commanded the composite sequence, not yet finished. I do not think that atkbd code correctly handles this situation now, and simply adding a lock there probably make things worse. > > > Understanding all the rules for > > that was a bridge too far for me given the time I had for the project > > then. If you have that covered (I haven't looked at the diffs yet), > > you're golden. > > I`m not familiar with ddb internals, that is why i wrote first mail. > > > > > Warner > > > >> Patches can be found here: > >> https://reviews.freebsd.org/D10263 (atkbdc, serialize hw registers > >> access) > >> https://reviews.freebsd.org/D10264 (psm, serialize softc access, mark > >> interrupt and cdev handlers MPSAFE) > >> > > -- > WBR > Vladimir Kondratyev > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Mon May 8 19:48:44 2017 Return-Path: Delivered-To: freebsd-arch@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 16E08D63E79 for ; Mon, 8 May 2017 19:48:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (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 BB5B417E1 for ; Mon, 8 May 2017 19:48:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x242.google.com with SMTP id 67so3775439itx.2 for ; Mon, 08 May 2017 12:48:43 -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; bh=3peXJ0wZKGtPtCfQhxN6AbwRzxUMGinjB7ec9XqR2D8=; b=rqklCcS742FYLeyyuupKp5fySExM4WZzd7BRsa049jTqnSUvoy6zDDkPqYxQWvwvhV mjSgfHraJ5P0fq2FUWg45I2NwccCsvSz9xneVwsQABE6RAa+Ly2vXEuQUPDTAZ9BTm6k yFJ3qAg0oOPzwcXOSS6oxVg2el9KSUZBLtxTmCPFCXb529HhHdbnmBnGIpwi/Qh9jYzj dJRZ4TmX37kSbn3aFpaGGPoJVG/f9XbPZTQCU4+eHmuXgzCYuh8Sgi9fdAhKDW4CaUJc 2nPlgtPjj7t++misgArwxjgp9J22Wi+oRwLbWZ8LUX/Cn6mWlaNoNu/TAp9p/FHo3EFJ Bz5w== 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=3peXJ0wZKGtPtCfQhxN6AbwRzxUMGinjB7ec9XqR2D8=; b=df0LpwgCvipyRXPCG5JSunbiBQqD1zztaA3ZLL6D/ZqlzsrYteqgHbGmwrdWyInUpd INXftn9OoRRe9HX/SMyqZdQ0iHqfTU2rQWdhABr/xlnNU+u68j340Y8fGGnmITAl5Q43 bJFPcDCQ0nFpJqqM6vXWRbAcW1/pMD5FTEpC0znqIJOdvpaRiE8ym5SEH5YHttffV3kx u2e3DYiyFlGO94jHI5/9LnX4yZmNCQjcnR1jDwm0ygddnAjbyre6TVFGzIkc/IuAwT2Z tOpippmGzHCpMVqzLsMWl8MNOSCxzcC4Na7+tYgr/NQRef8wkpEHZotsdrU1iMQji6dM EOSw== X-Gm-Message-State: AN3rC/4S+gfCGt8LdEZbaQu4vsqilnV8O5ltCzUVc654ESfZx3QyTEtE BCnwYN6Biy7XA7Kj0OLZnme0dlga5Q== X-Received: by 10.36.3.136 with SMTP id e130mr21528388ite.64.1494272922577; Mon, 08 May 2017 12:48:42 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.126.6 with HTTP; Mon, 8 May 2017 12:48:42 -0700 (PDT) X-Originating-IP: [2607:fb10:7021:1::333f] In-Reply-To: <20170508193935.GE1622@kib.kiev.ua> References: <80600e8d3da7725a66e2a1e24cbfd916@kondratyev.su> <20170508193935.GE1622@kib.kiev.ua> From: Warner Losh Date: Mon, 8 May 2017 13:48:42 -0600 X-Google-Sender-Auth: am7YQ9GvqW3v0KNZ6clj3BIlRow Message-ID: Subject: Re: psm(4) & atkbdc(4) locking To: Konstantin Belousov Cc: Vladimir Kondratyev , owner-freebsd-arch@freebsd.org, "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 19:48:44 -0000 On Mon, May 8, 2017 at 1:39 PM, Konstantin Belousov wrote: > On Mon, May 08, 2017 at 09:58:27PM +0300, Vladimir Kondratyev wrote: >> On 2017-05-08 21:39, Warner Losh wrote: >> > On Mon, May 8, 2017 at 12:33 PM, Vladimir Kondratyev >> > wrote: >> >> Hi All >> >> >> >> In order to implement evdev support in psm(4) driver I`m going to add >> >> mutexes to psm and atkbdc drivers and mark psm interrupt and cdev >> >> handlers >> >> MPSAFE. >> >> Atkbd(4) is depending on Giant like before. >> >> >> >> Locking of these drivers seems to be low-hanging fruit as spl() calls >> >> are >> >> still in place but it has not occurred. >> >> >> >> Does someone know why it is not done yet? For reasons other than >> >> "Nobody >> >> took care of it"? >> >> Any hidden traps? >> > >> > Working rock-solid reliably in ddb(4) is what tripped me up when I >> > started down this path 10 years ago. >> >> I tried to avoid atkbd changes as much as possible. Patch adds atkbdc >> mutex acquisition >> before each hardware access and nothing more. I think mutexes should be >> ignored in ddb mode. > Locks are not ignored in kdb_active mode, and this is reasonable. > Instead, kdb should not acquire locks at all. > > Consider a situation where you need to send a composite command to > the hardware, which consists of several registers accesses, and the > whole sequence of accesses is covered by a lock to ensure atomicity. > Kdb may be entered at arbitrary moment, including the middle of the > lock-protected section. This means that kdb might be entered with the > lock owned by some thread, not neccessary the thread which was executing > when entrance occured. More, the hardware state is some intermediate > state of being commanded the composite sequence, not yet finished. Yes. This is the snag I ran into... > I do not think that atkbd code correctly handles this situation now, > and simply adding a lock there probably make things worse. It did for me, since breaking to keyboard was totally broken by the changes I made to try to lock things since it was quite likely to interrupt things when locks were held... I had a very naive implementation, which wasn't up to the task, so some care is needed. But this was in the 5.x or 6.x time frame, and the locking situation wrt GIANT is much better today than then... I don't think it's a huge problem, but just one that the implementor needs to be aware of... Since I was unaware of all the details up front, I came up with a solution that couldn't possibly work so I abandoned it. Warner >> > Understanding all the rules for >> > that was a bridge too far for me given the time I had for the project >> > then. If you have that covered (I haven't looked at the diffs yet), >> > you're golden. >> >> I`m not familiar with ddb internals, that is why i wrote first mail. >> >> > >> > Warner >> >> >> >> Patches can be found here: >> >> https://reviews.freebsd.org/D10263 (atkbdc, serialize hw registers >> >> access) >> >> https://reviews.freebsd.org/D10264 (psm, serialize softc access, mark >> >> interrupt and cdev handlers MPSAFE) >> >> >> >> -- >> WBR >> Vladimir Kondratyev >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Mon May 8 21:02:50 2017 Return-Path: Delivered-To: freebsd-arch@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 BFD76D63B9A; Mon, 8 May 2017 21:02:50 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 4FF9DE5B; Mon, 8 May 2017 21:02:49 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id CA5D91049388; Tue, 9 May 2017 07:02:39 +1000 (AEST) Date: Tue, 9 May 2017 07:02:35 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Warner Losh cc: Konstantin Belousov , "freebsd-arch@freebsd.org" , Vladimir Kondratyev , owner-freebsd-arch@freebsd.org Subject: Re: psm(4) & atkbdc(4) locking In-Reply-To: Message-ID: <20170509055914.N18777@besplex.bde.org> References: <80600e8d3da7725a66e2a1e24cbfd916@kondratyev.su> <20170508193935.GE1622@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=WvBbCZXv c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=pGLkceISAAAA:8 a=5kqv1pd6HEkGC7XHVJAA:9 a=CjuIK1q_8ugA:10 a=6kGIvZw6iX1k4Y-7sg4_:22 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 21:02:51 -0000 On Mon, 8 May 2017, Warner Losh wrote: > On Mon, May 8, 2017 at 1:39 PM, Konstantin Belousov wrote: >> On Mon, May 08, 2017 at 09:58:27PM +0300, Vladimir Kondratyev wrote: >>> On 2017-05-08 21:39, Warner Losh wrote: >>>> On Mon, May 8, 2017 at 12:33 PM, Vladimir Kondratyev >>>> wrote: >>>>> Hi All >>>>> >>>>> In order to implement evdev support in psm(4) driver I`m going to add >>>>> mutexes to psm and atkbdc drivers and mark psm interrupt and cdev >>>>> handlers >>>>> MPSAFE. >>>>> Atkbd(4) is depending on Giant like before. >>>>> >>>>> Locking of these drivers seems to be low-hanging fruit as spl() calls >>>>> are >>>>> still in place but it has not occurred. High-hanging fruit. it is a lot of work to replace the buggy locking by something that works, without causing deadlocks instead of relatively harmless races. >>>>> Does someone know why it is not done yet? For reasons other than >>>>> "Nobody >>>>> took care of it"? >>>>> Any hidden traps? There is ddb (discussed below), and also syscons calling the keyboard driver. syscons is still Giant-locked, partly because keyboard drivers are. The common Giant lock works more simply than separate non Giant ones. The same non-Giant lock for both would would have some of the complexities of Giant without the support already being there. >>>> Working rock-solid reliably in ddb(4) is what tripped me up when I >>>> started down this path 10 years ago. >>> >>> I tried to avoid atkbd changes as much as possible. Patch adds atkbdc >>> mutex acquisition >>> before each hardware access and nothing more. I think mutexes should be >>> ignored in ddb mode. They are only ignored if you do it explicitly, but this is fragile. If the hardware works after ignoring locks while in kdb mode, then it must work after ignoring locks in all modes. >> Locks are not ignored in kdb_active mode, and this is reasonable. >> Instead, kdb should not acquire locks at all. (This should be ddb_active mode. Only ddb uses the keyboard. But there is only a flag for kdb.) See my recent fixes for syscons. These basically lock console output correctly, but for the keyboard they depend on keyboard drivers having no locking and not needing any (really, both syscons and keyboard drivers are supposed to be locked by a common lock which is Giant, but this doesn't work for i/o in kdb mode and is fragile for low-level console output not in kdb mode. My tests arrange for console output from almost to worst places where it shouldn't be done (from IPI STOP handlers, where the CPU doing the output must succeed despite other CPUs that have already been stopped holding console driver locks). Keyboard drivers are harder to test in this context, and are sure to fail. so I don't try hard to test them. However, kdb and panics in this context sometime reach the keyboard driver. Also, on syscons entry in such context, it tries to not use keyboard drivers if not necessary. >> Consider a situation where you need to send a composite command to >> the hardware, which consists of several registers accesses, and the >> whole sequence of accesses is covered by a lock to ensure atomicity. >> Kdb may be entered at arbitrary moment, including the middle of the >> lock-protected section. This means that kdb might be entered with the >> lock owned by some thread, not neccessary the thread which was executing >> when entrance occured. More, the hardware state is some intermediate >> state of being commanded the composite sequence, not yet finished. AT keyboards don't seem to mind some corruption of the hardware state. In general, provided a bad state doesn't destroy the device, then at worst the driver can probably recover by resetting everything after a timeout. My fixes are simpler and more complete for sio. They are simpler because the driver only has 1 lock for input and output (but this lock is also shared between sio devices, which gives problems related to those for Giant -- console output is supposed to be immediate and must be synchronous, but you are forced to wait for other devices). sio always did an almost complete state switch for console entry and exit. This is possible since the device registers are read-write and restoring them works as well as a reset for getting back to a usable state. My recent fixes mainly add some control of the nesting for the stacked states, and extra care for some !kdb cases. > Yes. This is the snag I ran into... > >> I do not think that atkbd code correctly handles this situation now, >> and simply adding a lock there probably make things worse. Yes, it would just give deadlock. See my recent fixes. atkbd currently requires Giant locking, but this is obviously impossible for low-level console i/o (even without ddb). Syscons used to do null locking in this case, without really trying. Initially it used non-null spls, but spls don't work at all for this use (since spl only locks out interrupts). Then when syscons was converted to Giant, Giant works too well for hiding itself, so syscons has almost no explicit references to Giant, and certainly none for low-level-console i/o where they wouldn't work. Giant also works well for locking out the interrupt handlers, but converting the spls to null ones made them do even less than before to accidentally limit console i/o. If you sprinkle locks that actually, work, then deadlock is certain in some cases. If you use recursive locks like syscons still does, then they will often avoid deadlock but won't actually work. They reduce to null spls if they are already held by the same thread. Typical examples of deadlocks are: - thread holding lock is stopped in IPI STOP handler - another thread calls the console driver, perhaps to report a problem in its IPI STOP handler Typical examples of recursive (or otherwise ignored) locks not actually working when the are needed are: - thread is in super-critical region of console driver and aquires lock. This should be a spinlock, and interrupts should be disabled (this is a side effect of spinlocks) - NMIs and traps cannot be disabled. They are often caused by NMI IPI STOPs and debugger traps. Since the region is super-critical, i/o should not be done, at least blindly. But recursive locks are useless for stopping the i/o, since the same thread owns the lock. Ignoring the lock in kdb mode is equally dangerous. > It did for me, since breaking to keyboard was totally broken by the > changes I made to try to lock things since it was quite likely to > interrupt things when locks were held... I had a very naive > implementation, which wasn't up to the task, so some care is needed. > But this was in the 5.x or 6.x time frame, and the locking situation > wrt GIANT is much better today than then... Not much better. There are just more deadlocks and less races now. Lots of deadlocks were added even at the printf() and msgbuf level. One deadlock in cnputs() was there for many years. Output is now droppped there instead. > I don't think it's a huge problem, but just one that the implementor > needs to be aware of... Since I was unaware of all the details up > front, I came up with a solution that couldn't possibly work so I > abandoned it. The difficulties are mostly in complex hardware and drivers. The only method that is sure to work is complete reinitialization/reset whenever needed (including before the normal driver is probed), without losing too much i/o. To take shortcuts in this, so that it doesn't take as much code as the normal driver, you have to understand the hardware better than is needed for writing the normal driver. Bruce From owner-freebsd-arch@freebsd.org Mon May 8 21:03:37 2017 Return-Path: Delivered-To: freebsd-arch@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 641E7D63BF8; Mon, 8 May 2017 21:03:37 +0000 (UTC) (envelope-from vladimir@kondratyev.su) Received: from corp.infotel.ru (corp.infotel.ru [195.170.219.3]) by mx1.freebsd.org (Postfix) with ESMTP id D499312F6; Mon, 8 May 2017 21:03:36 +0000 (UTC) (envelope-from vladimir@kondratyev.su) Received: from corp (corp.infotel.ru [195.170.219.3]) by corp.infotel.ru (Postfix) with ESMTP id F15841BF70; Tue, 9 May 2017 00:03:29 +0300 (MSK) X-Virus-Scanned: amavisd-new at corp.infotel.ru Received: from corp.infotel.ru ([195.170.219.3]) by corp (corp.infotel.ru [195.170.219.3]) (amavisd-new, port 10024) with ESMTP id 6SF-dpfxiDyJ; Tue, 9 May 2017 00:03:17 +0300 (MSK) Received: from mail.cicgroup.ru (unknown [195.170.219.74]) by corp.infotel.ru (Postfix) with ESMTP id 0A0C61BF69; Tue, 9 May 2017 00:03:17 +0300 (MSK) Received: from mail.cicgroup.ru (localhost [127.0.0.1]) by mail.cicgroup.ru (Postfix) with ESMTP id EAB8A574A91; Tue, 9 May 2017 00:03:12 +0300 (MSK) X-Virus-Scanned: amavisd-new at cicgroup.ru Received: from mail.cicgroup.ru ([127.0.0.1]) by mail.cicgroup.ru (mail.cicgroup.ru [127.0.0.1]) (amavisd-new, port 10024) with SMTP id Wh6Mb0FnBZ9n; Tue, 9 May 2017 00:03:10 +0300 (MSK) Received: from localhost (localhost [127.0.0.1]) by mail.cicgroup.ru (Postfix) with ESMTPA id 64D78574ABD; Tue, 9 May 2017 00:03:10 +0300 (MSK) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 09 May 2017 00:03:10 +0300 From: Vladimir Kondratyev To: Konstantin Belousov Cc: freebsd-arch@freebsd.org, owner-freebsd-arch@freebsd.org Subject: Re: psm(4) & atkbdc(4) locking In-Reply-To: <20170508193935.GE1622@kib.kiev.ua> References: <80600e8d3da7725a66e2a1e24cbfd916@kondratyev.su> <20170508193935.GE1622@kib.kiev.ua> Message-ID: <295ff62aa24ca6d9fd1c47ea4544ccd3@kondratyev.su> X-Sender: vladimir@kondratyev.su User-Agent: Roundcube Webmail/1.2.2 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 21:03:37 -0000 On 2017-05-08 22:39, Konstantin Belousov wrote: > On Mon, May 08, 2017 at 09:58:27PM +0300, Vladimir Kondratyev wrote: >> On 2017-05-08 21:39, Warner Losh wrote: >> > On Mon, May 8, 2017 at 12:33 PM, Vladimir Kondratyev >> > wrote: >> >> Hi All >> >> >> >> In order to implement evdev support in psm(4) driver I`m going to add >> >> mutexes to psm and atkbdc drivers and mark psm interrupt and cdev >> >> handlers >> >> MPSAFE. >> >> Atkbd(4) is depending on Giant like before. >> >> >> >> Locking of these drivers seems to be low-hanging fruit as spl() calls >> >> are >> >> still in place but it has not occurred. >> >> >> >> Does someone know why it is not done yet? For reasons other than >> >> "Nobody >> >> took care of it"? >> >> Any hidden traps? >> > >> > Working rock-solid reliably in ddb(4) is what tripped me up when I >> > started down this path 10 years ago. >> >> I tried to avoid atkbd changes as much as possible. Patch adds atkbdc >> mutex acquisition >> before each hardware access and nothing more. I think mutexes should >> be >> ignored in ddb mode. > Locks are not ignored in kdb_active mode, and this is reasonable. > Instead, kdb should not acquire locks at all. > > Consider a situation where you need to send a composite command to > the hardware, which consists of several registers accesses, and the > whole sequence of accesses is covered by a lock to ensure atomicity. > Kdb may be entered at arbitrary moment, including the middle of the > lock-protected section. This means that kdb might be entered with the > lock owned by some thread, not neccessary the thread which was > executing > when entrance occured. More, the hardware state is some intermediate > state of being commanded the composite sequence, not yet finished. > Sending a composite command does not happen on regular operation. It can happen on initialization, errors, led state changing and some ioctls only, so i can change patch to protect them with giant as before. But receive path is looking more complex as there are 2 data queues that can be filled in both interrupt and polling ways Nevertheless, there is simple fallback way: just add giant lock support to evdev > I do not think that atkbd code correctly handles this situation now, > and simply adding a lock there probably make things worse. > -- WBR Vladimir Kondratyev From owner-freebsd-arch@freebsd.org Tue May 9 19:09:35 2017 Return-Path: Delivered-To: freebsd-arch@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 8279CD6647F for ; Tue, 9 May 2017 19:09:35 +0000 (UTC) (envelope-from dds@FreeBSD.org) Received: from sphinx.otenet.gr (smtp-out34.otenet.gr [83.235.69.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4772CC46 for ; Tue, 9 May 2017 19:09:34 +0000 (UTC) (envelope-from dds@FreeBSD.org) Received: from [192.168.136.3] (ppp-2-87-107-206.home.otenet.gr [2.87.107.206]) by sphinx.otenet.gr (ESMTP) with ESMTPSA for ; Tue, 9 May 2017 22:09:30 +0300 (EEST) To: freebsd-arch@freebsd.org From: Diomidis Spinellis Subject: FreeBSD architecture diagram Message-ID: Date: Tue, 9 May 2017 22:09:32 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 19:09:35 -0000 I've tried to put together a rough diagram of the FreeBSD architecture. It's based on the corresponding books by Maurice Bach and McKusick/Neville-Neil, plus my personal categorization of manual pages and some source code browsing. You can find it online at https://dspinellis.github.io/unix-architecture/. I'd very much welcome any feedback you may have regarding important errors or missing elements. You can send feedback by email or through the GitHub repo that contains the diagram's source code: by opening issues or through pull requests. If there's interest I'd be happy to maintain it as a project of our community. Kind regards, Diomidis From owner-freebsd-arch@freebsd.org Wed May 10 07:31:22 2017 Return-Path: Delivered-To: freebsd-arch@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 6685BD6698D for ; Wed, 10 May 2017 07:31:22 +0000 (UTC) (envelope-from roberfern@gmail.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 2D4C21E27; Wed, 10 May 2017 07:31:22 +0000 (UTC) (envelope-from roberfern@gmail.com) Received: by mail-io0-x22f.google.com with SMTP id o12so8107652iod.3; Wed, 10 May 2017 00:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DZ/dfkb42ypV6Vv8dQRJK9duvEogYajf/S1kbXuvjyg=; b=Gqp7vLtiW564ojlneNuSE4tTfBljsi48mELI5K7awPrRhc4Tgl2EUeP627gBlPiKe6 WlJ3flXbyux80iwLedXxrvc315lk8iij+Is6YsWvKKXudlDkk+zgubuGiuLFrvZdm3C2 t04ZAV45lw4zN65BgOw8/iM452HYL4MSlHlHEKYCDGoqr3NWFIUXS9c09jx8eIg3SDVc csC5Hm3VGvX4Rm1W0+eRWuzvIj2ARijGgDj1DYEpwXC05BzPAqSTUZobZ0Xr0j6CS5BQ OTKdkMNZMBx1rnQkHOOFsziBoC/doIWabl2yAtPZE+rjGB4jTLfBsIV3bXCB2/DlLesg P38w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DZ/dfkb42ypV6Vv8dQRJK9duvEogYajf/S1kbXuvjyg=; b=kC261g9UoojLnLPyuKxWFeOQycDSgKjyMu1n/wSq+iSDedgDMb8BXH3cFdg0N0Rtpr t/+SZUFP1zNACX7R3IHEmO27CAY02atYctmKXClbWAHe72PS25QyhufSuJU3ZVkKBWZ/ 1L8UZPJn9TtPsBk6tPynAW7cT7goSp6A1P+DpEqNwswtrGWIthAiWSazTIAhfHgnrCME 1B0WVMjoBDPymLe9Iw1o/hAGmb7344QdVvN93j/qKXLV3pDYOW+ApgpCnx3e7SthQmMf hilOUSIXJcxqp9SGNF805uARJdReKpgNXayYHeIR4bWP2PL26+TrOtRDggE5dU4qHQs+ SA6g== X-Gm-Message-State: AODbwcC56XOCj/DZTU5QX0aebuikiswN/9a2NyIEDRXvVJarf43EUmsq xknO4ePnqGRNzKWMilx6OSb6CpW8Qg== X-Received: by 10.107.20.134 with SMTP id 128mr1999231iou.132.1494401481318; Wed, 10 May 2017 00:31:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.37.21 with HTTP; Wed, 10 May 2017 00:31:20 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Roberto_Fern=C3=A1ndez?= Date: Wed, 10 May 2017 09:31:20 +0200 Message-ID: Subject: Re: FreeBSD architecture diagram To: Diomidis Spinellis Cc: freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 07:31:22 -0000 2017-05-09 21:09 GMT+02:00 Diomidis Spinellis : > I've tried to put together a rough diagram of the FreeBSD architecture. > It's based on the corresponding books by Maurice Bach and > McKusick/Neville-Neil, You are forgetting to mention Robert Watson, he is also a co-writer of the book. > plus my personal categorization of manual pages and some source code > browsing. You can find it online at https://dspinellis.github.io/u > nix-architecture/. I'd very much welcome any feedback you may have > regarding important errors or missing elements. You can send feedback by > email or through the GitHub repo that contains the diagram's source code: > by opening issues or through pull requests. If there's interest I'd be > happy to maintain it as a project of our community. > > Kind regards, > > Diomidis > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@freebsd.org Wed May 10 10:03:00 2017 Return-Path: Delivered-To: freebsd-arch@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 ED8F3D640FF for ; Wed, 10 May 2017 10:03:00 +0000 (UTC) (envelope-from rockyhotas@post.com) Received: from mout.gmx.com (mout.gmx.com [74.208.4.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mail.gmx.com", Issuer "thawte SSL CA - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A9892D46; Wed, 10 May 2017 10:03:00 +0000 (UTC) (envelope-from rockyhotas@post.com) Received: from [95.250.64.53] by 3capp-mailcom-lxa05.server.lan (via HTTP); Wed, 10 May 2017 12:02:53 +0200 MIME-Version: 1.0 Message-ID: From: "Rocky Hotas" To: "Diomidis Spinellis" Cc: freebsd-arch@freebsd.org Subject: Re: FreeBSD architecture diagram Content-Type: text/plain; charset=UTF-8 Date: Wed, 10 May 2017 12:02:53 +0200 Importance: normal Sensitivity: Normal In-Reply-To: References: X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:SpJRiwiteok9HSa72f4RRxoB5Ez+FPkoIbIh2NMFzMP QaW7GBocc/U8ED0O8+wOlBK5vfrUxyaLK3yIyuLAY6A0VAuKHa BSFfzyg5cwt9qMk0ydXYfT3Q6pV8v3I4VPN/edSVmQXU380Q/8 HU6cI8dhMgZpTrj2OcGFpsM+zuJkqORwPl8Ar12Tb9aFnZn3Wd 86Q1Cgt5RcdfC9G1JDq5QH58YauqFQSPW7Ho1bYY/d7EicTYN1 fxcFM+MFQLZrTUSvQQ2GkVd6Ebi/S/FYPxg2qKqmLr4SLjcMf8 ifdtstaZLbcMWVl2fPelbQ3jME3 X-UI-Out-Filterresults: notjunk:1;V01:K0:U6RTB32V5XM=:66E+jS/SnEQfeYZiYe26/i w7SJThk8kcpVJhmdJxEaO0/aaC30OmnIrqG/6hISH7fN3SDKlikSwh/z3eTss0dez+ez8kYjv gcJHfHjU9l83IqkWIW25tcjP2VLF144k1D+mQJcxw0e9hwZC1lBofmm1f1EPHsJF+BH37/jSJ 3Ax79ZmlAZBASQRjdCMBeWU+qcv1V23eGehuUjsrCZNXH2g0k9eW7w0E6iMGrVHg0Oew8CwX8 2U5gklljbfmaY3PcZB3T/yA3OOL1mwm/ll8KTHKaIDkwaye6di3VDJiger8EC9eB9L/wsZVxb FjBlWsYDxaW7b9JyIlfZfFX5aeR1wWHa5P/YFwx55QWHiZGdWv5uhdPOzgf1Z50X19ai9ymg5 DkPsSkiL/97c/6DhNQuKs8yhO+wts2g3fUCQ5LUcJAqIvBAYLEBsmksuPueWqNYIF6x2EXps8 A/r7eqWZlQ== X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 10:03:01 -0000 Hi! > Sent: Tuesday, May 09, 2017 at 9:09 PM > From: "Diomidis Spinellis" > To: freebsd-arch@freebsd.org > Subject: FreeBSD architecture diagram > > I've tried to put together a rough diagram of the FreeBSD architecture. > It's based on the corresponding books by Maurice Bach and > McKusick/Neville-Neil, plus my personal categorization of manual pages > and some source code browsing. First of all, thank you for such a work, IMHO it is good and useful, also for new users. > I'd very much welcome > any feedback you may have regarding important errors or missing > elements. This is not an error report, but just a couple of suggestions. 1) Why don't you turn all the `vl' items inside the `hbox' in a Computer Modern Typewriter (fixed-width) font? They can be more readable and maybe even more recognizable, this way. 2) Another suggestion is about making another version of the pdf, with more than one page, where the single categories are expanded: more items can then be included, and (with the contribution of other users) some descriptions can be written as well, both for the category title and for the items themselves. > Kind regards, > > Diomidis Bye and thank you for your project! Rocky