hmm, dependencies

hmm, dependencies

[Redeeman]

hello.. reiser4 is now in mm, but i realize that nearly all of the stuff
that was mm specific when the move to mm was made, are probably merged
into upstream by now, i wonder, can anyone tell me exactly what from mm
it depends on?

thanks


-- 
Redeeman <redeeman@metanurb.dk>

Re: hmm, dependencies

[Vladimir Saveliev]

Hello

On Thu, 2004-12-16 at 22:56, Redeeman wrote:
> hello.. reiser4 is now in mm, but i realize that nearly all of the stuff
> that was mm specific when the move to mm was made, are probably merged
> into upstream by now, i wonder, can anyone tell me exactly what from mm
> it depends on?
> 
> thanks
> 

reiser4 got included into mm not because it needed something of it, but
rather because it is supposed that being in mm for certain amount of
time reiser4 will get a lot of testing and will prove that it is worth
to get included into stock kernel. 

Re: hmm, dependencies

[Redeeman]

On Fri, 2004-12-17 at 16:55 +0300, Vladimir Saveliev wrote:
> Hello
> 
> On Thu, 2004-12-16 at 22:56, Redeeman wrote:
> > hello.. reiser4 is now in mm, but i realize that nearly all of the stuff
> > that was mm specific when the move to mm was made, are probably merged
> > into upstream by now, i wonder, can anyone tell me exactly what from mm
> > it depends on?
> > 
> > thanks
> > 
> 
> reiser4 got included into mm not because it needed something of it, but
> rather because it is supposed that being in mm for certain amount of
> time reiser4 will get a lot of testing and will prove that it is worth
> to get included into stock kernel. 
im aware, however, the reiser4 patches in mm are against mm, which means
it depends on something from it, and i'd like to find out what :D so
that i can take it out and apply to vanilla along with reiser4
> 
> 
-- 
Redeeman <redeeman@metanurb.dk>

Re: hmm, dependencies

[Cal]

----------
and then at Fri, 17 Dec 2004 16:22:50 +0100, it was written ...
 >im aware, however, the reiser4 patches in mm are against mm, which means
 >it depends on something from it, and i'd like to find out what :D so
 >that i can take it out and apply to vanilla along with reiser4

That actually sounds like an awful lot of work, for questionable gain,
and I doubt you'll find anyone willing to undertake it for you.  For
reiser4 with vanilla (2.6.9 -> 2.6.10-rc3-bkX), try reiser4-for-2.6.9-3.gz
from namesys.  For 2.6.10-rc3+, you'll also need
reiser4-generic_acl-fix.patch (from 2.6.10-rc1-mm4/broken-out/).

Works for me.

cheers, Cal

Re: hmm, dependencies

[Vladimir Saveliev]

[-- Attachment #1: Type: text/plain, Size: 1284 bytes --]

Hello

On Fri, 2004-12-17 at 18:22, Redeeman wrote:
> On Fri, 2004-12-17 at 16:55 +0300, Vladimir Saveliev wrote:
> > Hello
> > 
> > On Thu, 2004-12-16 at 22:56, Redeeman wrote:
> > > hello.. reiser4 is now in mm, but i realize that nearly all of the stuff
> > > that was mm specific when the move to mm was made, are probably merged
> > > into upstream by now, i wonder, can anyone tell me exactly what from mm
> > > it depends on?
> > > 
> > > thanks
> > > 
> > 
> > reiser4 got included into mm not because it needed something of it, but
> > rather because it is supposed that being in mm for certain amount of
> > time reiser4 will get a lot of testing and will prove that it is worth
> > to get included into stock kernel. 
> im aware, however, the reiser4 patches in mm are against mm, which means
> it depends on something from it, and i'd like to find out what :D so
> that i can take it out and apply to vanilla along with reiser4

did you see ftp.namesys.com/pub/reiser4-for-2.6/2.6.9?
It contains all things which reiser4 depends on.

If you would like to add reiser4 to vanilla kernel yourself you would
have to add reiser4 patches of mm kernel to vanilla one:

people/akpm/patches/2.6/2.6.X/2.6.X-mmY/broken-out/reiser4-*
and add the patch i am attaching to this email.


[-- Attachment #2: reiser4-for-2.6.9.patch --]
[-- Type: text/plain, Size: 6796 bytes --]


This patch is to get reiser4 runable under not mm serie of kernel

diff -puN fs/reiser4/as_ops.c~reiser4-for-2.6.9 fs/reiser4/as_ops.c


 fs/reiser4/as_ops.c               |   18 +++++++++---------
 fs/reiser4/page_cache.c           |    8 ++++----
 fs/reiser4/plugin/file/file.c     |    8 ++++----
 fs/reiser4/plugin/object.c        |    1 -
 fs/reiser4/plugin/security/perm.c |    2 +-
 5 files changed, 18 insertions(+), 19 deletions(-)

diff -puN fs/reiser4/as_ops.c~reiser4-for-2.6.9 fs/reiser4/as_ops.c
--- linux-2.6.9/fs/reiser4/as_ops.c~reiser4-for-2.6.9	2004-12-08 16:27:45.008736629 +0300
+++ linux-2.6.9-vs/fs/reiser4/as_ops.c	2004-12-08 16:28:54.056614275 +0300
@@ -75,7 +75,7 @@ reiser4_clear_page_dirty(struct page *pa
 	mapping = page->mapping;
 	BUG_ON(mapping == NULL);
 
-	read_lock_irqsave(&mapping->tree_lock, flags);
+	spin_lock_irqsave(&mapping->tree_lock, flags);
 	if (TestClearPageDirty(page)) {
 		/* clear dirty tag of page in address space radix tree */
 		radix_tree_tag_clear(&mapping->page_tree, page->index,
@@ -84,12 +84,12 @@ reiser4_clear_page_dirty(struct page *pa
 		radix_tree_tag_clear(&mapping->page_tree, page->index,
 				     PAGECACHE_TAG_REISER4_MOVED);
 
-		read_unlock_irqrestore(&mapping->tree_lock, flags);
+		spin_unlock_irqrestore(&mapping->tree_lock, flags);
 		if (!mapping->backing_dev_info->memory_backed)
 			dec_page_state(nr_dirty);
 		return;
 	}
-	read_unlock_irqrestore(&mapping->tree_lock, flags);
+	spin_unlock_irqrestore(&mapping->tree_lock, flags);
 }
 
 /* as_ops->set_page_dirty() VFS method in reiser4_address_space_operations.
@@ -114,7 +114,7 @@ static int reiser4_set_page_dirty(struct
 		struct address_space *mapping = page->mapping;
 
 		if (mapping) {
-			read_lock_irq(&mapping->tree_lock);
+			spin_lock_irq(&mapping->tree_lock);
 			/* check for race with truncate */
 			if (page->mapping) {
 				assert("vs-1652", page->mapping == mapping);
@@ -126,7 +126,7 @@ static int reiser4_set_page_dirty(struct
 				radix_tree_tag_set(&mapping->page_tree,
 						   page->index, PAGECACHE_TAG_REISER4_MOVED);
 			}
-			read_unlock_irq(&mapping->tree_lock);
+			spin_unlock_irq(&mapping->tree_lock);
 			__mark_inode_dirty(mapping->host, I_DIRTY_PAGES);
 		}
 	}
@@ -145,14 +145,14 @@ int reiser4_set_page_dirty2(struct page 
 		struct address_space *mapping = page->mapping;
 
 		if (mapping) {
-			read_lock_irq(&mapping->tree_lock);
+			spin_lock_irq(&mapping->tree_lock);
 			/* check for race with truncate */
 			if (page->mapping) {
 				assert("vs-1652", page->mapping == mapping);
 				if (!mapping->backing_dev_info->memory_backed)
 					inc_page_state(nr_dirty);
 			}
-			read_unlock_irq(&mapping->tree_lock);
+			spin_unlock_irq(&mapping->tree_lock);
 			__mark_inode_dirty(mapping->host, I_DIRTY_PAGES);
 		}
 	}
@@ -600,13 +600,13 @@ reiser4_releasepage(struct page *page, i
 		/* we are under memory pressure so release jnode also. */
 		jput(node);
 
-		write_lock_irq(&mapping->tree_lock);
+		spin_lock_irq(&mapping->tree_lock);
 		/* shrink_list() + radix-tree */
 		if (page_count(page) == 2) {
 			__remove_from_page_cache(page);
 			__put_page(page);
 		}
-		write_unlock_irq(&mapping->tree_lock);
+		spin_unlock_irq(&mapping->tree_lock);
 
 		return 1;
 	} else {
diff -puN fs/reiser4/page_cache.c~reiser4-for-2.6.9 fs/reiser4/page_cache.c
--- linux-2.6.9/fs/reiser4/page_cache.c~reiser4-for-2.6.9	2004-12-08 16:27:45.014737053 +0300
+++ linux-2.6.9-vs/fs/reiser4/page_cache.c	2004-12-08 16:27:45.035738537 +0300
@@ -533,7 +533,7 @@ int set_page_dirty_internal (struct page
 		struct address_space *mapping = page->mapping;
 
 		if (mapping) {
-			read_lock_irq(&mapping->tree_lock);
+			spin_lock_irq(&mapping->tree_lock);
 			if (page->mapping) {	/* Race with truncate? */
 				BUG_ON(page->mapping != mapping);
 				if (!mapping->backing_dev_info->memory_backed)
@@ -551,7 +551,7 @@ int set_page_dirty_internal (struct page
 						PAGECACHE_TAG_REISER4_MOVED);
 				}
 			}
-			read_unlock_irq(&mapping->tree_lock);
+			spin_unlock_irq(&mapping->tree_lock);
 			__mark_inode_dirty(mapping->host, I_DIRTY_PAGES);
 		}
 	}
@@ -595,13 +595,13 @@ reiser4_internal void capture_reiser4_in
 			struct address_space * mapping = inode->i_mapping;
 			unsigned long flags;
 
-			read_lock_irqsave(&mapping->tree_lock, flags);
+			spin_lock_irqsave(&mapping->tree_lock, flags);
 			if (!radix_tree_tagged(&mapping->page_tree, PAGECACHE_TAG_DIRTY) &&
 			    !radix_tree_tagged(&mapping->page_tree, PAGECACHE_TAG_REISER4_MOVED))
 			{
 				inode->i_state &= ~(I_DIRTY);
 			}
-			read_unlock_irqrestore(&mapping->tree_lock, flags);
+			spin_unlock_irqrestore(&mapping->tree_lock, flags);
 		}
 		spin_unlock(&inode_lock);
 
diff -puN fs/reiser4/plugin/file/file.c~reiser4-for-2.6.9 fs/reiser4/plugin/file/file.c
--- linux-2.6.9/fs/reiser4/plugin/file/file.c~reiser4-for-2.6.9	2004-12-08 16:27:45.019737406 +0300
+++ linux-2.6.9-vs/fs/reiser4/plugin/file/file.c	2004-12-08 16:27:45.038738749 +0300
@@ -1363,7 +1363,7 @@ sync_page_list(struct inode *inode)
 	mapping = inode->i_mapping;
 	from = 0;
 	result = 0;
-	read_lock_irq(&mapping->tree_lock);
+	spin_lock_irq(&mapping->tree_lock);
 	while (result == 0) {
 		struct page *page;
 
@@ -1375,17 +1375,17 @@ sync_page_list(struct inode *inode)
 		/* page may not leave radix tree because it is protected from truncating by inode->i_sem downed by
 		   sys_fsync */
 		page_cache_get(page);
-		read_unlock_irq(&mapping->tree_lock);
+		spin_unlock_irq(&mapping->tree_lock);
 
 		from = page->index + 1;
 
 		result = sync_page(page);
 
 		page_cache_release(page);
-		read_lock_irq(&mapping->tree_lock);
+		spin_lock_irq(&mapping->tree_lock);
 	}
 
-	read_unlock_irq(&mapping->tree_lock);
+	spin_unlock_irq(&mapping->tree_lock);
 	return result;
 }
 
diff -puN fs/reiser4/plugin/object.c~reiser4-for-2.6.9 fs/reiser4/plugin/object.c
--- linux-2.6.9/fs/reiser4/plugin/object.c~reiser4-for-2.6.9	2004-12-08 16:27:45.024737760 +0300
+++ linux-2.6.9-vs/fs/reiser4/plugin/object.c	2004-12-08 16:27:45.040738890 +0300
@@ -991,7 +991,6 @@ static void delete_inode_common(struct i
 	 * FIXME: this resembles generic_delete_inode
 	 */
 	list_del_init(&object->i_list);
-	list_del_init(&object->i_sb_list);
 	object->i_state |= I_FREEING;
 	inodes_stat.nr_inodes--;
 	spin_unlock(&inode_lock);
diff -puN fs/reiser4/plugin/security/perm.c~reiser4-for-2.6.9 fs/reiser4/plugin/security/perm.c
--- linux-2.6.9/fs/reiser4/plugin/security/perm.c~reiser4-for-2.6.9	2004-12-08 16:27:45.028738042 +0300
+++ linux-2.6.9-vs/fs/reiser4/plugin/security/perm.c	2004-12-08 16:27:45.041738961 +0300
@@ -14,7 +14,7 @@
 static int
 mask_ok_common(struct inode *inode, int mask)
 {
-	return generic_permission(inode, mask, NULL);
+	return vfs_permission(inode, mask);
 }
 
 static int

_

Re: hmm, dependencies

[Redeeman]

On Fri, 2004-12-17 at 20:30 +0300, Vladimir Saveliev wrote:
> Hello
> 
> On Fri, 2004-12-17 at 18:22, Redeeman wrote:
> > On Fri, 2004-12-17 at 16:55 +0300, Vladimir Saveliev wrote:
> > > Hello
> > > 
> > > On Thu, 2004-12-16 at 22:56, Redeeman wrote:
> > > > hello.. reiser4 is now in mm, but i realize that nearly all of the stuff
> > > > that was mm specific when the move to mm was made, are probably merged
> > > > into upstream by now, i wonder, can anyone tell me exactly what from mm
> > > > it depends on?
> > > > 
> > > > thanks
> > > > 
> > > 
> > > reiser4 got included into mm not because it needed something of it, but
> > > rather because it is supposed that being in mm for certain amount of
> > > time reiser4 will get a lot of testing and will prove that it is worth
> > > to get included into stock kernel. 
> > im aware, however, the reiser4 patches in mm are against mm, which means
> > it depends on something from it, and i'd like to find out what :D so
> > that i can take it out and apply to vanilla along with reiser4
> 
> did you see ftp.namesys.com/pub/reiser4-for-2.6/2.6.9?
> It contains all things which reiser4 depends on.
nice
> 
> If you would like to add reiser4 to vanilla kernel yourself you would
> have to add reiser4 patches of mm kernel to vanilla one:
> 
> people/akpm/patches/2.6/2.6.X/2.6.X-mmY/broken-out/reiser4-*
> and add the patch i am attaching to this email.
> 
yeah i tried that, however they dont patch against latest vanilla, it
would seem the vfs has changed abit.. i just wondered if anyone knew
exactly which of the mm patches was needed to make up for this, but, now
you gave me that url :) never mind..

thanks

-- 
Redeeman <redeeman@metanurb.dk>

Re: hmm, dependencies

[Vladimir Saveliev]

Hello

On Fri, 2004-12-17 at 21:09, Redeeman wrote:
> On Fri, 2004-12-17 at 20:30 +0300, Vladimir Saveliev wrote:
> > Hello
> > 
> > On Fri, 2004-12-17 at 18:22, Redeeman wrote:
> > > On Fri, 2004-12-17 at 16:55 +0300, Vladimir Saveliev wrote:
> > > > Hello
> > > > 
> > > > On Thu, 2004-12-16 at 22:56, Redeeman wrote:
> > > > > hello.. reiser4 is now in mm, but i realize that nearly all of the stuff
> > > > > that was mm specific when the move to mm was made, are probably merged
> > > > > into upstream by now, i wonder, can anyone tell me exactly what from mm
> > > > > it depends on?
> > > > > 
> > > > > thanks
> > > > > 
> > > > 
> > > > reiser4 got included into mm not because it needed something of it, but
> > > > rather because it is supposed that being in mm for certain amount of
> > > > time reiser4 will get a lot of testing and will prove that it is worth
> > > > to get included into stock kernel. 
> > > im aware, however, the reiser4 patches in mm are against mm, which means
> > > it depends on something from it, and i'd like to find out what :D so
> > > that i can take it out and apply to vanilla along with reiser4
> > 
> > did you see ftp.namesys.com/pub/reiser4-for-2.6/2.6.9?
> > It contains all things which reiser4 depends on.
> nice
> > 
> > If you would like to add reiser4 to vanilla kernel yourself you would
> > have to add reiser4 patches of mm kernel to vanilla one:
> > 
> > people/akpm/patches/2.6/2.6.X/2.6.X-mmY/broken-out/reiser4-*
> > and add the patch i am attaching to this email.
> > 
> yeah i tried that, however they dont patch against latest vanilla, it
> would seem the vfs has changed abit.. i just wondered if anyone knew
> exactly which of the mm patches was needed to make up for this, but, now
> you gave me that url :) never mind..
> 

Ah, yes, you are right, there is a patch which rejects.
But, I guess that if we keep ftp.namesys.com/pub/reiser4-for-2.6/
uptodate - that would be ok and we would not have to release separate
patches for vanilla kernel?


> thanks

Re: hmm, dependencies

[Hans Reiser]

Vladimir Saveliev wrote:

>Hello
>
>On Fri, 2004-12-17 at 21:09, Redeeman wrote:
>  
>
>>On Fri, 2004-12-17 at 20:30 +0300, Vladimir Saveliev wrote:
>>    
>>
>>>Hello
>>>
>>>On Fri, 2004-12-17 at 18:22, Redeeman wrote:
>>>      
>>>
>>>>On Fri, 2004-12-17 at 16:55 +0300, Vladimir Saveliev wrote:
>>>>        
>>>>
>>>>>Hello
>>>>>
>>>>>On Thu, 2004-12-16 at 22:56, Redeeman wrote:
>>>>>          
>>>>>
>>>>>>hello.. reiser4 is now in mm, but i realize that nearly all of the stuff
>>>>>>that was mm specific when the move to mm was made, are probably merged
>>>>>>into upstream by now, i wonder, can anyone tell me exactly what from mm
>>>>>>it depends on?
>>>>>>
>>>>>>thanks
>>>>>>
>>>>>>            
>>>>>>
>>>>>reiser4 got included into mm not because it needed something of it, but
>>>>>rather because it is supposed that being in mm for certain amount of
>>>>>time reiser4 will get a lot of testing and will prove that it is worth
>>>>>to get included into stock kernel. 
>>>>>          
>>>>>
>>>>im aware, however, the reiser4 patches in mm are against mm, which means
>>>>it depends on something from it, and i'd like to find out what :D so
>>>>that i can take it out and apply to vanilla along with reiser4
>>>>        
>>>>
>>>did you see ftp.namesys.com/pub/reiser4-for-2.6/2.6.9?
>>>It contains all things which reiser4 depends on.
>>>      
>>>
>>nice
>>    
>>
>>>If you would like to add reiser4 to vanilla kernel yourself you would
>>>have to add reiser4 patches of mm kernel to vanilla one:
>>>
>>>people/akpm/patches/2.6/2.6.X/2.6.X-mmY/broken-out/reiser4-*
>>>and add the patch i am attaching to this email.
>>>
>>>      
>>>
>>yeah i tried that, however they dont patch against latest vanilla, it
>>would seem the vfs has changed abit.. i just wondered if anyone knew
>>exactly which of the mm patches was needed to make up for this, but, now
>>you gave me that url :) never mind..
>>
>>    
>>
>
>Ah, yes, you are right, there is a patch which rejects.
>But, I guess that if we keep ftp.namesys.com/pub/reiser4-for-2.6/
>uptodate - that would be ok and we would not have to release separate
>patches for vanilla kernel
>  
>
How is this a one step install process for users?  Anything that 
diverges from a one step install process is bad with the amount badness 
proportional to the number of steps.  Minimize the badness.

Give the task to vitaly though.

>
>  
>
>>thanks
>>    
>>
>
>
>
>  
>