[parisc-linux] dump driver for parisc-linux: patch vs CVS

[parisc-linux] dump driver for parisc-linux: patch vs CVS

[Bruno Vidal]

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

	Hi.
I've a dump driver available for 2.4.17-pa3 and I'll
upgrade my source to latest CVS bits and redo the 
modifications. But do you think it is possible to
put in the CVS these modifications ? 
I have modified:
./Makefile 
./arch/parisc/config.in
./arch/parisc/kernel/traps.c
./arch/parisc/mm/init.c
./drivers/Makefile 
./drivers/char/sysrq.c
./init/main.c
./kernel/ksyms.c
./kernel/panic.c
./kernel/sched.c

And I've added:
./include/linux/dump.h 
./drivers/dump/Makefile
./drivers/dump/dump_base.c
./drivers/dump/dump_rle.c
./drivers/dump/dump_parisc.c

So my question: 
-Do you think it is a good idea to have a dump driver available 
in the standart kernel ?
-If yes, who is able to do the code review, and put this dump 
module in the CVS ?

	Thanks.
 
-- 
	Vidal Bruno, (770-4271)
        SSD-HA Team, HP-UX & LINUX Support
	bruno_vidal@admin.france.hp.com

[-- Attachment #2: Card for Bruno Vidal --]
[-- Type: text/x-vcard, Size: 386 bytes --]

begin:vcard 
n:Bruno;VIDAL
tel;fax:01-69-82-60-14
tel;work:01-69-29-42-71
x-mozilla-html:TRUE
url:www.france.hp.com
org:Solution Center
version:2.1
email;internet:bruno_vidal@hp.com
title:Expert Logiciel Environnement Haute Disponibilité
adr;quoted-printable:;;HP France=0D=0A;Z.A de Courtaboeuf;1 Av. du Canada;91947 Les Ulis cedex;France
x-mozilla-cpt:;26208
fn:VIDAL Bruno
end:vcard

Re: [parisc-linux] dump driver for parisc-linux: patch vs CVS

[Randolph Chung]

> -Do you think it is a good idea to have a dump driver available 
> in the standart kernel ?
> -If yes, who is able to do the code review, and put this dump 
> module in the CVS ?

The usual procedure as I understand it is to post a diff to this list
(cvs diff -uNp from the root of your linux tree). People will try it
out/post comments and once that is done someone can check this in for
you.

randolph
-- 
   @..@                                         http://www.TauSq.org/
  (----)
 ( >__< )
 ^^ ~~ ^^

Re: [parisc-linux] dump driver for parisc-linux: patch vs CVS

[Grant Grundler]

Bruno Vidal wrote:
> 	Hi.
> I've a dump driver available for 2.4.17-pa3 and I'll
> upgrade my source to latest CVS bits and redo the 
> modifications. But do you think it is possible to
> put in the CVS these modifications ? 


As Randolph noted, we need to see the diff and what was changed
in the generic kernel. Is the kernel and user space code GPL?

> I have modified:
> ./Makefile 
> ./arch/parisc/config.in
> ./arch/parisc/kernel/traps.c
> ./arch/parisc/mm/init.c
> ./drivers/Makefile 
> ./drivers/char/sysrq.c
> ./init/main.c
> ./kernel/ksyms.c
> ./kernel/panic.c
> ./kernel/sched.c

The last four might cause trouble....

> 
> And I've added:
> ./include/linux/dump.h 
> ./drivers/dump/Makefile
> ./drivers/dump/dump_base.c
> ./drivers/dump/dump_rle.c
> ./drivers/dump/dump_parisc.c

and we need to ask 2.4 maintainer if this can be added upstream too...

> So my question: 
> -Do you think it is a good idea to have a dump driver available 
> in the standart kernel ?

I do. But it's really up to linus/et al to decide that.
I can choose to commit this code to *our* tree (parisc-linux) only.
(and that's really not just my decision - need some consensus)

> -If yes, who is able to do the code review, and put this dump 
> module in the CVS ?

Ideally, I'd like to see outstanding non-arch code changes merged
upstream first..  Otherwise, I don't mind maintaining that code in our tree.

thanks!
grant

Re: [parisc-linux] dump driver for parisc-linux: patch vs CVS

[Bruno Vidal]

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

	Hi.
So my work for the next few days will to create a patch
of all my modification for the latest CVS bits (so you will
have only the modifications). But I'll send it to which people ?

Grant Grundler wrote:
> As Randolph noted, we need to see the diff and what was changed
> in the generic kernel. Is the kernel and user space code GPL?

Everything is under GPL, even the code coming from SGI. I leave
all informations about the SGI code and the header of all their files.
But I've modified the code to handle specific needs for p4. I'm
also currently added code to handle multiple dump device. And I've also
the project to dump only kernel space and not user space.

> > I have modified:
> > ./Makefile
> > ./arch/parisc/config.in
> > ./arch/parisc/kernel/traps.c
> > ./arch/parisc/mm/init.c
> > ./drivers/Makefile
> > ./drivers/char/sysrq.c
> > ./init/main.c
> > ./kernel/ksyms.c
> > ./kernel/panic.c
> > ./kernel/sched.c
> 
> The last four might cause trouble....
I know, I can try to put kernel/ksyms.c to arch/parisc/kernel/parisc_ksyms.c
but it can break the code for ia64 and other architecture. but for the other
it is not possible: panic (call to dump), sched.c (another call to dump), 
main.c (init of dump). I've also an IA64 box where I can do test, so I've also
the project to do it working on it (lots of project :-).

> 
> >
> > And I've added:
> > ./include/linux/dump.h
> > ./drivers/dump/Makefile
> > ./drivers/dump/dump_base.c
> > ./drivers/dump/dump_rle.c
> > ./drivers/dump/dump_parisc.c
> 
> and we need to ask 2.4 maintainer if this can be added upstream too...
I defenitly think that it is a really needed feature (I'm working perhaps 
since a too long time in support center :-).

> 
> > So my question:
> > -Do you think it is a good idea to have a dump driver available
> > in the standart kernel ?
> 
> I do. But it's really up to linus/et al to decide that.
> I can choose to commit this code to *our* tree (parisc-linux) only.
> (and that's really not just my decision - need some consensus)

perfectly understand, so, you already have my vote :-)

> 
> > -If yes, who is able to do the code review, and put this dump
> > module in the CVS ?
> 
> Ideally, I'd like to see outstanding non-arch code changes merged
> upstream first..  Otherwise, I don't mind maintaining that code in our tree.
>
My main probleme is to have a up to date code, because I have to follow
each modification and redo the merge each time I want to update my CVS.
I agree that I need to add comments in my code, but before going further
I prefer to know if this code will stay a "patch" or not.
 
> thanks!
> grant
> 
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

-- 
	Vidal Bruno, (770-4271)
        SSD-HA Team, HP-UX & LINUX Support
	bruno_vidal@admin.france.hp.com

[-- Attachment #2: Card for Bruno Vidal --]
[-- Type: text/x-vcard, Size: 386 bytes --]

begin:vcard 
n:Bruno;VIDAL
tel;fax:01-69-82-60-14
tel;work:01-69-29-42-71
x-mozilla-html:TRUE
url:www.france.hp.com
org:Solution Center
version:2.1
email;internet:bruno_vidal@hp.com
title:Expert Logiciel Environnement Haute Disponibilité
adr;quoted-printable:;;HP France=0D=0A;Z.A de Courtaboeuf;1 Av. du Canada;91947 Les Ulis cedex;France
x-mozilla-cpt:;26208
fn:VIDAL Bruno
end:vcard

Re: [parisc-linux] dump driver for parisc-linux: patch vs CVS

[Randolph Chung]

> So my work for the next few days will to create a patch
> of all my modification for the latest CVS bits (so you will
> have only the modifications). But I'll send it to which people ?

Either put it on the web/ftp some place and send the URL to this list, or if
the patch is not too large, just compress and attach it in a mail to the
list. My guess is that this is fairly large, so you might want to go
with the first option. Or you can send it to, say, Grant or myself, and
we can put it up on the ftp.p-l.org site and post the URL for you.

randolph
-- 
   @..@                                         http://www.TauSq.org/
  (----)
 ( >__< )
 ^^ ~~ ^^

Re: [parisc-linux] dump driver for parisc-linux: patch vs CVS

[Grant Grundler]

Bruno Vidal wrote:
> 	Hi.
> So my work for the next few days will to create a patch
> of all my modification for the latest CVS bits (so you will
> have only the modifications). But I'll send it to which people ?

1) Send "cvs diff" output to this list
2) Use ".cvsrc" from build-tools/ repository
  ("diff -uNp" is key here)
3) If the diff is more than 100-200 lines, post a URL instead

I think I, tausq, ESIEE, willy should review/try it.

> Grant Grundler wrote:
> > As Randolph noted, we need to see the diff and what was changed
> > in the generic kernel. Is the kernel and user space code GPL?
> 
> Everything is under GPL, even the code coming from SGI. I leave
> all informations about the SGI code and the header of all their files.

Ok. You might also want to put a URL of your tarball of programs...perhaps
some debian types on debian-hppa would be interested in creating
a debian package of those.

> But I've modified the code to handle specific needs for p4.
> I'm
> also currently added code to handle multiple dump device. And I've also
> the project to dump only kernel space and not user space.

Cool! if you could keep those changes seperate for now...that
might make life easier in case we want to send those changes
back "upstream" (to SGI I assume).

> > > ./init/main.c
> > > ./kernel/ksyms.c
> > > ./kernel/panic.c
> > > ./kernel/sched.c
> > 
> > The last four might cause trouble....

> I know, I can try to put kernel/ksyms.c to arch/parisc/kernel/parisc_ksyms.c
> but it can break the code for ia64 and other architecture. but for the other
> it is not possible: panic (call to dump), sched.c (another call to dump), 
> main.c (init of dump). I've also an IA64 box where I can do test, so I've als
>   o
> the project to do it working on it (lots of project :-).

heh...if you know it will break another arch, leave it alone.

> I defenitly think that it is a really needed feature (I'm working perhaps 
> since a too long time in support center :-).

Even folks outside the support center think it's a good idea.

...
> My main probleme is to have a up to date code, because I have to follow
> each modification and redo the merge each time I want to update my CVS.
> I agree that I need to add comments in my code, but before going further
> I prefer to know if this code will stay a "patch" or not.

I can't promise anything. You know what I want.
Comments/guidance from Alan Cox and/or Matthew Wilcox would be good here.

grant