Messages in this thread |  | | Date | Mon, 28 Aug 2000 10:55:35 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: proc_register & co. policy change ??? |
| |
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/
|  |