lkml.org 
[lkml]   [1996]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectAdvise 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!


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.101 / U:1.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site