In <[EMAIL PROTECTED]>, Jordan K. Hubbard wrote:
> > Anyway I'm wondering if experiences like the above are grounds for
> > filing a problem report. Since I'm tracking the `stable' branch, I
> > don't expect updating the OS will cause my development system to stop
> > working. Is this a reasonable expectation?
>
> It is a reasonable expectation and you might also, just to get
> yourself back on the functionality track, talk to Martin Cracauer
> <[EMAIL PROTECTED]> about the problems you've been having since
> he's both a FreeBSD user and a CMU CL hacker.
I don't think this is FreeBSD's fault.
CMUCL current approach to memory management works by examining the
memory contents the OS uses for a process by a human and having it
compile-time hardcoded in the executable. When updating the OS below
it, it will break when memory schemes in the OS change. The locations
and ranges CMUCL depends on can by no means be documented as a stable
interface by the OS.
There is hope for CMUCL, though. The old scheme it currently uses is
inheritend from the old days of Mach on DECstations and IBM PC/RT
where you had to do many things yourself that are nowsupported by more
elegant documented interfaces like dlopen.
As I understand, the SBCL CMUCL derivate fixes all these issues and I
think there is a good change that it gets merged back into CMUCL. If
people decide to discontinue support for some old of the old
platforms, but I think a memory allocation scheme that cooperates with
the OS on FreeBSD, Linux and Solaris has more people behind it than
PC/RT owners exist in the world.
It's nice to see how similar the problems are in the FreeBSD and CMUCL
world :-)
More remarks:
- When you update your FreeBSD, try booting a new kernel to test CMUCL
before you `make world`.
- The scheme to place memory segments in the FreeBSD kernel is quite
simple. If you start from the mmap(2) system call implementation and
follow the path of the addr==NULL (pick one) case, you will see how
it iterates over the existing mappings. Once you got it, you can
judge over further changes better.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <[EMAIL PROTECTED]> http://www.cons.org/cracauer/
Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
