Re: [parisc-linux] warning: minor abi change

Re: [parisc-linux] warning: minor abi change

[Grant Grundler]

Joel,
I mistakenly replied only to you on my previous mail.
Can you please forward my previous reply to parisc-linux mailing list
or send a copy back to me - I'll post it to the list then.

On Fri, Jun 27, 2003 at 06:14:58PM +0200, Joel Soete wrote:
> Hi Grant,
> 
> > diff -NaurX dontdiff linux-2.4.21-pa0/drivers/ide/pci/ns87415.c linux-2.4.21-rc8-pa35/drivers/ide/pci/ns87415.c
> 
> > This is for c3000/j5000/et al workstations.
> > NS "SuckyIO" multifunction chip includes ns87415 compatible IDE controller.
> 
> ...
> >> +#define __save_and_cli(x)  do { __save_flags(x); __cli(); } while(0);
> >> +#define __save_and_sti(x)  do { __save_flags(x); __sti(); } while(0);
> >> +
> 
> > This is something different - but I'd think this is needed too.
> > Make sure this isn't a merge error (ie see if it's defined elsewhere).
> 
> I need it to make work my ide cdrom onto my b2k (I grab this stuff
> from another platform)

ah ok.

The IDE CDROM are pretty standard devices. Note the DMA does NOT work.
And even with PIO mode, it just barely works - enough to do an install.
So don't use it too much unless you can afford to crash your box.
At least that was my experience with 2.4.19 or so.

> The following stuff is just a variant (just for info)

ok.

...
> > If they are no longer referenced, that's fine.
> hmm in fact the last ref of 'cpu_irq_actions' is in arch/parisc/kernel/processor.c
> and now embrace by #if 0 [...] #endif
> (I will see to cleanup too)
> ...

ok

> 
> > I need the above changes in a format that I apply with "patch -p1 < diff"
> 
> Here is attached Mydiff2421.txt

ok. let me apply local and try it out first. If all is well, should see
something by this weekend.

thanks,
grant

Re: [parisc-linux] warning: minor abi change

[Joel Soete]

Grant Grundler wrote:

>Joel,
>I mistakenly replied only to you on my previous mail.
>Can you please forward my previous reply to parisc-linux mailing list
>or send a copy back to me - I'll post it to the list then.
>
No pb, I kust forward it to the p-l ml.

>
>On Fri, Jun 27, 2003 at 06:14:58PM +0200, Joel Soete wrote:
>  
>
>>Hi Grant,
>>
>>    
>>
>>>diff -NaurX dontdiff linux-2.4.21-pa0/drivers/ide/pci/ns87415.c linux-2.4.21-rc8-pa35/drivers/ide/pci/ns87415.c
>>>      
>>>
>>>This is for c3000/j5000/et al workstations.
>>>NS "SuckyIO" multifunction chip includes ns87415 compatible IDE controller.
>>>      
>>>
>>...
>>    
>>
>>>>+#define __save_and_cli(x)  do { __save_flags(x); __cli(); } while(0);
>>>>+#define __save_and_sti(x)  do { __save_flags(x); __sti(); } while(0);
>>>>+
>>>>        
>>>>
>>>This is something different - but I'd think this is needed too.
>>>Make sure this isn't a merge error (ie see if it's defined elsewhere).
>>>      
>>>
>>I need it to make work my ide cdrom onto my b2k (I grab this stuff
>>from another platform)
>>    
>>
>
>ah ok.
>
>The IDE CDROM are pretty standard devices. Note the DMA does NOT work.
>And even with PIO mode, it just barely works - enough to do an install.
>So don't use it too much unless you can afford to crash your box.
>At least that was my experience with 2.4.19 or so.
>
Yes also experiment this inconvinience. I just needed it to install the 
initial debian (in its time) and now to read some doc or small ft via rw-cd.

>>The following stuff is just a variant (just for info)
>>    
>>
>
>ok.
>
>...
>  
>
>>>If they are no longer referenced, that's fine.
>>>      
>>>
>>hmm in fact the last ref of 'cpu_irq_actions' is in arch/parisc/kernel/processor.c
>>and now embrace by #if 0 [...] #endif
>>(I will see to cleanup too)
>>...
>>    
>>
>
>ok
>
>  
>
>>>I need the above changes in a format that I apply with "patch -p1 < diff"
>>>      
>>>
>>Here is attached Mydiff2421.txt
>>    
>>
>
>ok. let me apply local and try it out first.
>
Logical

> If all is well, should see
>something by this weekend.
>  
>
It works for my b180 and b2k. I will test it also on the N (still UP 
mode) next week.

Good luck and thanks for your attention,
    Joel

Re: [parisc-linux] warning: minor abi change

[Grant Grundler]

On Fri, Jun 27, 2003 at 06:14:58PM +0200, Joel Soete wrote:
> I need it to make work my ide cdrom onto my b2k (I grab this stuff
> from another platform)


Joel,
I've reworked the __save_and_cli and __save_and_sti mess so that's ok to
commit along with most of what you previously preposed.  I've tested on
64-bit (a500) but am having several problems with 32-bit (c3000) config.

Patch applies to our current CVS:
	ftp://ftp.parisc-linux.org/patches/diff-2.4.21-pa2

My .config and untested kernel/modules are at:
	ftp://ftp.parisc-kernel.org/kernels/c3000/2.4.21-pa2.tgz

Summary of issues that follow:
1) __canonicalize_funcptr_for_compare still a problem with 32-bit modules
2) Makefiles messed up for ide-proc.o	(seems to have a fix already)
3) various IDE modules not exporting symbols.
4) added EXPORT_SYMBOL(sys_wait4) as well.
5) Lack of a test machine at home. Can someone test c3000/2.4.21-pa2.tgz?

Patch also fixes asm problem with arch/parisc/kernel/real2.S.


Details:

1) Dave warned us last December about __canonicalize_funcptr_for_compare
   and gcc-3.3. "make modules_install" fails with this symbol missing in:

   	drivers/ide/ide-disk.o (fixed in patch but won't be committed)
	drivers/scsi/aic79xx/aic79xx.o
	fs/smbfs/smbfs.o
	lib/zlib_deflate/zlib_deflate.o

   Having no clue how to properly fix this in either the toolchain
   or where to find the man page for __canonicalize_funcptr_for_compare(),
   I disabled the last three in my .config and hacked ide-disk.c
   to use (void *) for comparisons.
   Any volunteer to write some sample code for this?
   
2) CONFIG_IDE=m leads to lots of unresolved symbols in IDE modules.
   Willy just pointed me at

   	http://www.ussg.iu.edu/hypermail/linux/kernel/0307.0/0995.html

   which should solve this problem.  The description below is just FYI.
   I'll rework the IDE patch to follow "upstream" fix in the next
   couple of days.

   Basic problem starts with drivers/Makefile:
   	subdir-$(CONFIG_IDE) += ide
   causing the "make vmlinux" to ignore drivers/ide subdir if CONFIG_IDE=m.
   This doesn't work when CONFIG_PROC_FS=y. ide-proc.o doesn't get built.
   drivers/ide/Makefile:
	ifeq($(CONFIG_BLK_DEV_IDE),y)
		obj-$(CONFIG_PROC_FS) += ide-proc.o
	endif

   I hacked  drivers/ide/Makefile to read:
	ifeq ($(CONFIG_PROC_FS),y)
	obj-$(CONFIG_BLK_DEV_IDE)               += ide-proc.o
	endif
   It presumes (1) PROC_FS is y or n and never 'm' and (2) IDE /proc
   support should be loaded as a module if CONFIG_BLK_DEV_IDE=m.


3) various IDE modules not exporting symbols.
	+EXPORT_SYMBOL_GPL(ide_release_dma);
	+EXPORT_SYMBOL(do_ide_request);
	+EXPORT_SYMBOL(ide_modules);
	+EXPORT_SYMBOL(generic_subdriver_entries);
	+EXPORT_SYMBOL(ide_find_setting_by_name);
	+EXPORT_SYMBOL(ide_read_setting);
	+EXPORT_SYMBOL(ide_add_generic_settings);
	+EXPORT_SYMBOL_GPL(ide_scan_pcibus);

4) added EXPORT_SYMBOL(sys_wait4) as well.

5) Lack of a test machine at home. I'm waiting for c3k's I've ordered.
   Nice folks sent me "workstation power cord kit" via priority mail but
   no sign of the workstation itself. :^/
   If someone can test this patch on a C3k, I'd be willing to commit
   the non-IDE parts of it. IDE needs rework to follow upstream's fix.

hth,
grant

Re: [parisc-linux] warning: minor abi change

[John David Anglin]

> 1) Dave warned us last December about __canonicalize_funcptr_for_compare
>    and gcc-3.3. "make modules_install" fails with this symbol missing in:
> 
>    	drivers/ide/ide-disk.o (fixed in patch but won't be committed)
> 	drivers/scsi/aic79xx/aic79xx.o
> 	fs/smbfs/smbfs.o
> 	lib/zlib_deflate/zlib_deflate.o
> 
>    Having no clue how to properly fix this in either the toolchain
>    or where to find the man page for __canonicalize_funcptr_for_compare(),
>    I disabled the last three in my .config and hacked ide-disk.c
>    to use (void *) for comparisons.
>    Any volunteer to write some sample code for this?

Instead of adding (void *) to each comparison, you could add a kernel
version of __canonicalize_funcptr_for_compare:

__canonicalize_funcptr_for_compare:
	bv %r0(%r2)
	copy %r26,%r28

or for PA 2.0

__canonicalize_funcptr_for_compare:
        bve (%r2)
	copy %r26,%r28

I think there was a possible solution along these lines posted on the list
a few months ago (joel?).

This solution assumes that canonicalization is unnecessary in the kernel.
Probably, in most cases it is.  However, if you really need to canonicalize
a function pointer from user space, then you are going to have to figure
out how to call into the dynamic loader from the kernel.  This obviously
isn't very safe.  So, possibly this implies that function pointers passed
in syscalls should be canonicalized before the kernel is entered (i.e.,
glibc should do the canonicalization).

As far as kernel modules go, I don't know how function pointers are
handled.  If you pass a function pointer from one module to another,
does it need canonicalization?  If canonicalization is never necessary
in the kernel, possibly I could add a GCC option to disable canonicalization.

Sorry, about the lack of documentation.  To see what the function does,
it's currently necessary to look in the GCC gcc/config/pa directory.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] warning: minor abi change

[Grant Grundler]

On Sat, Jul 05, 2003 at 07:53:34PM -0400, John David Anglin wrote:
> Instead of adding (void *) to each comparison,

This is just a temporary workaround and I have no plans of committing
any (void *) casts to fix this problem.

> you could add a kernel
> version of __canonicalize_funcptr_for_compare:
> 
> __canonicalize_funcptr_for_compare:
> 	bv %r0(%r2)
> 	copy %r26,%r28
> 
> or for PA 2.0
> 
> __canonicalize_funcptr_for_compare:
>         bve (%r2)
> 	copy %r26,%r28
> 
> I think there was a possible solution along these lines posted on the list
> a few months ago (joel?).

Ok.  I didn't see it when trolling the mail archive.
No matter, I'll try it.
Anyone have an opinion on which arch/parisc file this should go in?

> This solution assumes that canonicalization is unnecessary in the kernel.
> Probably, in most cases it is.  However, if you really need to canonicalize
> a function pointer from user space, then you are going to have to figure
> out how to call into the dynamic loader from the kernel.  This obviously
> isn't very safe.  So, possibly this implies that function pointers passed
> in syscalls should be canonicalized before the kernel is entered (i.e.,
> glibc should do the canonicalization).
> 
> As far as kernel modules go, I don't know how function pointers are
> handled.  If you pass a function pointer from one module to another,
> does it need canonicalization?

I depend on willy/tausq/amodra/et al to understand stuff like this.

> If canonicalization is never necessary
> in the kernel, possibly I could add a GCC option to disable canonicalization.

I think willy suggested privately that might be case.

> Sorry, about the lack of documentation.  To see what the function does,
> it's currently necessary to look in the GCC gcc/config/pa directory.

oh no problem. Kernel has lots of stale/missing documentation too.
Just need guidance on where to find the relevant code and which
path to take.

thanks,
grant

Re: [parisc-linux] warning: minor abi change

[Joel Soete]

Grant Grundler wrote:

>On Sat, Jul 05, 2003 at 07:53:34PM -0400, John David Anglin wrote:
>  
>
>>Instead of adding (void *) to each comparison,
>>    
>>
>
>This is just a temporary workaround and I have no plans of committing
>any (void *) casts to fix this problem.
>
>  
>
>>you could add a kernel
>>version of __canonicalize_funcptr_for_compare:
>>
>>__canonicalize_funcptr_for_compare:
>>	bv %r0(%r2)
>>	copy %r26,%r28
>>
>>or for PA 2.0
>>
>>__canonicalize_funcptr_for_compare:
>>        bve (%r2)
>>	copy %r26,%r28
>>
>>I think there was a possible solution along these lines posted on the list
>>a few months ago (joel?).
>>    
>>
Yes I test succesfully (as w-a) some similar solution. (see: 
<http://lists.parisc-linux.org/pipermail/parisc-linux/2003-May/019982.html>) 
but I doubt that it is the right way ...

>Ok.  I didn't see it when trolling the mail archive.
>No matter, I'll try it.
>Anyone have an opinion on which arch/parisc file this should go in?
>  
>
... arch/parisc/lib/fptr.c seems well the right place (what do you think?)
but the rest of EXPORT_SYMBOL was just 'to make it compile' but do not 
sound (please don't ask me to decribe this sound :) ) to me the way it 
have to be (sorry I was waiting more guidance to submit more complete 
work :( )

hth,
    Joel

Re: [parisc-linux] warning: minor abi change

[Carlos O'Donell]

> > This solution assumes that canonicalization is unnecessary in the kernel.
> > Probably, in most cases it is.  However, if you really need to canonicalize
> > a function pointer from user space, then you are going to have to figure
> > out how to call into the dynamic loader from the kernel.  This obviously
> > isn't very safe.  So, possibly this implies that function pointers passed
> > in syscalls should be canonicalized before the kernel is entered (i.e.,
> > glibc should do the canonicalization).
> > 
> > As far as kernel modules go, I don't know how function pointers are
> > handled.  If you pass a function pointer from one module to another,
> > does it need canonicalization?
> 
> I depend on willy/tausq/amodra/et al to understand stuff like this.

I can't really come up with a scenario where userspace passes a function
pointer to the kernel and has the kernel call or compare the function
pointer?

If someone can, please tell me :)

c.

Re: [parisc-linux] warning: minor abi change

[John David Anglin]

> I can't really come up with a scenario where userspace passes a function
> pointer to the kernel and has the kernel call or compare the function
> pointer?

One example is sigaction.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] warning: minor abi change

[Carlos O'Donell]

> > I can't really come up with a scenario where userspace passes a function
> > pointer to the kernel and has the kernel call or compare the function
> > pointer?
> 
> One example is sigaction.

Fixable, I can stick a sigaction wrapper in userspace. Should we though?

c.

[parisc-linux] IDE modules build prob

[Grant Grundler]

On Sat, Jul 05, 2003 at 05:08:34PM -0600, Grant Grundler wrote:
> 2) CONFIG_IDE=m leads to lots of unresolved symbols in IDE modules.
>    Willy just pointed me at
> 
>    	http://www.ussg.iu.edu/hypermail/linux/kernel/0307.0/0995.html
> 
>    which should solve this problem.

Alan Cox's "it's a start" patch has problems when applied
to our 2.4.21 tree (diff appended):
...
ld -r -o ide-core.o ide-iops.o ide-taskfile.o ide.o ide-lib.o ide-io.o
ide-default.o ide-proc.o setup-pci.o  ide-dma.o 
ide-default.o(.text.idedefault_init+0x0): In function `init_module':
: multiple definition of `init_module'
ide.o(.text.init_module+0x0): first defined here
make[2]: *** [ide-core.o] Error 1
make[2]: Leaving directory `/home/src/linux/drivers/ide'
...

grundler <507>fgrep module_init *c
...
ide-default.c:module_init(idedefault_init);
...
ide.c:module_init(ide_init);
...
grundler <508>

I gather each .o file is only allowed to have one module_init().
If that a deficiency in parisc build or something else?

thanks,
grant


Index: drivers/ide/Makefile
===================================================================
RCS file: /var/cvs/linux/drivers/ide/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- drivers/ide/Makefile	26 Jun 2003 15:07:16 -0000	1.11
+++ drivers/ide/Makefile	6 Jul 2003 05:53:08 -0000
@@ -8,7 +8,6 @@
 # In the future, some of these should be built conditionally.
 #
 
-O_TARGET := idedriver.o
 
 export-objs := ide-iops.o ide-taskfile.o ide-proc.o ide.o ide-probe.o ide-dma.o ide-lib.o setup-pci.o ide-io.o ide-disk.o
 
@@ -29,24 +28,23 @@ endif
 
 # Core IDE code - must come before legacy
 
-obj-$(CONFIG_BLK_DEV_IDE)		+= ide-probe.o ide-geometry.o ide-iops.o ide-taskfile.o ide.o ide-lib.o ide-io.o ide-default.o
-obj-$(CONFIG_BLK_DEV_IDEDISK)		+= ide-disk.o
-obj-$(CONFIG_BLK_DEV_IDECD)		+= ide-cd.o
-obj-$(CONFIG_BLK_DEV_IDETAPE)		+= ide-tape.o
-obj-$(CONFIG_BLK_DEV_IDEFLOPPY)		+= ide-floppy.o
+ide-core-objs := ide-iops.o ide-taskfile.o ide.o ide-lib.o ide-io.o ide-default.o ide-proc.o
+ide-detect-objs := ide-probe.o ide-geometry.o
 
 ifeq ($(CONFIG_BLK_DEV_IDEPCI),y)
-obj-$(CONFIG_BLK_DEV_IDE)		+= setup-pci.o
+ide-core-objs += setup-pci.o 
 endif
 ifeq ($(CONFIG_BLK_DEV_IDEDMA_PCI),y)
-obj-$(CONFIG_BLK_DEV_IDE)		+= ide-dma.o
+ide-core-objs += ide-dma.o 
 endif
-obj-$(CONFIG_BLK_DEV_ISAPNP)		+= ide-pnp.o
-
 
-ifeq ($(CONFIG_BLK_DEV_IDE),y)
-obj-$(CONFIG_PROC_FS)			+= ide-proc.o
-endif
+# Initialisation order:
+# Core sets up
+# Legacy drivers may register a callback
+# Drivers are pre initialised
+# Probe inits the drivers and driver callbacks
+# Raid scans the devices 
+obj-$(CONFIG_BLK_DEV_IDE) += ide-core.o
 
 ifeq ($(CONFIG_BLK_DEV_IDE),y)
   obj-y		+= legacy/idedriver-legacy.o
@@ -58,10 +56,28 @@ else
   endif
 endif
 
+obj-$(CONFIG_BLK_DEV_ISAPNP) += ide-pnp.o
+
+obj-$(CONFIG_BLK_DEV_IDEDISK) += ide-disk.o
+obj-$(CONFIG_BLK_DEV_IDECD) += ide-cd.o
+obj-$(CONFIG_BLK_DEV_IDETAPE) += ide-tape.o
+obj-$(CONFIG_BLK_DEV_IDEFLOPPY) += ide-floppy.o
+
+obj-$(CONFIG_BLK_DEV_IDE) += ide-detect.o 
 
 ifeq ($(CONFIG_BLK_DEV_IDE),y)
 # RAID must be last of all
   obj-y		+= raid/idedriver-raid.o
 endif
 
+list-multi := ide-core.o ide-detect.o
+O_TARGET := idedriver.o
+
 include $(TOPDIR)/Rules.make
+
+ide-core.o: $(ide-core-objs)
+	$(LD) -r -o $@ $(ide-core-objs)
+
+ide-detect.o: $(ide-detect-objs)
+	$(LD) -r -o $@ $(ide-detect-objs)
+

Re: [parisc-linux] IDE modules build prob

[Grant Grundler]

On Sat, Jul 05, 2003 at 11:57:54PM -0600, Grant Grundler wrote:
> I gather each .o file is only allowed to have one module_init().

My tree builds/links/modules_install now.

Removed ide-default.o from ide-core-objs.
Added the following line after the device (disk/tape/cd) drivers:

obj-$(CONFIG_BLK_DEV_IDE) += ide-default.o

I need to go back and see if the EXPORT_SYMBOLS() I added
to various IDE files are still needed. Not tonight.

I've updated the -pa2 patch at:
	ftp://ftp.parisc-linux.org/patches/diff-2.4.21-pa2

and corresponding binaries/.config at:
	ftp://ftp.parisc-kernel.org/kernels/c3000/2.4.21-pa2.tgz

grant

Re: [parisc-linux] IDE modules build prob

[Alan Cox]

On Sul, 2003-07-06 at 07:31, Grant Grundler wrote:
> On Sat, Jul 05, 2003 at 11:57:54PM -0600, Grant Grundler wrote:
> > I gather each .o file is only allowed to have one module_init().
> 
> My tree builds/links/modules_install now.
> 
> Removed ide-default.o from ide-core-objs.
> Added the following line after the device (disk/tape/cd) drivers:
> 
> obj-$(CONFIG_BLK_DEV_IDE) += ide-default.o
> 
> I need to go back and see if the EXPORT_SYMBOLS() I added
> to various IDE files are still needed. Not tonight.

The module patch relies on you having the 2.4.22-pre3 IDE changes for
things like ide-default

$grep init_module drivers/ide/ide-default.c
$