Detecting changes when mapping /dev/devstat

[Shea Levy]

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 <shea at shealevy.com> 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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20161231/463f0bc2/attachment.sig>