From owner-freebsd-hackers@freebsd.org Sun Jan 1 03:21:35 2017 Return-Path: Delivered-To: freebsd-hackers@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 76F9BC95355 for ; Sun, 1 Jan 2017 03:21:35 +0000 (UTC) (envelope-from shea@shealevy.com) Received: from smtprelay.hostedemail.com (smtprelay0062.hostedemail.com [216.40.44.62]) (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 39A931288 for ; Sun, 1 Jan 2017 03:21:34 +0000 (UTC) (envelope-from shea@shealevy.com) Received: from smtprelay.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by smtpgrave08.hostedemail.com (Postfix) with ESMTP id 059E4211214 for ; Sat, 31 Dec 2016 15:32:36 +0000 (UTC) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay05.hostedemail.com (Postfix) with ESMTP id C4163268E11 for ; Sat, 31 Dec 2016 15:32:27 +0000 (UTC) X-Session-Marker: 7368656140736865616C6576792E636F6D X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, shea@shealevy.com, :, RULES_HIT:41:355:379:599:800:871:960:966:968:973:988:989:1000:1260:1313:1314:1345:1359:1381:1437:1516:1518:1534:1541:1575:1711:1730:1747:1777:1792:2194:2196:2198:2199:2200:2201:2393:2559:2562:2731:3138:3139:3140:3141:3142:3354:3865:3866:3867:3868:3870:3871:3872:3874:4362:4385:5007:6261:6506:6747:7281:7909:8603:9010:9040:9108:10004:10848:11026:11232:11658:11914:12296:12438:12663:13138:13161:13229:13231:14096:14180:14181:14721:14819:21060:21080:21324:21433:30034:30041:30054:30070:30075, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:none, Custom_rules:0:0:0, LFtime:1, LUA_SUMMARY:none X-HE-Tag: price96_328b02b6bac01 X-Filterd-Recvd-Size: 3694 Received: from localhost (unknown [50.49.103.26]) (Authenticated sender: shea@shealevy.com) by omf06.hostedemail.com (Postfix) with ESMTPA for ; Sat, 31 Dec 2016 15:32:27 +0000 (UTC) From: Shea Levy To: freebsd-hackers@freebsd.org Subject: Re: Detecting changes when mapping /dev/devstat In-Reply-To: <87r34o3ity.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me> References: <87r34o3ity.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me> Date: Sat, 31 Dec 2016 10:32:26 -0500 Message-ID: <87mvfcnmgl.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2017 03:21:35 -0000 --=-=-= Content-Type: text/plain So looking into this more I see the thing to check is stat.allocated && stat.unit_number != -1. But there's a bigger problem of there being no good way (as far as I can tell) to know how big of a mapping we want! The number of devices is not enough, because depending on the order of calls to devstat_new_entry and devstat_remove_entry the actually active devices can live anywhere in the list. The best I can come up with is: * map successively larger multiples of the page size. * iterate through the map until I find numdevs structures with stat.allocated && stat.unit_number != -1 (and properly matching sequence numbers), mapping more pages in if needed. * Check the generation number and reiterate, possibly dropping pages if all devices are now available and adding them if needed. Can we do better? In particular, do we need to get the generation number to detect when to reiterate? Thanks, Shea Shea Levy writes: > Hi all, > > What is the appropriate way to detect changes when accessing devstat > info via a mapping of /dev/devstat? I'm interested both in changes to > the device list as a whole and new statistics on a given device. > > For new stats on a given device, it seems the only way to detect a new > stat is to check the sequence number for that device. Is that right? > > For changes in the device list, it's a bit less clear. My hope was that > I could map space for one more struct devstat than the current numdevs > and just check to see if some field or other is nonzero, but in my > glances through subr_devstat.c I'm not sure if there are any guarantees > about those fields for structures past the current list, especially if a > device was added and removed. Is there anything doable here? > > Thanks, > Shea > > P.S. I wasn't quite sure which list was appropriate for this question, > please feel free to point me to another! --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE6ESKvwKkwnxgMLnaXAvWlX2G/icFAlhnz4oACgkQXAvWlX2G /icsUhAAkggKWLIX4/gGh9QSR3+QgUOCBinhpwfBUcVLfILMvTuiJMyVrCazHJNH ovyGfA1naRtEOkp29hgAv1Y0KzhgU1erYqAx/TD86NEl0arWmWoGCXiEdsUkjmSl pOrn0i12Ijv8wvHRdL9NxvVJoW1tvIGuDozAQW69HJ2bQifU/cEFsxI3OTYhqiRv 6Cw0JTbXQzXrITYKKkcY3HZdUjFcKBG+XZ2YucPnLOCWK96/v6NZNXSYhtoaxPXL CyAjaujlKHGlgbMzoDW7emxkxTpg3R+yNa3q1G7LitGflrqzgE33URll1TDY9/Y8 4SkM4TNcpySRtxj4hUF4Vgj1mX97H5e6y7nC7brYAGGiHa9vKyf3WofGCA0zL77s 2hS9l4sFAhz996iYOQf0PPBrAOkhJzvTyN8SXxPSEq5iEBej5QL+9w9dKYb6mBBw uWQnYg2x9AsFqrv9oJU1i9I1SXYSkQmZf1MRuKgwwiDvltHmVWuo4mspP+ljnXqP je0mlG4/sjGa7JxPvRWDlhMsFylOaEvg7bBau/g/2OZ0vXfgZA0nHycQkSoK7Ofm XP0SjvzY9HFOY4AxjqXVdLq/2rsrU64OWZ0Mi/rHZa1Sf87J4UZsrYppQVeohdA+ ALnMgvE5kdMvYWO4/4FW/JM98hykkBrqey8iee+HqxW6eV3Xui4= =bMB3 -----END PGP SIGNATURE----- --=-=-=--