9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: presotto@closedmind.org
To: 9fans@cse.psu.edu
Subject: Re: [9fans] correcting old failures, and NJ vs MA
Date: Wed, 10 Oct 2001 09:04:34 -0400	[thread overview]
Message-ID: <20011010130436.D697919A3E@mail.cse.psu.edu> (raw)

[-- Attachment #1: Type: text/plain, Size: 2229 bytes --]

Composing the viewpoints I've seen:

>But Plan 9 has been advertised as a superior alternative to the
>usual developer's interactive computing environment.  A good Web
>browser is another essential tool, these days.  Why should one
>be forced to buy a second computer to do something that ought to
>be right up the alley of the first one?

and

>People have noted (quite rightly) that the kernel code for moving
>directories is tricky and easy to get wrong and complex.  But what
>they haven't noted is that the user-space solution is even more tricky
>(if you expect it to solve the same problems), and even easier to get
>wrong, and even more complex.

...I guess we should write a web browser and stick it in the
kernel.

We are indeed driven by kernel simplicity more than anything else
because it has to survive a more varied load than individual commands.
A failure of the kernel is deadly to everything on the system.  It also
has the most persistent state of any part of the system so that leaks
and stray memory references that wouldn't bother a program tend to
eventually bring the kernel down.  Because of that, we try to put
things in kernel only if they significantly improve performance, are needed
to enforce some policy, or just can't be done outside the kernel.
Moving a directory doesn't fall into any of these categories, though
some parts of the operation do.  The move itself should be in a library
if it's going to be used by more than one program.

I find moving directories often useful, though orders of magnitude less
so than compiling, reading mail, buying wrenches on the web, ...
Making moving directories fast and convenient is as useful as
doing the same for rearranging furniture.  The current mv does let
you move directories and doesn't do it any less correctly than
the kernel could. I've spent more time reading the messages about
moving directories here than I ever would have saved by
had they been implemented.

As for find, this isn't rocket science.  Quit yapping and implement it
if you want it.  To be safe from graph cycles, you can keep 
track of qids of directories or, if you're lazy, use fd2path and give
up when the tree gets too deep.

[-- Attachment #2: Type: message/rfc822, Size: 2024 bytes --]

From: Boyd Roberts <boyd@strakt.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] correcting old failures, and NJ vs MA
Date: Wed, 10 Oct 2001 11:16:10 +0200
Message-ID: <3BC411DA.3B191015@strakt.com>

"Thomas Bushnell, BSG" wrote:
> People have noted (quite rightly) that the kernel code for moving
> directories is tricky and easy to get wrong and complex.  But what
> they haven't noted is that the user-space solution is even more tricky
> (if you expect it to solve the same problems), and even easier to get
> wrong, and even more complex.

A user mode bug won't crash the machine.

             reply	other threads:[~2001-10-10 13:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-10 13:04 presotto [this message]
2001-10-11  9:10 ` Thomas Bushnell, BSG
2001-10-11 14:29   ` david presotto
2001-10-11 15:26     ` Boyd Roberts
2001-10-11 15:54       ` andrey mirtchovski
  -- strict thread matches above, loose matches on Subject: below --
2001-10-11 11:39 forsyth
2001-10-09 21:51 bwc
2001-10-09 21:44 forsyth
2001-10-09 17:43 anothy
2001-10-10  8:56 ` Thomas Bushnell, BSG
2001-10-10  9:16   ` Boyd Roberts
2001-10-11  4:27   ` Alexander Viro
2001-10-11  9:11     ` Thomas Bushnell, BSG

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=20011010130436.D697919A3E@mail.cse.psu.edu \
    --to=presotto@closedmind.org \
    --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).