I don't think you are disagreeing with me. They are not generic by
any means. But I think the SCSI and net code could easily be ported
to use a generic /proc interface. I only used SCSI as an example of
a _non-generic_ interface, that IMHO should be made more generic.
>heck they really shouldn't be part of the /proc code! The /proc
>system ALREADY has a generic interface, but it is not used :-(
Yes, well... at the moment the generic interface is rather limited.
There is no generic inode_operations exported for use by modules,
so these have to be written. And if you look at the code for the
various inode_operations already coded, they are very similar. Most
of the code duplication is in implementing these non-generic
inode_operations. This is where I want to start unifying the code.
My goal is to expand it's capabilities to the extent that most (if
not all) /proc entries would use the generic interface.
>IMHO, all code should register/unregister a /proc entry from somewhere
>other than the proc code. Only the "system" stuff should be anywhere
>near the base /proc code - and then it should likely be in separate
>files.
Exactly. But code organization is just a part of it. Do we really
need reserved inodes? The only area this still makes sense is with
the /proc/PID stuff because lookups are much faster with a 1:1
mapping of PID to inode. The rest of the code could use
proc_register_dynamic().
>Good luck - somebody (I forget - you?) posted some patches for
>/proc a while back to clean it up. Perhaps you should check the
>archives for this.
It was not me. Thanks for the tip though. I will check the archives.
Rob
(rriggs@tesser.com)