mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Limin Gu <limin@dbear.engr.sgi.com>
To: jeffrey.hundstad@mnsu.edu (Jeffrey E. Hundstad)
Cc: holt@sgi.com (Robin Holt),
	linux-kernel@vger.kernel.org, limin@dbear.engr.sgi.com (Limin Gu)
Subject: Re: [RFC][PATCH] jobfs - new virtual filesystem for job kernel/user
Date: Thu, 9 Dec 2004 09:24:14 -0800 (PST)	[thread overview]
Message-ID: <200412091724.iB9HOEf26056@dbear.engr.sgi.com> (raw)
In-Reply-To: <41B88319.9070207@mnsu.edu> from "Jeffrey E. Hundstad" at Dec 09, 2004 10:53:45 AM

> 
> I'd have to second Robin's sentiments.  IMHO there should be a very 
> strong reason to have this type of information in a new filesystem as 
> this type of proliferation is counterproductive.
> 
> -- 
> jeffrey hundstad
> 
> Robin Holt wrote:
> 
> >On Wed, Dec 08, 2004 at 02:03:21PM -0800, Limin Gu wrote:
> >  
> >
> >>Hello,
> >>
> >>I am looking for your comments on the attached draft, it is the job patch 
> >>for 2.6.9. I have posted job patch for older kernel before, but in this patch
> >>I have replaced the /proc/job binary ioctl calls with a new small virtual 
> >>filesystem (jobfs).
> >>
> >>Job uses the hook provided by PAGG (Process Aggregates). A job is a group
> >>related processes all descended from a point of entry process and identified
> >>by a unique job identifier (jid). You can find the general information
> >>about PAGG and Job at http://oss.sgi.com/projects/pagg/
> >>
> >>I will very much appreciate your comments, suggestions and criticisms
> >>on this new filesystem design and implementation as the job kernel/user
> >>communication interface. The patch is still a draft.
> >>
> >>Thank you!
> >>    
> >>
> >
> >I maintain my position that this belongs in /proc.

This is a question I try to find an answer. If the community agrees
the /proc is the right place for it, I would be very happy to move it
to /proc and implement it with procfs.

> >
> >Why not have a structure something like:
> >
> >/proc/<pid>/job -> ../jobs/<jid>

SGI is providing job to our customers as a kernel module. 
But adding /proc/<pid>/job needs to patch fs/proc/base.c, we can not
do that in a module. Of course if job gets accepted, this won't be a problem.

> >/proc/jobs/<jid>/<pid> -> ../../<pid>
> >
> >What other information is really necessary from userland?

We want to keep the same userland libraries and commands we have been
providing to our customers. Here is the library interface.

jid_t
job_create( jid_t jid_requested, uid_t uid, int options );

jid_t
job_getjid( pid_t pid );

jid_t
job_waitjid( jid_t jid, int *status, int options );

int
job_killjid( jid_t jid, int sig );

int
job_getjidcnt( void );

int
job_getjidlist( jid_t *jid, int bufsize );	/* buffer size in bytes*/

int
job_getpidcnt( jid_t jid );

int
job_getpidlist( jid_t jid, pid_t *pid, int bufsize ); /* buffer size in bytes*/

uid_t
job_getuid( jid_t jid );

pid_t
job_getprimepid( jid_t jid );

int
job_sethid( unsigned int hid );

int
job_detachjid( jid_t jid );

jid_t
job_detachpid( pid_t pid );

We will need more than those two entries in /proc as you listed above.
Would it be considered abusing /proc to have too much job stuff there?

Thanks,
--Limin

  reply	other threads:[~2004-12-09 17:38 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-08 22:03 [RFC][PATCH] jobfs - new virtual filesystem for job kernel/user interface Limin Gu
2004-12-09  1:16 ` Chris Wright
2004-12-09  2:09   ` Limin Gu
2004-12-09  2:56 ` Rusty Russell
2004-12-09 14:05 ` Robin Holt
2004-12-09 16:53   ` Jeffrey E. Hundstad
2004-12-09 17:24     ` Limin Gu [this message]
2004-12-10  7:39       ` [RFC][PATCH] jobfs - new virtual filesystem for job kernel/user Jan Engelhardt
2004-12-09 14:27 ` [RFC][PATCH] jobfs - new virtual filesystem for job kernel/user interface Andreas Schwab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200412091724.iB9HOEf26056@dbear.engr.sgi.com \
    --to=limin@dbear.engr.sgi.com \
    --cc=holt@sgi.com \
    --cc=jeffrey.hundstad@mnsu.edu \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®