[PATCH 0/1] LP#309378 -- port dm-raid4-5 to 2.6.28 and re-enable
Andy Whitcroft
apw at canonical.com
Sat Dec 27 11:17:32 UTC 2008
On Fri, Dec 26, 2008 at 10:58:54AM -0700, Tim Gardner wrote:
> Andy Whitcroft wrote:
> > Someone seems to be using dm-raid4-5 and has filed a bug on it. There
> > is no later version available upstream. I have therefore attempted a
> > forward port of this. The port seems trivial enough but raid is obviously
> > something rather sensitive as its failure mode is unpleasant.
> >
> > The main thing is that an interface in the kernel was no longer used
> > by anything and was removed (a common occurance), so I have had to
> > reinstate this. Basically all internal users of the locked form
> > of {set,clear}_page_locked() had gone so they were removed. Now it
> > is entirly possible we could move to the unlocked interfaces, but it
> > is significantly safer to assume not and reinstate them; based on the
> > assumption that upstream will port this forward to 2.6.28 at some point
> > after release and is far better placed to make that call.
> >
> > Comments?
> >
> > -apw
> >
> > Andy Whitcroft (1):
> > UBUNTU: ubuntu: Add dm-raid4-5 driver -- port to 2.6.28
> >
> > include/linux/pagemap.h | 8 ++++++++
> > ubuntu/dm-raid4-5/Makefile | 2 +-
> > ubuntu/dm-raid4-5/dm-raid4-5.c | 2 +-
> > 3 files changed, 10 insertions(+), 2 deletions(-)
> >
> >
>
> Applied, though with a slight modification. I moved
> {set,clear}_page_locked() into dm-raid4-5.c. I don't see the benefit of
> cluttering the mainline include files. Are you concerned that
> set_page_locked()/clear_page_locked() might be reintroduced to mainline
> with different semantics?
I was concerned that _set_page_locked() might change. So placing it
there might trigger a failure merge failure should that happen. A
difficult balance between the benefits of that against the obvious
advantage of keeping the whole of it in the ubuntu directory. I am
happy either way.
-apw
More information about the kernel-team
mailing list