[Bdi4emc-help] Re: BDI-4.38 suggestions
bdi-emc at ntlworld.com
Fri Dec 30 12:45:35 CET 2005
Hi Kent & Gene
On Thursday 29 December 2005 20:21, Kent A. Reed wrote:
> At least on paper, subversion looks great. If Source Forge is going to
> migrate to it from CVS, then it sounds like your hand will be forced
> soon enough.
If the EMC developers decide to switch to subversion, I fear they will be
shooting themselves in the collective foot. Quite a few users and developers
are running RH-7.x systems, and there are a considerable number of RH-6.x
installations to boot. Whilst there are subversion.rpm packages available for
RH-7.x, you have to go digging for them. For the many running RH-6.x boxes, I
suspect the situation will be much worse.
> In descending order of priority, my desiderata are (writing EMC/EMC2 as
> if they were one animal, which of course they aren't):
> 1) painlessly install a Linux with real-time extensions on which
> EMC/EMC2 will run
> 2) provide the resources to update/maintain this real-time Linux,
> preferably directly via the internet, but indirectly through a transfer
> of packages via CD or flash drive is acceptable if it can be managed easily
> 3) provide an environment in which I can build a running copy of
> EMC/EMC2 from source.
> 4) provide the source code for a stable version of EMC/EMC2.
> 5) provide a running copy of EMC/EMC2 "out of the box."
All the above are amply provided for by Debian's apt tools. apt-get manages
equally well with networked repositories, or from CDs. Installing a single
package from floppy (or flash drive) would probably require the use of dpkg
(the back end to apt-get). Even the sources can be downloaded with apt-get
along with any prerequisite build dependencies... [note to self: Fix build
deps and generate a source package for emc]
> Item 3 is next most important because it means I can build an running
> copy of EMC/EMC2 from source that might be provided with the BDI or that
> I download / update from Source Forge. Obviously this requirement is
> more important for EMC2 than for EMC since, quoting from the Wiki, the
> latter is "...the old stable version and no major improvement will be
> done here."
I've not done any significant work with the old EMC tree for the best part of
two years now. Most of my efforts have been in a branch of emc2 - The EMC
version found on the BDI-4 disk is the result. Although both head and bdi-4
branches share much code in common, most of the user space code is identical,
as are core parts of the RT modules, the bdi-4 branch does not use the HAL
layer. Think of the BDI-4 build as a staging platform for the time when
(if ?) emc2 becomes stable enough for widespread use. Although from what I
hear, emc3 may be just round the corner.
From the Klingon book of C:
Klingon function calls do not have 'parameters' - they have 'arguments' - and
they ALWAYS WIN THEM.
More information about the Bdi4emc-help