[Xenomai] __COBALT_SYSCALL_BIT

[Xenomai] __COBALT_SYSCALL_BIT

[Julien Stephan]

Hello,

Is it safe to change __COBALT_SYSCALL_BIT from 0x10000000 to 0x700 ?
Or it may broke some xenomai functionnalities?

I need to do that, because the ISA of my architecture specifies that the
scall number should be on 12 bits... It is not compiling otherwise..

Julien
-- 
 
Logo <http://www.smile.fr/>

14 rue Génissieu
38000 GRENOBLE
www.smile.fr <http://www.smile.fr/> 	
*Julien STEPHAN*
Ingénieur étude et développement
Email : julien.stephan@smile.fr <mailto:julien.stephan@smile.fr>
Tel : +33 (0)4.58.00.19.59

 

bandeaux_mail
<http://www.smile.fr/Ressources/Livres-blancs/Ingenierie/Linux-pour-l-embarque?utm_source=signature&utm_medium=email&utm_campaign=signature>

eco Pour la planète, n'imprimez ce mail que si c'est nécessaire

Re: [Xenomai] __COBALT_SYSCALL_BIT

[Philippe Gerum]

On 12/20/2016 11:12 AM, Julien Stephan wrote:
> Hello,
> 
> Is it safe to change __COBALT_SYSCALL_BIT from 0x10000000 to 0x700 ?
> Or it may broke some xenomai functionnalities?
> 
> I need to do that, because the ISA of my architecture specifies that the
> scall number should be on 12 bits... It is not compiling otherwise..
> 

I still don't know which architecture you are talking about, so I can't
answer questions about porting Xenomai to it.

-- 
Philippe.

Re: [Xenomai] __COBALT_SYSCALL_BIT

[Julien Stephan]

I'm porting Xenomai on the MPPA processor of Kalray. The problem is that
their Linux port is quite new and is not yet publicly available ...


On 20/12/2016 12:23, Philippe Gerum wrote:
> On 12/20/2016 11:12 AM, Julien Stephan wrote:
>> Hello,
>>
>> Is it safe to change __COBALT_SYSCALL_BIT from 0x10000000 to 0x700 ?
>> Or it may broke some xenomai functionnalities?
>>
>> I need to do that, because the ISA of my architecture specifies that the
>> scall number should be on 12 bits... It is not compiling otherwise..
>>
> I still don't know which architecture you are talking about, so I can't
> answer questions about porting Xenomai to it.
>

-- 
 
Logo <http://www.smile.fr/>

14 rue Génissieu
38000 GRENOBLE
www.smile.fr <http://www.smile.fr/> 	
*Julien STEPHAN*
Ingénieur étude et développement
Email : julien.stephan@smile.fr <mailto:julien.stephan@smile.fr>
Tel : +33 (0)4.58.00.19.59

 

bandeaux_mail
<http://www.smile.fr/Ressources/Livres-blancs/Ingenierie/Linux-pour-l-embarque?utm_source=signature&utm_medium=email&utm_campaign=signature>

eco Pour la planète, n'imprimez ce mail que si c'est nécessaire

Re: [Xenomai] __COBALT_SYSCALL_BIT

[Lennart Sorensen]

On Tue, Dec 20, 2016 at 01:36:44PM +0100, Julien Stephan wrote:
> I'm porting Xenomai on the MPPA processor of Kalray. The problem is that
> their Linux port is quite new and is not yet publicly available ...

Well that would easily be fixed if someone with the GPL code decided to
share it.  The license clearly says you can and that no other restrictions
are allowed to be impossed on the code.

I had never heard of this one before, although looking at their website,
I don't have much hope.  I don't think we need another architecture, which
means yet another architecture to support in the kernel, glibc, gcc, not
to mention all the stupid runtimes that need architecture specific code
(hard enough to get those to support existing popular architectures).
And when I see VLIW for a general purpose CPU, I can only think "doomed".
It never worked before, and I don't believe it ever will.  But maybe
they don't actually mean VLIW in the traditional sense.  Or maybe it is
just intel that can't make it work.

The design looks an awful lot like the tilera tile chips, which are also
lots of cores in a big mesh with lots of fast IO and VLIW.  Not sure
they have had much success yet.

Well we will see what happens.

-- 
Len Sorensen

Re: [Xenomai] __COBALT_SYSCALL_BIT

[Julien Stephan]

On 20/12/2016 15:36, Lennart Sorensen wrote:
> On Tue, Dec 20, 2016 at 01:36:44PM +0100, Julien Stephan wrote:
>> I'm porting Xenomai on the MPPA processor of Kalray. The problem is that
>> their Linux port is quite new and is not yet publicly available ...
> Well that would easily be fixed if someone with the GPL code decided to
> share it.  The license clearly says you can and that no other restrictions
> are allowed to be impossed on the code.
Excuse me for my poor english: "not yet" may be confusing... I meant
"not currently"
> I had never heard of this one before, although looking at their website,
> I don't have much hope.  I don't think we need another architecture, which
> means yet another architecture to support in the kernel, glibc, gcc, not
> to mention all the stupid runtimes that need architecture specific code
> (hard enough to get those to support existing popular architectures).
> And when I see VLIW for a general purpose CPU, I can only think "doomed".
> It never worked before, and I don't believe it ever will.  But maybe
> they don't actually mean VLIW in the traditional sense.  Or maybe it is
> just intel that can't make it work.
>
> The design looks an awful lot like the tilera tile chips, which are also
> lots of cores in a big mesh with lots of fast IO and VLIW.  Not sure
> they have had much success yet.
>
> Well we will see what happens.
>
>

Well, thank you for your poor answer, but if you cannot help me, just
don't.

So my question was completely architecture independent. I wanted to know
if changing the __COBALT_SYSCALL_BIT from  0x10000000 to 0x700 was safe.
I mean, maybe some part of xenomai code really need it at 0x10000000.

So anyone that know xenomai better than me can answer it?

Thank you in advance
Julien
-- 
 
Logo <http://www.smile.fr/>

14 rue Génissieu
38000 GRENOBLE
www.smile.fr <http://www.smile.fr/> 	
*Julien STEPHAN*
Ingénieur étude et développement
Email : julien.stephan@smile.fr <mailto:julien.stephan@smile.fr>
Tel : +33 (0)4.58.00.19.59

 

bandeaux_mail
<http://www.smile.fr/Ressources/Livres-blancs/Ingenierie/Linux-pour-l-embarque?utm_source=signature&utm_medium=email&utm_campaign=signature>

eco Pour la planète, n'imprimez ce mail que si c'est nécessaire

Re: [Xenomai] __COBALT_SYSCALL_BIT

[Philippe Gerum]

On 12/20/2016 01:36 PM, Julien Stephan wrote:
> I'm porting Xenomai on the MPPA processor of Kalray. The problem is that
> their Linux port is quite new and is not yet publicly available ...

This company presented an ongoing effort to port Linux to their MPPA
processor back in October 2013. This hardly qualifies as a "new" effort:
http://events.linuxfoundation.org/sites/events/files/slides/Rybczynska_Going_Linux_on_Massive_Multicore.pdf

Such Linux code not being publicly available after three years may be
interpreted as an obvious unwillingness to ever disclose it.

Therefore, the whole point of any technical discussion about your
project on this public list would be about asking people to help your
company delivering a development task to a customer, for your company's
and its customer's exclusive advantage, but strictly no upside for the
Xenomai user base.

As a matter of fact, nothing that could be discussed there regarding
your project would be beneficial for the Xenomai users and contributors
(Linux likewise), since none of them may ever have access to the
resulting work, or learn from it for their own present or future
projects. What might be the incentive for these people to help you with
such port then, why would they care?

I do understand that, as an engineer, you merely inherited the situation
and did not create it, taking the flak for those who did. That is
unfortunate, and I want to make clear that this is nothing personal.
However, despite Xmas time approaching, I don't believe in Santa: such
situation can't bring anything useful to the Xenomai project, but only
chasing wild gooses about a secretive processor running undisclosed code.

I'd be glad to be proven wrong though, but until this is demonstrated,
I'll stay away from this discussion.

-- 
Philippe.