Messages in this thread |  | | Date | Fri, 27 Sep 1996 13:16:20 -0600 (MDT) | From | Rob Riggs <> | Subject | Re: /proc filesystem code cleanup |
| |
On 27-Sep-96 "Andrew E. Mileski" wrote: >> I am working with on implementing /proc support on a driver and >> noticed that each subsystem seems to implement their interface to >> the proc code a bit differently. Only the SCSI devices seem to >> have any sort of uniform proc interface, but it is still very >> SCSI specific. > >I disagree with you - the SCSI (and net code) are _NOT_ generic...
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)
|  |