rfc: community developed and driven alt-sdk

[notzed]

As a preface I have had a phone convo with Andreas related to this a few weeks ago but the idea then was a bit different but I had this idea a few days ago and I would be more comfortable with this approach. This is probably not ideal as far as adapteva is concerned, ... but i'm only a customer and a hobbyist and not an investor so I have different priorities and motivations.

It's pretty clear from the current state of the sdk and it's progress that adapteva are struggling with the software side of the parallella. I suppose there are justifiable reasons but given the kickstarter it's still disappointing that it wasn't a community effort from the very beginning. The current sdk is i imagine what "embedded" developers are used to, but that's just not good enough for those who paid for the thing.

My idea is to have an "officially unofficial" Free Software and community based SDK/runtime licensed as LGPL (it might need some exception for the inline code). This would probably have to be in addition to the "official" one which would be for their user-hostile "enterprise" customers and investors who can't deal with such a license. Adapteva would have limited control and no ownership of such an sdk (but neither would they need to resource it).

TBH if an enterprise company is uncomfortable with (L)GPL licenses then that's a good thing - if they want to be part of an overpriced/underdelivering pay-as-you-go ecosystem they should expect to suffer from it and not gain any benefits from free labour which is free of such constraints. They can pay if they need it, so they should pay if they want it. Not working in the field allows me to say things like that from a comfortable position of ignorance and financial isolation.

All I would want from Adapteva are docs and already gpl code like a kernel driver and the toolchain (and some ongoing fpga improvements/features). And some sort of endorsement since some people seem to think that's important.

Obviously (for those following) I made a very big start on such a project last year with ezesdk but my goal was really just to write complex multi-core programs rather than work on an sdk itself so once it reached that point of functionality I didn't really have much else to add. I don't work in any field related to system software so my approach ignored almost everything in the current sdk, didn't consider legacy code or c++ or multi-epiphany support, and tried to fit with the hardware peculiarities using methods from long-dead operating systems from pre-mmu days. I think it's better for it and would be the baseline to start with as far as i'm concerned.

Given this is 100% a hobby for me i'd need some personal motivation before I would spend much time on it let along start using a bug system or even git, ... although i'm not sure what that motivation would be. I have a lot of time, plenty of experience, but not much patience anymore (particularly for 'user support').

But to start:

1. Are other customers interested in this?
2. Are any other developers interested in working on such a thing? (experienced or otherwise)
3. What does adapteva think?

I don't really have a roadmap but i've some ideas about the end goal.

I guess if not i'll just stick to ezesdk and the fickleness of my own interest in it. Which is very fickle and waning.

[piotr5]

I'm not interested in an alternative sdk. what I would like is if epiphany would be natively supported by linux, in the way framebuffer or other graphics acceleration are supported. i.e. kernel should manage epiphany in the same way it does manage arm -- just seperately -- so that you can take a pthread program, compile it with egcc and get a program ready to be uploaded to eCores, by the kernel. similarily memory-management should be done by kernel and compiler, not some sdk!

but for sdk, it would be nice if an implementation for c++ could be written. there are some nice ideas implemented in boost, but they work only with pthread, not epiphany! for that again no alternative sdk is needed, just wrap current implementation in c++ objects and template-classes...

also, I don't understand what is meant with sdk not being a public effort. isn't sdk in git and thereby anyone working on it could make a pull-request?

[aolofsson]

[9600]

[notzed]

9600: It's "enterprise" friendly because adapteva own the copyrights and can relicense it without gpl which companies like Ericsson are allergic to. adapteva don't want to manage copyright assignment (and most people don't like that anyway) so the only way to get community involvement and to maintain this ability is to license it using apache or bsd or something "enterprise friendly". This is what andreas told me directly, over the phone. He was going to announce something weeks ago about opening up development but never did so I guess he just changed his mind.

[aolofsson]

Awkward....

...announcement coming.

Andreas