Add MiniOS as a target

[jpemartins]

Add support for MiniOS as an additional target to Click. Like we discussed two weeks ago, this pull request already takes into account the changes you suggested i.e. usage of system toolchain, a bit of restyling, docs. I don't exactly know how to deal with the dependencies (newlib, lwip, mini-os) but I don't include them to give more freedom to the developers. I added this information to the INSTALL file with instructions, in a ClickOS section.

Please have a look and let me know what do you think.

Cheers!

[kohler]

Hi, I'm psyched for this!

An initial question: It seems possible that CLICK_MINIOS should actually define CLICK_USERLEVEL, because there's a lot of overlap. Is that crazy?

[jpemartins]

Initially was like that. So when rewriting the Click build integration we switched to just CLICK_MINIOS to be cleaner. Problem is that MiniOS is a bit limited, and not libc complete. So in the end, I am just afraid that a lot of !CLICK_MINIOS would be spread out all over the place. But might not be the case! @fmanco has a better word on this, since he rewrote how everything got assembled.

[fmanco]

Hey, in fact we started by define CLICK_USERLEVEL and then have special cases to compile with minios, but there were a couple of reasons that made me switch to this option. It looked (at least for me) cleaner to define CLICK_MINIOS only on the specific cases where it is necessary, making it also less likely that we need to think about minios when changing the user level. Since there are some functionality minios doesn't support (e.g. minios doesn't have a filesystem) we would probably end up replacing CLICK_USERLEVEL || CLICK_MINIOS by CLICK_USERLEVEL && !CLICK_MINIOS on different places. Also I'm not sure how to handle config-minios.h since I let in the header only the essential macros to build with minios.

It is for sure possible to rewrite this defining CLICK_USERLEVEL, if you think that's the appropriate way to do it, but I'm not sure that it would be cleaner or bring any advantage. What do you think?

[kohler]

I am convinced. I still wonder about clickos vs. minios (would be nice to
define a consistent name!). More comments later.

On Tue, Apr 15, 2014 at 11:51 AM, Filipe Manco notifications@github.comwrote:

Hey, in fact we started by define CLICK_USERLEVEL and then have special
cases to compile with minios, but there were a couple of reasons that made
me switch to this option. It looked (at least for me) cleaner to define
CLICK_MINIOS only on the specific cases where it is necessary, making it
also less likely that we need to think about minios when changing the user
level. Since there are some functionality minios doesn't support (e.g.
minios doesn't have a filesystem) we would probably end up replacing CLICK_USERLEVEL
|| CLICK_MINIOS by CLICK_USERLEVEL && !CLICK_MINIOS on different places.
Also I'm not sure how to handle config-minios.h since I let in the header
only the essential macros to build with minios.

It is for sure possible to rewrite this defining CLICK_USERLEVEL, if you
think that's the appropriate way to do it, but I'm not sure that it would
be cleaner or bring any advantage. What do you think?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/118#issuecomment-40498773
.

[jpemartins]

Just updated the pull request, regarding this matter. There was still a remnant of CLICK_OS in one of the commits.

[kohler]

Placeholder comment: I still intend to look at this in more detail.

[jpemartins]

Hi Eddie, I just updated the PR because I had a minor bug in the element handlers. Did you get a chance to get back to this in the meantime? Do you have any comments or concerns?

Thanks in advance!

[kohler]

MERGED!!! THANK YOU! Very exciting.

[jpemartins]

AWESOME! :D Thank you Eddie!