linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zach Brown <zach.brown@oracle.com>
To: Phillip Susi <psusi@cfl.rr.com>
Cc: linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>, Ulrich Drepper <drepper@redhat.com>,
	Arjan van de Ven <arjan@infradead.org>,
	Andrew Morton <akpm@zip.com.au>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	"Evgeniy Polyakov"@agminet03.oracle.com
Subject: Re: syslets v7: back to basics
Date: Mon, 10 Dec 2007 14:15:52 -0800	[thread overview]
Message-ID: <475DBA98.3000508@oracle.com> (raw)
In-Reply-To: <475DAFE9.7040700@cfl.rr.com>


> I pulled from your tree to look over the patches, and noticed that it
> looks like several commits were merged improperly.  It looks like they
> were auto merged or something from an email, and the commit message
> contains the email headers, rather than just the commit message in the
> body.  This leads to the shortlog showing entries that start with
> "Return-Path:".

These are patches that guilt imported from email messages.  It didn't
strip the headers and I didn't care to.  I'll try to in the future, it
isn't a big deal.

> I was hoping to find at least some initial information on the overall
> design in Documentation/ but don't see any.  Have you written any yet
> that I could take a look at elsewhere maybe?

No, but it's coming.  I'd like to have some robust documentation so that
Ulrich can help me understand what more he'd need to support POSIX AIO
with syslets from glibc.

> Some of the things I was trying to figure out is does each syslet get
> its own stack,

Yes.  Each blocking operation has a thread that is performing the
operation synchronously.  The benefit is that the thread is only created
if the operation blocks.  If it doesn't block then it's a normal system
call invocation.  You don't have to manage threads and communicate the
arguments and results of system calls amongst threads for the case where
it never blocks.

> and schedule only at a few well defined points

No, every blocking point is considered a scheduling point.

> , and if
> so, would it then be fair to characterize them as kernel mode fibers?

I'm not sure what exactly you mean by kernel mode fibers (I can guess,
but I'd rather not).  From the answer of to the last question, though,
I'm going to guess that it might not be the most apt characterization.

- z


      reply	other threads:[~2007-12-10 22:16 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-06 23:20 syslets v7: back to basics Zach Brown
2007-12-06 23:20 ` [PATCH 1/6] indirect: use asmlinkage in i386 syscall table prototype Zach Brown
2007-12-06 23:20   ` [PATCH 2/6] syslet: asm-generic support to disable syslets Zach Brown
2007-12-06 23:20     ` [PATCH 3/6] syslet: introduce abi structs Zach Brown
2007-12-06 23:20       ` [PATCH 4/6] syslets: add indirect args Zach Brown
2007-12-06 23:20         ` [PATCH 5/6] syslets: add generic syslets infrastructure Zach Brown
2007-12-06 23:20           ` [PATCH 6/6] syslets: add both 32bit and 64bit x86 syslet support Zach Brown
2007-12-07 11:55           ` [PATCH 5/6] syslets: add generic syslets infrastructure Evgeniy Polyakov
2007-12-07 18:24             ` Zach Brown
2008-01-09  2:03           ` Rusty Russell
2008-01-09  3:00             ` Zach Brown
2008-01-09  3:48               ` Rusty Russell
2008-01-09 18:16                 ` Zach Brown
2008-01-09 22:04                   ` Rusty Russell
2008-01-09 22:58                     ` Linus Torvalds
2008-01-09 23:05                       ` Linus Torvalds
2008-01-09 23:47                       ` Zach Brown
2008-01-10  1:18                       ` Rusty Russell
2008-01-09 23:15                     ` Davide Libenzi
2008-01-10  5:41                   ` Jeff Garzik
2007-12-08 12:40   ` [PATCH 1/6] indirect: use asmlinkage in i386 syscall table prototype Simon Holm Thøgersen
2007-12-08 21:22     ` Zach Brown
2007-12-08 12:52 ` [PATCH] Fix casting on architectures with 32-bit pointers/longs Simon Holm Thøgersen
2007-12-10 19:46 ` syslets v7: back to basics Jens Axboe
2007-12-10 21:30 ` Phillip Susi
2007-12-10 22:15   ` Zach Brown [this message]

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=475DBA98.3000508@oracle.com \
    --to=zach.brown@oracle.com \
    --cc="Evgeniy Polyakov"@agminet03.oracle.com \
    --cc=akpm@zip.com.au \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arjan@infradead.org \
    --cc=drepper@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=psusi@cfl.rr.com \
    --cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).