Re: proc_register & co. policy change ???

From: Alexander Viro (viro@math.psu.edu)
Date: Mon Aug 28 2000 - 09:55:35 EST


On Mon, 28 Aug 2000, Velizar Bodoursky wrote:

> Ok I tryed to write some basic modules and all of a sudden I can't link them
> with the latest test7, went trough the EXPORT declaration and saw the reason
> those symbols aren't exported at all, went back to 2.2.16 and the EXPORT
> statements are in place, why is this are there some new functions which
> should replace this as a interface to proc from module's side, or is just a
> omission which hasn't been noticed yet, altrough i see that in test6 and so on.

create_proc_entry() and friends for files, proc_mkdir() for directories,
proc_symlink() for symlinks and proc_mknod() for device nodes/named
pipes/sockets.

Statically allocated proc entries are GONE. Along with the mind-boggling
amount of cruft in the drivers, BTW - these days you don't need to know
about, trace the changes in or care about the struct proc_dir_entry.

IOW, forget about proc_register() - 'E's kicked the bucket, 'e's shuffled
off 'is mortal coil, run down the curtain and joined the bleedin' choir
invisibile!! THIS IS AN EX-PARROT!! <ahem> Sorry. It's not only not
exported - it's static in file and I'll probably rename it just to avoid
the patches trying to reexport the sucker.

Same goes for proc_unregister(), indeed - use remove_proc_entry() for
that.

BTW, statically allocated inode numbers in proc are also gone with one
(obvious) exception - root directory. The rest is dynamic, so you can stop
worrying about clashes with other modules, maintaining the list of magic
constants, maintaining patches to proc_fs.h, etc.

The bottom line: forget about the voodoo needed to deal with procfs - it
became very simple now.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:21 EST