--- linux-2.6.24logfs/fs/Kconfig~logfs 2008-03-24 12:39:10.190939342 +0100
+++ linux-2.6.24logfs/fs/Kconfig 2008-04-01 19:48:18.517351063 +0200
@@ -1385,6 +1385,23 @@ config JFFS2_CMODE_FAVOURLZOendchoice
+config LOGFS
+ bool "Log Filesystem (EXPERIMENTAL)"
+ depends on (MTD || BLOCK) && EXPERIMENTAL
+ select ZLIB_INFLATE
+ select ZLIB_DEFLATE
+ select CRC32
+ help
+ Flash filesystem aimed to scale efficiently to large devices.
+ In comparison to JFFS2 it offers significantly faster mount
+ times and potentially less RAM usage, although the latter has
+ not been measured yet.
+
+ In its current state it is still very experimental and should
+ not be used for other than testing purposes.
+
+ If unsure, say N.
+
config CRAMFS
tristate "Compressed ROM file system support (cramfs)"
depends on BLOCK
--- linux-2.6.24logfs/fs/Makefile~logfs 2008-03-24 12:39:10.190939342 +0100
+++ linux-2.6.24logfs/fs/Makefile 2008-03-24 12:40:08.127616634 +0100
@@ -99,6 +99,7 @@ obj-$(CONFIG_NTFS_FS) += ntfs/
obj-$(CONFIG_UFS_FS) += ufs/
obj-$(CONFIG_EFS_FS) += efs/
obj-$(CONFIG_JFFS2_FS) += jffs2/
+obj-$(CONFIG_LOGFS) += logfs/
obj-$(CONFIG_AFFS_FS) += affs/
obj-$(CONFIG_ROMFS_FS) += romfs/
obj-$(CONFIG_QNX4FS_FS) += qnx4/
--- /dev/null 2008-03-30 12:15:48.586669308 +0200
+++ linux-2.6.24logfs/fs/logfs/Makefile 2008-04-01 19:48:07.170961891 +0200
@@ -0,0 +1,14 @@
+obj-$(CONFIG_LOGFS) += logfs.o
+
+logfs-y += compr.o
+logfs-y += dir.o
+logfs-y += file.o
+logfs-y += gc.o
+logfs-y += inode.o
+logfs-y += journal.o
+logfs-y += memtree.o
+logfs-y += readwrite.o
+logfs-y += segment.o
+logfs-y += super.o
+logfs-$(CONFIG_BLOCK) += dev_bdev.o
+logfs-$(CONFIG_MTD) += dev_mtd.o--
Is it really still the "Log Filesystem"? By now, I had the impression
that "logfs" is a name by itself, so it should be called the
"Logfs file system", and "config LOGFS_FS" respectively, likeYou shouldn't add the Makefile and Kconfig before adding the actual
files, or you could cause git-bisect problems.Arnd <><
--
"Logfs file system" might make sense. LOGFS_FS is something I would
rather avoid. For some reason my brain reacts strongly to repetition,I keep hearing that and I also continue to forget it. It shouldn't
matter either way, because it simply makes no sense to merge 15 seperate
patches file-by-file for something that is functionally one change. The
split is all about review and has nothing to do with merging.But if I finally remembered it, at least these comments would cease.
I'll try.Jörn
--
Beware of bugs in the above code; I have only proved it correct, but
not tried it.
-- Donald Knuth
--
How about LOG_FS then? I don't think there is a really good argument
either way, but a large majority uses the *_FS notation in Kconfig.Arnd <><
--
Fair enough.
Jörn
--
Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface.
-- Doug MacIlroy
--
[...]
Hi Joern,
can you make the Kconfig/Makefile changes the last patch? This will help git
bisect.Christian
--
I won't merge 15 patches anyway. The splitup is for review purposes
only. ;)Jörn
--
Sometimes, asking the right question is already the answer.
-- Unknown
--
| Greg Kroah-Hartman | [PATCH 004/196] Chinese: add translation of SubmittingPatches |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Willy Tarreau | Re: Linux 2.6.21 |
| Jan Kundrát | kswapd high CPU usage with no swap |
git: | |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
| David Miller | Re: [PATCH] tcp: splice as many packets as possible at once |
