Re: [9fans] Fs Kernel

Re: [9fans] Fs Kernel

[C H Forsyth]

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

see /sys/src/fs/words
for a few hints

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

From: nigel@9fs.org
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Fs Kernel
Date: Mon, 6 Jan 2003 17:22:33 0000
Message-ID: <fa0a29ffa78d7a4f560ed841a58a2020@9fs.org>

> which kernel mkfile do I use for the file server?
> thanks
> will551

/sys/src/fs/*/mkfile

Re: [9fans] Fs Kernel

[nigel]

> which kernel mkfile do I use for the file server?
> thanks
> will551

/sys/src/fs/*/mkfile

Re: [9fans] how to avoid a memset() optimization

[presotto]

My probably incorrect 2 cents.  I think the basic problem is
bigger than volatile's power to solve.  There is no silver bullet.

My only experience with volatile was trying to make inferno emu code
run when compiled with non-plan9 compilers.  I never did figure out
everywhere it was needed.  Our waserror()/nexterror() stuff completely
blew away optimizing compilers since they are essentially longjumps.
Therefore, the compilers didn't know the active scope of a variable
so that registerization (and other opts) broke the code.  The appropriate
application of volatile fixed the problem though appropriate seemed
to be different for each compiler.  The general rule of thumb was that
any variable used by the waserror block should be volatile.  This seemed
to work in most instances but not all.  We had afternoons of sitting around
the Unix room trying to define exactly what it was that volatile
did in different compilers.  I never felt safe about the emu code
because of it.

My three main conclusions from this were:
1) waserror/nexterror is definitely evil unless understood by the
 compiler and perhaps even then.  It's a step outside the language
 definition and therefore a dangerous step to take.  We were
 comfortable with it in Plan 9 because we controlled the compilers
 but it became tortuous when someone else controlled them.

2) Volatile's meaning needs to grow to encompass the optimization
 du jour (don't registerize, don't optimize away memory accesses,
 don't optimize away condition code changes, don't inline code
 that contains it, ...) or we need more constructs.  It's hard to
 not screw up when using a construct whose meaning requires an in
 depth knowledge of what the compiler does.  To a certain extent, knowing
 the compiler's properties is a prerequisite to working in a kernel
 but there's a limit to what you have to understand.

 I'ld be happy if volatile just meant what I think it was originally
 intended for: don't optimize away or reorder any memory references.
 However, that in itself has myriad side effects.
 People will start to use it to avoid loop unrollings etc not envisioned
 by the compiler writer.

3) I'm too stupid to understand what C has become.  Perhaps I should go back
 to assembler.  Oops, I'm way to stupid to understand what ken's
 assembler does, I should go back to 1's and 0's.

The idea that compiler optimization is a knob that you turn till some
assumption you made becomes incorrect is scarey to me.  Very few
people understand the languages they use well enough to know when
they're treading on dangerous ground.  Even fewer testing environments
are complete enough to notice when something really has broken such
as the inadvertant creation of covert channels that got this started.
Luckily incorrect behavior in most programs doesn't really matter
because what most programs do is pretty ill defined.

Re: [9fans] how to avoid a memset() optimization

[Roman V. Shaposhnick]

On Thu, Nov 14, 2002 at 11:47:11AM -0500, presotto@plan9.bell-labs.com wrote:
> Our waserror()/nexterror() stuff completely
> blew away optimizing compilers since they are essentially longjumps.
........
> My three main conclusions from this were:
> 1) waserror/nexterror is definitely evil unless understood by the
>  compiler and perhaps even then.  It's a step outside the language
>  definition and therefore a dangerous step to take.  We were
>  comfortable with it in Plan 9 because we controlled the compilers
>  but it became tortuous when someone else controlled them.

  That's a very interesting remark, since I've always wondered why don't
  you use waserror()/nexterror() in the rest of the Plan9 source tree
  as a regular error handling mechanism.

  Personally I'm still struggling with developing an error handling
  policy that I'd feel comfortable with. Of course, good old:

       if ((a = do_it()) == BadThingHappened)
            return TellEmAboutIt;

  works, but costs a little bit too much when clarity is needed. Especially
  when a "transaction" like pattern is needed ( e.g. I need to
  to have o1 = f1(); o2 = f2(); o3 = f3(); but if any of f* fails,
  I have to destroy what I've got so far ).

  C++ style exceptions are nice, but easily abused, and I haven't seen
  any way of emulating then in pure C.

  So, what your experience has been with error handling ( granted, you
  must've had plenty ;-) ) and what would you consider the most
  comfortable one ?

Thanks,
Roman.

Re: [9fans] how to avoid a memset() optimization

[Ralph Corderoy]

Hi Roman,

> Of course, good old:
>      
>      if ((a = do_it()) == BadThingHappened)
>           return TellEmAboutIt;
> 
> works, but costs a little bit too much when clarity is needed.
> Especially when a "transaction" like pattern is needed ( e.g. I need
> to to have o1 = f1(); o2 = f2(); o3 = f3(); but if any of f* fails, I
> have to destroy what I've got so far ). 

A common way of doing this is using goto.

        failed = 1;

        if ((res1 = lock(A) == 0) {
            goto releaseA;
        }
        if ((res2 = lock(B) == 0) {
            goto releaseB;
        }
        if ((res3 = lock(C) == 0) {
            goto releaseC;
        }

        foo(res1, res2, res3);
        failed = 0;

    releaseC:
        release(C);
    releaseB:
        release(B);
    releaseA:
        release(A);

        return failed;

Cheers,

-- 
Ralph Corderoy.      http://inputplus.co.uk/ralph/     http://troff.org/

[9fans] Fs Kernel

[Conor Williams]

which kernel mkfile do I use for the file server?
thanks
will551