* hmm, dependencies @ 2004-12-16 19:56 Redeeman 2004-12-17 13:55 ` Vladimir Saveliev 0 siblings, 1 reply; 8+ messages in thread From: Redeeman @ 2004-12-16 19:56 UTC (permalink / raw) To: Reiserfs Mailinglist 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> ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: hmm, dependencies 2004-12-16 19:56 hmm, dependencies Redeeman @ 2004-12-17 13:55 ` Vladimir Saveliev 2004-12-17 15:22 ` Redeeman 0 siblings, 1 reply; 8+ messages in thread From: Vladimir Saveliev @ 2004-12-17 13:55 UTC (permalink / raw) To: redeeman; +Cc: Reiserfs Mailinglist 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: hmm, dependencies 2004-12-17 13:55 ` Vladimir Saveliev @ 2004-12-17 15:22 ` Redeeman 2004-12-17 16:39 ` Cal 2004-12-17 17:30 ` Vladimir Saveliev 0 siblings, 2 replies; 8+ messages in thread From: Redeeman @ 2004-12-17 15:22 UTC (permalink / raw) To: Reiserfs Mailinglist 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> ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: hmm, dependencies 2004-12-17 15:22 ` Redeeman @ 2004-12-17 16:39 ` Cal 2004-12-17 17:30 ` Vladimir Saveliev 1 sibling, 0 replies; 8+ messages in thread From: Cal @ 2004-12-17 16:39 UTC (permalink / raw) To: redeeman; +Cc: reiserfs-list ---------- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: hmm, dependencies 2004-12-17 15:22 ` Redeeman 2004-12-17 16:39 ` Cal @ 2004-12-17 17:30 ` Vladimir Saveliev 2004-12-17 18:09 ` Redeeman 1 sibling, 1 reply; 8+ messages in thread From: Vladimir Saveliev @ 2004-12-17 17:30 UTC (permalink / raw) To: redeeman; +Cc: Reiserfs Mailinglist [-- 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 _ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: hmm, dependencies 2004-12-17 17:30 ` Vladimir Saveliev @ 2004-12-17 18:09 ` Redeeman 2004-12-17 18:37 ` Vladimir Saveliev 0 siblings, 1 reply; 8+ messages in thread From: Redeeman @ 2004-12-17 18:09 UTC (permalink / raw) To: Reiserfs Mailinglist 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> ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: hmm, dependencies 2004-12-17 18:09 ` Redeeman @ 2004-12-17 18:37 ` Vladimir Saveliev 2004-12-20 17:14 ` Hans Reiser 0 siblings, 1 reply; 8+ messages in thread From: Vladimir Saveliev @ 2004-12-17 18:37 UTC (permalink / raw) To: redeeman; +Cc: Reiserfs Mailinglist 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: hmm, dependencies 2004-12-17 18:37 ` Vladimir Saveliev @ 2004-12-20 17:14 ` Hans Reiser 0 siblings, 0 replies; 8+ messages in thread From: Hans Reiser @ 2004-12-20 17:14 UTC (permalink / raw) To: Vladimir Saveliev; +Cc: redeeman, Reiserfs Mailinglist 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 >> >> > > > > > ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2004-12-20 17:14 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-12-16 19:56 hmm, dependencies Redeeman 2004-12-17 13:55 ` Vladimir Saveliev 2004-12-17 15:22 ` Redeeman 2004-12-17 16:39 ` Cal 2004-12-17 17:30 ` Vladimir Saveliev 2004-12-17 18:09 ` Redeeman 2004-12-17 18:37 ` Vladimir Saveliev 2004-12-20 17:14 ` Hans Reiser
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.