Browse Source

More documentation

tags/v0.9.3
Michael Brown 19 years ago
parent
commit
e911a74724
2 changed files with 52 additions and 25 deletions
  1. 34
    6
      src/core/buffer.c
  2. 18
    19
      src/include/buffer.h

+ 34
- 6
src/core/buffer.c View File

49
  *
49
  *
50
  * @endcode
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
  * Note that the rather convoluted way of manipulating the buffer
84
  * Note that the rather convoluted way of manipulating the buffer
57
  * descriptors (using copy_{to,from}_phys rather than straightforward
85
  * descriptors (using copy_{to,from}_phys rather than straightforward
58
  * pointers) is needed to cope with operation as a PXE stack, when we
86
  * pointers) is needed to cope with operation as a PXE stack, when we
59
  * may be running in real mode or 16-bit protected mode, and therefore
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
  * buffer_free_block) apart.  If this condition is not satisfied, data
232
  * buffer_free_block) apart.  If this condition is not satisfied, data
204
  * corruption will occur.  (See split_free_block() for details.)
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
 int fill_buffer ( struct buffer *buffer, const void *data,
240
 int fill_buffer ( struct buffer *buffer, const void *data,

+ 18
- 19
src/include/buffer.h View File

3
 
3
 
4
 #include "stdint.h"
4
 #include "stdint.h"
5
 
5
 
6
-/*
7
- * "start" and "end" denote the real boundaries of the buffer.  "fill"
8
- * denotes the offset to the first free block in the buffer.  (If the
9
- * buffer is full, "fill" will equal ( end - start ) ).
6
+/* @file */
7
+
8
+/**
9
+ * A buffer
10
+ *
11
+ * @c start and @c end denote the real boundaries of the buffer, and
12
+ * are physical addresses.  @c fill denotes the offset to the first
13
+ * free block in the buffer.  (If the buffer is full, @c fill will
14
+ * equal @c end-start.)
10
  *
15
  *
11
  */
16
  */
12
 struct buffer {
17
 struct buffer {
13
-	physaddr_t	start;
14
-	physaddr_t	end;
15
-	off_t		fill;
18
+	physaddr_t	start;		/**< Start of buffer in memory */
19
+	physaddr_t	end;		/**< End of buffer in memory */
20
+	off_t		fill;		/**< Offset to first gap in buffer */
16
 };
21
 };
17
 
22
 
18
-/*
19
- * Free blocks in the buffer start with a "tail byte".  If non-zero,
20
- * this byte indicates that the free block is the tail of the buffer,
21
- * i.e. occupies all the remaining space up to the end of the buffer.
22
- * When the tail byte is non-zero, it indicates that the remainder of
23
- * the descriptor (the struct buffer_free_block) follows the tail
24
- * byte.
23
+/**
24
+ * A free block descriptor.
25
  *
25
  *
26
- * This scheme is necessary because we may end up with a tail that is
27
- * smaller than a struct buffer_free_block.
26
+ * See \ref buffer_int for a full description of the fields.
28
  *
27
  *
29
  */
28
  */
30
 struct buffer_free_block {
29
 struct buffer_free_block {
31
-	char		tail;
32
-	physaddr_t	next_free;
33
-	physaddr_t	end;
30
+	char		tail;		/**< Tail byte marker */
31
+	physaddr_t	next_free;	/**< Address of next free block */
32
+	physaddr_t	end;		/**< End of this block */
34
 } __attribute__ (( packed ));
33
 } __attribute__ (( packed ));
35
 
34
 
36
 /* Functions in buffer.c */
35
 /* Functions in buffer.c */

Loading…
Cancel
Save