Re: Reasons for a buffer or RAM

"Charles A. Crayne" wrote:
>
> On Wed, 01 Jun 2005 17:48:33 -0400
> Frank Kotler <fbkotler@xxxxxxxxxxx> wrote:
>
> :I want my buffer(s) on the stack, so it
> :can be recursive.
>
> You don't need to have your buffers on the stack to make it recursive. The
> better way is to allocate buffers dynamically and chain them together, as
> required.

Okay... I figured allocating buffers dynamically... keeping
a pointer on the stack... and freeing the buffer when I exit
the function (on each level) would be a way to do it. How
(and why) would I chain them together?

Seemed "simpler" to put 'em on the stack. Einstein said
(supposedly) that "things should be as simple as possible,
but no simpler." I may be trying to get "too simple" here...

> Of course, you may have to upgrade your antiquated kernel, if you can't get
> old mmap working.

Well, I think I can get old mmap working for "MAP_PRIVATE"
(which is what I'd want here, I think???). I was getting the
SIGBUS from trying to MAP_SHARED to communicate with a
process running in a different address space. It seems
(logically, and going by Randy's HLA example) that this
needs a file to "anchor" a shared memory area - without that
(or something) to "tie them together", how would the two
processes know it was the same area? Okay... but if this
file is zero-length, I get the SIGBUS by trying to write to
the area returned by mmap.

Randy's code apparently contains "O_TRUNC" (although it's
not "showing"... implied by "mmfile.openNew" I think) so I
always have a zero-length file, and it always fails. In my
Nasm code, I write one byte to the file before trying to
mmap it, and it works fine. I understand that mmap would
"round up" if I asked for one byte anyway, but I ask for
4096, and I can write to anywhere in that area - apparently
without actually writing anything to the disk file. SIGSEGV
if I try to write beyond it - SIGBUS seems limited to the
zero-length file in this case.

If this isn't limited to my kernel (2.2.19) - and maybe even
if it is - this might indicate a bug in Randy's hlalib code.
The "Linux end" of it hasn't been "exercised" as much as the
"Windows end", and it wouldn't be too astonishing to find a
bug lurking there.

I need to upgrade *anyway*, but I'd like to hear the results
of someone with a shiny new kernel trying Randy's code. The
Windows-specific "sleep" will have to be replaced (or just
commented out) for it to assemble. If it'll run without the
SIGBUS - even get as far as the "cls" - then it's a bug or
"version problem" here. If not, someone needs to look into
why not.

But thanks to T.M. Sommers' suggestion, *my* code works...
But that's a separate issue than why Jonathan suggested not
to make a .bss buffer over 16k...

Best,
Frank
.

Relevant Pages

  • Re: Reentrant problem with inet_ntoa in the kernel
    ... I use google mail web interface to post messages, ... that stack space is a limited resource in the ... which means adding those buffers can hit quite hard. ... but is the kernel stack too small to contain another 32 bytes at most? ...
    (freebsd-net)
  • Re: delay on select()
    ... When the stack sees the first send, ... > The solution is for programs that send data over TCP to properly manage ... allows immidiate sending of data in the TCP buffers, ... is TCP_CORK that allows to assemble package in system buffers and then ...
    (comp.unix.programmer)
  • Re: stack allocation and gcc
    ... one of 32 bytes in each of the sub branches. ... 64 bytes since as you say, the two buffers named buf2can be ... The mov sets up the new stack ... gcc does not allocate 32 bytes too ...
    (Linux-Kernel)
  • Re: Writing a SECURE daemon
    ... boundaries of buffers on the stack. ... int foo() { ... Then you overwrite the return address of foowith cmd. ...
    (comp.os.linux.security)
  • Re: Question about memory mapping mechanism
    ... I'm a lousy person to be advising on driver writing, ... use the infiniband approach to mmap() the user-space pages and send them ... the buffers as it already does. ... If you allocate a compound page, you need to have marked it as ...
    (Linux-Kernel)
Loading