Remote File Access With Emacs

QNX Newsgroups (Archives) qdn.public.qnxrtp.applications
1

I’ve been somewhat successfully running Emacs in a QNX6 Photon
terminal window for a while now. It works well enough with the
exception of two problems. The color syntax highlighting colors are
all messed up (not the way I configured them in my .emacs file) and
apparently can’t be changed. Strange colors are annoying but they’re
not a show stopper. The problem that really kills me is that there
are certain key combinations like CTRL-SPACE (normally runs
“set-mark-command”), ALT-SPACE (normally runs “just_one_space” and
ALT-BACKSPACE (normally runs “backward-kill-word”) that don’t work
under QNX/Photon.

I think this is a Photon limitation rather than a problem with the QNX
Emacs port, but it makes any serious editing painful. Remapping those
(and other) affected Emacs commands to different key combinations is
an option, but I use Emacs on several Linux and Windows systems and
they all work fine as is. My fingers are trained to use the default
Emacs key-combos and I’d like to stick to them.

I presume that there will be no change in QNX anytime soon that will
suddenly make these key combinations valid but I thought I could do my
QNX development from my Linux machine by taking advantage of Emacs’
ability to access files remotely via FTP.

For the most part, editing a remote file is just like editing a local
file except you occasionally need to enter the password for your
remote account and saves take a bit longer since the edited file is
actually being transmitted back to the remote system rather than saved
locally on disk. Unfortunately, there seems to be something about the
QNX FTP server that Emacs doesn’t like and I think it is related to
the LIST command that Emacs generates when it first establishes a
connection with the FTP server. I’ve found very little information on
the web about this problem but I gather it’s not uncommon, affects
Berkeley derived FTP servers, and is caused by non-standard options
being sent by Emacs. I don’t know how to solve it. I don’t have (and
haven’t yet found) the Lisp source code to the ange-ftp package (the
package Emacs uses to do its FTP magic) and the package itself no
longer seems to be supported… even though it’s still part of a
standard Emacs install.

Even though the root of the problem seems to be on the Emacs side
(assuming what I’ve read is accurate), I’d like to find a solution
that involves a change on the QNX side so that all the Emacs’s on all
my systems around here could suddenly get to my QNX files without all
having to be modified first. One option that comes to mind is to
replace the standard QNX FTP server with an alternate that does
understand whatever screwy LIST command Emacs is generating (I gather
that although non-standard, the behavior Emacs is looking for is
common). Does anyone have any suggestions for alternate FTP servers?

Anyway, if anyone else has had any success getting Emacs to access
remote files on a QNX system via FTP, I’d sure love to hear how you
did it!


Kind Regards,


Charlie Hubbard

2

In article <l1j3ivgidt8agnsmsakbk79277o6okiid2@4ax.com>, charles.hubbard@pnl.gov says…
[…]

common). Does anyone have any suggestions for alternate FTP servers?

Hello Charlie:

I heard success story about running this one on QNX
http://www.pureftpd.org/
Don’t know though if it help you with Emacs.

Best regards,
Eduard.

3

Charlie Hubbard

I’m probably telling you what you already know here, but here goes
anyway.

You can redirect the output of emacs under QNX to a remote X server
(your Linux box) using “emacs -display server:0”, where server is the
host name or IP address of your Linux box. I used that approach with no
problem displaying on XWin32, a Windows based Xserver. You need to use
‘xhost +’ (or a more restrictive form) on the Linux end first to give
emacs permission to display.

An alternative would be to NFS mount your files from the QNX box under
Linux and use your local Linux emacs to edit them. But this way you have
to use remote shell commands (rsh etc) to run the compiler on QNX from
emacs.

Regards

–
William Morris
william@bangel.demon.co.uk

4

On Fri, 25 Jul 2003 22:46:12 -0300, ed1k <ed1k@humber.bay> wrote:

In article <> l1j3ivgidt8agnsmsakbk79277o6okiid2@4ax.com> >, > charles.hubbard@pnl.gov > says…
[…]
common). Does anyone have any suggestions for alternate FTP servers?

Hello Charlie:

I heard success story about running this one on QNX
http://www.pureftpd.org/
Don’t know though if it help you with Emacs.

Best regards,
Eduard.

Hi Eduard:

Thanks for the link! This looks like a great FTP server but I wasn’t
able to get it to compile “out of the box” on QNX 6.2. Mind you I
only tried

./configure
make install-strip

as listed in the README file. But during the make I get the error

ftpd.c: In function set_signals_client
ftpd.c: 4043 ‘SA_RESTART’ undeclared (first use in this function)

which is fatal. It could be this is an easy fix, I don’t know. I
don’t have time to dig into it right now though. I don’t suppose
anyone has a QNX 6.2 binary for this do they?


Regards,


Charlie

5

On 28 Jul 2003 09:00:22 GMT, William Morris <wrm@bangel.demon.co.uk>
wrote:

Charlie Hubbard

I’m probably telling you what you already know here, but here goes
anyway.

You can redirect the output of emacs under QNX to a remote X server
(your Linux box) using “emacs -display server:0”, where server is the
host name or IP address of your Linux box. I used that approach with no
problem displaying on XWin32, a Windows based Xserver. You need to use
‘xhost +’ (or a more restrictive form) on the Linux end first to give
emacs permission to display.

No, I didn’t know that! I might give that a try and see if I can get
it to work.

An alternative would be to NFS mount your files from the QNX box under
Linux and use your local Linux emacs to edit them. But this way you have
to use remote shell commands (rsh etc) to run the compiler on QNX from
emacs.

There is an alternative remote-file-access package available for Emacs
called “tramp” which isn’t limited to just FTP. It can use telnet,
rsh, ssh, rcp, scp, ftp and others. I’ve been playing with that but
so far have nothing working. If it goes through a terminal
application like telnet or ssh it needs versions of uuencode or
mimencode on the remote (QNX) system. Unfortunately, the QNX version
of uuencode can’t accept input from stdin and, for some reason, I
can’t get the “tramp” package to recognize mimencode even though I’ve
(finally) got it installed on the QNX platform. When using an
alternative file transfer system like rcp or scp it has the
restriction that it must be possible to transfer files without first
sending a password. I don’t have rcp set up on our QNX box and I
don’t want to set it up. I do have OpenSSH 3 running but, right now
at least, when using scp to transfer files it requires a password. I
may be able to get around this by setting up SSH user keys but I don’t
know much about that.

I’m afraid I’ll have to do real work today so I can’t play around with
this stuff. Hopefully sometime in the next few days I’ll be able to
get remote access from Emacs working either through exporting the
display, finding an alternative FTP server that Emacs likes or getting
something from the “tramp” package working.


Regards,


Charlie Hubbard

6

charles.hubbard@pnl.gov wrote:

I’ve been somewhat successfully running Emacs in a QNX6 Photon
terminal window for a while now. It works well enough with the
exception of two problems. The color syntax highlighting colors are
all messed up (not the way I configured them in my .emacs file) and
apparently can’t be changed. Strange colors are annoying but they’re
not a show stopper. The problem that really kills me is that there
are certain key combinations like CTRL-SPACE (normally runs
“set-mark-command”), ALT-SPACE (normally runs “just_one_space” and
ALT-BACKSPACE (normally runs “backward-kill-word”) that don’t work
under QNX/Photon.

Is there any reason why you are not running this under XPhoton rather
than in a terminal window? I use it all the time without problems.

I just tried the Ctrl-Space which works, Alt-Space which unfortuntely is
intercepted by the pwm and opens a menu on the photon window, and
Alt-Backspace which works. Colors also seem to work right - although I
just took the defaults with syntax highlighting.

Rick…

–
Rick Duff Internet: rick@astranetwork.com
Astra Network URL: http://www.astranetwork.com
QNX Consulting and Custom Programming Phone: +1 (204) 997-NETW (6389)

7

On Fri, 25 Jul 2003 18:42:13 -0700, <charles.hubbard@pnl.gov> wrote:

I’ve been somewhat successfully running Emacs in a QNX6 Photon
terminal window for a while now. It works well enough with the
exception of two problems. The color syntax highlighting colors are
all messed up (not the way I configured them in my .emacs file) and
apparently can’t be changed. Strange colors are annoying but they’re
not a show stopper. The problem that really kills me is that there
are certain key combinations like CTRL-SPACE (normally runs
“set-mark-command”), ALT-SPACE (normally runs “just_one_space” and
ALT-BACKSPACE (normally runs “backward-kill-word”) that don’t work
under QNX/Photon.

Just for information purposes, the “answers” to your two problems are:

  1. syntax highlighting colors - this version of emacs does not
    implement syntax highlighting on the terminal the same way that
    it treats color in X. The net result is that it does not work
    well (or at all) in QNX. The next version of emacs treats the
    two conditions similarly, and the color highlighting in the
    terminal would probably work. I have no intention of attempting
    to port the next emacs version until (unless?) QNX fixes either
    a) adds a patch to malloc (sumbitted almost 2 years ago) that allows emacs
    to dump its image, or b) updates its woefully out of
    date C library source in the public CVS tree.

  2. Ctrl-space does not generate a keystroke event in a QNX terminal.
    This has nothing to do with emacs or Photon. That key combination
    is simply ignored by the QNX terminal driver. This was the case
    even in QNX4 days. I was given the impression that this could be
    fixed by fiddling with the a terminal definition or keystroke map
    or something, but I have never dug deep enough to determine how.

I could use all of your help with respect to emacs on QNX6. Every
time QNX updates the OS, there is a substantial chance that emacs
will stop working. This has something to do with changes in memory
mapping that make emacs fault when it loads. Emacs is a special
case since it dumps its running image to disk during the build.
In any case, with QNX 6.2 or 6.2.1 (can’t remember), it became
impossible to compile emacs. The package in the Cogent repository
was the built on whatever QNX version last had up-to-date C library
source available, and required a C library modification. The next
time QNX changes and emacs breaks, there will be no recourse, and
we can kiss goodbye to emacs on QNX6 altogether. I have had no
luck getting QNX to make the (harmless) C library patch, and doubt
I ever will. You could all help out, though, by trying to
convince QNX to update their CVS tree when they update the OS.
A few more voices might make QNX notice.

Cheers,
Andrew

8

Andrew Thomas wrote:

A few more voices might make QNX notice.

For what’s worth, add my voice. :wink: I would hate to be forced to use
vim or that stupid editor in the ide to do anything. I would be forced
to use Charles approach and run the editor on a linux machine.

Hey QSS, what’s the issue from your point of view with making these changes?

Rick

–
Rick Duff Internet: rick@astranetwork.com
Astra Network URL: http://www.astranetwork.com
QNX Consulting and Custom Programming Phone: +1 (204) 997-NETW (6389)

9

On Mon, 28 Jul 2003 21:06:40 -0500, Rick Duff <rick@astranetwork.com>
wrote:

Is there any reason why you are not running this under XPhoton rather
than in a terminal window? I use it all the time without problems.

I just tried the Ctrl-Space which works, Alt-Space which unfortuntely is
intercepted by the pwm and opens a menu on the photon window, and
Alt-Backspace which works. Colors also seem to work right - although I
just took the defaults with syntax highlighting.

That certainly sounds more usable. When I first installed Emacs under
QNX I was running under XPhoton but it was so GOD AWFUL slow it was
almost unusable. I now start Emacs from a terminal window with the
-nw option.

I don’t know why it runs so slowly the other way. Maybe I’m doing
something wrong. Our development system is a 1GHz machine with 512MB
of RAM and it seems like that should be good enough (under QNX4 we
used to run QNX with Photon reasonably successfully on embedded
486/66’s). I think it may have more to do with the fact that I access
the system almost exclusively using Phindows 2.00. I’m not sure
what’s happened with Phindows. On QNX4 with Phindows 1.0, Phindows
was fast and solid. On QNX6 Phindows seems to be slow and glitchy
. Until updating my phrelay with a test version from QNX, it
used to lock up a lot too. It doesn’t lock up anymore but it still
does a number of annoying things (like refusing to redraw terminal
windows when a Windows app in front of Phindows goes away). But
that’s a gripe for a different thread.

Thanks for the data point!


Charlie Hubbard

10

That certainly sounds more usable. When I first installed Emacs under
QNX I was running under XPhoton but it was so GOD AWFUL slow it was
almost unusable. I now start Emacs from a terminal window with the
-nw option.

Well, if you are using Phindows that means you are going to be adding alot
of latency:

app → tcpip → XPhoton → Photon → phrelay → tcpip → phindows

and back again. Additionally, XPhoton is cheating on it’s side and using
bitmaps so those images are what would be streamed over the phrelay instead
of a draw stream.

chris

–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

11

Rick Duff <rick@astranetwork.com> wrote:

Andrew Thomas wrote:
For what’s worth, add my voice. > :wink: > I would hate to be forced to use
vim or that stupid editor in the ide to do anything. I would be forced
to use Charles approach and run the editor on a linux machine.

I’ll second that. The ability to run standard tools on QNX is a big

plus towards its usability. Running emacs native on QNX made life
bearable for me recently when Windows was the only desktop option.
It is of course possible to run emacs on Windows and use Samba to
access files on QNX but that has its own limitations.

Regards

William Morris
william@bangel.demon.co.uk

12

On Fri, 25 Jul 2003 18:42:13 -0700, charles.hubbard@pnl.gov wrote:
[snip]

For the most part, editing a remote file is just like editing a local
file except you occasionally need to enter the password for your
remote account and saves take a bit longer since the edited file is
actually being transmitted back to the remote system rather than saved
locally on disk. Unfortunately, there seems to be something about the
QNX FTP server that Emacs doesn’t like and I think it is related to
the LIST command that Emacs generates when it first establishes a
connection with the FTP server. I’ve found very little information on
the web about this problem but I gather it’s not uncommon, affects
Berkeley derived FTP servers, and is caused by non-standard options
being sent by Emacs. I don’t know how to solve it. I don’t have (and
haven’t yet found) the Lisp source code to the ange-ftp package (the
package Emacs uses to do its FTP magic) and the package itself no
longer seems to be supported… even though it’s still part of a
standard Emacs install.

Just to follow up…

I’ve finally got a fix for this that works with the QNX FTP server.
There is an Emacs variable called “ange-ftp-dumb-unix-host-regexp”
that can be set to let the Emacs ange-ftp package know which hosts
don’t support the non-standard LIST options and work around the
problem. In my .emacs file I added the following…


(setq ange-ftp-dumb-unix-host-regexp “myqnxbox”)

Then when I use the standard Emacs syntax to open a file on that host,
everything works fine. For example to the “find-file” command
(normally bound to C-x C-f) I enter…

/chubbard@myqnxbox:somefile.c

and I’m prompted for a password and the file is transparently FTPed
over and presented for editing.

I would prefer to use scp for the transfers ala the tramp.el module
but hours of messing around have yet to yield a working tramp setup.
Even when using scp as its means for file transfer, tramp still
insists on doing quite a bit of stuff over the terminal connection
(ssh in this case) . This fails (I gather) because various tools tramp
wants to use one the QNX side either aren’t there or don’t have the
capability tramp needs. In a last ditch attempt at getting things to
work tramp tries to copy over small perl scripts that can do what it
needs done but, for some reason, it always hangs on the transfer.

Anyway FTP seems to work fine once the above variable gets set to
identify the problem host. SCP would be better but I’m tired of
screwing with it.


Charlie Hubbard

13

Andrew Thomas <andrew@cogent.ca> wrote in message
news:oprs2q2tj0w9rgrq@nntp.qnx.com…

I have no intention of attempting
to port the next emacs version until (unless?) QNX fixes either
a) adds a patch to malloc (sumbitted almost 2 years ago) that allows emacs
to dump its image,
b) updates its woefully out of
date C library source in the public CVS tree.

Seeing as the patch is before my time, what is the issue with the malloc
that prevents emacs from dumping its image? As to the CVS tree, that I
cannot comment on, but I’ve alread mentioned it to management (where that
goes, I donno).

-Adam

I could use all of your help with respect to emacs on QNX6. Every
time QNX updates the OS, there is a substantial chance that emacs
will stop working. This has something to do with changes in memory
mapping that make emacs fault when it loads. Emacs is a special
case since it dumps its running image to disk during the build.
In any case, with QNX 6.2 or 6.2.1 (can’t remember), it became
impossible to compile emacs. The package in the Cogent repository
was the built on whatever QNX version last had up-to-date C library
source available, and required a C library modification. The next
time QNX changes and emacs breaks, there will be no recourse, and
we can kiss goodbye to emacs on QNX6 altogether. I have had no
luck getting QNX to make the (harmless) C library patch, and doubt
I ever will. You could all help out, though, by trying to
convince QNX to update their CVS tree when they update the OS.
A few more voices might make QNX notice.

I think the newsgroups for technical discussion aren’t really the forum to
get ‘heard’ on policy (partly since those people that make some of the
choices aren’t reading them on a regular basis).

On the other hand, ‘harmless’ is my favourite word describing changes made
in behaviour, especially that to which many things rely - famous last words.
I’ll impose on you a little and ask what the behaviour change is that Emacs
requires (since I find it hard to believe there is a reliance on how malloc
actually carves up memory in the heap, since this would break on different
allocators with a malloc interface (of which there are many) and not really
a QNX specific issue (note I’m not saying ‘no’, just looking for more info).

Cheers,
-Adam

14

On Wed, 30 Jul 2003 23:25:26 -0400, Adam Mallory <amallory@qnx.com> wrote:

I think the newsgroups for technical discussion aren’t really the forum
to get ‘heard’ on policy (partly since those people that make some of the
choices aren’t reading them on a regular basis).

Thanks for responding, Adam. In reality this is not a matter of policy.
QNX has already established the policy of presenting certain parts of
the source tree to public CVS. The problem is one of implementation of
that policy.

On the other hand, ‘harmless’ is my favourite word describing changes
made
in behaviour, especially that to which many things rely - famous last
words.
I’ll impose on you a little and ask what the behaviour change is that
Emacs
requires (since I find it hard to believe there is a reliance on how
malloc
actually carves up memory in the heap, since this would break on
different
allocators with a malloc interface (of which there are many) and not
really
a QNX specific issue (note I’m not saying ‘no’, just looking for more
info).

I would be happy to elaborate. In one version of another of QNX6, the
memory
allocator got smart and realized that it could give back memory to the OS
when memory is freed if an entire page/block/whatever was completely freed
in the application. This is a Good Thing in general, but it has the
capability to produce a memory map in the application that is non-
contiguous.
I.e., there can be “holes” in the process’s address space. While that is
not normally a problem, Emacs is a special case. It dumps its memory to
disk
by finding the start and end of text and the start and end of heap, and
dumping these as TEXT and DATA into a new ELF excutable. The holes in the
memory map cause a segmentation fault during the dump. I know of no way to
dump only the mapped portion of the memory into the new ELF executable.

There is an added problem - Emacs uses sbrk() to determine the end of
memory,
and the QNX allocator does not actually keep the sbrk() information up to
date. I have a hack for sbrk() that has worked in the past, but it looks
like it could fail with any new update of the OS. So, as an aside, I would
like to see an sbrk() implementation that works.

Anyway, the solution to the memory hole problem is simple. There is a
single test in the free() implementation that looks to see if a block is
completely empty. If it is, it is unlinked from the list of used blocks,
and is returned to the OS. All you need to do is add an option to
mallopt() that tells free() not to perform this test. Any program that
does not supply this option continues to get the efficient memory
behaviour, but programs like Emacs, Common LISP, C++ garbage collectors,
and a handful of others that would fail due to this can be made to work
with a simple OS-dependent call to mallopt.

I really think this is harmless, and I also suspect that it is a
necessary precondition for a functioning sbrk() implementation.

Hope that clarifies.
Andrew

15

Andrew Thomas <andrew@cogent.ca> wrote in message
news:oprs6jdtplw9rgrq@nntp.qnx.com…

Thanks for responding, Adam. In reality this is not a matter of policy.
QNX has already established the policy of presenting certain parts of
the source tree to public CVS. The problem is one of implementation of
that policy.

True, but policies change (not saying they will/are, just saying…), and
the ‘powers that be’ are still the decision makers in this case, not the
technical people. Anyways, I digress…


I would be happy to elaborate. In one version of another of QNX6, the
memory
allocator got smart and realized that it could give back memory to the OS
when memory is freed if an entire page/block/whatever was completely freed
in the application. This is a Good Thing in general, but it has the
capability to produce a memory map in the application that is non-
contiguous.
I.e., there can be “holes” in the process’s address space. While that is
not normally a problem, Emacs is a special case. It dumps its memory to
disk
by finding the start and end of text and the start and end of heap, and
dumping these as TEXT and DATA into a new ELF excutable. The holes in the
memory map cause a segmentation fault during the dump. I know of no way
to
dump only the mapped portion of the memory into the new ELF executable.

Well as a start, you can setup a SIGSEGV handler and setjmp/longjmp (ie.
try/catch) on pages in the heap to figure out what is where. Each new area
you discover can be a new data section in the ELF excutable which on load,
would be collected into the data loadable segment at execution time (IIRC).

There is an added problem - Emacs uses sbrk() to determine the end of
memory,
and the QNX allocator does not actually keep the sbrk() information up to
date. I have a hack for sbrk() that has worked in the past, but it looks
like it could fail with any new update of the OS. So, as an aside, I
would
like to see an sbrk() implementation that works.

Well the UNIX standard says that the use of brk()/sbrk() is unspecified when
an application uses any other memory functions such as (not limited to)
malloc/free/mmap. I’m not trying to cop out, but the use of brk/sbrk is
very fragile in the Emacs case IMHO.

Anyway, the solution to the memory hole problem is simple. There is a
single test in the free() implementation that looks to see if a block is
completely empty. If it is, it is unlinked from the list of used blocks,
and is returned to the OS. All you need to do is add an option to
mallopt() that tells free() not to perform this test. Any program that
does not supply this option continues to get the efficient memory
behaviour, but programs like Emacs, Common LISP, C++ garbage collectors,
and a handful of others that would fail due to this can be made to work
with a simple OS-dependent call to mallopt.

Well the reliance on sbrk/brk is a historical thing, and it’s meaning is not
very clear in a virtual memory system (since it was put in long before
virtual memory). I can see a world of hurt coming on for Emacs and anything
that relies on brk/sbrk.

I really think this is harmless, and I also suspect that it is a
necessary precondition for a functioning sbrk() implementation.

The change is already in, as an option to mallopt() (MALLOC_MEMORY_HOLD is
the flag if memory serves) as part of a larger scheme to control the return
of memory to the system at different rates (rather than just always or
never).

Hope that helps you out some.

-Adam

16

Maybe QSSL could appoligize to Ted Green and we can get a copy of vedit for
QNX6.

“Rick Duff” <rick@astranetwork.com> wrote in message
news:bg5uvr$201$1@inn.qnx.com…

Andrew Thomas wrote:
A few more voices might make QNX notice.


For what’s worth, add my voice. > :wink: > I would hate to be forced to use
vim or that stupid editor in the ide to do anything. I would be forced
to use Charles approach and run the editor on a linux machine.

Hey QSS, what’s the issue from your point of view with making these
changes?

Rick

–
Rick Duff Internet: > rick@astranetwork.com
Astra Network URL: > http://www.astranetwork.com
QNX Consulting and Custom Programming Phone: +1 (204) 997-NETW (6389)

17

On Fri, 1 Aug 2003 09:14:10 -0500, “Bill Caroselli”
<QTPS@Earthlink.net> wrote:

Maybe QSSL could appoligize to Ted Green and we can get a copy of vedit for
QNX6.

I couldn’t stand vedit myself but there were a couple of developers
around here that used it. Everyone has a favorite I guess. I was a
big fan of JED on QNX4 and it seems to run equally well on QNX6 (it’s
color syntax highlighting works properly and it’s even fast under
Phindows). I particularly like JED’s macro language, SLang. It’s
simple and powerful. Emacs’ Lisp causes my brain to meltdown turning
me into a quivering blob of Jell-o. I actually think JED is a better
editor than Emacs.

That being said, I’m used to Emacs and use Emacs on every other
platform I work on. The JED Emacs emulation is not bad but it’s not
Emacs. I’ve had trouble getting JED on different platforms to behave
the same way with my QNX JED configuration file.


C.

18

On Thu, 31 Jul 2003 13:45:21 -0400, Adam Mallory <amallory@qnx.com> wrote:

Andrew Thomas <> andrew@cogent.ca> > wrote in message
news:> oprs6jdtplw9rgrq@nntp.qnx.com> …
Thanks for responding, Adam. In reality this is not a matter of policy.
QNX has already established the policy of presenting certain parts of
the source tree to public CVS. The problem is one of implementation of
that policy.

True, but policies change (not saying they will/are, just saying…), and
the ‘powers that be’ are still the decision makers in this case, not the
technical people. Anyways, I digress…

Public policies are supposed to change publically. Has QNX decided not
to maintain the public CVS archive?

Well as a start, you can setup a SIGSEGV handler and setjmp/longjmp (ie.
try/catch) on pages in the heap to figure out what is where. Each new
area you discover can be a new data section in the ELF excutable which on
load, would be collected into the data loadable segment at execution time
(IIRC).

Ouch. That sounds like a last resort.

Well the UNIX standard says that the use of brk()/sbrk() is unspecified
when an application uses any other memory functions such as (not limited
to)
malloc/free/mmap. I’m not trying to cop out, but the use of brk/sbrk is
very fragile in the Emacs case IMHO.
[…]

Well the reliance on sbrk/brk is a historical thing, and it’s meaning is
not very clear in a virtual memory system (since it was put in long
before
virtual memory). I can see a world of hurt coming on for Emacs and
anything that relies on brk/sbrk.

Emacs actually only uses sbrk(0) to determine the end of virtual memory
for the process. If you can tell me another method, I’ll remove sbrk
in a heartbeat.

I really think this is harmless, and I also suspect that it is a
necessary precondition for a functioning sbrk() implementation.

The change is already in, as an option to mallopt() (MALLOC_MEMORY_HOLD
is the flag if memory serves) as part of a larger scheme to control the
return of memory to the system at different rates (rather than just
always or never).

Excellent. Which version of the OS has this? I’m running
QNX 6.2.1 2003/01/08-02:15:12EST
I don’t know what patch level that would be. This is not documented
and the constant does not exist in this version.

Thanks,
Andrew

19

Andrew Thomas <andrew@cogent.ca> wrote in message
news:oprtf11r0kw9rgrq@nntp.qnx.com…

Public policies are supposed to change publically. Has QNX decided not
to maintain the public CVS archive?

Like I said, I have no clue to policy direction, and I’m not suggesting that
the policy will/won’t change. Anyways this is OT and I have nothing of
value to add except ‘I don’t know’.

Ouch. That sounds like a last resort.

Much like using a relic like sbrk(), and since this is ‘setup’ time the
extra work really isn’t that much in the grand scheme of Emacs land.

Emacs actually only uses sbrk(0) to determine the end of virtual memory
for the process. If you can tell me another method, I’ll remove sbrk
in a heartbeat.

If Emacs uses any memory function together with sbrk() the results are not
defined regardless of what the rational for using sbrk() is. In addition,
the assumption that the heap is virtually contiguous is, IMHO, frail to say
the least - lots of allocator schemes out there break that assumption (not
just ours).

The best method I think would be for Emacs to provide its own hunk
allocator, which can setup the heap anyway it sees fit. This would solve
the issue of heap information (start/stop/contig?) and layout. Also it
would give you a much more robust way of doing what you’re trying to
acomplish.

Excellent. Which version of the OS has this? I’m running
QNX 6.2.1 2003/01/08-02:15:12EST
I don’t know what patch level that would be. This is not documented
and the constant does not exist in this version.

It’s not out, it will be in a future release - hence the fact you don’t have
it, nor is it doc’d.

Cheers,
-Adam

20

On Tue, 5 Aug 2003 15:35:24 -0400, Adam Mallory <amallory@qnx.com> wrote:

Andrew Thomas <> andrew@cogent.ca> > wrote in message
news:> oprtf11r0kw9rgrq@nntp.qnx.com> …

If Emacs uses any memory function together with sbrk() the results are
not defined regardless of what the rational for using sbrk() is. In
addition, the assumption that the heap is virtually contiguous is, IMHO,
frail to say the least - lots of allocator schemes out there break that
assumption (not just ours).

Interestingly, the very many operating systems supported by emacs either
provide a system allocator that does maintain contiguous virtual memory
or provide a functioning sbrk() that allows gmalloc to work. While I agree
with you in principle, I don’t see much evidence for it in practise.

Emacs can be configured to use gmalloc, which uses sbrk() exclusively.
The problem is that sbrk() does not work as documented, even when it is
the only memory allocator in use. Part of this is likely due to other
library functions using other memory allocation techniques (shared memory
or segment allocation?), which makes it impossible not to “use any memory
function together with sbrk()”.

The best method I think would be for Emacs to provide its own hunk
allocator, which can setup the heap anyway it sees fit. This would solve
the issue of heap information (start/stop/contig?) and layout. Also it
would give you a much more robust way of doing what you’re trying to
acomplish.

This is the gmalloc route. It fails. I cannot remember how, frankly,
but as I said, it has to do with sbrk() not really obeying its own
documentation.

Generally speaking, I am willing to put in a few days of work to port
emacs to QNX6, but I am not willing to totally rewrite its memory
allocators or ELF dumping code. I was rather hoping that QNX would
try to support emacs, at least passively - it’s one of the most popular GNU
tools. It is unfortunately also a pretty severe test case for
“compatibility”, where compatibility is defined as
“conformance to a legacy assortment of random side-effects”. We don’t have
to like it, but it’s the world we live in.

Cheers,
Andrew