and not likely to become so. Comments on each configuration
are below.
+ Force CPU386 - This BSP was developed as part of the initial
port of RTEMS to the i386. This board has been unavailable
for a long time now.
+ GO32 - This BSP and some CPU code supported djgpp v1.x. This
version is now quite old. No one has stepped forward to
update the code to v2.x which may be technically impossible
anyway. More importantly, go32 has been superceded by the pc386 BSP.
and not likely to become so. Comments on each configuration
are below.
+ Force CPU386 - This BSP was developed as part of the initial
port of RTEMS to the i386. This board has been unavailable
for a long time now.
+ GO32 - This BSP and some CPU code supported djgpp v1.x. This
version is now quite old. No one has stepped forward to
update the code to v2.x which may be technically impossible
anyway. More importantly, go32 has been superceded by the pc386 BSP.
now prototypes the malloc family in stdlib.h. This causes conflicts
with the way the network stack overrides the definitions of malloc.
As best I (being Joel) can tell, commenting stdlib.h out keeps the
files compiling and referencing the desired malloc/free but results
in more warnings.
and not likely to become so. Comments on each configuration
are below.
+ Force CPU386 - This BSP was developed as part of the initial
port of RTEMS to the i386. This board has been unavailable
for a long time now.
+ GO32 - This BSP and some CPU code supported djgpp v1.x. This
version is now quite old. No one has stepped forward to
update the code to v2.x which may be technically impossible
anyway. More importantly, go32 has been superceded by the pc386 BSP.
and not likely to become so. Comments on each configuration
are below.
+ Force CPU386 - This BSP was developed as part of the initial
port of RTEMS to the i386. This board has been unavailable
for a long time now.
+ GO32 - This BSP and some CPU code supported djgpp v1.x. This
version is now quite old. No one has stepped forward to
update the code to v2.x which may be technically impossible
anyway. More importantly, go32 has been superceded by the pc386 BSP.
and not likely to become so. Comments on each configuration
are below.
+ Force CPU386 - This BSP was developed as part of the initial
port of RTEMS to the i386. This board has been unavailable
for a long time now.
+ GO32 - This BSP and some CPU code supported djgpp v1.x. This
version is now quite old. No one has stepped forward to
update the code to v2.x which may be technically impossible
anyway. More importantly, go32 has been superceded by the pc386 BSP.
I'm working on code to mount my host based file system on the base file
system (imfs) and have a suggestion for a change to eval.c in the
c/src/lib/libc directory of the 8/20/1999 snapshot. The current version
does not test the result value returned from the evalpath callback (line 47)
in the case where follow_link is true. Attached is my suggested change.
Without this test the node_type callback may be called after evalpath
failed. node_type could set the type to some value other then
RTEMS_FILESYSTEM_HARD_LINK or RTEMS_FILESYSTEM_SYM_LINK but it seems cleaner
to add the check on result.
and not likely to become so. Comments on each configuration
are below.
+ Force CPU386 - This BSP was developed as part of the initial
port of RTEMS to the i386. This board has been unavailable
for a long time now.
+ GO32 - This BSP and some CPU code supported djgpp v1.x. This
version is now quite old. No one has stepped forward to
update the code to v2.x which may be technically impossible
anyway. More importantly, go32 has been superceded by the pc386 BSP.
