mount -a remounts tmpfs entries: bug or feature?

[Cathey, Jim]

>We would have asked for it [my opinion] back in 2005
>when this very issue was extensively discussed...

My, that's rather rude.  Did I kick your puppy or
something?  I was not _on_ this very list back in 2005,
I don't see why you think I would have been, nor how
you could think that I _should_ have been.

>>I greatly dislike using if(FOO) with
>>the expectation that the compiler will eliminate the code.

>Then you dislike building the Linux kernel, which relies
>heavily on this, and which is where I got it from in the first place.

Yes.  And I still find it tremendously parochial.  I stand by
my statement: I much prefer a clear expression of code that
I expect to be eliminated, versus code that I do not.

>Dead code elimination was a common optimization technique back in the
>1980's.  Even Turbo C for DOS did it.  It's about 30 years old.

Yes.  That's not the point I was making.

>This [VMS] would not include BusyBox.

Should I have used a different example?  I thought it was
pretty clear to invoke a clearly non-Unix platform that had
at least some fame in the industry.  Although, in this case,
perhaps merely citing some non-Linux-2.6, non-gcc-4.X platform
would have been sufficient.  ("We've got both kinds, Country
_and_ Western!")

>I'm sorry you don't understand how modern compilers work.

Perhaps I don't.  But if I'm trying to support both Linux and
OSE platforms (and I do this at work), it's rather difficult
to deal with the decision to include <efs.h> or <unistd.h>
without using #if.  Hiding it in another layer doesn't count,
not if it's still there.  Exporting the problem into sed-world
doesn't count, either.

I did turn down a job at Diab some time ago.  Their compiler's
author said that I was the only person not already working there
that understood how it worked.  (Perhaps they liked that I, a
mere customer, was able to re-target it to the TMS34010.  That
code is still in use today, in banks.)  But I didn't want to move
to CA.  (The Diab compiler kicked the snot out of the AT&T
compiler of the day, and gcc.  It's still well thought of, and
is a current offering of Wind River for the embedded market.)

But it's old.  Doesn't count.

>(The "no #ifdef in .c files" part.)

They can certainly be abused.  Part of our job is to keep
our hands out of the rotating knives.  But that doesn't mean
I think we should go back to using sheep to mow the lawn, either.

>>Is it really the intent, after all, that BB _only_ be usable
>>with gcc 4.x, presumably on Linux?  How parochial!
>Please show me an implementation of perl other than Larry Wall's.

Huh?

>So far you haven't mentioned a single target that GCC _doesn't_
>produce output for.

The list of targets that gcc no longer will produce output for
is longer than the list for which it will.  One doesn't have to
look far.

>But right now, the Linux kernel makes extensive use of gcc extensions,
>and only builds with gcc.

Does that make it right, or admirable?  Has gcc reached the point
yet where it can only be built with itself?  Not really something
to be proud of!

>You're sounding _remarkably_ uniformed.

Perhaps I am, considering that I am a hardware engineer trapped
in a software world. (For the second time).  But, Sir, consider
this my apology for having offended your tender sensibilities merely
by expressing an opinion.  An opinion clearly marked as such.

(I have others, regarding some current 'standard' practices that
I don't think are as hot as they are made out to be.  I'll be happy
to save those for another time and/or place.)

I use gotos, and #ifdefs, where appropriate, and I'm proud of it;
White Papers be damned.

-- Jim