kernel_samsung_sm7125

jenna

Author	SHA1	Message	Date
Marcin Krol	53978d0a7a	brd: don't show ramdisks in /proc/partitions In 2.6.25, ramdisk devices show up in /proc/partitions, which is a behaviour change from the old rd.c. Add GENHD_FL_SUPPRESS_PARTITION_INFO, which was present in rd.c. All kernels prior to 2.6.25 weren't displaying ramdisks in /proc/partitions. Since there are many userspace tools using information from /proc/partitions some of them may now behave incorrectly (I didn't tested any though). For example before 2.6.25 /proc/partitions was empty if no block devices like hard disks and such were detected by kernel. Now all 16 ramdisks are always visible there. Some software may rely on such information (I mean, on empty /proc/partitions). There was quite similar situation back in 2004, and ramdisks were excluded back from displaying. Thats why I called this a regression (maybe a bit unfortunate). See this patch for info: http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.3-rc2/2.6.3-rc2-mm1/broken-out/nbd-proc-partitions-fix.patch I also think that someone somewhere (long time ago) excluded ramdisks from /proc/partitions for good reasons. It is possible that now such new "feature" is harmless, but I think there are more chances that someone will say "hey, /proc/partitions has changed, now my software doesn't work" then "hey where did my new 2.6.25 feature go". nbd devices are also excluded, maybe for very same (unknown to me) reasons. Signed-off-by: Marcin Krol <hawk@pld-linux.org> Signed-off-by: Nick Piggin <npiggin@suse.de> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>	17 years ago
Laurent Vivier	d7853d1f89	brd: modify ramdisk device to be able to manage partitions This patch adds partition management for Block RAM Device (BRD). This patch is done to keep in sync BRD and loop device drivers. This patch adds a parameter to the module, max_part, to specify the maximum number of partitions per RAM device. Example: # modprobe brd max_part=63 # ls -l /dev/ram* brw-rw---- 1 root disk 1, 0 2008-04-03 13:39 /dev/ram0 brw-rw---- 1 root disk 1, 64 2008-04-03 13:39 /dev/ram1 brw-rw---- 1 root disk 1, 640 2008-04-03 13:39 /dev/ram10 brw-rw---- 1 root disk 1, 704 2008-04-03 13:39 /dev/ram11 brw-rw---- 1 root disk 1, 768 2008-04-03 13:39 /dev/ram12 brw-rw---- 1 root disk 1, 832 2008-04-03 13:39 /dev/ram13 brw-rw---- 1 root disk 1, 896 2008-04-03 13:39 /dev/ram14 brw-rw---- 1 root disk 1, 960 2008-04-03 13:39 /dev/ram15 brw-rw---- 1 root disk 1, 128 2008-04-03 13:39 /dev/ram2 brw-rw---- 1 root disk 1, 192 2008-04-03 13:39 /dev/ram3 brw-rw---- 1 root disk 1, 256 2008-04-03 13:39 /dev/ram4 brw-rw---- 1 root disk 1, 320 2008-04-03 13:39 /dev/ram5 brw-rw---- 1 root disk 1, 384 2008-04-03 13:39 /dev/ram6 brw-rw---- 1 root disk 1, 448 2008-04-03 13:39 /dev/ram7 brw-rw---- 1 root disk 1, 512 2008-04-03 13:39 /dev/ram8 brw-rw---- 1 root disk 1, 576 2008-04-03 13:39 /dev/ram9 # fdisk /dev/ram0 Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel Building a new DOS disklabel. Changes will remain in memory only, until you decide to write them. After that, of course, the previous content won't be recoverable. Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite) Command (m for help): o Building a new DOS disklabel. Changes will remain in memory only, until you decide to write them. After that, of course, the previous content won't be recoverable. Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite) Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 1 First cylinder (1-2, default 1): 1 Last cylinder or +size or +sizeM or +sizeK (1-2, default 2): 2 Command (m for help): w The partition table has been altered! Calling ioctl() to re-read partition table. Syncing disks. # ls -l /dev/ram0* brw-rw---- 1 root disk 1, 0 2008-04-03 13:40 /dev/ram0 brw-rw---- 1 root disk 1, 1 2008-04-03 13:40 /dev/ram0p1 # mkfs /dev/ram0p1 mke2fs 1.40-WIP (14-Nov-2006) Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 4016 inodes, 16032 blocks 801 blocks (5.00%) reserved for the super user First data block=1 Maximum filesystem blocks=16515072 2 block groups 8192 blocks per group, 8192 fragments per group 2008 inodes per group Superblock backups stored on blocks: 8193 Writing inode tables: done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 26 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. # mount /dev/ram0p1 /mnt df /mnt Filesystem 1K-blocks Used Available Use% Mounted on /dev/ram0p1 15521 138 14582 1% /mnt # ls -l /mnt total 12 drwx------ 2 root root 12288 2008-04-03 13:41 lost+found # umount /mnt # rmmod brd Signed-off-by: Laurent Vivier <Laurent.Vivier@bull.net> Acked-by: Nick Piggin <nickpiggin@yahoo.com.au> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Jens Axboe <jens.axboe@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>	17 years ago
Jared Hulbert	30afcb4bd2	return pfn from direct_access, for XIP Alter the block device ->direct_access() API to work with the new get_xip_mem() API (that requires both kaddr and pfn are returned). Some architectures will not do the right thing in their virt_to_page() for use by XIP (to translate from the kernel virtual address returned by direct_access(), to a user mappable pfn in XIP's page fault handler. However, we can't switch it to just return the pfn and not the kaddr, because we have no good way to get a kva from a pfn, and XIP requires the kva for its read(2) and write(2) handlers. So we have to return both. Signed-off-by: Jared Hulbert <jaredeh@gmail.com> Signed-off-by: Nick Piggin <npiggin@suse.de> Cc: Carsten Otte <cotte@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: linux-mm@kvack.org Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>	17 years ago
Petr Tesarik	26defe34e4	fix brd allocation flags While looking at the implementation of the Ram backed block device driver, I stumbled across a write-only local variable, which makes little sense, so I assume it should actually work like this: Signed-off-by: Petr Tesarik <ptesarik@suse.cz> Signed-off-by: Nick Piggin <npiggin@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>	17 years ago
Nick Piggin	75acb9cd2e	rd: support XIP Support direct_access XIP method with brd. Signed-off-by: Nick Piggin <npiggin@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>	17 years ago
Nick Piggin	9db5579be4	rewrite rd This is a rewrite of the ramdisk block device driver. The old one is really difficult because it effectively implements a block device which serves data out of its own buffer cache. It relies on the dirty bit being set, to pin its backing store in cache, however there are non trivial paths which can clear the dirty bit (eg. try_to_free_buffers()), which had recently lead to data corruption. And in general it is completely wrong for a block device driver to do this. The new one is more like a regular block device driver. It has no idea about vm/vfs stuff. It's backing store is similar to the buffer cache (a simple radix-tree of pages), but it doesn't know anything about page cache (the pages in the radix tree are not pagecache pages). There is one slight downside -- direct block device access and filesystem metadata access goes through an extra copy and gets stored in RAM twice. However, this downside is only slight, because the real buffercache of the device is now reclaimable (because we're not playing crazy games with it), so under memory intensive situations, footprint should effectively be the same -- maybe even a slight advantage to the new driver because it can also reclaim buffer heads. The fact that it now goes through all the regular vm/fs paths makes it much more useful for testing, too. text data bss dec hex filename 2837 849 384 4070 fe6 drivers/block/rd.o 3528 371 12 3911 f47 drivers/block/brd.o Text is larger, but data and bss are smaller, making total size smaller. A few other nice things about it: - Similar structure and layout to the new loop device handlinag. - Dynamic ramdisk creation. - Runtime flexible buffer head size (because it is no longer part of the ramdisk code). - Boot / load time flexible ramdisk size, which could easily be extended to a per-ramdisk runtime changeable size (eg. with an ioctl). - Can use highmem for the backing store. [akpm@linux-foundation.org: fix build] [byron.bbradley@gmail.com: make rd_size non-static] Signed-off-by: Nick Piggin <npiggin@suse.de> Signed-off-by: Byron Bradley <byron.bbradley@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>	17 years ago

6 Commits (1beee8dc8cf58e3f605bd7b34d7a39939be7d8d2)