<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 25, 2016 at 4:22 AM, Christian Mauderer <span dir="ltr"><<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Essentially I agree that it would be nice to build civetweb as an<br>
external library especially with the different network stacks in mind.<br>
But there are some points that keep me from doing it:<br>
<br>
1. I have really no Idea what would be necessary to build it as an<br>
upstream project using RSB. If that are only something like three simple<br>
steps, it should be possible to squeeze it in the little time budget<br>
that is left for the project. If I first have to analyze and change a<br>
lot of RSB, it would be challenging.<br>
<br></blockquote><div>FWIW I think this can be a secondary goal. Switching over to the real</div><div>upstream project with proper licensing is important. </div><div><br></div><div>When we do this, we incur some burden of "retraining" users to consider</div><div>a webserver an external addon. But that is the direction I think we want</div><div>to head with httpd, telnetd, ftpd, etc. So it is a good long term goal.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Chris, I think you know the RSB best: What steps do you think would be<br>
necessary?<br>
<br></blockquote><div><br></div><div>Chris...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. Currently there is one test case for mghttpd (libtests/mghttpd01).<br>
This is one of the few tests that check some networking functions in<br>
RTEMS. Further we should not loose the ability to test software when it<br>
is build with RSB. How would we handle tests for software in RSB?<br>
<br></blockquote><div><br></div><div>That's a Chris question. We should aim to have tests which run with</div><div>either network stack for RSB built network services. This is a good</div><div>requirement on the plan to moving to separately built network stacks</div><div>and services.</div><div><br></div><div>Having thought about this, I am not opposed to seeing the patches</div><div>merged as long as it is clear what is just moving to the new upstream,</div><div>what are patches, the patches are submitted upstream and we push</div><div>to get them merged.</div><div><br></div><div>I realize you need a practical goal. I would like concurrence from Chris</div><div>and Gedare on the short and long term plans. If you can make any</div><div>progress on the long term plan, that's good but we should accept</div><div>the short term needed improvement. </div><div><br></div><div>Perfection is the enemy of the good enough.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Kind regards<br>
<br>
Christian Mauderer<br>
<span class=""><br>
Am 23.04.2016 um 15:07 schrieb Joel Sherrill:<br>
> I am really with Gedare and Chris that it would be better to treat this<br>
> as an upstream project. Use the RSB and track patches through RTEMS tools.<br>
><br>
> It would be a good case to push the model of a single network service<br>
> supporting both stacks and begin the process of removing networking code<br>
> from the base RTEMS git repo.<br>
><br>
> It would also push us to figure out how to rest RSB built packages.<br>
><br>
> On Apr 22, 2016 12:05 AM, "Christian Mauderer"<br>
> <<a href="mailto:christian.mauderer@embedded-brains.de">christian.mauderer@embedded-brains.de</a><br>
</span><span class="">> <mailto:<a href="mailto:christian.mauderer@embedded-brains.de">christian.mauderer@embedded-brains.de</a>>> wrote:<br>
><br>
> Yes that's right. 05/13 just adds the unchanged sources from civetweb.<br>
> Beneath civetweb.c and civetweb.h it also adds handle_form.inl and<br>
> md5.inl. The last two files are included into civetweb.c. According to<br>
> the documentation "The *INL* file extension represents code that is<br>
> statically included inline in a source file."<br>
><br>
> And yes: The patch didn't get through. I have got a replay that "Your<br>
> message to devel awaits moderator approval". The civetweb.c file is over<br>
> 300k and the mailing list seems to have a maximum of 256k. I hoped that<br>
> one of the mail admins would approve the patch soon.<br>
><br>
> Am 21.04.2016 um 22:49 schrieb Gedare Bloom:<br>
> > I think patch 05/13 probably adds civetweb.c and civetweb.h? But it<br>
> > did not come through the mailman.<br>
> ><br>
> > On Thu, Apr 21, 2016 at 4:46 PM, Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a><br>
</span><span class="">> <mailto:<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>>> wrote:<br>
> >> P.S. might be worth it to open a ticket related to civetweb and<br>
> >> #update it from these patches.<br>
> >><br>
> >> On Thu, Apr 21, 2016 at 4:45 PM, Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a><br>
</span><span class="">> <mailto:<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>>> wrote:<br>
> >>> Is the plan eventually to be able to use the upstream civetweb?<br>
> or to<br>
> >>> track it with our own copy?<br>
> >>><br>
> >>> On Thu, Apr 21, 2016 at 4:49 AM, Christian Mauderer<br>
> >>> <<a href="mailto:christian.mauderer@embedded-brains.de">christian.mauderer@embedded-brains.de</a><br>
</span><span class="">> <mailto:<a href="mailto:christian.mauderer@embedded-brains.de">christian.mauderer@embedded-brains.de</a>>> wrote:<br>
> >>>> This patch series replaces the mongoose webserver by its still MIT<br>
> >>>> licensed fork civetweb.<br>
> >>>><br>
> >>>> Please note that I try to get some (currently two) of the patches<br>
> >>>> directly into civetweb too. But I think that it might need some<br>
> time and<br>
> >>>> adaption till they are accepted. So I thought that adding them<br>
> to RTEMS<br>
> >>>> would still make sense as a working interim solution.<br>
> >>>><br>
> >>>> _______________________________________________<br>
> >>>> devel mailing list<br>
</span>> >>>> <a href="mailto:devel@rtems.org">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org">devel@rtems.org</a>><br>
<span class="">> >>>> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
><br>
> --<br>
> --------------------------------------------<br>
> embedded brains GmbH<br>
> Christian Mauderer<br>
> Dornierstr. 4<br>
> D-82178 Puchheim<br>
> Germany<br>
> email: <a href="mailto:christian.mauderer@embedded-brains.de">christian.mauderer@embedded-brains.de</a><br>
</span>> <mailto:<a href="mailto:christian.mauderer@embedded-brains.de">christian.mauderer@embedded-brains.de</a>><br>
> Phone: <a href="tel:%2B49-89-18%2094%20741%20-%2018" value="+4989189474118">+49-89-18 94 741 - 18</a> <tel:%2B49-89-18%2094%20741%20-%2018><br>
> Fax: <a href="tel:%2B49-89-18%2094%20741%20-%2008" value="+4989189474108">+49-89-18 94 741 - 08</a> <tel:%2B49-89-18%2094%20741%20-%2008><br>
<span class="">> PGP: Public key available on request.<br>
><br>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
> _______________________________________________<br>
> devel mailing list<br>
</span>> <a href="mailto:devel@rtems.org">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org">devel@rtems.org</a>><br>
<div class="HOEnZb"><div class="h5">> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
><br>
<br>
--<br>
--------------------------------------------<br>
embedded brains GmbH<br>
Christian Mauderer<br>
Dornierstr. 4<br>
D-82178 Puchheim<br>
Germany<br>
email: <a href="mailto:christian.mauderer@embedded-brains.de">christian.mauderer@embedded-brains.de</a><br>
Phone: <a href="tel:%2B49-89-18%2094%20741%20-%2018" value="+4989189474118">+49-89-18 94 741 - 18</a><br>
Fax: <a href="tel:%2B49-89-18%2094%20741%20-%2008" value="+4989189474108">+49-89-18 94 741 - 08</a><br>
PGP: Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
</div></div></blockquote></div><br></div></div>