GSOC 2015 Monkey HTTP Server

[Sujay Raj]

Hi,
I am interested in working on porting the Monkey HTTP Server to RTEMS
as a GSOC project.

This is the first time I am applying to GSOC and though I have written
a lot of code, it is also my first attempt at working in an Open
Source project.

Some personal projects that I have worked on include developing a
hobby operating system ( following Bran's Kernel Development Tutorial
and osdev ), writing ray tracers, as well as porting the nweb web
server ( 200 lines of C code ) to python ( it was undertaken as an
exercise to learn more about the functioning and implementation of
webservers ). Further I have familiarity with x86 assembly (nasm), not
extraordinary, but fluent.

I have successfully compiled and executed sample programs for
sparc-sis but from what I have read sparc-sis doesn't support TCP/IP.
So I followed the wiki and compiled it for pc386 on QEMU too as it had
networking support.

I was wondering if this may be the required architecture and simulator
for this project.

Further, I would like to mention, that though this may be an approach
with GSOC in mind, but I wish to end up as a full time contributor for
the RTEMS project in time to come as it suits my taste and past
experience.

Kindly point out things I need to do to proceed and other comments.

Regards
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSOC 2015 Monkey HTTP Server

[Sujay Raj]

Well I started writing the first draft of the project proposal ( which
I shall hopefully finish by tonight, Its 9 PM here ).

I am making "porting the Monkey web server to RTEMS as well as a
partial reorganization of the network stacks present in RTEMS to make
it more modular", as the primary deliverable of this project.

>From what it appears, porting Monkey can be done in about a month + a
week for any delays. The development environment is already set up and
I am tweaking around with the code. So, by the mid-term evaluation I
expect to get monkey working on RTEMS (without enough time for
debugging).

For the second part, that is, getting the network stack of choice
built from RSB for the applications to be built against, I am a bit
apprehensive about the time limit. This task, at the first glance
doesn't appear that difficult, but it might be. So the second half (
till the final evaluation ) will involve getting the network stacks in
a separate build + a separate package for network tests + debugging.

I think debugging and testing will be a major part of the project.

I was thinking along the lines, that the second part of the project
should be done first, but as Joel pointed out, the first step should
be monkey getting ported as a package.

kindly point out any comments/suggestions.



On Fri, Mar 20, 2015 at 6:27 AM, Chris Johns  wrote:
> On 20/03/2015 2:57 am, Eduardo Silva wrote:
>>
>> if there are some application for that project and some accepted
>> student, I would be glad to sign as a mentor to cover Monkey specifics.
>> Note: we will need a second mentor to cover RTEMS specifics,
>
>
> I can help, after all you and I have talked about the work to be done
> before.
>
> Chris
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSOC 2015 Monkey HTTP Server

[Sujay Raj]

BSP: pc386 simulated on QEMU

On Fri, Mar 20, 2015 at 9:27 PM, Gedare Bloom  wrote:
> On Fri, Mar 20, 2015 at 11:39 AM, Sujay Raj  wrote:
>> Well I started writing the first draft of the project proposal ( which
>> I shall hopefully finish by tonight, Its 9 PM here ).
>>
>> I am making "porting the Monkey web server to RTEMS as well as a
>> partial reorganization of the network stacks present in RTEMS to make
>> it more modular", as the primary deliverable of this project.
>>
>> From what it appears, porting Monkey can be done in about a month + a
>> week for any delays. The development environment is already set up and
>> I am tweaking around with the code. So, by the mid-term evaluation I
>> expect to get monkey working on RTEMS (without enough time for
>> debugging).
>>
> What RTEMS target/BSP do you intend to use?
>
>> For the second part, that is, getting the network stack of choice
>> built from RSB for the applications to be built against, I am a bit
>> apprehensive about the time limit. This task, at the first glance
>> doesn't appear that difficult, but it might be. So the second half (
>> till the final evaluation ) will involve getting the network stacks in
>> a separate build + a separate package for network tests + debugging.
>>
> I think there is a lot of complexity here.
>
>> I think debugging and testing will be a major part of the project.
>>
> Always.
>
>> I was thinking along the lines, that the second part of the project
>> should be done first, but as Joel pointed out, the first step should
>> be monkey getting ported as a package.
>>
> I agree with Joel. The second part is harder to scope. It will be much
> better for you to have a solid task and deliverable (port Monkey) for
> the first-half.
>
>> kindly point out any comments/suggestions.
>>
> Be sure you identify when and where you plan to submit code. We like
> to see code pushed into RTEMS, and into upstream projects if needed,
> throughout the summer, not just at the end.
>
>>
>>
>> On Fri, Mar 20, 2015 at 6:27 AM, Chris Johns  wrote:
>>> On 20/03/2015 2:57 am, Eduardo Silva wrote:
>>>>
>>>> if there are some application for that project and some accepted
>>>> student, I would be glad to sign as a mentor to cover Monkey specifics.
>>>> Note: we will need a second mentor to cover RTEMS specifics,
>>>
>>>
>>> I can help, after all you and I have talked about the work to be done
>>> before.
>>>
>>> Chris
>>>
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSOC 2015 Monkey HTTP Server

[Sujay Raj]

I submitted the tentative proposal on the proposal page
devel.rtems.org/wiki/GSoC/2015 .

I have a few points to mention.
1. About the BSP to work upon, I have not mentioned anything
specifically in the proposal because that is to be discussed. I do not
have enough working experience with ARM/zynq architecture. ( I worked
with ARM last trying to make homebrew games for the Nintendo GBA where
the emulator was Visual Boy Advance :) )  I have always worked with
x86 architectures. But yes, I can easily switch over to it, in little
time if I am pointed towards some resources about emulating it with
QEMU, and any other specifics about zynq.

2.   The sample proposal talked about setting up repository on
code.google.com, which is not accepting any new project and will close
within an year.

3. About the second part of my project, About separate RSB packaging
of network stacks,
 i. should I include lwIP too?
 ii. Is anyone else working on it? Should that affect my including
lwIP in my proposal?
iii. Does the project look too ambitious to be completed in the timeframe?
iv. Will the inclusion of lwIP in the things to be done make the
project too big?

Regards,
Sujay Raj



On Fri, Mar 20, 2015 at 9:45 PM, Joel Sherrill
 wrote:
>
>
> On 3/20/2015 11:03 AM, Sujay Raj wrote:
>> BSP: pc386 simulated on QEMU
>>
>> On Fri, Mar 20, 2015 at 9:27 PM, Gedare Bloom  wrote:
>>> On Fri, Mar 20, 2015 at 11:39 AM, Sujay Raj  wrote:
>>>> Well I started writing the first draft of the project proposal ( which
>>>> I shall hopefully finish by tonight, Its 9 PM here ).
>>>>
>>>> I am making "porting the Monkey web server to RTEMS as well as a
>>>> partial reorganization of the network stacks present in RTEMS to make
>>>> it more modular", as the primary deliverable of this project.
>>>>
>>>> From what it appears, porting Monkey can be done in about a month + a
>>>> week for any delays. The development environment is already set up and
>>>> I am tweaking around with the code. So, by the mid-term evaluation I
>>>> expect to get monkey working on RTEMS (without enough time for
>>>> debugging).
>>>>
>>> What RTEMS target/BSP do you intend to use?
>>>
> The most likely candidates IMO are arm/zynq or i386/pc386 on qemu.
> Both include network simulators.  The ARM might be more better since
> there are active core developers on Zynq. And I don't know how much
> action Monkey has seen on non-x86 architectures.
>>>> For the second part, that is, getting the network stack of choice
>>>> built from RSB for the applications to be built against, I am a bit
>>>> apprehensive about the time limit. This task, at the first glance
>>>> doesn't appear that difficult, but it might be. So the second half (
>>>> till the final evaluation ) will involve getting the network stacks in
>>>> a separate build + a separate package for network tests + debugging.
>>>>
>>> I think there is a lot of complexity here.
> There is.  First goal should be Monkey against the new stack. I
> **think** that's
> the only stack that Zynq has a driver for.  Build order is:
>
> + rtems w/o networking
> + new stack
> + Monkey
>
> Once it is working, then upstream patches and make an RSB package. With
> documentation as needed.
>
> That is a good goal.
>
>>>> I think debugging and testing will be a major part of the project.
>>>>
>>> Always.
>>>
>>>> I was thinking along the lines, that the second part of the project
>>>> should be done first, but as Joel pointed out, the first step should
>>>> be monkey getting ported as a package.
>>>>
>>> I agree with Joel. The second part is harder to scope. It will be much
>>> better for you to have a solid task and deliverable (port Monkey) for
>>> the first-half.
> After Monkey is an RSB package, my idea was to decompose some of the network
> services in rtems/ now and make them independent packages (or a single
> add-on
> network services package) that is built separate from RTEMS.
>
> Ultimately, we do want RTEMS + network stack + services but there are steps.
>>>> kindly point out any comments/suggestions.
>>>>
>>> Be sure you identify when and where you plan to submit code. We like
>>> to see code pushed into RTEMS, and into upstream projects if needed,
>>> throughout the summer, not just at the end.
> +1 and documentation with example(s). Setup of any service like this on
> RTEMS
> may have details not applicable to any other host OS.
>
> --joel
&

Re: GSOC 2015 Monkey HTTP Server

[Sujay Raj]

Thanks.
I submitted the proposal online at the GSOC website. Also, I included
lwIP in the proposal.

On Mon, Mar 23, 2015 at 8:52 PM, Gedare Bloom  wrote:
> On Sun, Mar 22, 2015 at 6:56 PM, Sujay Raj  wrote:
>> I submitted the tentative proposal on the proposal page
>> devel.rtems.org/wiki/GSoC/2015 .
>>
> Please also submit your proposal to the official GSOC Melange system.
> You can revise it until the deadline, and it is better to get it in
> early to avoid any technical difficulties.
>
>> I have a few points to mention.
>> 1. About the BSP to work upon, I have not mentioned anything
>> specifically in the proposal because that is to be discussed. I do not
>> have enough working experience with ARM/zynq architecture. ( I worked
>> with ARM last trying to make homebrew games for the Nintendo GBA where
>> the emulator was Visual Boy Advance :) )  I have always worked with
>> x86 architectures. But yes, I can easily switch over to it, in little
>> time if I am pointed towards some resources about emulating it with
>> QEMU, and any other specifics about zynq.
>>
> The BSP / arch shouldn't matter too much, although Monkey is probably
> more-used on x86 platforms. Really, it would be best for you to use
> both platforms so you can shake out any bugs that are arch-dependent.
>
>> 2.   The sample proposal talked about setting up repository on
>> code.google.com, which is not accepting any new project and will close
>> within an year.
>>
> Use github. We need to update the sample.
>
>> 3. About the second part of my project, About separate RSB packaging
>> of network stacks,
>>  i. should I include lwIP too?
> Yes.
>
>>  ii. Is anyone else working on it? Should that affect my including
>> lwIP in my proposal?
> Possibly, but don't let it affect your proposal. The most recent port
> of lwIP appears to be for the beagleboard. We might have a student
> work on integrating it, possibly even into RSB. But you should still
> anticipate that you might get to do it yourself.
>
>> iii. Does the project look too ambitious to be completed in the 
>> timeframe?
> Hard to say. Sometimes things that look hard turn out easy, and vice versa.
>
>> iv. Will the inclusion of lwIP in the things to be done make the
>> project too big?
> No. I think it is a good set. You always want to have "stretch goals".
>
>> Regards,
>> Sujay Raj
>>
>>
>>
>> On Fri, Mar 20, 2015 at 9:45 PM, Joel Sherrill
>>  wrote:
>>>
>>>
>>> On 3/20/2015 11:03 AM, Sujay Raj wrote:
>>>> BSP: pc386 simulated on QEMU
>>>>
>>>> On Fri, Mar 20, 2015 at 9:27 PM, Gedare Bloom  wrote:
>>>>> On Fri, Mar 20, 2015 at 11:39 AM, Sujay Raj  wrote:
>>>>>> Well I started writing the first draft of the project proposal ( which
>>>>>> I shall hopefully finish by tonight, Its 9 PM here ).
>>>>>>
>>>>>> I am making "porting the Monkey web server to RTEMS as well as a
>>>>>> partial reorganization of the network stacks present in RTEMS to make
>>>>>> it more modular", as the primary deliverable of this project.
>>>>>>
>>>>>> From what it appears, porting Monkey can be done in about a month + a
>>>>>> week for any delays. The development environment is already set up and
>>>>>> I am tweaking around with the code. So, by the mid-term evaluation I
>>>>>> expect to get monkey working on RTEMS (without enough time for
>>>>>> debugging).
>>>>>>
>>>>> What RTEMS target/BSP do you intend to use?
>>>>>
>>> The most likely candidates IMO are arm/zynq or i386/pc386 on qemu.
>>> Both include network simulators.  The ARM might be more better since
>>> there are active core developers on Zynq. And I don't know how much
>>> action Monkey has seen on non-x86 architectures.
>>>>>> For the second part, that is, getting the network stack of choice
>>>>>> built from RSB for the applications to be built against, I am a bit
>>>>>> apprehensive about the time limit. This task, at the first glance
>>>>>> doesn't appear that difficult, but it might be. So the second half (
>>>>>> till the final evaluation ) will involve getting the network stacks in
>>>>>> a separate build + a separate package for network tests + debugging.
>>>>>>
>>>>> I think there is a lot of complexity here.

GSOC 2015 Proposal Review: Monkey HTTP server

[Sujay Raj]

Dear community members,

I successfully uploaded my proposal for GSOC 2015 at

http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/sujayraaj/5629499534213120


I welcome you all for any reviews/suggestions/criticism for the same.
The proposal is public.

With regards,

Sujay Raj
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Getting Networking to work on QEMU : Monkey Port

[Sujay Raj]

Hi,

I have successfully compiled RTEMS and all applications that donot
require networking work fine in QEMU. I tried compiled the
network-demos overwriting the networkconfig.h with
networkconfig-qemu.h.
initially there was an error with the networkconfig-qemu file:

../networkconfig.h:148:12: error: conflicting types for
'rtems_3c509_driver_attach'
 extern int rtems_3c509_driver_attach (struct rtems_bsdnet_ifconfig *, int);
. include/bsp.h:102:12: note: previous declaration of
'rtems_3c509_driver_attach' was here
 extern int rtems_3c509_driver_attach(struct rtems_bsdnet_ifconfig *config);

So I removed the extra 'int' parameter from the function,  it should
work if I use other nic like i82559er or ne2k_isa.

Most of the network demos compiled successfully.

then I tried setting up tap:

sudo tunctl -u `id -u`
sudo ifconfig tap0 10.1.1.1 netmask 255.255.255.0 up
sudo dhcpd -d tap0

and when each of the above executed successfully, I ran

sudo qemu -cpu 486 -m 8 -kernel netdemo/o-optimize/netdemo.exe -net
nic,macaddr=00:80:7F:22:61:77,model=i82559er -net
tap,vlan=0,ifname=tap0,script=no,downscript=no

but each time netdemo shows that the host is unreachable, so do other
applications.

I even tried running those applications using the user networking in
qemu (by port-forwarding) but that too didn't work.

So, Either I am missing a step, or doing it wrong. This was my fourth
day I spent over this problem so I decided to ask for help.

Kindly have a look.

With Regards,
Sujay Raj
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Network Demos on QEMU

[Sujay Raj]

Hi,

netdemo of 'network-demos' doesn't run as expected. I set up tap
successfully, and am trying to run netdemo using the
rtems-testing/qemu-support scripts.

1. The echoServer starts, as visible in the terminal :
Create socket.
Bind socket.
Listen.
Accept.

But neither telnet or ping work.

2. running transmitTcp with 't' shows :Can't connect socket: Host is unreachable

3. running transmitUdp with 'u' leads to a fatal error and ends the simulation :
Create socket.
Bind socket.
Opt:0Optlen:4
Opt:32Optlen:4
Can't broadcast: Host is unreachable
fatal error, exiting


Note: My tap device is has been set up correctly and is working. I
tried it on ttyLinux running in QEMU, through tap, and I was able to
ssh into it. All I had to do was to manually give the IP address to
eth0 as 10.1.2.5.

So, it works for other systems, not for rtems.

The diff of my networkconfig.h file with the default
networkconfig-qemu.h has minimal change:

< extern int rtems_3c509_driver_attach (struct rtems_bsdnet_ifconfig
*);//, int);
---
> extern int rtems_3c509_driver_attach (struct rtems_bsdnet_ifconfig *, int);

which I had to change to compile everything.

Any help would be greatly appreciated.

Thanks and regards.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Build of rtems-libbsd for all BSPs

[Sujay Raj]

On i386/pc386, adding a line :

extern u_int64_t tsc_freq;

to freebsd/sys/contrib/altq/altq/altq_subr.c

gets it to build successfully. Though I wonder what its repercussions would be.

On Thu, May 28, 2015 at 8:43 PM, Joel Sherrill
 wrote:
> Hi
>
> I decided to attempt to build rtems-libbsd for all BSPs. I didn't
> expect great results but 136 of 193 BSPs did not complete the build.
>
> Overall, the results are surprising. No x86 or SPARC BSPs could
> build rtems-libbsd. And many ARM and PowerPC BSPs had build issues
> that were *NOT* running out of memory linking.
>
> Apparently, a target has to have C++ and dlfcn.h or it is not attempted.
>
> Some general failure patterns:
>
> + SPARC pci header
> + Missing bsp/irq-info.h
> + Missing libcpu/cache.h
> + Missing rtems_interrupt_server_initialize()
> + ohci_lpc.c:221:18: error: 'EIO' undeclared
> + x86 tsc_freq variable missing
> + powerpc: Unsupported CPU model
>
> The full report is attached.
>
> --
> Joel Sherrill, Ph.D. Director of Research & Development
> joel.sherr...@oarcorp.comOn-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available(256) 722-9985
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-libbsd waf params

[Sujay Raj]

>From what I could make out from the documentation in README.waf,
in waf configure , --prefix is where you would like to install rtems-libbsd,
--rtems is where you installed your bsp, that is, the '--prefix' you
passed while configuring the bsp.
'--rtems-tools' points to the tool-set you built using RSB (the
--prefix you passed to the RSB) and
'--rtems-bsps' should be provided with the string 'architecture/bsp'.

 (everything without quotes, quotes are just for illustration)

usually --prefix and --rtems would have the same value, but it depends
on how you are setting things up.


Further, from libbsd.txt, in config.inc BSP should only be the name of
your BSP, not c/raspberrypi/make.

See if this helps.
Regards



On Fri, Jun 5, 2015 at 10:47 PM, Yurii Shevtsov  wrote:
> Since 'waf' requires four params and 'make' only three in config.inc,
> I got confused with waf. Could anyone help me with waf params? Here is
> my config.inc:
>   TARGET = arm-rtems4.11
>   BSP = c/raspberrypi/make
>   PREFIX = /home/gtament/development/rtems/src/b-rpi
>
> Thanks in advance)
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Test selectpollkqueue01 in rtems-libbsd fails for kqueue.

[Sujay Raj]

I am working on the xilinx_zynq_a9_qemu bsp.

The output just prior to the error is  :

test kqueue timer
test kqueue timer
test kqueue connect
worker: create new connect socket
worker: connect
test kqueue read
worker: write
test kqueue write
assertion "event.data == 20428" failed: file
"../../testsuite/selectpollkqueue01/test_main.c", line 880, function:
test_kqueue_write
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

multiple definition of __getreent

[Sujay Raj]

Hi ,

I am working on porting the monkey http server to rtems.

I am working on the bsp: xilinx_zynq_a9_qemu , target: arm-rtems4.11.

There are two libraries that I am supposed to link to create my final
executable, one is libbsd.a and the other is libc.

libbsd.a links alright, but whenever I try to link libc to create the final
executable , I get an error:

/home/raaj/development/rtems/4.11/bsps/arm-rtems4.11/xilinx_zynq_a9_qemu/lib/librtemscpu.a(default-configuration.o):
In function `__getreent':

/home/raaj/development/rtems/xilinx_zynq_a9_qemu/arm-rtems4.11/c/xilinx_zynq_a9_qemu/cpukit/libmisc/../../cpukit/../../../xilinx_zynq_a9_qemu/lib/include/rtems/confdefs.h:2420:
multiple definition of `__getreent'

/home/raaj/development/rtems/4.11/tools/lib/gcc/arm-rtems4.11/4.9.2/../../../../arm-rtems4.11/lib/thumb/armv7-a/neon/hard/libc.a(lib_a-getreent.o):

/home/raaj/development/rtems/rtems-source-builder/rtems/build/arm-rtems4.11-gcc-4.9.2-newlib-2.2.0.20150423-x86_64-linux-gnu-1/build/arm-rtems4.11/thumb/armv7-a/neon/hard/newlib/libc/reent/../../../../../../../../../gcc-4.9.2/newlib/libc/reent/getreent.c:13:
first defined here



The CFLAGS I am using to compile are :

-march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9 -O0 -g
-qrtems -B/home/raaj/development/rtems/4.11/bsps/arm-rtems4.11/lib
-B/home/raaj/development/rtems/4.11/bsps/arm-rtems4.11/xilinx_zynq_a9_qemu/lib/
--specs bsp_specs



note: I require libc for three function , initgroups, timegm, and sendfile.

note: I am working on a cmake build system

If the information given here is insufficient, kindly ask.

Thanks and regards,
Sujay Raj
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: multiple definition of __getreent

[Sujay Raj]

@Chris , I used  'target_link_libraries' in mk_bin/CMakeLists.txt to link
libc.a and libbsd.a to the monkey-bin target

@Joel, removing -O0 doesn't work too.

I needed libc for three function , initgroups, timegm, and sendfile.

Today I figured that monkey can function without 'initgroups' , if it is
given all privileges, which I think will be the case when it runs on rtems
(I tested on linux and when run from root, it can work without initgroups)
. And I wrote a my_timegm function emulating what timegm does. So these two
functions aren't needed anymore. (both were tested and working on linux)

The problem comes with sendfile.

So, just to get things working, I also wrote a make shift version of
sendfile using read/write (which is working on linux, but is theoretically
slow).

Doing the above removed the requirement of linking libc.a totally.

So yeah, we now have a working version of monkey on rtems using libbsd,
which is ready to be tested on qemu. Though, this is not the ideal
circumstances that we would have hoped for, and I certainly would want
monkey to be using the default sendfile from the library.

Regards,
Sujay Raj

On Sun, Jun 21, 2015 at 5:00 AM, Joel Sherrill 
wrote:

> I suspect it is because he is compiling at -O0.
>
> On June 20, 2015 6:13:23 PM CDT, Chris Johns  wrote:
> >On 20/06/2015 2:34 am, Sujay Raj wrote:
> >> Hi ,
> >>
> >> I am working on porting the monkey http server to rtems.
> >>
> >> I am working on the bsp: xilinx_zynq_a9_qemu , target: arm-rtems4.11.
> >>
> >> There are two libraries that I am supposed to link to create my final
> >> executable, one is libbsd.a and the other is libc.
> >>
> >> libbsd.a links alright, but whenever I try to link libc to create the
> >> final executable , I get an error:
> >>
> >>
>
> >/home/raaj/development/rtems/4.11/bsps/arm-rtems4.11/xilinx_zynq_a9_qemu/lib/librtemscpu.a(default-configuration.o):
> >> In function `__getreent':
> >>
> >>
>
> >/home/raaj/development/rtems/xilinx_zynq_a9_qemu/arm-rtems4.11/c/xilinx_zynq_a9_qemu/cpukit/libmisc/../../cpukit/../../../xilinx_zynq_a9_qemu/lib/include/rtems/confdefs.h:2420:
> >> multiple definition of `__getreent'
> >>
> >>
>
> >/home/raaj/development/rtems/4.11/tools/lib/gcc/arm-rtems4.11/4.9.2/../../../../arm-rtems4.11/lib/thumb/armv7-a/neon/hard/libc.a(lib_a-getreent.o):
> >>
> >>
>
> >/home/raaj/development/rtems/rtems-source-builder/rtems/build/arm-rtems4.11-gcc-4.9.2-newlib-2.2.0.20150423-x86_64-linux-gnu-1/build/arm-rtems4.11/thumb/armv7-a/neon/hard/newlib/libc/reent/../../../../../../../../../gcc-4.9.2/newlib/libc/reent/getreent.c:13:
> >> first defined here
> >>
> >>
> >>
> >> The CFLAGS I am using to compile are :
> >>
> >> -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9
> >-O0
> >> -g -qrtems -B/home/raaj/development/rtems/4.11/bsps/arm-rtems4.11/lib
> >>
>
> >-B/home/raaj/development/rtems/4.11/bsps/arm-rtems4.11/xilinx_zynq_a9_qemu/lib/
> >> --specs bsp_specs
> >>
> >>
> >>
> >> note: I require libc for three function , initgroups, timegm, and
> >sendfile.
> >>
> >> note: I am working on a cmake build system
> >>
> >> If the information given here is insufficient, kindly ask.
> >>
> >
> >Can you please post the full command line you are using to link with ?
> >
> >Thanks
> >Chris
> >___
> >devel mailing list
> >devel@rtems.org
> >http://lists.rtems.org/mailman/listinfo/devel
>
> --joel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: multiple definition of __getreent

[Sujay Raj]

I am updating my github repo after cleaning the code, for you all to
verify. I will drop a mail when its ready.

Regards,
Sujay Raj


On Sun, Jun 21, 2015 at 10:54 PM, Sujay Raj  wrote:

> @Chris , I used  'target_link_libraries' in mk_bin/CMakeLists.txt to link
> libc.a and libbsd.a to the monkey-bin target
>
> @Joel, removing -O0 doesn't work too.
>
> I needed libc for three function , initgroups, timegm, and sendfile.
>
> Today I figured that monkey can function without 'initgroups' , if it is
> given all privileges, which I think will be the case when it runs on rtems
> (I tested on linux and when run from root, it can work without initgroups)
> . And I wrote a my_timegm function emulating what timegm does. So these two
> functions aren't needed anymore. (both were tested and working on linux)
>
> The problem comes with sendfile.
>
> So, just to get things working, I also wrote a make shift version of
> sendfile using read/write (which is working on linux, but is theoretically
> slow).
>
> Doing the above removed the requirement of linking libc.a totally.
>
> So yeah, we now have a working version of monkey on rtems using libbsd,
> which is ready to be tested on qemu. Though, this is not the ideal
> circumstances that we would have hoped for, and I certainly would want
> monkey to be using the default sendfile from the library.
>
> Regards,
> Sujay Raj
>
> On Sun, Jun 21, 2015 at 5:00 AM, Joel Sherrill 
> wrote:
>
>> I suspect it is because he is compiling at -O0.
>>
>> On June 20, 2015 6:13:23 PM CDT, Chris Johns  wrote:
>> >On 20/06/2015 2:34 am, Sujay Raj wrote:
>> >> Hi ,
>> >>
>> >> I am working on porting the monkey http server to rtems.
>> >>
>> >> I am working on the bsp: xilinx_zynq_a9_qemu , target: arm-rtems4.11.
>> >>
>> >> There are two libraries that I am supposed to link to create my final
>> >> executable, one is libbsd.a and the other is libc.
>> >>
>> >> libbsd.a links alright, but whenever I try to link libc to create the
>> >> final executable , I get an error:
>> >>
>> >>
>>
>> >/home/raaj/development/rtems/4.11/bsps/arm-rtems4.11/xilinx_zynq_a9_qemu/lib/librtemscpu.a(default-configuration.o):
>> >> In function `__getreent':
>> >>
>> >>
>>
>> >/home/raaj/development/rtems/xilinx_zynq_a9_qemu/arm-rtems4.11/c/xilinx_zynq_a9_qemu/cpukit/libmisc/../../cpukit/../../../xilinx_zynq_a9_qemu/lib/include/rtems/confdefs.h:2420:
>> >> multiple definition of `__getreent'
>> >>
>> >>
>>
>> >/home/raaj/development/rtems/4.11/tools/lib/gcc/arm-rtems4.11/4.9.2/../../../../arm-rtems4.11/lib/thumb/armv7-a/neon/hard/libc.a(lib_a-getreent.o):
>> >>
>> >>
>>
>> >/home/raaj/development/rtems/rtems-source-builder/rtems/build/arm-rtems4.11-gcc-4.9.2-newlib-2.2.0.20150423-x86_64-linux-gnu-1/build/arm-rtems4.11/thumb/armv7-a/neon/hard/newlib/libc/reent/../../../../../../../../../gcc-4.9.2/newlib/libc/reent/getreent.c:13:
>> >> first defined here
>> >>
>> >>
>> >>
>> >> The CFLAGS I am using to compile are :
>> >>
>> >> -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9
>> >-O0
>> >> -g -qrtems -B/home/raaj/development/rtems/4.11/bsps/arm-rtems4.11/lib
>> >>
>>
>> >-B/home/raaj/development/rtems/4.11/bsps/arm-rtems4.11/xilinx_zynq_a9_qemu/lib/
>> >> --specs bsp_specs
>> >>
>> >>
>> >>
>> >> note: I require libc for three function , initgroups, timegm, and
>> >sendfile.
>> >>
>> >> note: I am working on a cmake build system
>> >>
>> >> If the information given here is insufficient, kindly ask.
>> >>
>> >
>> >Can you please post the full command line you are using to link with ?
>> >
>> >Thanks
>> >Chris
>> >___
>> >devel mailing list
>> >devel@rtems.org
>> >http://lists.rtems.org/mailman/listinfo/devel
>>
>> --joel
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Sendfile for Rtems

[Sujay Raj]

I am working on porting Monkey HTTP server on rtems.

Sendfile is not specified in POSIX.1-2001 or other standards and its
implementations vary depending on the unix/linux system being used.

Freebsd has sendfile in its libc.

So I opened this thread to discuss how should we proceed with this matter,
if we should work on getting sendfile in newlib, or if there is any
portable solution that we can use in its place.

cc to Joel and Eduardo.

Thanks and Regards,
Sujay Raj
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Sendfile for Rtems

[Sujay Raj]

I agree with Sebastian.

Using read write in a loop can only serve as a makeshift measure.

If we have consensus here, then I can work on getting sendfile backed up in
libbsd. (though, I have some serious background reading to do before I am
able to do it, but I think I can. )

Thanks and Regards,
Sujay Raj

On Wed, Jun 24, 2015 at 12:21 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> I would use the sendfile system call implementation from FreeBSD and add
> it to the libbsd. Its not a big win if you use read() and write() to
> implement sendfile().  This makes only sense if you can use kernel space
> zero-copy buffers.
>
> - Eduardo Silva  schrieb:
> >
> Sujay,
>
> Monkey use conditionals for each implementation: Linux, FreeBSD and OSX.
> My suggestion is that RTEMS may implement a sendfile based on FreeBSD
> format which can easily be emulated as a read() and further write() for
> socket operations. That will help not only Monkey, but also other software
> that requires such interface.
>
> I am not the best one to talk about RTEMS, but the Kernel always knows
> better it buffers capacity that the program on the other side.
>
> do you think is possible to do that on RTEMS ?
>
> regards,
>
> On Tue, Jun 23, 2015 at 12:05 PM, Joel Sherrill  > wrote:
>
>>
>>
>> >
>>
>> > On 6/23/2015 12:49 PM, Sujay Raj wrote:
>>
>> >
>>>
>>>
>>> > I am working on porting Monkey HTTP server on rtems.
>>>
>>> >
>>>
>>> > Sendfile is not specified in POSIX.1-2001 or other standards and its
>>> implementations vary depending on the unix/linux system being used.
>>>
>>> >
>>>
>>> > Freebsd has sendfile in its libc.
>>>
>>> >
>>
>>
>> >
>>
>> > FreeBSD has a completely different API for sendfile(). Plus the source
>>
>> > must be a regular file and the destination a socket.
>>
>> >
>>
>> >https://www.freebsd.org/cgi/man.cgi?query=sendfile&sektion=2
>>
>> >
>>
>> > This is a random discussion of sendfile() on various OSes. It mentions
>>
>> > the assumption that the source must normally be able to be mmap'ed.
>>
>> > Since you can't do that on RTEMS, you are stuck with a loop
>>
>> > implementation. [1]
>>
>> >
>>
>> >https://groups.google.com/forum/#!topic/comp.unix.programmer/65oDSzpEzx8
>>
>> >
>>
>> >
>>>
>>>
>>> > So I opened this thread to discuss how should we proceed with this
>>> matter, if we should work on getting sendfile in newlib, or if there is any
>>> portable solution that we can use in its place.
>>>
>>> >
>>
>>
>> >
>>
>> > Given that (a) it is not POSIX and (b) there is no agreement between
>>
>> > Linux and FreeBSD, it is highly unlikely newlib would accept an
>>
>> > implementation.
>>
>> >
>>
>> > Given (b), I don't personally see merging it into RTEMS since we
>>
>> > have to pick a winner and loser on the API.
>>
>> >
>>
>> > What's the feeling on having a default implementation in Monkey and
>>
>> > using that as a backup? With [1] as a consideration again.
>>
>> >
>>
>> >
>>
>> > [1] The size of the buffer user for read/write has to be accounted
>>
>> > for. If this is on a thread stack, then it can't be too large or that
>>
>> > imposes a burden on calling sendfile(). I can see an implementation
>>
>> > doing a malloc() of the buffer and then free()'ing it.
>>
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>>
>>>
>>> > cc to Joel and Eduardo.
>>>
>>> >
>>>
>>> > Thanks and Regards,
>>>
>>> > Sujay Raj
>>>
>>> >
>>
>>
>> >
>>
>> > --
>>
>> > Joel Sherrill, Ph.D. Director of Research & Development
>>
>> > joel.sherr...@oarcorp.comOn-Line Applications Research
>>
>> > Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>>
>> > Support Available(256) 722-9985
>>
>> >
>
>
>
>
> --
> Eduardo Silva
> Monkey Software
>
> >
>
>
> --
>
> Sebastian Huber, embedded brains GmbH
>
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de 
> <http://lists.rtems.org/mailman/listinfo/devel>
> PGP : Public key available on request.
>
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Sendfile for Rtems

[Sujay Raj]

Okay, So I will dig in to the details of the implementation of sendfile on
freebsd to find if it does indeed use mmap, or if there is an
implementation that doesn't.

I will inform as soon as I figure it out if this is the correct way out.

Thanks and Regards,
Sujay Raj

On Wed, Jun 24, 2015 at 12:49 AM, Joel Sherrill 
wrote:

>
>
> On 6/23/2015 2:15 PM, Gedare Bloom wrote:
>
>> On Tue, Jun 23, 2015 at 3:13 PM, Sujay Raj  wrote:
>>
>>> I agree with Sebastian.
>>>
>>> Using read write in a loop can only serve as a makeshift measure.
>>>
>>> If we have consensus here, then I can work on getting sendfile backed up
>>> in
>>> libbsd. (though, I have some serious background reading to do before I am
>>> able to do it, but I think I can. )
>>>
>>>  Yes this makes the most sense.
>>
>
> If it doesn't rely on mmap(). If it does, then it won't work.
>
>
>  Thanks and Regards,
>>> Sujay Raj
>>>
>>> On Wed, Jun 24, 2015 at 12:21 AM, Sebastian Huber
>>>  wrote:
>>>
>>>>
>>>> I would use the sendfile system call implementation from FreeBSD and add
>>>> it to the libbsd. Its not a big win if you use read() and write() to
>>>> implement sendfile().  This makes only sense if you can use kernel space
>>>> zero-copy buffers.
>>>>
>>>> - Eduardo Silva  schrieb:
>>>>
>>>>>
>>>>>  Sujay,
>>>>
>>>> Monkey use conditionals for each implementation: Linux, FreeBSD and OSX.
>>>> My suggestion is that RTEMS may implement a sendfile based on FreeBSD
>>>> format
>>>> which can easily be emulated as a read() and further write() for socket
>>>> operations. That will help not only Monkey, but also other software that
>>>> requires such interface.
>>>>
>>>> I am not the best one to talk about RTEMS, but the Kernel always knows
>>>> better it buffers capacity that the program on the other side.
>>>>
>>>> do you think is possible to do that on RTEMS ?
>>>>
>>>> regards,
>>>>
>>>> On Tue, Jun 23, 2015 at 12:05 PM, Joel Sherrill
>>>>  wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>  On 6/23/2015 12:49 PM, Sujay Raj wrote:
>>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>  I am working on porting Monkey HTTP server on rtems.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>  Sendfile is not specified in POSIX.1-2001 or other standards and its
>>>>>>> implementations vary depending on the unix/linux system being used.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>  Freebsd has sendfile in its libc.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>  FreeBSD has a completely different API for sendfile(). Plus the source
>>>>>>
>>>>>
>>>>>  must be a regular file and the destination a socket.
>>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>  https://www.freebsd.org/cgi/man.cgi?query=sendfile&sektion=2
>>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>  This is a random discussion of sendfile() on various OSes. It mentions
>>>>>>
>>>>>
>>>>>  the assumption that the source must normally be able to be mmap'ed.
>>>>>>
>>>>>
>>>>>  Since you can't do that on RTEMS, you are stuck with a loop
>>>>>>
>>>>>
>>>>>  implementation. [1]
>>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>
>>>>>> https://groups.google.com/forum/#!topic/comp.unix.programmer/65oDSzpEzx8
>>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>  So I opened this thread to discuss how should we proceed with this
>>>>>>> matter, if we should work on getting sendfil

Using tar to access files

[Sujay Raj]

I need to access configurations files the for web server I am porting to
rtems.

I create a tar archive , that contains the required folders and files ,
convert it into c source using rtems-bin2c , ( a header file and a c source
) and link them with my project.

In the init, I call

sc = Untar_FromMemory((void *)TARFILE_START, (size_t)TARFILE_SIZE);

where TARFILE_START is the macro with the name of the array , TARFILE_SIZE
is the size of the array.

But when I run the program, I get errors of the form

"Untar: failed to create file /"

for all the files in the tar archive (there are about 10 files, 10 errors).

There are no build errors, and since my application recognizes files
present in the tar archive, I think possibly I am missing to initialize
something.

Help would be really appreciated.

Thanks and Regards,
Sujay Raj
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: i386 build fail

[Sujay Raj]

1. A guess : python and its devel packages might not be installed in your
system.

2. To be sure of what is happening, you need to see the error report
'rsb-report-i386--gnu-1.txt' which is mentioned in the screen shot you
provided. It usually pinpoints what happened wrong. ( gdb has a python
dependency, I got that wrong once ).
Viewing all the log files usually solves the problem.

3. In my personal opinion, dumping formatted text output in the mail is
comparatively better than posting screen-shots. And if you prefer
screen-shots, you might prefer to crop to only the required portions.

Thanks and Regards,
Sujay Raj


On Sat, Aug 8, 2015 at 10:39 AM, punit vara  wrote:

> Sorry I have mistakenly attached another screenshot. Here is build
> error screen shot .I have followed GSoC getting started guide.
>
> ../source-builder/sb-set-builder --log=l-i386.txt \
>
> --prefix=$HOME/development/rtems/4.11 4.11/rtems-i386
>
> I am using this command to build i386 setup .
> Please find the attachment of error screenshot.
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Building RTEMS hello world image using CMake

[Sujay Raj]

Note: the RTEMS_TOOLS and BSP_DIR variables in the above mail point to the
toolchain directory and BSP directory respectively and need to be passed to
cmake while calling it using the ( -D ) flag.

On Sun, Mar 13, 2016 at 5:22 PM, Sujay Raj  wrote:

> cmake works fine if the variables are over-ridden. And things aren't that
> difficult while using pc386 bsp.
> But if we are dealing with arm or other archs, the best way ( and the
> recommended one ) to do during cross-compiling would be to create a
> toolchain file, forcing cmake to use the cross compiling toolchain, and not
> run its tests that it usually runs for x86/x86-64 systems.
>
> documentation on how to do it is available here:
>
> https://cmake.org/Wiki/CMake_Cross_Compiling
>
> an example for the cmake toolchain file for building an application for
> rtems:
>
> https://github.com/sujayraaj/monkey/blob/1.6/cmake/rtems/RTEMS.tc
>
> and adding :
>
>
> set(ARCH arm )
> set(BSP xilinx_zynq_a9_qemu )
> set(BSP_CFLAGS "-march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard
> -mtune=cortex-a9" )
>
> set(RTEMS_CFLAGS "${BSP_CFLAGS} -O0 -g -qrtems
> -B${BSP_DIR}/${ARCH}-rtems4.11/lib" )
>
> set(RTEMS_CFLAGS "${RTEMS_CFLAGS}
> -B${BSP_DIR}/${ARCH}-rtems4.11/xilinx_zynq_a9_qemu/lib/" )
>
> set(RTEMS_CFLAGS "${RTEMS_CFLAGS} --specs bsp_specs")
> set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${RTEMS_CFLAGS}")
>
>
> at the top of the CmakeLists.txt file.
>
> ( Somehow I didn't recieve Chris's mail on this thread so what I have said
> might be repetitive )
>
>
> On Sat, Mar 12, 2016 at 8:23 PM, Gedare Bloom  wrote:
>
>> If this works for you, and you are sufficiently interested, it would
>> be useful to provide CMake example for the examples-v2.git repository
>> for others to benefit.
>>
>> On Sat, Mar 12, 2016 at 9:29 AM, Sambeet Panigrahi
>>  wrote:
>> > Thank you Chris.That works perfectly:)
>> >
>> > On Mar 11, 2016 6:32 AM, "Chris Johns"  wrote:
>> >>
>> >>  [ Please excuse the delay. It took a while to get
>> >>something worth posting sorted out. ]
>> >>
>> >> On 04/03/2016 14:46, Sambeet Panigrahi wrote:
>> >>>
>> >>> I wanted to build a hello world image of RTEMS using cmake. Can
>> someone
>> >>> provide me steps for doing so or point me to the right resources ?
>> >>
>> >>
>> >> I attach a couple of files from a friend of mine, Andi, who knows and
>> >> works with cmake. I have not tried them and I do not know if they work.
>> >>
>> >> If you have any questions please feel free to ask.
>> >>
>> >> Chris
>> >
>> >
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Building RTEMS hello world image using CMake

[Sujay Raj]

cmake works fine if the variables are over-ridden. And things aren't that
difficult while using pc386 bsp.
But if we are dealing with arm or other archs, the best way ( and the
recommended one ) to do during cross-compiling would be to create a
toolchain file, forcing cmake to use the cross compiling toolchain, and not
run its tests that it usually runs for x86/x86-64 systems.

documentation on how to do it is available here:

https://cmake.org/Wiki/CMake_Cross_Compiling

an example for the cmake toolchain file for building an application for
rtems:

https://github.com/sujayraaj/monkey/blob/1.6/cmake/rtems/RTEMS.tc

and adding :


set(ARCH arm )
set(BSP xilinx_zynq_a9_qemu )
set(BSP_CFLAGS "-march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard
-mtune=cortex-a9" )

set(RTEMS_CFLAGS "${BSP_CFLAGS} -O0 -g -qrtems
-B${BSP_DIR}/${ARCH}-rtems4.11/lib" )

set(RTEMS_CFLAGS "${RTEMS_CFLAGS}
-B${BSP_DIR}/${ARCH}-rtems4.11/xilinx_zynq_a9_qemu/lib/" )

set(RTEMS_CFLAGS "${RTEMS_CFLAGS} --specs bsp_specs")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${RTEMS_CFLAGS}")


at the top of the CmakeLists.txt file.

( Somehow I didn't recieve Chris's mail on this thread so what I have said
might be repetitive )


On Sat, Mar 12, 2016 at 8:23 PM, Gedare Bloom  wrote:

> If this works for you, and you are sufficiently interested, it would
> be useful to provide CMake example for the examples-v2.git repository
> for others to benefit.
>
> On Sat, Mar 12, 2016 at 9:29 AM, Sambeet Panigrahi
>  wrote:
> > Thank you Chris.That works perfectly:)
> >
> > On Mar 11, 2016 6:32 AM, "Chris Johns"  wrote:
> >>
> >>  [ Please excuse the delay. It took a while to get
> >>something worth posting sorted out. ]
> >>
> >> On 04/03/2016 14:46, Sambeet Panigrahi wrote:
> >>>
> >>> I wanted to build a hello world image of RTEMS using cmake. Can someone
> >>> provide me steps for doing so or point me to the right resources ?
> >>
> >>
> >> I attach a couple of files from a friend of mine, Andi, who knows and
> >> works with cmake. I have not tried them and I do not know if they work.
> >>
> >> If you have any questions please feel free to ask.
> >>
> >> Chris
> >
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel