[lkml]   [2001]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Diff between 2.4.6pre3aa2 and 2.4.6pre5aa1:

Moved on top of 2.4.6pre5.

Only in 2.4.6pre3aa2: 00_alpha-warnings-1
Only in 2.4.6pre3aa2: 00_backout-udelay-1
Only in 2.4.6pre3aa2: 00_locks-1
Only in 2.4.6pre3aa2: 00_xircom-tulip-cb-2.4.5ac13-1
Only in 2.4.6pre3aa2: 10_alpha-udelay-1

Merged in pre5.

Only in 2.4.6pre5aa1: 00_alpha-irq_err_count-1

Fix alpha compile from Jeff.


Only in 2.4.6pre5aa1: 00_bh-async-1

Patch to to allow lowlevel layer
to override bh->b_end_io callback without breaking the
async I/O.

(nice to have)

Only in 2.4.6pre3aa2: 00_ksoftirqd-6
Only in 2.4.6pre5aa1: 00_ksoftirqd-7

%c1 do_softirq merged in mainline, fix reject.

Only in 2.4.6pre3aa2: 00_ksoftirqd-6_ppc-1
Only in 2.4.6pre5aa1: 00_ksoftirqd-7_ppc-2

Dropped a comment (no code change). ('and' is really needed
because lwz doesn't update the equal bit state of the cpu)

Only in 2.4.6pre3aa2: 10_no-virtual-1
Only in 2.4.6pre5aa1: 10_no-virtual-2

Comments generated rejects, fixup.

Only in 2.4.6pre3aa2/30_tux: 30_tux-2
Only in 2.4.6pre5aa1/30_tux: 30_tux-3

Include init.h to fix some compilation trouble and drop the
__KERNEL_SYSCALLS__ #defines from the .c files.

In the 40_experimental there's the latest blkdev in pagecache and it has
to be applied after all the other patches. Issue to solve in the
blkdev-pagecache-3 patch are:

- fix ramdisk: lookup on pagecache and pin blkdev address space
while the ramdisk stays allocated
- I/O granularity is fixed to 4k, this can be easily decreased with
a recompile, but I'm wondering if we should make the granularity
dynamic somehow to avoid the partial write to do too many
read-modify-write cycles
- Currently the pagecache assumes the end of the device is aligned
for excess on the next 4k (in genereal BUFFERED_BLOCKSIZE)
boundary to be sure we can read and write all bytes of the disk.
(see buffered_blk_size) I don't expect problems but blkdev layer
must be able to cope with it.

I'm running this patch on all my systems and I didn't had problems yet
(though you cannot expect to get ramdisk and in turn initrd working
[ramfs works fine of course]). As said in a earlier email you can do
rawio now by simply openeing the blkdev with O_DIRECT (however you get
the BUFFERED_BLOCKSIZE granularity for it too, instead of the
hardblocksize granularity of the /dev/raw rawio, but this also means you
pay less cycles for bulding a flood of 512 bytes large bh) and mmap
private and shared on the blkdev works like with files in the fs.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:55    [W:0.031 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site