Messages in this thread |  | | Date | Tue, 21 May 1996 21:40:43 +1000 | From | Robert Cohen <> | Subject | Advise wanted for implementing MPP extensions to /proc file system. |
| |
Hi, I have been looking at implementing some extensions to the /proc filesystem in APLinux. We wanted to add some MPP extensions to allow you to get info on processes on any cell.
What I'm planning on implementing is an mpp subdirectory under /proc containing a directory for each cell of the MPP machine. Each of these would be a clone of the /proc directory of that cell.
This is all orthogonal to the question of whether you should have a SSI (single system image) interface where the PID type can represent a process on any node.
Even in a SSI system are advantages to having a hierarchy under the /proc file system because otherwise a ps of the local machine would require communication since a readdir of /proc would list every process on every cell.
I'm not terribly familiar with filesystem implementation at the VFS level. I've been working on the principle of jumping in and seeing how far I get. I wasnt going to yell for help until I hit something hard.
The easy stuff hasnt given me any trouble. I have an mpp directory registered with proc_register_dynamic and files in it that give info on the machine (number of cells etc).
What I'm having trouble with is working out how to organise inode numbers for the remote directories.
One approach would be to encode both the cell number and process number into the inode number as an extension of what is done in /proc for the process directories. However you run out of bits fairly quickly. I would like 10 bits for cell id at a minimum.
My next idea was to use the same system of nuumbering as /proc, and deal with the fact that there are duplicate inode numbers in /proc/ and /proc/mpp/<cid>/ by having separate readdir and lookup functions. I encoded the cell number that a file represents in the data field of the proc_dir_entry structure.
However I ran into problems with the inode hashing stuff. It didnt like having duplicate inode numbers. Is there a standard technique for this problem? I believe that some of the existing linux file systems use duplicate inode numbers.
Should I set up a new superblock for the sub filesystem which I presume would give me a new hash table? Can I avoid using the hash table? I tried calling own version of proc_read_inode (which didnt use iget ) from lookup but I didnt register it in a superblock so the standard one was called as well.
-- Robert Cohen email: robert@cs.anu.edu.au PhD Student, Dept of Computer Science, Australian National University. =============================== ----------------------> Run fast, crash young, and leave a pretty core!
|  |