linux-toradex.git/include/linux/rbtree.h, branch v2.6.27.50 Linux kernel for Apalis and Colibri modules [PATCH] rbtree: fixed reversed RB_EMPTY_NODE and rb_next/prev 2006-09-30T18:26:56+00:00 Jens Axboe axboe@suse.de 2006-07-11T19:15:52+00:00 10fd48f2376db52f08bf0420d2c4f580e39269e1 The conditions got reserved. Also make rb_next() and rb_prev() check for the empty condition. Signed-off-by: Jens Axboe <axboe@suse.de> 
The conditions got reserved. Also make rb_next() and rb_prev() check
for the empty condition.

Signed-off-by: Jens Axboe <axboe@suse.de>
[PATCH] rbtree: support functions used by the io schedulers 2006-06-23T15:10:39+00:00 Jens Axboe axboe@suse.de 2006-06-21T07:36:18+00:00 dd67d051529387f6e44d22d1d5540ef281965fdd They all duplicate macros to check for empty root and/or node, and clearing a node. So put those in rbtree.h. Signed-off-by: Jens Axboe <axboe@suse.de> 
They all duplicate macros to check for empty root and/or node, and
clearing a node. So put those in rbtree.h.

Signed-off-by: Jens Axboe <axboe@suse.de>
[RBTREE] Switch rb_colour() et al to en_US spelling of 'color' for consistency 2006-06-05T19:19:05+00:00 David Woodhouse dwmw2@infradead.org 2006-06-05T19:19:05+00:00 2f3243aebd8df4d9eecaeca04bbff6c7dbfb2142 Since rb_insert_color() is part of the _public_ API, while the others are purely internal, switch to be consistent with that. Signed-off-by: David Woodhouse <dwmw2@infradead.org> 
Since rb_insert_color() is part of the _public_ API, while the others are
purely internal, switch to be consistent with that.

Signed-off-by: David Woodhouse <dwmw2@infradead.org>
[RBTREE] Add explicit alignment to sizeof(long) for struct rb_node. 2006-04-21T22:15:39+00:00 David Woodhouse dwmw2@infradead.org 2006-04-21T22:15:39+00:00 e977145aeaad23d443686f2a2d5b32800d1607c5 Seems like a strange requirement, but allegedly it was necessary for struct address_space on CRIS, because it otherwise ended up being only byte-aligned. It's harmless enough, and easier to just do it than to prove it isn't necessary... although I really ought to dig out my etrax board and test it some time. Signed-off-by: David Woodhouse <dwmw2@infradead.org> 
Seems like a strange requirement, but allegedly it was necessary for
struct address_space on CRIS, because it otherwise ended up being only
byte-aligned. It's harmless enough, and easier to just do it than to
prove it isn't necessary... although I really ought to dig out my etrax
board and test it some time.

Signed-off-by: David Woodhouse <dwmw2@infradead.org>
[RBTREE] Merge colour and parent fields of struct rb_node. 2006-04-21T12:35:51+00:00 David Woodhouse dwmw2@infradead.org 2006-04-21T12:35:51+00:00 55a981027fc393c86de2c4e7836c9515088a9a58 We only used a single bit for colour information, so having a whole machine word of space allocated for it was a bit wasteful. Instead, store it in the lowest bit of the 'parent' pointer, since that was always going to be aligned anyway. Signed-off-by: David Woodhouse <dwmw2@infradead.org> 
We only used a single bit for colour information, so having a whole
machine word of space allocated for it was a bit wasteful. Instead,
store it in the lowest bit of the 'parent' pointer, since that was
always going to be aligned anyway.

Signed-off-by: David Woodhouse <dwmw2@infradead.org>
[RBTREE] Add accessor macros for colour and parent fields of rb_node 2006-04-21T12:12:44+00:00 David Woodhouse dwmw2@infradead.org 2006-04-21T12:12:44+00:00 7fe1e133bf45b0fe70491ed3d4c5b491feff7aa8 This is in preparation for merging those fields into a single 'unsigned long', because using a whole machine-word for a single bit of colour information is wasteful. Signed-off-by: David Woodhouse <dwmw2@infradead.org> 
This is in preparation for merging those fields into a single
'unsigned long', because using a whole machine-word for a single bit
of colour information is wasteful.

Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Linux-2.6.12-rc2 2005-04-16T22:20:36+00:00 Linus Torvalds torvalds@ppc970.osdl.org 2005-04-16T22:20:36+00:00 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip! 
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!