[parisc-linux] CVS linux Vs. -test10

[parisc-linux] CVS linux Vs. -test10

[Paul Bame]

I've attached an overview of differences between our CVS linux sources
following the -test10 merge and the upstream -test10 sources.  This
document is also at http://puffin.external.hp.com/~bame/diff.html
The raw 'diff' output (now a bit out of date) is at
http://puffin.external.hp.com/~bame/diff.out

If anyone gets bored, this list is full of small (and not so small)
tasks which range from very simple (drivers/block/rd.c) to fairly
complex (scripts/*).

	-P


                        palinux Vs. linux 2.4.0-test10
                                       
   Here's a brief summary of the differences in common code between
   palinux (tag: LINUS_240_TEST10_MERGED) and the upstream -test10
   sources. The full diff output is in diff.out. NOTE this does not
   include machine-depend differences
     * Minor changes in several locations to support GSC
     * Minor top-level Makefile hacks, though the CFLAGS one is quite
       important.
     * Lots of RCS $Revision$ differences in ACPI (a different 'cvs
       import' would've eliminated these differences).
     * drivers/block/rd.c: obsolete debug code for parisc64. Changed a
       constant from 0xffffffffL to 0xffffffffUL because of a parisc64
       gcc bug initializing longs. The repaired code is probably "more
       correct" anyway.
     * drivers/char/Config.in: changes to support LASI, parisc real-time
       clock (CONFIG_GENRTC)
     * drivers/char/Makefile: Config-related changes to support HP
       keyboards and RTC
     * drivers/char/console.c: looks like dead or dying experimental
       parisc code -- probably should be removed. Also some
       parisc-specific comments and format changes which should
       disappear.
     * drivers/char/serial.c: support for GSC and A500 serial
     * drivers/net/Makefile,Space.c: mostly LASI LAN support
     * drivers/net/eepro100.c: no clue about this one
     * drivers/net/tulip/interrupt.c: workaround for a B180+busy-lan boot
       problem -- probably should be sent upstream.
     * drivers/net/tulip/tulip_core.c: required #ifdef for hppa, also
       printk() changes which appear valid
     * drivers/parport/Makefile: GSC
     * drivers/parport/parport_gsc.c: New file for palinux -- GSC
       parallel ports -- required
     * drivers/pci/pci.c: eh? Grant?
     * drivers/pci/setup-bus.c: function definition tweek -- Grant?
     * drivers/scsi: Lots of changes here -- rhirst? See for yourself.
       Basics: support LASI and Zalon scsi, changes to 53c8xx drivers,
       rename sim7x0 to sim710
     * drivers/sound: support for HP "Harmony" sound
     * drivers/video: STI and HP FB video drivers (iodccon is probably
       worthless)
     * fs: add support for SOM executables
     * fs/binfmt_elf.c,exec.c: changes for stack-grows-up?
     * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc
     * fs/proc/array.c: ?? something with signals ??
     * fs/stat.c: added __hppa__ to several #ifdefs
     * include/linux/binfmts.h,fs.h,kernel.h,tty.h,udf_fs_sb.h:
       unnecessary differences?
     * include/linux/init.h: we use different section names -- why????,
       probably some unnecessary other differences too
     * include/linux/mm.h: VM_STACK_FLAGS difference -- jsm?
     * include/linux/wait.h: parisc debugging -- should be removed
     * init/main.c: KWDB and GSC support plus a bunch of stuff which
       should probably go away.
     * kernel/Makefile,dma.c,fork.c,printk.c: eh?
     * kernel/module.c: possible parisc-needed changes
     * kernel/signal.c: unknown signal-related differences
     * lib/inflate.c: changed some constants to work around parisc64 gcc
       bug
     * mm/mprotect.c: ?
     * scripts/*: MANY differences here. Looks like a combination of
       things we hacked to fix configuration problems plus MAYBE not
       updating these files from new Linux versions in the past. 'make
       menuconfig' is significantly different from upstream. Even the
       mkdep.c program is different.

Re: [parisc-linux] CVS linux Vs. -test10

[Matthew Wilcox]

On Tue, Nov 14, 2000 at 09:35:01AM -0700, Paul Bame wrote:
> 
> I've attached an overview of differences between our CVS linux sources

ok, here's my memories.

>      * Lots of RCS $Revision$ differences in ACPI (a different 'cvs
>        import' would've eliminated these differences).

i assume someone's already done the appropriate cvs admin -ko magic
to fix this?

>      * drivers/char/Config.in: changes to support LASI, parisc real-time
>        clock (CONFIG_GENRTC)

istr this was `stolen' from the m68k port by sammy.

>      * drivers/char/serial.c: support for GSC and A500 serial

if they're working, send to Ted and he'll do an update with Linus at
some point.  <tytso@valinux.com>

>      * drivers/net/eepro100.c: no clue about this one

we were trying to get it to work for the Jan NYLWE show.  i doubt we have
any changes of note.  does anyone have an eepro in an hp?

>      * drivers/video: STI and HP FB video drivers (iodccon is probably
>        worthless)

agreed on iodccon.  unless we're using it up until the point that one of
the more advanced consoles takes over?  i don't think we are now.

>      * fs/binfmt_elf.c,exec.c: changes for stack-grows-up?

Yes, that's what they're for.

>      * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc

we certainly don't want to send it upstream, but we don't want to take it
out until the bug is fixed.  is fixing that bug on the webshite todo list?

>      * include/linux/binfmts.h,fs.h,kernel.h,tty.h,udf_fs_sb.h:
>        unnecessary differences?

mostly, yes.

>      * include/linux/init.h: we use different section names -- why????,
>        probably some unnecessary other differences too

because we use -ffunction-sections.  text.init clashes with a function called
init, and the linker just merges it into the text segment.  we need it to
be separate, so it became init.text.  there's patches around to do this for
other architectures too.  just bad naming choices initially.

>      * include/linux/wait.h: parisc debugging -- should be removed

yeah, that can die now.

>      * scripts/*: MANY differences here. Looks like a combination of
>        things we hacked to fix configuration problems plus MAYBE not
>        updating these files from new Linux versions in the past. 'make
>        menuconfig' is significantly different from upstream. Even the
>        mkdep.c program is different.

ok.  mea extremely culpa here.  i had an exclude file which included the
scripts/ directory.  someone should now ditch our stuff, take what's in
-test10, hack it till it works for us and check it in.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] CVS linux Vs. -test10

[Grant Grundler]

Matthew Wilcox wrote:
> On Tue, Nov 14, 2000 at 09:35:01AM -0700, Paul Bame wrote:
> ok, here's my memories.

Thanks Matthew!

hehe...sounds like someone's getting older. :^)

...
> >      * drivers/net/eepro100.c: no clue about this one
> 
> we were trying to get it to work for the Jan NYLWE show.

I think I did that. IIRC, it's a one-line change to use I/O port
space since MMIO wasn't usable without more invasive changes.

> i doubt we have any changes of note.  does anyone have an eepro in an hp?

I have picked nearly 30 i82557/i82558 PCI cards from scrap yard.
And maybe a few i82559 even. Did you need one (or two)? :^)

FWIW, this is the card/driver which I think was causing misaligned
data reference traps. I never had a chance to followup with this though.
At the time, I thought it would be *really* fun to show this working
to HP's marketing team...

> >      * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc
> 
> we certainly don't want to send it upstream, but we don't want to take it
> out until the bug is fixed.  is fixing that bug on the webshite todo list?

I don't think so. It's possible it's already fixed.

Relevant CVS log entry:
| revision 1.5
| date: 2000/07/18 03:15:25;  author: dhd;  state: Exp;  lines: +5 -0
| ARGH!  When I put in an assertion, NFS stops breaking randomly.  I
| suspect this is a compiler or binutils problem but I can't see any
| clear differences in the generated code.  I'll debug it later...

This sounds like the hppa64 bug we saw with %r29 getting trashed.
But I don't think David was working on hppa64 kernel at the time.
I can test 32-bit NFS Root tomorrow w/o assertion if no one else
beats me to it.

> >      * include/linux/init.h: we use different section names -- why????,
> >        probably some unnecessary other differences too
> 
> because we use -ffunction-sections.  text.init clashes with a function
> called init, and the linker just merges it into the text segment.  we
> need it to be separate, so it became init.text.  there's patches around
> to do this for other architectures too.  just bad naming choices initially.

We need to resolve this in order to merge upstream.
Matthew, any advice on how we should proceed?
Or would be easier for you pester Alan Cox and just get it fixed?

> >      * include/linux/wait.h: parisc debugging -- should be removed
> 
> yeah, that can die now.

I'd be happy to fix this by clobbering the current version with what's in
linux-2.4.0-test10. But what is the "right" way to revert changes we've made
so this doesn't show up in next merge?

I'll need to know this in order to revert the fs/nfs/read.c change as well.

thanks,
grant


Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253

Re: [parisc-linux] CVS linux Vs. -test10

[Matthew Wilcox]

On Sun, Nov 19, 2000 at 11:44:42PM -0800, Grant Grundler wrote:
> Matthew Wilcox wrote:
> > On Tue, Nov 14, 2000 at 09:35:01AM -0700, Paul Bame wrote:
> > ok, here's my memories.
> 
> Thanks Matthew!
> 
> hehe...sounds like someone's getting older. :^)

... when i were a lad, all this were fields!  Our dad used to kill us
every morning, we'd get up half an hour before we went to bed and walk
uphill both to and from school...

> ...
> > >      * drivers/net/eepro100.c: no clue about this one
> > 
> > we were trying to get it to work for the Jan NYLWE show.
> 
> I think I did that. IIRC, it's a one-line change to use I/O port
> space since MMIO wasn't usable without more invasive changes.

sounds right.  MMIO should work now though, right?

> > i doubt we have any changes of note.  does anyone have an eepro in an hp?
> 
> I have picked nearly 30 i82557/i82558 PCI cards from scrap yard.
> And maybe a few i82559 even. Did you need one (or two)? :^)

Heh, I only have a 712 right now :-)

> FWIW, this is the card/driver which I think was causing misaligned
> data reference traps. I never had a chance to followup with this though.
> At the time, I thought it would be *really* fun to show this working
> to HP's marketing team...

Oh yes, I remember that now.  Tulip always does a copy (well, it doesn't _have_
to, but we tell it to, just like the Alpha does).

> > >      * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc
> > 
> > we certainly don't want to send it upstream, but we don't want to take it
> > out until the bug is fixed.  is fixing that bug on the webshite todo list?
> 
> I don't think so. It's possible it's already fixed.
> 
> Relevant CVS log entry:
> | revision 1.5
> | date: 2000/07/18 03:15:25;  author: dhd;  state: Exp;  lines: +5 -0
> | ARGH!  When I put in an assertion, NFS stops breaking randomly.  I
> | suspect this is a compiler or binutils problem but I can't see any
> | clear differences in the generated code.  I'll debug it later...
> 
> This sounds like the hppa64 bug we saw with %r29 getting trashed.
> But I don't think David was working on hppa64 kernel at the time.
> I can test 32-bit NFS Root tomorrow w/o assertion if no one else
> beats me to it.

it was definitely a 32-bit kernel at the time.  It might be the same bug,
but I'm not sure.

> > >      * include/linux/init.h: we use different section names -- why????,
> > >        probably some unnecessary other differences too
> > 
> > because we use -ffunction-sections.  text.init clashes with a function
> > called init, and the linker just merges it into the text segment.  we
> > need it to be separate, so it became init.text.  there's patches around
> > to do this for other architectures too.  just bad naming choices initially.
> 
> We need to resolve this in order to merge upstream.
> Matthew, any advice on how we should proceed?
> Or would be easier for you pester Alan Cox and just get it fixed?

Hm.  Alan's not hacking on 2.4, last I heard.  I might pester Linus and
see if we can change that.  It's a mechanical change so he might not be
averse to it at this point.  Bear in mind we don't need to do a complete
merge at this point -- most architectures have a separate patch to apply
on top of Linus' tree.

> > >      * include/linux/wait.h: parisc debugging -- should be removed
> > 
> > yeah, that can die now.
> 
> I'd be happy to fix this by clobbering the current version with what's in
> linux-2.4.0-test10. But what is the "right" way to revert changes we've made
> so this doesn't show up in next merge?

I don't know that there's an official way to do this.  I always changed
the file to its previous state and then committed it.  There are a number of
ways of doing it; perhaps the cleanest is:

cvs diff -r1.4 -r1.5 fs/nfs/read.c >../read.c.diff
(then check the read.c.diff file)
patch -p1 <../read.c.diff
rm ../read.c.diff

or you can just delete the lines yourself.  Use diff to make sure there
aren't any silly cosmetic changes (eg whitespace).

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] CVS linux Vs. -test10

[Grant Grundler]

Matthew Wilcox wrote:
...
> sounds right.  MMIO should work now though, right?

It would have worked then too.
Changing it to use MMIO space would require disabling I/O Port space
by defining inb/outb locally to use gsc_readb/writeb.
My problem with doing that was the semantics are slightly different.
I/O Port space is non-postable and MMIO space is. I wasn't confident
a driver written to use I/O port space would work right under MMIO
though some certainly do.

...
> it was definitely a 32-bit kernel at the time.  It might be the same bug,
> but I'm not sure.

Can't be. AP (%r29) is a 64-bit only construct.
dhd also just confirmed it was 32-bit kernel.
I'll try it now.

...
> > We need to resolve this in order to merge upstream.
> > Matthew, any advice on how we should proceed?
> > Or would be easier for you pester Alan Cox and just get it fixed?
> 
> Hm.  Alan's not hacking on 2.4, last I heard.  I might pester Linus and
> see if we can change that.  It's a mechanical change so he might not be
> averse to it at this point.  Bear in mind we don't need to do a complete
> merge at this point -- most architectures have a separate patch to apply
> on top of Linus' tree.

Ok. What's the first step to getting arch/parisc* and include/asm-parisc*
into Linus's tree?

I had dinner with Bdale Garbee last night and one of two things he made
clear was we need to unfork from debian and linus's tree in order to move
forward. All our CVS branches need to become obsolete or "local sandboxes"
of the respective upstream partners. Feeding kernel bits upstream will
bring a new level of visibility (and *HELP*) to the parisc-linux port.

I totally agree with Bdale. I understand alot of work still needs to
happen in our tree (eg though sba_iommu.c works, it's current form sucks)
But pushing bits upstream to linus will not preclude us from doing that work.

I also find it odd that glibc is merged upstream *before* the kernel is.

For the record, the second issue bdale made clear was we need "boot
floppies" debian package working. We don't need more ISO images (no
offense to pjlahaie for his good work). "Boot floppies" is a pre-requisite
to becoming part of the next debian release. Given I still don't have
a clue how to build a debian package and I can still contribute alot
in other areas, it doesn't make sense for me to do it myself.


> > I'd be happy to fix this by clobbering the current version with what's in
> > linux-2.4.0-test10. But what is the "right" way to revert changes we've made
> > so this doesn't show up in next merge?
> 
> I don't know that there's an official way to do this.  I always changed
> the file to its previous state and then committed it.  There are a number of
> ways of doing it; perhaps the cleanest is:
> 
> cvs diff -r1.4 -r1.5 fs/nfs/read.c >../read.c.diff
> (then check the read.c.diff file)
> patch -p1 <../read.c.diff
> rm ../read.c.diff
> 
> or you can just delete the lines yourself.  Use diff to make sure there
> aren't any silly cosmetic changes (eg whitespace).

The part you described above is the easy part - np.
I'm worried about labels and tracking how we "name" the releases.
Mang or other CVS ninja's care to comment?

thanks,
grant

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253

Re: [parisc-linux] CVS linux Vs. -test10

[Grant Grundler]

Matthew Wilcox wrote:
...
> >      * fs/nfs/read.c: probably unnecessary hack for broken parisc64 gcc
> 
> we certainly don't want to send it upstream, but we don't want to take it
> out until the bug is fixed.  is fixing that bug on the webshite todo list?

It's fixed. I was able to NFS boot my A180 and install  palinux-0.5.iso
bits on the SCSI disk. I've reverted the change to the LINUS_240_TEST10
version.

> >      * include/linux/wait.h: parisc debugging -- should be removed
> 
> yeah, that can die now.

Is anyone else already doing this?

thanks,
grant

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253

Re: [parisc-linux] CVS linux Vs. -test10

[Matthew Wilcox]

On Mon, Nov 20, 2000 at 09:34:31AM -0800, Grant Grundler wrote:
> Ok. What's the first step to getting arch/parisc* and include/asm-parisc*
> into Linus's tree?

Someone (probably me) sends him a patch.  He told me at the Toronto
show that he was quite happy to apply anything that only touched those
two directories. (oh, and drivers/gsc wouldn't be a problem either).
Can I just check that no-one wants to rename drivers/gsc again?  :-)

> I had dinner with Bdale Garbee last night and one of two things he made
> clear was we need to unfork from debian and linus's tree in order to move
> forward. All our CVS branches need to become obsolete or "local sandboxes"
> of the respective upstream partners. Feeding kernel bits upstream will
> bring a new level of visibility (and *HELP*) to the parisc-linux port.

that's true.  last time we discussed this several people were unhappy
with the idea of sending our current work to Linus.  Is anyone unhappy
with doing this now?

> I also find it odd that glibc is merged upstream *before* the kernel is.

glibc is more portable :-)

> The part you described above is the easy part - np.
> I'm worried about labels and tracking how we "name" the releases.
> Mang or other CVS ninja's care to comment?

don't tag it.  just commit it.  tags are laid down at big events, not
when you fix bugs or undo changes.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] CVS linux Vs. -test10

[Grant Grundler]

Matthew Wilcox wrote:
...
> Someone (probably me) sends him a patch.  He told me at the Toronto
> show that he was quite happy to apply anything that only touched those
> two directories. (oh, and drivers/gsc wouldn't be a problem either).
> Can I just check that no-one wants to rename drivers/gsc again?  :-)

Hi Mathew,
I don't and it's a good question.
I would like a few files moved:

arch/parisc/kernel/ccio-dma.c    -> drivers/gsc/ccio-dma.c
arch/parisc/kernel/ccio-rm-dma.c -> drivers/gsc/ccio-rm-dma.c

    ccio will *always* be associated with a GSC bus since that's
    the secondary bus. And ccio supports devices below dino.c which
    already lives in drivers/gsc.

arch/parisc/kernel/lba_pci.c     -> drivers/ropes/lba_pci.c
arch/parisc/kernel/sba_iommu.c   -> drivers/ropes/sba_iommu.c
arch/parisc/kernel/iosapic.c     -> drivers/ropes/iosapic.c

    lba/sba code is equivalent to dino/ccio code for another set
    of platforms. And long term, I'm certain iosapic.c does not
    belong under arch/parisc. I can do this move if there are no
    major objections.

Any reason why we couldn't do these moves *after* you submit a patch?


FWIW, here are issues I see with merging IA64 iosapic code with mine:
o iosapic "discovery" (I invented register_iosapic() interface for parisc)
o parisc PDC calls (initialization)
o interrupt policy decisions (eg EOI generation and picking a CPU)
o I don't have time to do it in the near future.

Folks working on IA64 stuff inside HP need to think about:
(a) if they want to do the merge any time soon
(b) which iosapic.c they want to start with
(c) where the final version should live

thanks,
grant

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253

Re: [parisc-linux] CVS linux Vs. -test10

[Matthew Wilcox]

On Tue, Nov 21, 2000 at 01:24:31PM -0800, Grant Grundler wrote:
> I would like a few files moved:
> 
> arch/parisc/kernel/ccio-dma.c    -> drivers/gsc/ccio-dma.c
> arch/parisc/kernel/ccio-rm-dma.c -> drivers/gsc/ccio-rm-dma.c
> arch/parisc/kernel/lba_pci.c     -> drivers/ropes/lba_pci.c
> arch/parisc/kernel/sba_iommu.c   -> drivers/ropes/sba_iommu.c
> arch/parisc/kernel/iosapic.c     -> drivers/ropes/iosapic.c

> Any reason why we couldn't do these moves *after* you submit a patch?

Better to get our house in order before we patchbomb Linus, I think.
Renames are hard enough in CVS; renames in diff -u format are a real
stinker :-)

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] CVS linux Vs. -test10

[John Marvin]

> Better to get our house in order before we patchbomb Linus, I think.
> Renames are hard enough in CVS; renames in diff -u format are a real
> stinker :-)

In that case, we need to do some cleanup first.  I've been lobbying for
the removal of the almost empty arch/parisc/real directory, and its few
remaining valid files moved to the kernel directory.  There are also a
fair number of dead files.  Every file that is not currently involved in
the build should be removed, unless a good case for it remaining can be
made.  If the reason to keep it is not a long term reason, then that file
should not be sent to Linus (It sounds like it is a lot easier to add
files rather than remove/rename them).

If there are any files that are currently in use, but which we know
will eventually be removed, perhaps we should consider what to do with
that file (although I don't know of any files in this category at the
moment).

John Marvin
jsm@fc.hp.com

Re: [parisc-linux] CVS linux Vs. -test10

[Ryan Bradetich]

Grant Grundler wrote:

> Matthew Wilcox wrote:
> ...
> > Someone (probably me) sends him a patch.  He told me at the Toronto
> > show that he was quite happy to apply anything that only touched those
> > two directories. (oh, and drivers/gsc wouldn't be a problem either).
> > Can I just check that no-one wants to rename drivers/gsc again?  :-)
>
> Hi Mathew,
> I don't and it's a good question.
> I would like a few files moved:
>
> arch/parisc/kernel/ccio-dma.c    -> drivers/gsc/ccio-dma.c
> arch/parisc/kernel/ccio-rm-dma.c -> drivers/gsc/ccio-rm-dma.c

Grant,

Do you really want to merget the ccio-rm-dma.c file into Linus's tree?
It is just a reference file used to construct the real ccio-dma.c file ... I
don't believe it is referenced anywhere.

I'll double check this in the morning.

- Ryan


>     ccio will *always* be associated with a GSC bus since that's
>     the secondary bus. And ccio supports devices below dino.c which
>     already lives in drivers/gsc.
>
> arch/parisc/kernel/lba_pci.c     -> drivers/ropes/lba_pci.c
> arch/parisc/kernel/sba_iommu.c   -> drivers/ropes/sba_iommu.c
> arch/parisc/kernel/iosapic.c     -> drivers/ropes/iosapic.c
>
>     lba/sba code is equivalent to dino/ccio code for another set
>     of platforms. And long term, I'm certain iosapic.c does not
>     belong under arch/parisc. I can do this move if there are no
>     major objections.
>
> Any reason why we couldn't do these moves *after* you submit a patch?
>
> FWIW, here are issues I see with merging IA64 iosapic code with mine:
> o iosapic "discovery" (I invented register_iosapic() interface for parisc)
> o parisc PDC calls (initialization)
> o interrupt policy decisions (eg EOI generation and picking a CPU)
> o I don't have time to do it in the near future.
>
> Folks working on IA64 stuff inside HP need to think about:
> (a) if they want to do the merge any time soon
> (b) which iosapic.c they want to start with
> (c) where the final version should live
>
> thanks,
> grant
>
> Grant Grundler
> Unix Systems Enablement Lab
> +1.408.447.7253
>
> ---------------------------------------------------------------------------
> To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with
> `unsubscribe' as the subject.

Re: [parisc-linux] CVS linux Vs. -test10

[Grant Grundler]

Ryan Bradetich wrote:
> Do you really want to merget the ccio-rm-dma.c file into Linus's tree?
> It is just a reference file used to construct the real ccio-dma.c file ... I
> don't believe it is referenced anywhere.

Hi Ryan,
Yes I do. It is supposed to work for ccio+PCX-W platforms (eg C360).
Keeping it arround will document the pro/con's of that approach and
give folks who have time (and the right machine) something to experiment
with instead of writing it from scratch.  If someone finds an application
it's good for (short transactions with low latency requirements perhaps),
it's worth having around.

It's not referenced because I didn't add a CONFIG_CCIO_RM_IOMMU flag
or ccio_rm_init() call to drivers/gsc/gsc.c:gsc_init().  You are welcome
add this CONFIG flag by hacking arch/parisc/config.in and defconfig.
If you do, please add rules which only allow one or the other
CONFIG_CCIO* option to be enabled.

thanks,
grant

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253

Re: [parisc-linux] CVS linux Vs. -test10

[Grant Grundler]

John Marvin wrote:
> In that case, we need to do some cleanup first.

John,
I want a task list which leads us to a submital to linus.
That's why I listed the specific files I wanted moved.

Can you come up with (or ask someone else to come up) with a list of
files which meet your criteria?

All of your criteria sounds reasonable to me.
But I don't have a feel of which files meet your criteria.
If someone makes the task list, I'm happy to help with items
and verify the result works.

thanks,
grant

Re: [parisc-linux] CVS linux Vs. -test10

[John Marvin]

> Ryan Bradetich wrote:
> > Do you really want to merget the ccio-rm-dma.c file into Linus's tree?
> > It is just a reference file used to construct the real ccio-dma.c file ... I
> > don't believe it is referenced anywhere.
>
> Hi Ryan,
> Yes I do. It is supposed to work for ccio+PCX-W platforms (eg C360).
> Keeping it arround will document the pro/con's of that approach and
> give folks who have time (and the right machine) something to experiment
> with instead of writing it from scratch.  If someone finds an application
> it's good for (short transactions with low latency requirements perhaps),
> it's worth having around.
>
> It's not referenced because I didn't add a CONFIG_CCIO_RM_IOMMU flag
> or ccio_rm_init() call to drivers/gsc/gsc.c:gsc_init().  You are welcome
> add this CONFIG flag by hacking arch/parisc/config.in and defconfig.
> If you do, please add rules which only allow one or the other
> CONFIG_CCIO* option to be enabled.
>
Well, personally i'd vote to get rid of it. It works for ONE machine only,
and MAY have an advantage in some small case. But if we keep it, lets make
sure that it is real clear that it should NOT be the default choice.

It should be marked CONFIG_EXPERIMENTAL, and the text associated with it
should clearly show that it works on a C360 only. If possible, it should
also be made clear that ccio-dma.c works for C360, so people who have
C360's don't think they have to choose ccio-rm-dma.c.

Grant, I hope you are prepared to answer the parisc-linux mailing list
questions this is going to generate once parisc-linux starts becoming more
visible.  Another FAQ entry perhaps? :-)

John Marvin
jsm@fc.hp.com

Re: [parisc-linux] CVS linux Vs. -test10

[Paul Bame]

= I've been lobbying for
= the removal of the almost empty arch/parisc/real directory, and its few
= remaining valid files moved to the kernel directory.

Done.

		    arch/parisc/real
			R.I.P.

Re: [parisc-linux] CVS linux Vs. -test10

[Grant Grundler]

John Marvin wrote:
> Grant Grundler wrote:
> > Yes I do. It is supposed to work for ccio+PCX-W platforms (eg C360).
...
> Well, personally i'd vote to get rid of it. It works for ONE machine only,
> and MAY have an advantage in some small case.

And so does the OB600 mouse driver I rewrote/published.
AFAIK, it only works on OB600s.

I was originally thinking D/K/R-class boxes had PCX-W upgrades but
AFAICT, they don't.

> But if we keep it, lets make
> sure that it is real clear that it should NOT be the default choice.
> 
> It should be marked CONFIG_EXPERIMENTAL, and the text associated with it
> should clearly show that it works on a C360 only. If possible, it should
> also be made clear that ccio-dma.c works for C360, so people who have
> C360's don't think they have to choose ccio-rm-dma.c.

IIRC, Comments in the headers of both ccio files make those issues clear.
I'm not sure where else that needs to be documented.

> Grant, I hope you are prepared to answer the parisc-linux mailing list
> questions this is going to generate once parisc-linux starts becoming more
> visible.  Another FAQ entry perhaps? :-)

Ryan owns it. He's responsible for documenting it and adding FAQ questions.
He can choose to delete ccio-rm-dma.c as well.
:^)

I think it'd be a waste to throw it away before someone figures
out that it's really not useful - even if just for C360.

thanks,
grant

Re: [parisc-linux] CVS linux Vs. -test10

[Kirk Bresniker]

Grant Grundler wrote:

| I was originally thinking D/K/R-class boxes had PCX-W upgrades but
| AFAICT, they don't.
| 

The C-class upgrade to PCX-W was a one-off.  Upgrades for similar enterprise
servers were not designed. 

KMB
--
+============================================================+
|       Kirk Bresniker    	(916) 748-2393		     |
|       8000 Foothills Blvd                                  |
|       Roseville, CA 95747-5649                             |
|       kirkb@rose.hp.com                                    |

Re: [parisc-linux] CVS linux Vs. -test10

[Grant Grundler]

Grant Grundler wrote:
...
> arch/parisc/kernel/ccio-dma.c    -> drivers/gsc/ccio-dma.c
> arch/parisc/kernel/ccio-rm-dma.c -> drivers/gsc/ccio-rm-dma.c
> 
>     ccio will *always* be associated with a GSC bus since that's
>     the secondary bus. And ccio supports devices below dino.c which
>     already lives in drivers/gsc.

Ryan - moving/keeping these files is up to you.
I was just sharing what I thought was "right".
Apologies for not making that clear earlier.


> arch/parisc/kernel/lba_pci.c     -> drivers/ropes/lba_pci.c
> arch/parisc/kernel/sba_iommu.c   -> drivers/ropes/sba_iommu.c
> arch/parisc/kernel/iosapic.c     -> drivers/ropes/iosapic.c

I've talked to one of the folks working on IA64-linux.
They are interested in merging iosapic code but haven't even
looked at the parisc version I wrote. We talked a bit about the
issues and it doesn't sound like it's going to happen anytime soon.
In any case, iosapic.c doesn't belong under "drivers/ropes".

So none of this needs to move in the forseeable future.
It can all stay in arch/parisc/kernel.

grant

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253

Re: [parisc-linux] CVS linux Vs. -test10

[Stephen Zander]

>>>>> "Grant" == Grant Grundler <grundler@cup.hp.com> writes:
    Grant> For the record, the second issue bdale made clear was we
    Grant> need "boot floppies" debian package working. We don't need
    Grant> more ISO images (no offense to pjlahaie for his good
    Grant> work). "Boot floppies" is a pre-requisite to becoming part
    Grant> of the next debian release. Given I still don't have a clue
    Grant> how to build a debian package and I can still contribute
    Grant> alot in other areas, it doesn't make sense for me to do it
    Grant> myself.

</lurk>

Oooh, there's a reason for me to finally get the 712/80 under my desk
to be more than a foot-rest.  I'll see what I can do about this.

Note that the likelihood of Debian releasing woody anytime soon is
vanishingly small, so this dosen't have to happen Right Now.

<lurk>

-- 
Stephen (debian developer)

"Strange women lying in ponds distributing swords is no basis for a
system of government"

Re: [parisc-linux] CVS linux Vs. -test10

[Randolph Chung]

> Oooh, there's a reason for me to finally get the 712/80 under my desk
> to be more than a foot-rest.  I'll see what I can do about this.
> 
> Note that the likelihood of Debian releasing woody anytime soon is
> vanishingly small, so this dosen't have to happen Right Now.

So little faith... :P

Let me know what I can do to help.... it takes my dual-400MHz i386 box
about an hour to build boot-floopies; i don't even wait to think how
long it will take on the 712/80 :-)

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

Re: [parisc-linux] CVS linux Vs. -test10

[Alan Cox]

> Oooh, there's a reason for me to finally get the 712/80 under my desk
> to be more than a foot-rest.  I'll see what I can do about this.
> 
> Note that the likelihood of Debian releasing woody anytime soon is
> vanishingly small, so this dosen't have to happen Right Now.

My experiences with building Red Hat 7 so far are mostly good. I don't think
there will be many actual changes needed to build Debian packages either. I've
made very little that isnt 'use -fPIC' 'dont optimise C++'

Re: [parisc-linux] CVS linux Vs. -test10

[Paul Bame]

=     Grant> need "boot floppies" debian package working. We don't need
= 
= Oooh, there's a reason for me to finally get the 712/80 under my desk
= to be more than a foot-rest.  I'll see what I can do about this.
= 
= Note that the likelihood of Debian releasing woody anytime soon is
= vanishingly small, so this dosen't have to happen Right Now.

Well yes and no.  We want to release parisc-linux sooner than woody
will be ready for public stable release, so we'll want to do the
boot floppies work sooner than other architectures need it and
can probably therefore provide early testing too.  Since
we aren't going to time travel back to Debian potato, woody
boot floppies are increasingly interesting to replace our manual
install process (hey at least it's documented!).

	-P