> Richard B. Johnson writes ...
> >
> > On Mon, 30 Jun 1997, Michael Bruck wrote:
> >
> > > Ok, two short questions:
> > >
> > > Is there a arch-independant type available for the
> > > save_flags macro ? (flags_t ??)
> > >
No, anyway the save_flags macro is defined in a very different way for UP
(where it actually saves the contents of the 32 bit EFLAGS register) and
SMP, where it actually returns a value (boolean on x86, integer between 0
and 2 on SPARC) to tell restore_flags what to do wrt the global irq lock.
The name save_flags and restore_flags are actually misleading for SMP
machines.
BTW: for the SPARC, there is a macro called save_and_cli, which performs
the equivalent of save_flags followed by cli, this is very frequent in the
code and should be generalized to all architectures, some will benefit.
On PPC for example, cli() is a read modify write of the MSR (PSR on
SPARC), and reading this register twice is quite expensive (each "move
from MSR" costs the equivalent of up to 12 "normal" instructions on a 604).
> > > Is there a problem that could prevent one from using memory
> > > alloc'd from stack in the kernel like
> > >
> > > int foo(int bar)
> > > {
> > > int foo_bar[bar];
> > > ...
> > > }
> >
> > Even though that works.... There SHOULD be a problem with it! Don't
> > write code like that. For some reason gcc lets you get away with it.
> > If you must write code like that it's broken from the start. Automatic
> > variables are supposed to be automatic, not dynamic.
>
> First of all, the point that only gcc supports it isn't that important
> since Linux already uses a _ton_ of gcc-isms. Second, C9X will add
> support for the above to the official C language, so it isn't that evil.
It isn't evil, it's a potential kernel stack bomb. This should only be done
if you are _absolutely_ sure that it's only for a few tens of bytes.
And in this case you should allocate an array of the maximum size you
expect. There is hidden overhead with this type of declaration, i.e., that
the compiler has to keep somewhere (in the stack) a pointer to the base
address of each such variable. It also has to reload this pointer when the
variable is accessed and registers are in short supply (always on x86).
OTOH, it is perfectly acceptable in user code, and it helps to avoid
memory leaks.
Gabriel