Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 09 Mar 2003 08:15:36 +0100
From:      "Poul-Henning Kamp" <phk@phk.freebsd.dk>
To:        Nate Lawson <nate@root.org>
Cc:        cvs-src@FreeBSD.org, src-committers@FreeBSD.org
Subject:   Re: cvs commit: src/sys/sys devicestat.h 
Message-ID:  <70769.1047194136@critter.freebsd.dk>
In-Reply-To: Your message of "Sat, 08 Mar 2003 19:03:19 PST." <Pine.BSF.4.21.0303081754050.90870-100000@root.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSF.4.21.0303081754050.90870-100000@root.org>, 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?70769.1047194136>