Re: [9fans] useful language extension, or no?

Re: [9fans] useful language extension, or no?

[Sam]

You're right, and the capability to do:

struct type {
	int a;
	int b;
};

struct type2 {
	type;
	int c;
	int d;
};

saves so many more strokes in itself *and must* be more efficient.

Suppose I'm not saying "why," but "why not."  IMO it's cleaner and
quite possibly more efficient (without getting into a usec argument,
please).  Do you disagree?

Sam

On Tue, 16 Jul 2002, rob pike, esq. wrote:

> Saves you, what, 5 keystrokes?  Not too convincing.
>
> -rob
>

Re: [9fans] useful language extension, or no?

[rob pike, esq.]

Saves you, what, 5 keystrokes?  Not too convincing.

-rob

Re: [9fans] useful language extension, or no?

[Steve Kilbane]

> Suppose I'm not saying "why," but "why not."  IMO it's cleaner

I disagree. It's considerably more ambiguous. Your loop continuation
condition (i<NELS) may be failed by considerably more cases
than your trailing condition (i==NELS). What happens if your loop
body does "i=NELS+1"? What if your "i++" was actually something
like "i=arr[i]"? What if your continuation condition was
"i<NELS && j<NELS2"?

C's "for" is not like Pascal's FOR.

> and
> quite possibly more efficient

The pros and cons have already been discussed. I'd just like to
note that there's no particularly compelling reason why it would
generate different code from that which used the idiom. A good
optimiser would render them into the same internal form anyway.

"A good optimiser" is a subjective term, and Plan 9's C optimising
has already been discussed recent (Summary: it's good enough that
there are more important/interesting/useful things to work on),
but the point stands.

steve

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

[Russ Cox]

>   He doesn't need to know about volatile -- that's the whole point.
>   Once "experienced" programmer has set the buffer that way, the
>   less experienced just gets less chance to screw himself up

I'd still rather see it closer to the use that needs it.
If you're used to seeing secmemset then seeing
memset is a big red flag.  If you're used to seeing
memset with a volatile declaration, then you have
to seek out the volatile declaration, which might not
be anywhere near the call to memset.

This is a stupid argument anyway.  Volatile is a crock.
Here's another problem.  Suppose I'm worried that
leaking the processor flags at the end of my computation
might reveal something about the secret key.  I want to
clear them.  I could do something like:

	x = 0 & 0;

which in this particular case will clear the appropriate
flags.  But now the compiler comes along and optimizes
away the whole expression.  Where do I put my volatile
to make that stay?  Hmm?  The answer is not more crappy
qualifiers.  The answer is clearly dumber compilers.

Russ

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

[Douglas A. Gwyn]

Russ Cox wrote:
> This is a stupid argument anyway.  Volatile is a crock.
> Here's another problem.  Suppose I'm worried that
> leaking the processor flags at the end of my computation
> might reveal something about the secret key.  I want to
> clear them.  I could do something like:
> 	x = 0 & 0;
> which in this particular case will clear the appropriate
> flags.  But now the compiler comes along and optimizes
> away the whole expression.  Where do I put my volatile
> to make that stay?  Hmm?  The answer is not more crappy
> qualifiers.  The answer is clearly dumber compilers.

Do you really want the compiler to always generate code
	MOV	R1,#0
	MOV	R2,#0
	AND	R2,R1
	MOV	R2,X(SP)
?  Almost any modern compiler will peform the AND at
compiler time (constant folding), and most customers want
that.  Anyway, I don't see why you need to AND in this
context.  Are you talking about the C and V bits?  If some
other process can inspect those for your process I'd think
it could inspect a whole lot more..

It is certainly true that we could really use better access
to the C bit from higher-level language source code.  This
shows up especially in the MP library.  But exploiting too
specific knowledge about the workings of a specific platform
can be dangerous, as we've seen historically.  If anybody
can devise a *nice* way to get at the C bit in MP coding,
please let me know so that it can be proposed for C0x.

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

[Sam]

> Do you really want the compiler to always generate code
> 	MOV	R1,#0
> 	MOV	R2,#0
> 	AND	R2,R1
> 	MOV	R2,X(SP)

Yes, yes, and yes.  Optimizations which intelligently manage
register allocation are about as far as *I* appreciate.  Do
precisely what I say, and no less.  If I write poor code,
boo hoo for me.  Heavily optimizing compilers will *never*
make all coders equal and generally cause more headaches
than they're worth.

I do appreciate some warnings (ie if I forget to initialize
a variable to zero before I use it), but some of them are
just irritating.  Brantley looked over my shoulder a while
back and wondered why I was typing:

	if((m=fn())) {
		...
	}

saying, "what's with the extra parenthesis?"  "Oh, gcc complains
that I should surround assignment values used as a truth statement
and I've just incorporated it by habit to shut it up."

I hadn't even realized I was permitting gcc to define my style.
In essence, by permitting mad optimizations and then having to
do backflips just to keep the compiler from optimizing away
our real intentions, we're doing the same thing.  I hardly see
this as useful.

Cheers,

Sam

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

[Scott Schwartz]

I, for one, like optimizing compilers.  Sure, sometimes you need fine-
grained control, but mostly I want faster code.  But like rob says, maybe
something other than C is what's called for.

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

[Boyd Roberts]

I'd rather have slow and right over fast and broken.

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

[plan9]

On Thu, Nov 14, 2002 at 04:26:08PM +0100, Boyd Roberts wrote:
> I'd rather have slow and right over fast and broken.

You and the other 5% of the world's consumers.

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

[Douglas A. Gwyn]

> > Do you really want the compiler to always generate code
> >       MOV     R1,#0
> >       MOV     R2,#0
> >       AND     R2,R1
> >       MOV     R2,X(SP)
Sam wrote:
> Yes, yes, and yes.  Optimizations which intelligently manage
> register allocation are about as far as *I* appreciate.  Do
> precisely what I say, and no less.

I intentionally mimicked the PDP-11 in my example since it supports
nearly a direct mapping from C to instructions.  However, on many
modern machines there is no such direct mapping for many of (old)
C constructs, so trying to control code generation through use of
C source code is fruitless.  And once you accept that principle,
it is hard to tell what constitutes optimization versus simple
code generation.  If you want assembly language you know where to
find it...

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

[Dan Cross]

I like Proebsting's law.  Compiler optimizations will get you a 2 fold
increase in speed once every 18 years.  That said, I wouldn't give up
the optimizations I have now, but I'm not married to them.

	- Dan C.

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

[Sam]

Let's define "slow."  The last time I did a performance
test was on a des module I wrote.  The gcc compiled
-02 ran .2-.4 seconds faster (out of 3-4s).  Further
optlevels were not any better.

Anyone have any numbers showing that, "without optimizations,
this simply wouldn't be tolerable," in the face of well
written code?  In these instances does the compiler
generate crap code from the start, expecting an optimizer
to come clean it up later?

We wrote a C compiler for the language as of about
'73 for a coldfire target and it was a very telling
experience.  It was rather obvious that a simple
peephole optimizer would handle most of the inefficiencies
in the generated assy.  The code ran fast enough for
our purpose, however, so we didn't bother.  Indeed,
the human-time component is the most expensive
resource.  It's a shame 95% of the world doesn't
understand that.

Cheers,

Sam

On Thu, 14 Nov 2002 plan9@sigint.cs.purdue.edu wrote:

> On Thu, Nov 14, 2002 at 04:26:08PM +0100, Boyd Roberts wrote:
> > I'd rather have slow and right over fast and broken.
>
> You and the other 5% of the world's consumers.
>

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

[Douglas A. Gwyn]

Dan Cross wrote:
> I like Proebsting's law.  Compiler optimizations will get you a 2
> fold increase in speed once every 18 years.

Do you mean, that optimization technology improves at that rate?
For RISC architectures it is hard to tell optimization apart from
simply doing a good job of allocating registers, pipelines, etc.

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

[Dan Cross]

> > I like Proebsting's law.  Compiler optimizations will get you a 2
> > fold increase in speed once every 18 years.
>
> Do you mean, that optimization technology improves at that rate?

Yes.  He states it much more succinctly than I did:
http://research.microsoft.com/~toddpro/papers/law.htm

> For RISC architectures it is hard to tell optimization apart from
> simply doing a good job of allocating registers, pipelines, etc.

That's true, but eliminating whole function calls is pretty clearly
an optimization.

	- Dan C.

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

[Steve Kilbane]

> I'd rather have slow and right over fast and broken.

Others have different opinions. There are several issues here.

1. Some people want near-to-optimal code for the machine they've
chosen (slower code means faster machine needed, means higher price,
means fewer sales), and they want it soon (before their competitors
get all the market share). The economics of those markets mean they
need optimizing compilers. Vendors are happy to fill that need.

2. The language is being used for two different purposes: expressing
an abstract algorithm, and controlling the machine. These conflict.

3. There's a scary number of people out there who don't understand
the language they're using, and define it in terms of "Microsoft
gets it right," or "gcc does it properly", without realising they've
just been lucky. Their code can break from one compiler to another,
without having to optimize it. Optimizers just make it more obvious.

steve

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

[Douglas A. Gwyn]

Steve's reponse was very nice.  Another way of putting it
is that the "right" behavior is not at all obvious once
you think hard enough about it and examine a wide enough
variety of platforms and application requirements.  One
of the tasks undertaken by the C standards committee was
to negotiate among the conflicting demands and to draw
the line somewhere.  Individuals would very likely draw
the line in other places, depending on their personal
prejudices and values.  If the existing standard
specification is causing significant real problems, there
is a mechanism in place to get it reconsidered and maybe
the official line could be redrawn.  The really important
thing is to understand where the official line *is* and
to observe it (on both sides, programmer and implementor);
that allows all parties to work together even if they all
still want to grumble about some aspect of the work..

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

[Roman V. Shaposhnick]

On Thu, Nov 14, 2002 at 01:53:04AM -0500, Russ Cox wrote:
> >   He doesn't need to know about volatile -- that's the whole point.
> >   Once "experienced" programmer has set the buffer that way, the
> >   less experienced just gets less chance to screw himself up
>
> to make that stay?  Hmm?  The answer is not more crappy
> qualifiers.  The answer is clearly dumber compilers.

  Or may be the answer is
     #pragma get your hands off my data, your psycho

  ;)

Thanks,
Roman.

[9fans] presentation preparation

[Sam]

I'm working on a presentation and am
wondering what approach other 9'ers take
to preparing slides.  I'm thinking
a full screen page(1) would be sufficient
and I could use the extant doc prep
tools I'm becoming increasingly familiar
with.

Tips, tricks, and/or suggestions are welcomed.

Cheers,

Sam

Re: [9fans] presentation preparation

[Scott Schwartz]

| I could use the extant doc prep
| tools I'm becoming increasingly familiar
| with.

Not a Plan 9 specific answer, but...  I rather like latex with the
prosper package.  Ideally it is used to make pdf, and can take advantage
of acroread's features, but straight ps output should be usable.

Re: [9fans] presentation preparation

[andrey mirtchovski]

We were discussing latex presentations on this list some time ago (Russ
posted a fix to page to handle some mangled PostScript)...

I've done fine with presenting pdf or ps in a full-screen 'page' window on a
1024x768 laptop screen...

When talking about Plan 9 it is also useful to be able to hide the
presentation screen and show a few examples right there on the spot,
demo-style :)

I've sent Sam a sample presentation already, but didn't want to bother the
list with it. Another suggestion at the time was to use troff :)

andrey

On Sat, 15 Feb 2003, Scott Schwartz wrote:

> | I could use the extant doc prep
> | tools I'm becoming increasingly familiar
> | with.
>
> Not a Plan 9 specific answer, but...  I rather like latex with the
> prosper package.  Ideally it is used to make pdf, and can take advantage
> of acroread's features, but straight ps output should be usable.
>

Re: [9fans] presentation preparation

[Richard Miller]

> I'm working on a presentation and am
> wondering what approach other 9'ers take
> to preparing slides.

I write slides in html [actually in a simpler syntax which is
translated to html by an awk script] and use charon to display
them.

-- Richard

Re: [9fans] presentation preparation

[Russ Cox]

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

Attached are some presentations I've done using
troff and page, along with tools that make them
easier.

You can play with the variables at the end of tmac.ppt
(or the definitions themselves) to add color to various
parts.

I tend to shy away from color usually, though.
The auth talk is black and white, while the oscpu
presentation adds grey.

Russ

[-- Attachment #2: doc.tar.gz --]
[-- Type: application/octet-stream, Size: 12370 bytes --]

Re: [9fans] presentation preparation

[Fco.J.Ballesteros]

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

An alternative is to use either the foils macro package or
a derivative. This is the one I use along with the respective mkfile
with view, print, ... targets

hth

[-- Attachment #2: slides.tgz --]
[-- Type: application/x-tar, Size: 7848 bytes --]

Re: [9fans] presentation preparation

[Ralph Corderoy]

Hi andrey,

> Another suggestion at the time was to use troff :)

Bob Diertens' http://www.science.uva.nl/~bobd/useful/gpresent/ is useful
for producing PDF presentations using GNU troff.

Cheers,

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

[9fans] union directories

[Jack Johnson]

Ronald G. Minnich wrote:
 > truthfully, how many of you out there started out using disk/kfscmd
 > allow when you wanted to modify the kernel source?

I'll admit it, but I'm still a newbie so I have an extension of this
question.

Is there any way to, say, recompile a source tree with subfolders
without pre-creating those subfolders in the union directory?  Or,
what's the correct way to do something like:

mkdir 9
bind -bc 9 9
bind -ac /sys/src/9 9
cd 9
mk

(though that's not what I'm doing, I'm just needed an easy example)

-Jack

Re: [9fans] union directories

[Russ Cox]

there's no good way to do a recursive bind.
for the kernel you could piece it together with

t=/usr/you/9
bind -bc $t/pc /sys/src/9/pc
bind -bc $t/boot /sys/src/9/boot
cd /sys/src/9/pc
mk

Re: [9fans] union directories

[Adrian Tritschler]

Jack Johnson wrote:
> Ronald G. Minnich wrote:
>> truthfully, how many of you out there started out using disk/kfscmd
>> allow when you wanted to modify the kernel source?

I'll admit it.  How many knew any other way?  How many yet know?  Maybe a
little mention on the Wiki at
http://plan9.bell-labs.com/wiki/plan9/Compiling_kernels would be helpful.

Several months into my plan9 learning and I'm still getting my head around the
plan9 way of doing some things... most things...

> I'll admit it, but I'm still a newbie so I have an extension of this
> question.
> 
> Is there any way to, say, recompile a source tree with subfolders
> without pre-creating those subfolders in the union directory?  Or,
> what's the correct way to do something like:
> 
> mkdir 9
> bind -bc 9 9
> bind -ac /sys/src/9 9
> cd 9
> mk
> 
> (though that's not what I'm doing, I'm just needed an easy example)
> 
> -Jack

	Adrian

---------------------------------------------------------------
Adrian Tritschler    mailto:Adrian.Tritschler@its.monash.edu.au
Latitude 38°S, Longitude 145°E, Altitude 50m,      Shoe size 44
---------------------------------------------------------------

Re: [9fans] union directories

[anyrhine]

...
> files obscured within a union mount are not accessible to me; in fact,
> apart from telling me that the directory probably contains a union
> mount, information on those files is of no use at all.

I like having the duplicates precisely for that information.
I tend to use a quite fixed set of bindings, and most of the time it's
just a question of wheter I've made them, not what I've bound
where. 

...
> acme the same - what's the point of showing me two of the same names
> next to each other?  it just causes clutter. clicking on either
> one performs exactly the same action.

Especially in acme, because there it's (imho) easier to look for the expected
duplicates than execute something, focus on the output window for
the results, and then focus back to the original window.

Re: [9fans] union directories

[Russ Cox]

> Just to check user/group/world w flags.

even if those are set the file system might
be read-only.  for example when you 9fs sources
you can't change things in /n/source/plan9/cron
despite it being mode 777 and not a union mount.

Re: [9fans] union directories

[Keith Nash]

>> Is there any way to test the writability
>> of a directory, other than by attempting
>> to create a file there, or by combining
>> ls -ld with an examination of the output of ns?

>No.

>I'm not even sure how ls -ld would help you.
Just to check user/group/world w flags.

>ns would give you a first approximation.

Re: [9fans] union directories

[Russ Cox]

> Is there any way to test the writability
> of a directory, other than by attempting
> to create a file there, or by combining
> ls -ld with an examination of the output of ns?

No.

I'm not even sure how ls -ld would help you.
ns would give you a first approximation.

Re: [9fans] union directories

[Keith Nash]

> Ls tells the truth!  I see no value in causing it to lie.

It tells the truth and nothing but the truth, but does it tell the whole truth?

I might believe from running ls -ld on a directory that I can create a new file in it; but I can't, if the directory is a union mount, and none of the elements was bound with -c.

Is there any way to test the writability of a directory, other than by attempting to create a file there, or by combining ls -ld with an examination of the output of ns?


Keith.

Re: [9fans] union directories

[rog]

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

> Ls tells the truth!  I see no value in causing it to lie.

i'd like to be able to think of "ls" as showing me the files available
to me in a given directory.

files obscured within a union mount are not accessible to me; in fact,
apart from telling me that the directory probably contains a union
mount, information on those files is of no use at all.

there's a good implementation reason for having the duplicates show up
in raw reads (it only requires constant space in the kernel), but why
not get rid of the duplicates given that we're sorting the entries
anyway.

this isn't lying: it's showing a simplified version of the truth which
is not misleading (unlike the example in the lexnames paper).

> And then once ls lies, why doesn't ls *?  Why doesn't acme?

in fact, i think it's more important that * removes duplicates than ls.
i think it's a bug that:

	for (i in *) do something

can end up processing a single file multiple times.

acme the same - what's the point of showing me two of the same names
next to each other?  it just causes clutter. clicking on either
one performs exactly the same action.

> There might be good arguments that directory reads should
> reflect the information in the mount table, perhaps eliding
> duplicates and perhaps showing you the real stat info for 
> bound-over files (what you'd get with stat(2)).  Then again
> there are also good arguments for the way things are now.

mk was bitten by this at one stage.
it's a pity that
	ls -l | grep foo
doesn't necessarily give the same results as
	ls -ld foo

now that's a genuine case of ls (or at least unionread()) lying...
i agree about the arguments for the current behaviour though.

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

From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] union directories
Date: Mon, 3 Mar 2003 13:05:41 -0500
Message-ID: <0a304f2dd88c5bdb8eb1ce403c53e037@plan9.bell-labs.com>

> Actually I have had more Unix-oriented folks ask me if in a union ls 
> there could be an option, per-file, to display the binding for that file 
> when there is more than one. 

Per-file options are a bad idea not even worth talking about.

> I got real complaints from people about seeing multiple files with the 
> same name on an ls. 

Ls tells the truth!  I see no value in causing it to lie.
And then once ls lies, why doesn't ls *?  Why doesn't acme?
Ls does one thing.  It does it well.  It's consistent with the
rest of the system.  If you want sort -u, you know where to
find it.

There might be good arguments that directory reads should
reflect the information in the mount table, perhaps eliding
duplicates and perhaps showing you the real stat info for 
bound-over files (what you'd get with stat(2)).  Then again
there are also good arguments for the way things are now.

Read the ksh example in the lexnames paper.  The last thing we
need is user-space programs that ``patch'' kernel behaviors.
Arguing that the kernel needs fixing might be reasonable.
Changing ls to hack around perceived kernel deficiencies
is the path to madness (or to Linux, take your pick).

Russ

Re: [9fans] union directories

[Russ Cox]

> Is there a better answer?

Running ls -l on the file will give you the stat info
for the actual file.  

Compare ls -l /dev | grep mouse and ls -l /dev/mouse.

Re: [9fans] union directories

[Ronald G. Minnich]

On Mon, 3 Mar 2003, Russ Cox wrote:

> Read the ksh example in the lexnames paper.  The last thing we
> need is user-space programs that ``patch'' kernel behaviors.
> Arguing that the kernel needs fixing might be reasonable.
> Changing ls to hack around perceived kernel deficiencies
> is the path to madness (or to Linux, take your pick).

I phrased it wrong. I did not mean a patch to 'ls'. 

Try again. 


I have showed folks union mounts, done an ls, and gotten complaints such
as: when you edit/cat/print a file, how do you know what you're editing?  
My only answer is weak: 'well you did the bind, so you know'.

Is there a better answer?

ron

Re: [9fans] union directories

[Russ Cox]

> Actually I have had more Unix-oriented folks ask me if in a union ls 
> there could be an option, per-file, to display the binding for that file 
> when there is more than one. 

Per-file options are a bad idea not even worth talking about.

> I got real complaints from people about seeing multiple files with the 
> same name on an ls. 

Ls tells the truth!  I see no value in causing it to lie.
And then once ls lies, why doesn't ls *?  Why doesn't acme?
Ls does one thing.  It does it well.  It's consistent with the
rest of the system.  If you want sort -u, you know where to
find it.

There might be good arguments that directory reads should
reflect the information in the mount table, perhaps eliding
duplicates and perhaps showing you the real stat info for 
bound-over files (what you'd get with stat(2)).  Then again
there are also good arguments for the way things are now.

Read the ksh example in the lexnames paper.  The last thing we
need is user-space programs that ``patch'' kernel behaviors.
Arguing that the kernel needs fixing might be reasonable.
Changing ls to hack around perceived kernel deficiencies
is the path to madness (or to Linux, take your pick).

Russ

Re: [9fans] union directories

[Ronald G. Minnich]

On Mon, 3 Mar 2003 rog@vitanuova.com wrote:

> come to that, it would be nice if ls -l used a stable sorting
> algorithm so that it was possible to tell which file attributes were
> likely to correspond to the file that would be opened under a
> particular name.

Actually I have had more Unix-oriented folks ask me if in a union ls 
there could be an option, per-file, to display the binding for that file 
when there is more than one. 

I got real complaints from people about seeing multiple files with the 
same name on an ls. 

Not that we want to put whiteouts in there, however.

ron

Re: [9fans] union directories

[rog]

> (Bind -bc 9 9 is like:
> 
> 	bind 9 9 
> 	bind -bc 9 9
> 
> hence everything appears twice.)

is there a good reason why ls doesn't eliminate duplicates when
showing union directories?

occasionally it might be useful, but as the default behaviour?

come to that, it would be nice if ls -l used a stable sorting
algorithm so that it was possible to tell which file attributes were
likely to correspond to the file that would be opened under a
particular name.

i did both of these things in inferno, with no obvious adverse
consequences.

Re: [9fans] union directories

[Geoff Collyer]

Yes, your example would have roughly the same effect as my second
example, except that mine uses /tmp/x as the mount point and yours
uses /sys/lib, and sometimes that matters.

The point to note is that

	mkdir x; bind -a /sys/lib x
and
	mkdir x; bind -ac /sys/lib x

do an implicit

	bind  /tmp/x /tmp/x

before the bind of /sys/lib, which leaves /tmp/x uncreateable unless
it is then bound into the union with -c, with something like

	bind -bc /tmp/x /tmp/x

after the bind of /sys/lib, or

	bind -c /tmp/x /tmp/x

before it.

Re: [9fans] union directories

[Jack Johnson]

Geoff Collyer wrote:
> `bind -c 9 9' remains useful, however, to retain createability of the
> directory in which a union mount is then performed:
> bind -c /tmp/x /tmp/x
> bind -a /sys/lib /tmp/x
> cd /tmp
> ; >x/FOO
> ; unmount x; ls x
> x/FOO

OK, but if I'm currently understanding this correctly, shouldn't it now be:

bind -bc /tmp/x /sys/lib
cd /sys/lib
 >FOO
cd /tmp
unmount /sys/lib; ls x
x/FOO

?

How does this differ from yours?  It *looks* like you end up with the
same scenario I originally presented.

-Jack

Re: [9fans] union directories

[Geoff Collyer]

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

`bind -c 9 9' remains useful, however, to retain createability of the
directory in which a union mount is then performed:

; cd /tmp
; mkdir x
; bind -a /sys/lib x
; ns|tail -4
mount -b '#s/rio.geoff.73279' /dev
bind  /tmp/x /tmp/x
bind -a /sys/lib /tmp/x
cd /tmp
; >x/FOO
x/FOO: rc: can't open: mounted directory forbids creation

versus

; unmount x
; bind -c x x
; bind -a /sys/lib x
; ns|tail -4
mount -b '#s/rio.geoff.73279' /dev
bind -c /tmp/x /tmp/x
bind -a /sys/lib /tmp/x
cd /tmp
; >x/FOO
; unmount x; ls x
x/FOO

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

From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] union directories
Date: Fri, 28 Feb 2003 13:56:18 -0500
Message-ID: <1f229e0b2b861ffeebd62738b74c9cd3@plan9.bell-labs.com>

You used to need to say "bind foo foo" to set up a mount
point for future union mounts.  (A long time ago.)
Now the system inserts these for you, though they're
still visible in the /proc/$pid/ns file (and thus the
output of ns).

Bind -bc 9 9 is a different thing, and almost
certainly not what is wanted, especially in the
example given -- it doesn't have any effect except
to make everything appear twice in the directory.
(Bind -bc 9 9 is like:

	bind 9 9
	bind -bc 9 9

hence everything appears twice.)

Russ

Re: [9fans] union directories

[Jack Johnson]

Russ Cox wrote:
> Bind -bc 9 9 is a different thing, and almost
> certainly not what is wanted

Aha!

It's a psychological mishap on my part.

I was thinking, "Create a union directory, add the writeable directory
to the beginning and the source directory to the end of the union
directory," rather than, "Unite the (new) writeable directory to the
beginning of the (old) source directory."

Which, in retrospect, makes the intent in the man page seem completely
obvious now.

Thanks!

-Jack

Re: [9fans] union directories

[Russ Cox]

You used to need to say "bind foo foo" to set up a mount
point for future union mounts.  (A long time ago.)
Now the system inserts these for you, though they're
still visible in the /proc/$pid/ns file (and thus the
output of ns).

Bind -bc 9 9 is a different thing, and almost
certainly not what is wanted, especially in the
example given -- it doesn't have any effect except
to make everything appear twice in the directory.
(Bind -bc 9 9 is like:

	bind 9 9
	bind -bc 9 9

hence everything appears twice.)

Russ

[9fans] union directories

[Joel Salomon]

Jack Johnson wrote:

> mkdir 9
> bind -bc 9 9
> bind -ac /sys/src/9 9
> cd 9
> mk

What is the significance of bind -bc 9 9 ?
I've seen this bind foo foo elsewhere - what does it do?
--Joel

Re: [9fans] union directories

[Douglas A. Gwyn]

rog@vitanuova.com wrote:
> if i type:
>         echo hello > /usr/rog/file
> i expect /usr/rog/file to be created if it isn't already there, but
> overwritten if it is.

What you expect is a strong function of what you are accustomed to.
Whether or not the above is desired behavior is about a 50-50
proposition, based on my own experience (with a lot of lost data).

My point about create is that it seems its primary function is to
write an entry into a directory.  Whether or not it should fail if
the entry is already there is debatable, but truncating the content
of the pointed-to file seems like a different function, indeed one
that is already available by open-for-writing.

I think the database people would support the position that the
basic actions need to be atomic, which pretty much means simple.

Re: [9fans] union directories

[G. David Butler]

No, I did NOT pay him to say this! :)


"Douglas A. Gwyn" <DAGwyn@null.net> wrote:
__________
>rob pike wrote:
>> This is all a legacy of Unix's model that create means two different
>> things in the two situations.
>
>Well, there you go -- an attempt to create an existing file should
>fail.  That is a simpler and more useful property.
>

Re: [9fans] union directories

[rog]

> > This is all a legacy of Unix's model that create means two different
> > things in the two situations.
>
> Well, there you go -- an attempt to create an existing file should
> fail.  That is a simpler and more useful property.

it's not just a problem with the semantics of the create() system call,
but with the shell too.

if i type:

	echo hello > /usr/rog/file

i expect /usr/rog/file to be created if it isn't already there, but
overwritten if it is.

if create didn't overwrite an existing file, the shell would have to do
exactly as the kernel does currently, and for most intents and purposes
you'd still get the same "dual meaning".

i think under 9p2000 it's possible to call create() with an OEXCL
option and get the semantics you suggest.

  cheers,
    rog.

Re: [9fans] union directories

[Douglas A. Gwyn]

rob pike wrote:
> This is all a legacy of Unix's model that create means two different
> things in the two situations.

Well, there you go -- an attempt to create an existing file should
fail.  That is a simpler and more useful property.

Re: [9fans] union directories

[rob pike]

	The manual says "creation goes to the first element of the union that 
	permits creation". Doesn't that means that it shoud jump non_writable?.

Actually, the manual page bind(1) says,

	[-c] can be used in addition to any of the above to permit
	creation in a union directory.
	When a new file is created in a union directory,
	it is placed in the first element of the union that permits creation.

In this context, I don't feel it's ambiguous.

Bind(2) says,

	When a create system call (see open (2)) attempts to create in a union
	directory, and the file does not exist, the elements of the union are
	searched in order until one is found with MCREATE set.  The file is
	created in that directory; if that attempt fails, the create fails.

which is even clearer.

As to what it *should* do, this topic was one of the most discussed
in the early days of the system.  The current behavior obviously
reflects an easy implementation.  It's worked well in practice but
better designs may exist.

	Lookup should win whenever creation wins.

I'm not sure what this means.  There's no "winning" going on, and
lookup cannot work the same as creation if the file does not exist,
since there's nothing to look up.  If there is an existing file with that
name, in any element of the union, it is the one to which creation
will always apply.

This is all a legacy of Unix's model that create means two different
things in the two situations.

-rob

Re: [9fans] union directories

[Gorka Guardiola Muzquiz]

Russ> Actually that's the way it's supposed to work.
The manual says "creation goes to the first element of the union that 
permits creation". Doesn't that means that it should jump over non_writeble?
Even taking that in account, I can't see the logic behind this behaviour.
Lookup should win whenever creation wins. That would be symmetrical and
clean. with bind -ac n1 n2, bind -bc n1 n2, bind -ac n2 n1, bind -bc n2 n1
you would cover all the logical possibilities, and you save doing
bind -c n1 n2

Re: [9fans] union directories

[Gorka Guardiola Muzquiz]

>Actually that's the way it's supposed to work.
The manual says "creation goes to the first element of the union that 
permits creation". Doesn't that means that it shoud jump non_writable?.

Re: [9fans] union directories

[Gorka Guardiola Muzquiz]

Re: [9fans] union directories

[Russ Cox]

That's an unfortunate choice of words (in the manual).
"Permits creation" in that context means "was bound
into the union with -c" not "creates would succeed there
if tried".

Russ

Re: [9fans] union directories

[Russ Cox]

Actually that's the way it's supposed to work.

    Say you have two directories free_space and non_writable.
    If you write:

    bind -bc free_space non_writable 

    You add space to non_writable. Everything works fine. free_space is before
    non_writable in non_writable. If you create a file in non_writable you
    are actually creating int in free_space.

The union looks like

 * free_space
   non_writable

where the * means the directory was bound with -c.
Creates go to the topmost starred directory.

    bind -ac non_writable2 free_space2

    non_writable2 is after free_space2 in free_space2. You should be able to
    write in free_space. *you can't*. Even stranger:

Now you have

   free_space2
 * non_writable2

Creates go to non_writable2, but the directory
isn't writable.

    bind -ac fspace1 fspace2

    Any file in fspace2 supersedes any file in fspace1 with the same name,
    but if you create a file in fspace2 it is actually created *in fspace1*!!!???.
    fspace1 is *after* fspace2 for already existing files,
    but it is *before* when you create new ones.

Now you have

   fspace2
 * fspace1

Creates go to fspace1 but fspace2 wins for lookups.

It's just the way it's defined.  Note that if you did

bind -c fspace2 fspace2
bind -ac fspace1 fspace2

you'd have

 * fspace2
 * fspace1

so creates would go to fspace2 (the fact that fspace1
is starred is ignored), and fspace2 would win for lookups.

Russ

[9fans] union directories

[Gorka Guardiola Muzquiz]

I have encountered a behaviour in bind (well, actually in the fs) which
I find inconsistent. I may not be a bug, but it is counter intuitive.
Say you have two directories free_space and non_writable.
If you write:
bind -bc free_space non_writable 

You add space to non_writable. Everything works fine. free_space is before
non_writable in non_writable. If you create a file in non_writable you
are actually creating int in free_space.

bind -ac non_writable2 free_space2

non_writable2 is after free_space2 in free_space2. You should be able to
write in free_space. *you can't*. Even stranger:

bind -ac fspace1 fspace2

Any file in fspace2 supersedes any file in fspace1 with the same name,
but if you create a file in fspace2 it is actually created *in fspace1*!!!???.
fspace1 is *after* fspace2 for already existing files,
but it is *before* when you create new ones.

I find this weird and counter intuitive. It also seems to contradict
the manual page.  Is there any reason for this?. Is there something
I am not getting?.
-- 
                 Saludos,
                         Gorka

"Curiosity sKilled the cat"
-- 
    /"\
    \ /    ascii ribbon campaign - against html mail 
     X                           - against ms attachments
    / \