[PATCH] proc_lookup not exported

[PATCH] proc_lookup not exported

[Jeff Golds]

Hi folks.

I noticed that proc_lookup is not exported in fs/proc/procfs_syms.c but
that the function is an external in include/linux/proc_fs.h.

This patch exports the function appropriately and is against the 2.4.3
kernel tree.

*** procfs_syms.c.orig  Tue Apr 17 15:50:56 2001
--- procfs_syms.c       Tue Apr 17 15:51:19 2001
***************
*** 19,24 ****
--- 19,25 ----
  EXPORT_SYMBOL(proc_net);
  EXPORT_SYMBOL(proc_bus);
  EXPORT_SYMBOL(proc_root_driver);
+ EXPORT_SYMBOL(proc_lookup);
 
  static DECLARE_FSTYPE(proc_fs_type, "proc", proc_read_super,
FS_SINGLE);


-Jeff


-- 
Jeff Golds
jgolds@resilience.com

Re: [PATCH] proc_lookup not exported

[Alexander Viro]

On Tue, 17 Apr 2001, Jeff Golds wrote:

> Hi folks.
> 
> I noticed that proc_lookup is not exported in fs/proc/procfs_syms.c but
> that the function is an external in include/linux/proc_fs.h.

Not every public function needs to be exported. proc_lookup() is
shared between different files in fs/proc/, so it can't be made
static. However, it got no business being used outside of the
fs/proc and it certainly shouldn't be used in modules.

Re: [PATCH] proc_lookup not exported

[Jeff Golds]

Alexander Viro wrote:
> 
> On Tue, 17 Apr 2001, Jeff Golds wrote:
> 
> > Hi folks.
> >
> > I noticed that proc_lookup is not exported in fs/proc/procfs_syms.c but
> > that the function is an external in include/linux/proc_fs.h.
> 
> Not every public function needs to be exported. proc_lookup() is
> shared between different files in fs/proc/, so it can't be made
> static. However, it got no business being used outside of the
> fs/proc and it certainly shouldn't be used in modules.
> 

I don't see why not. I created my own mkdir and rmdir handlers in my
module.  I'd like to use the lookup function that proc supplies instead
of supplying my own, why shouldn't I be allowed to do that?  It's not as
if I am doing something other than what normally happens:  I am
assigning inode_operations::lookup to be proc_lookup.

-Jeff


-- 
Jeff Golds
jgolds@resilience.com

Re: [PATCH] proc_lookup not exported

[Alexander Viro]

On Wed, 18 Apr 2001, Jeff Golds wrote:

> I don't see why not. I created my own mkdir and rmdir handlers in my
> module.  I'd like to use the lookup function that proc supplies instead
> of supplying my own, why shouldn't I be allowed to do that?  It's not as
> if I am doing something other than what normally happens:  I am
> assigning inode_operations::lookup to be proc_lookup.

Use ramfs as a model; procfs is not well-suited for that sort of work.

Re: [PATCH] proc_lookup not exported

[Jeff Golds]

Alexander Viro wrote:
> 
> On Wed, 18 Apr 2001, Jeff Golds wrote:
> 
> > I don't see why not. I created my own mkdir and rmdir handlers in my
> > module.  I'd like to use the lookup function that proc supplies instead
> > of supplying my own, why shouldn't I be allowed to do that?  It's not as
> > if I am doing something other than what normally happens:  I am
> > assigning inode_operations::lookup to be proc_lookup.
> 
> Use ramfs as a model; procfs is not well-suited for that sort of work.
> 

I don't want to cause trouble, but it sure seems like the kernel source
tree could be better organized.  For example, in every C application I
have seen, global header files specify interfaces into the relevant
module and local header files are for intramodule use only.  In the
Linux kernel tree, ALL the header files are global, thus, you can't
easily tell what things are exported and what is not as you can't just
look at the header file.  Isn't this against what open source is about: 
Requiring inside knowledge about the code?

I don't understand why local header files are not used.  It's easy to
prevent people from using the wrong functions, simply make a script that
checks to see if people are including the local header files from other
modules and return an error if they are.  This could be checked at build
time.

Maybe this is all old news, I am rather new to the Linux kernel, but
perhaps this is something that could be addressed in future (2.5?)
versions of the kernel.

-Jeff

-- 
Jeff Golds
jgolds@resilience.com