"This function is exported by default on IA32"

Actually it appears to not be exported on ia32 either.

Which (GPL) module needs this export ?

You are correct.  It isn't exported on IA32 either.  
The module being worked with is PowerPath which isn't GPLd.  

The symbol was exported previously in Update 2 for ia32. This is no 
longer the case with Update 3.

I'd like to better understand how RedHat determines which symbols get 
exported.

(From Jeff)

-Lu

According to my source trees, revalidate_scsidisk() was never
exported at any time in RHEL3 (nor in RHEL2.1).  Currently, it
is the policy of Red Hat when introducing exports of symbols
for use in modules to use the EXPORT_SYMBOL_GPL() macro.  But
this would not be of use to PowerPath, since it's not GPL'ed.

If EMC can show that this symbol was exported previously in upstream
2.4 or 2.6 that makes things a lot simpler. If it has never been
exported, then we would need to get the acceptance from the upstream
SCSI subsystem maintainers.  Which would require a convincing argument
of the generic benefits and rationale.

Not trying to be difficult here, but merely pointing out our legal
obligations that we can't just arbitrarily export whatever symbols we
want.

So we need the background info to come up with a compelling rationale.

Just curious.... why is this x86-64 specific?  What lead you to think
that things worked fine without the export for x86 previously?  Is the
real request to export it across the board?

The above comments on general benefit/justification still hold, just
trying to better understand the request.

The symbol was somehow exported implicitly on update 2 and earlier 
kernels. That changed with update 3, which breaks PowerPath (see 
output from ksyms below). We'd like to find out what changes prompted 
this behavior. 

Dave

update 3

[root@lcld0084 root]# uname -a
Linux lcld0084 2.4.21-18.ELsmp #1 SMP Thu Jul 22 15:12:08 EDT 2004 
i686 i686 i38
6 GNU/Linux
[root@lcld0084 root]# ksyms -a|grep revalidate_scsidisk
[root@lcld0084 root]#

update 2

[root@lca0093 root]# uname -a
Linux lca0093 2.4.21-15.0.3.ELhugemem #1 SMP Tue Jun 29 17:49:15 EDT 
2004 i686 i
686 i386 GNU/Linux
[root@lca0093 root]# ksyms -a|grep revalidate_scsidisk
8282e2a0  revalidate_scsidisk               [sd_mod]
[root@lca0093 root]#


(From David)

I have tracked this down to a quirk of the "insmod" command.  The
symbol in question was *never* explicitly exported.  However, when
a module is built without any explicit exports, "insmod" by default
exports *every* non-static symbol of the module (unless the "-x"
option is used).

Prior to U3, revalidate_scsidisk() was "accidentally" exported
without any module versioning checksum (along with hundreds of
symbols from other modules) due to its associated source file
(drivers/scsi/sd.c) not having any explicitly exported symbols.

In U3, a new explicitly exported routine was added to this source
file in support of diskdump (and drivers/scsi/Makefile was changed
to add sd.o to the "export-objs" list).  The "insmod" command now
exports the new symbol (sd_find_scsi_device), but no longer exports
the old one (revalidate_scsidisk).

I've also just checked Upstream: revalidate_scsidisk() exists in
2.4.26 as a non-exported symbol, but it does not exist in 2.6.7.

Cheers.  -ernie

A question for EMC....

This is a tough issue.  Reason being, that revalidate_scsidisk() was
never part of the officially supported kernel symbols exported in
RHEL3.  It is not included in the official KMI which are EXPORT_SYMBOL
and EXPORT_SYMBOL_GPL tagged.  Its not modversions protected. Rather
through a side effect of insmod was it previously available.  Here's why:

If there are *no* symbols in a module which are EXPORT_SYMBOL or
EXPORT_SYMBOL_GPL tagged then a quirk of the insmod command is to end
up exporting all symbols in the module.  This is how
revalidate_scsidisk() got exposed.

Then in U3, a legitimate export was added to a file in this same
module.  The end result is that only this one single new export is
provided.  All the prior ones previously exported as a side effect are
no longer exported.

What to do about it?
1) Try to find an alternative approach that EMC can use to accomplish
the desired capability.  More on this in the next comment update.

2) Mark the requested symbol as EXPORT_SYMBOL_GPL.  This would be
useless from an EMC perspective.

3) Mark the symbol as EXPORT_SYMBOL.  This would be the ideal option
from an EMC perspective.  As mentioned above in comment #5, we can't
just arbitrarily add symbols for legal reasons (yes there have been
real issues in the recent past).  In order for us to add exports
(expecially for cases where the export isn't upstream) we need the
concent of the respective subsystem maintainer(s).  In order to get
something EXPORT_SYMBOL we need to demonstrate its generic usefulness
to non-GPL as well as GPL consumers.  Especially when it comes to
interfaces for binary drivers, the prospects for concent are bleak.

The following is an excerpt from an interinal IRC session where a
possible alternative approach is discussed. The intention is to find a
means for powerpath to get the job done using other officially
exported kernel interfaces.


> the function is already _sort_ of exported ---
> For any scsi block device, the block_device_operations->revalidate()
call in turn calls revalidate_scsidisk() with second arg 0
> and a BLKRRPART ioctl() calls it with second arg 1 (and this should
be the only case where that is needed)
 

Another translation of above recomendation:

There may well be a workaround for powerpath's use of
revalidate_scsidisk().  [Technically,
block_device_operations->revalidate(dev) is almost exactly equivalent;
revalidate_scsidisk() is only slightly more flexible and there's a good
chance that the difference between them is irrelevant to powerpath.]

Thanks Tim.  I'll forward your comments back to the PowerPath 
developers and will update the bugzilla again after discussing with 
them.
-H

Heather - our code freeze for RHEL3 U3 is noon tomorrow. So we're
under a major time crunch.  As mentioned above, its unlikely we can
push this through upstream.  But I want us working w/ EMC to ensure
that you can get by with other interfaces.

The issue appears to have been resolved with a change in PowerPath.
Closing the issue.

Reclosing as WONTFIX.