|
@@ -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,
|