From: Christoph Hellwig <hch@sgi.com>
To: John Hesterberg <jh@sgi.com>
Cc: linux-kernel@vger.kernel.org, Robin Holt <holt@sgi.com>,
Dan Higgins <djh@sgi.com>
Subject: Re: [PATCH] 2.5.43 CSA, Job, and PAGG
Date: Mon, 21 Oct 2002 15:43:23 -0400 [thread overview]
Message-ID: <20021021154323.A14826@sgi.com> (raw)
In-Reply-To: <20021018140546.M25310@sgi.com>; from jh@sgi.com on Fri, Oct 18, 2002 at 02:05:46PM -0500
On Fri, Oct 18, 2002 at 02:05:46PM -0500, John Hesterberg wrote:
> > +
> > +/* List of pagg (process aggregate) attachments */
> > + struct pagg_list_s pagg_list;
> > };
> >
> > You don't need the header for an unreferences structure pointer.
> > And sched.h already includes far to many other headers..
>
> It's not a structure pointer, it's the structure itself.
Umm, of course your right - sorry for the thinko (seeo? :))
> > +/* Host ID for the localhost */
> > +static uint32_t jid_hid = DISABLED;
> > +
> > +static char *hid = NULL;
> > +MODULE_PARM(hid, "s");
> >
> > What's this for?
>
> A host id (hid) is used as the top 32 bits of the job id.
> It gets initialized when you load the module, and can be
> changed with the JOB_SETHID call.
Any reason it's a char, not some interger?
> > Umm, no, ioctl on procfs is not the proper interfaces. It looks like
> > all ioctl subcalls were syscalls initially (on unicos?), so doing the
> > as actual syscalls would at least be better. Defining a proper
> > ascii file interface (i.e. echo start <arg1> <arg2> <etc.. > file)
> > sounds better.
>
> What we *really* want would be a new syscall, but we can't lock down
> the syscall number in an external patch. If we get integrated by Linus,
> then we'd love to cut over to a new syscall. For now, the ioctl on
> /proc behaves almost identically to how a new syscall would,
> in that we pass down arguments in binary format, can copyout
> results, etc. This is what the code on both ends is expecting.
Well, no. It's not one syscall but many - and we really don't like adding
new multiplexer syscalls to linux, even less then normal ones.
You might want to look at fs/nfsd/nfsctl.c in 2.5 for a proper fs-based
interface for this.
next prev parent reply other threads:[~2002-10-21 12:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-17 15:21 [PATCH] 2.5.43 CSA, Job, and PAGG John Hesterberg
2002-10-17 16:21 ` Dave Jones
2002-10-17 17:50 ` Robin Holt
2002-10-17 18:52 ` Dave Jones
2002-10-18 2:33 ` Christoph Hellwig
2002-10-18 19:05 ` John Hesterberg
2002-10-21 19:43 ` Christoph Hellwig [this message]
2002-10-18 2:44 ` Christoph Hellwig
2002-10-18 1:07 ` Andi Kleen
2002-10-18 1:22 ` Robin Holt
2002-10-18 14:37 ` Keith Owens
2002-10-18 22:00 ` Christoph Hellwig
2002-10-18 15:43 ` Keith Owens
2002-10-18 16:19 ` David Woodhouse
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=20021021154323.A14826@sgi.com \
--to=hch@sgi.com \
--cc=djh@sgi.com \
--cc=holt@sgi.com \
--cc=jh@sgi.com \
--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