From owner-cvs-src Sat Mar 8 23:15:51 2003 Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 382CB37B401; Sat, 8 Mar 2003 23:15:49 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC1E143F93; Sat, 8 Mar 2003 23:15:47 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.8/8.12.8) with ESMTP id h297FaNw070770; Sun, 9 Mar 2003 08:15:45 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Nate Lawson Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/sys devicestat.h From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 08 Mar 2003 19:03:19 PST." Date: Sun, 09 Mar 2003 08:15:36 +0100 Message-ID: <70769.1047194136@critter.freebsd.dk> Sender: owner-cvs-src@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Nate Lawson wri tes: >> Revision Changes Path >> 1.19 +14 -1 src/sys/sys/devicestat.h > >It would be nice to see some email on arch@ about this. There may have >been others working on functionality in this area. I have floated patches recently but gotten very little response. > >> @@ -121,6 +124,8 @@ >> } devstat_type_flags; >> >> struct devstat { >> + int sequence0; /* Update sequence# */ >> + int allocated; /* Allocated entry */ >> STAILQ_ENTRY(devstat) dev_links; >> u_int32_t device_number; /* >> * Devstat device >> @@ -203,12 +208,20 @@ >> */ >> devstat_type_flags device_type; /* Device type */ >> devstat_priority priority; /* Controls list pos. */ >> + >> + int sequence1; /* Update sequence# */ >> }; > >Is there a reason for adding one element at the beginning and one at the >end? Despite the fact this API is properly versioned, I believe accepted >practice is to add items at the end unless other requirements supersede >this one. Yes, these structures will be mmap'ed from kernel to userland and user land will (likely) memcpy() them to private storage as snapshot'ing. To be able to tell if you have an atomic snapshot, the two counters must be identical. >>+struct devstat *devstat_new_entry(const char *dev_name, >>+ int unit_number, u_int32_t block_size, >>+ devstat_support_flags flags, >>+ devstat_type_flags device_type, >>+ devstat_priority priority); > >This only differs from devstat_add_entry by the fact that it returns a new >devstat rather than leaving that to the user. Is there any reason not to >make this two separate calls: devstat_alloc and then devstat_add_entry? To be able to do the mmap stunt, they have to be allocated from special pages, so there is no option not to anymore. That's why there is only one call. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-src" in the body of the message