9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Dave Lukes <davel@anvil.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] kernel development: how not to
Date: Mon,  8 May 2006 16:44:33 +0100	[thread overview]
Message-ID: <445F6761.8020405@anvil.com> (raw)
In-Reply-To: <00842b4663291b0523bb203740d23f74@quanstro.net>

Yawn.

After the Beserkeley folks implemented vread() and vwrite() in 4.1BSD
many people (including myself) saw the concept and thought
"why didn't they just detect that as a special case in read() and write()?":
exactly the same benefits without the new syscalls.

In the same way, most of the speed improvements for muck like splice(),
could probably be gained by tuning the current system
(and, hey, you might even speed up a couple of other things along the way).

Of course improving current functionality without complicating any 
visible interfaces
is far less fun that implementing the
    wankmyego(fuckme, im, so, clever, look, at, all, these, parameters, 
i, must, be, a, genius)
syscall.

Sigh,
    DaveL

erik quanstrom wrote:
> sort of.  it's an extension.  here's the kerneltrap summary:
>
> 	http://kerneltrap.org/node/6506
>
> what linux actually said is that COW games (e.g. for freebsd's zero-copy
> socket code) are worse than just copying the data.
>
> the real difference between bsd's stuff and what linus did is
> the linux trick is an explict system call, not a vm game.
> but he misses that adding strange system calls that parallel
> read and write is even bigger trouble.  either your fundamental
> object is a file (unix) or a block of memory (multix).  pick a
> lane!  certainly don't mix the two at the same level.
>
> linus may be right that the freebsd vm's techniques are broken.
> i don't know.
>
> the zero-copy idea is tantalizing.  it would be neat to allow the
> network stacks or devdraw to live in a user-level fileserver
> without a performance (2 copy) penalty.  but it may be the case
> that allowing this trickery is more code than it is worth.
>
> - erik
>
> On Fri May  5 10:20:1CDT 2006, leimy2k@gmail.com wrote:
>   
>> Is the the vmslice that Linus told BSD people they were a bunch of
>> retards for not having?
>>
>>
>>
>> On 5/5/06, erik quanstrom <quanstro@quanstro.net> wrote:
>>     
>>> the linux guys decided to implement system calls
>>> "splice" and "tee".  splice concatinates the pages from
>>> two files -- the vm equivalent of "cat a b".  tee
>>> is the vm equivalent of its namesake.
>>>
>>>         http://lwn.net/Articles/181169/#Comments
>>>
>>> the best part is the conclusion -- "needs a bit more work".
>>> ha!
>>>
>>> - erik
>>>       



  reply	other threads:[~2006-05-08 15:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-05 15:41 erik quanstrom
2006-05-08 15:44 ` Dave Lukes [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-05-08 19:41 erik quanstrom
2006-05-05 15:12 erik quanstrom
2006-05-05 15:19 ` David Leimbach

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=445F6761.8020405@anvil.com \
    --to=davel@anvil.com \
    --cc=9fans@cse.psu.edu \
    /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).