rtems-libbsd build error

[Christian Mauderer]

Am 01.04.19 um 15:29 schrieb Vijay Kumar Banerjee:

[...] (I removed some of the discussion to make it more readable)

> 
>     If you use the fb and framebuffer headers from RTEMS, you will get an
>     RTEMS interface. The RTEMS based console code will work fine. But it
>     might would be the solution where more work is necessary to port other
>     applications or libraries. It seems that we have some libs already (like
>     nano-X: https://devel.rtems.org/wiki/GSoC/2009/Wrapup) so I would be OK
>     with that.
> 
>     The other alternative would be to use the FreeBSD code that does the
>     same. I'm not sure whether they call it framebuffer or something else.
>     But I would expect that there is something similar. In that case it
>     might would be simpler to port graphics libraries that already work on
>     FreeBSD.
> 
>     Both ways could be nice. I'm really not sure which one I would prefer.
>     The first one is better integrated into the existing RTEMS ecosystem.
>     The second one promises a wider world. So either take the one that
>     interests you more or just use the one that looks simpler ;-)
> 
> I will take the 2nd path and use the codes from freebsd fb. In the
> forked branch 
> I have imported them along with the iic souce files just to make sure
> that it builds.
> I have also added the driver references in the nexus-device.h 
> I have a few questions/doubts before moving on to creating a fresh
> branch to import
> the file cleanly so that porting work can be started.
> 
> There are a lot of files that are imported and out of them some were .m
> files that 
> I built manually with the awk scripts and imported using the libbsd.py .
> It seems like those 
> will need a cleanup and will need to be added to the Makefile.todo (?) 

Most likely Makefile.todo is currently the right place. Also in long
term it should move to waf. But that's out of the scope of your project.

> 
> Will the whole thing be one big patch? or will it be done in chunks of
> the subdirectory
> like videomode headers and souce imported in one patch, fb in another ?

I think I already have made a note at your proposal: I would suggest to
split it up in smaller functional blocks. That even allows to merge
small parts during the GSoC instead of having one big block at the end.
But please note that all parts should be useful and every commit in
libbsd (and in RTEMS) must be compilable. Otherwise (useful) tools like
`git bisect` won't work.

So if you have functional groups: Split it up. If a big block is
necessary because the small parts can't work on their own: Keep it in
one import + one port commit.

> 
[...]



-- 
--------------------------------------------
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.