Nope. Unless I'm thinking of the wrong nvidia-agp patchfizz wrote:so to take full advantage of the nvidia agp patch, would i NOT include support for agpgart?
I have fixed these patches for -love2 (and -mm2) and combined them into one patch. I can send this to people, but maybe there's someone out there with web space who will post it?steel300 wrote:Yet To Do:
Runtime Selectable Block Scheduler
I could host them. I already have a variety of ebuilds and such on my server. But also send it to steel300, he can incorporate it into the love patchset, which I cannot.relyt wrote:I have fixed these patches for -love2 (and -mm2) and combined them into one patch. I can send this to people, but maybe there's someone out there with web space who will post it?steel300 wrote:Yet To Do:
Runtime Selectable Block Scheduler
Code: Select all
kernel (hd0,1)/boot/bzImage root=/dev/hda4 elevator=cfq
You make a good point. The answer is that most of the 'review' done at this level comes from being discriminating about where you accept patches from.asimon wrote:I just asked myself if anyone does actually review all those patches? Just wondering how easy it would be to get some evil(tm) code into the love-sources...
Code: Select all
--- elv-select.patch 2003-12-30 12:54:02.000000000 -0500
+++ elv-select.patch 2003-12-30 13:08:12.000000000 -0500
@@ -77,7 +77,7 @@
return;
- elevator_exit(q);
-+ if (e->elevator)
++ if (q->elevator)
+ elevator_exit(q);
del_timer_sync(&q->unplug_timer);
@@ -740,10 +740,8 @@
ad->current_batch_expires = jiffies + ad->batch_expire[REQ_SYNC];
ad->write_batch_count = ad->batch_expire[REQ_ASYNC] / 10;
-@@ -1823,8 +1786,58 @@ static int as_init(request_queue_t *q, e
+@@ -1823,6 +1786,56 @@ static int as_init(request_queue_t *q, e
ad->write_batch_count = 2;
-
- ad->new_success = 512;
+}
- return 0;Yes, apart from 5 small rejects it applies cleanly to mm2. The rejected stuff is already in mm2.lems wrote:By the way: There's a new ALSA Kernel patch available.
http://www.alsa-project.org/alsa/ftp/ke ... 0.patch.gz
I just booted into 2.6.1-rc-1-mm1 with alsa-bk-2003-12-30 and Con's 2.6.0-am-5.didl wrote:
2.6.1-rc1-mm1 is out
Alsa doesn't apply very nicely to 2.6.1-rc-1-mm1 for me! A few hunks fail.asimon wrote:I just booted into 2.6.1-rc-1-mm1 with alsa-bk-2003-12-30 and Con's 2.6.0-am-5.didl wrote:
2.6.1-rc1-mm1 is out
No, I did nothing to "fix" it. It's the same as above with 2.6.0-mm2. The few hunks which fail are already part of 2.6.0-mm2 and 2.6.1-rc-1-mm1 (looks like these are mostly spinlock fixes):didl wrote: Alsa doesn't apply very nicely to 2.6.1-rc-1-mm1 for me! A few hunks fail. Did you do anything to fix this??

Code: Select all
--- linux/include/linux/fb.h.orig 2004-01-01 05:49:13.422361696 -0600
+++ linux/include/linux/fb.h 2004-01-01 05:54:38.732906976 -0600
@@ -414,6 +414,14 @@
int currcon; /* Current VC. */
void *pseudo_palette; /* Fake palette of 16 colors */
struct device *dev; /* pointer to the device for this fb */
+#ifdef CONFIG_BOOTSPLASH
+ struct splash_data *splash_data;
+ unsigned char *splash_pic;
+ int splash_pic_size;
+ int splash_bytes;
+ char *silent_screen_base; /* real screen base */
+ char fb_cursordata[64];
+#endif
/* From here on everything is device dependent */
void *par;
};