| 
				
			 | 
			
			
				
				@@ -49,15 +49,44 @@ 
			 | 
		
		
	
		
			
			| 
				49
			 | 
			
				49
			 | 
			
			
				
				  * 
			 | 
		
		
	
		
			
			| 
				50
			 | 
			
				50
			 | 
			
			
				
				  * @endcode 
			 | 
		
		
	
		
			
			| 
				51
			 | 
			
				51
			 | 
			
			
				
				  * 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				52
			 | 
			
			
				
				+ * For a description of the internal operation, see \ref buffer_int. 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				53
			 | 
			
			
				
				+ * 
			 | 
		
		
	
		
			
			| 
				52
			 | 
			
				54
			 | 
			
			
				
				  */ 
			 | 
		
		
	
		
			
			| 
				53
			 | 
			
				55
			 | 
			
			
				
				  
			 | 
		
		
	
		
			
			| 
				54
			 | 
			
				
			 | 
			
			
				
				-/** @package Internals 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				56
			 | 
			
			
				
				+/** @page buffer_int Buffer internals 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				57
			 | 
			
			
				
				+ * 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				58
			 | 
			
			
				
				+ * A buffer consists of a single, contiguous area of memory, some of 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				59
			 | 
			
			
				
				+ * which is "filled" and the remainder of which is "free".  The 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				60
			 | 
			
			
				
				+ * "filled" and "free" spaces are not necessarily contiguous. 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				61
			 | 
			
			
				
				+ * 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				62
			 | 
			
			
				
				+ * When a buffer is initialised via init_buffer(), it consists of a 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				63
			 | 
			
			
				
				+ * single free space.  As data is added to the buffer via 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				64
			 | 
			
			
				
				+ * fill_buffer(), this free space decreases and can become fragmented. 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				65
			 | 
			
			
				
				+ * 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				66
			 | 
			
			
				
				+ * Each free block within a buffer starts with a "tail byte".  If the 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				67
			 | 
			
			
				
				+ * tail byte is non-zero, this indicates that the free block is the 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				68
			 | 
			
			
				
				+ * tail of the buffer, i.e. occupies all the remaining space up to the 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				69
			 | 
			
			
				
				+ * end of the buffer.  When the tail byte is non-zero, it indicates 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				70
			 | 
			
			
				
				+ * that a descriptor (a @c struct @c buffer_free_block) follows the 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				71
			 | 
			
			
				
				+ * tail byte.  The descriptor describes the size of the free block and 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				72
			 | 
			
			
				
				+ * the address of the next free block. 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				73
			 | 
			
			
				
				+ * 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				74
			 | 
			
			
				
				+ * We cannot simply always start a free block with a descriptor, 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				75
			 | 
			
			
				
				+ * because it is conceivable that we will, at some point, encounter a 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				76
			 | 
			
			
				
				+ * situation in which the final free block of a buffer is too small to 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				77
			 | 
			
			
				
				+ * contain a descriptor.  Consider a protocol with a blocksize of 512 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				78
			 | 
			
			
				
				+ * downloading a 1025-byte file into a 1025-byte buffer.  Suppose that 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				79
			 | 
			
			
				
				+ * the first two blocks are received; we have now filled 1024 of the 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				80
			 | 
			
			
				
				+ * 1025 bytes in the buffer, and our only free block consists of the 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				81
			 | 
			
			
				
				+ * 1025th byte.  Using a "tail byte" solves this problem. 
			 | 
		
		
	
		
			
			| 
				55
			 | 
			
				82
			 | 
			
			
				
				  * 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				83
			 | 
			
			
				
				+ *  
			 | 
		
		
	
		
			
			| 
				56
			 | 
			
				84
			 | 
			
			
				
				  * Note that the rather convoluted way of manipulating the buffer 
			 | 
		
		
	
		
			
			| 
				57
			 | 
			
				85
			 | 
			
			
				
				  * descriptors (using copy_{to,from}_phys rather than straightforward 
			 | 
		
		
	
		
			
			| 
				58
			 | 
			
				86
			 | 
			
			
				
				  * pointers) is needed to cope with operation as a PXE stack, when we 
			 | 
		
		
	
		
			
			| 
				59
			 | 
			
				87
			 | 
			
			
				
				  * may be running in real mode or 16-bit protected mode, and therefore 
			 | 
		
		
	
		
			
			| 
				60
			 | 
			
				
			 | 
			
			
				
				- * cannot directly access arbitrary areas of memory. 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				88
			 | 
			
			
				
				+ * cannot directly access arbitrary areas of memory using simple 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				89
			 | 
			
			
				
				+ * pointers. 
			 | 
		
		
	
		
			
			| 
				61
			 | 
			
				90
			 | 
			
			
				
				  * 
			 | 
		
		
	
		
			
			| 
				62
			 | 
			
				91
			 | 
			
			
				
				  */ 
			 | 
		
		
	
		
			
			| 
				63
			 | 
			
				92
			 | 
			
			
				
				  
			 | 
		
		
	
	
		
			
			| 
				
			 | 
			
			
				
				@@ -203,10 +232,9 @@ static inline void unfree_block ( struct buffer *buffer, 
			 | 
		
		
	
		
			
			| 
				203
			 | 
			
				232
			 | 
			
			
				
				  * buffer_free_block) apart.  If this condition is not satisfied, data 
			 | 
		
		
	
		
			
			| 
				204
			 | 
			
				233
			 | 
			
			
				
				  * corruption will occur.  (See split_free_block() for details.) 
			 | 
		
		
	
		
			
			| 
				205
			 | 
			
				234
			 | 
			
			
				
				  * 
			 | 
		
		
	
		
			
			| 
				206
			 | 
			
				
			 | 
			
			
				
				- * @att In practice this is not a problem.  Callers of fill_buffer() 
			 | 
		
		
	
		
			
			| 
				207
			 | 
			
				
			 | 
			
			
				
				- * will be download protocols such as TFTP, and very few protocols 
			 | 
		
		
	
		
			
			| 
				208
			 | 
			
				
			 | 
			
			
				
				- * have a block size smaller than @c sizeof(struct @c 
			 | 
		
		
	
		
			
			| 
				209
			 | 
			
				
			 | 
			
			
				
				- * buffer_free_block). 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				235
			 | 
			
			
				
				+ * In practice this is not a problem.  Callers of fill_buffer() will 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				236
			 | 
			
			
				
				+ * be download protocols such as TFTP, and very few protocols have a 
			 | 
		
		
	
		
			
			| 
				
			 | 
			
				237
			 | 
			
			
				
				+ * block size smaller than @c sizeof(struct @c buffer_free_block). 
			 | 
		
		
	
		
			
			| 
				210
			 | 
			
				238
			 | 
			
			
				
				  * 
			 | 
		
		
	
		
			
			| 
				211
			 | 
			
				239
			 | 
			
			
				
				  */ 
			 | 
		
		
	
		
			
			| 
				212
			 | 
			
				240
			 | 
			
			
				
				 int fill_buffer ( struct buffer *buffer, const void *data, 
			 |