[Xenomai-core] [PULL REQUEST] fixes for 2.5.4

[Xenomai-core] [PULL REQUEST] fixes for 2.5.4

[Philippe Gerum]

This series is mainly about fixing the shared heap management for nommu,
and introducing a way to break out from syscall-less runaway loops, in
primary mode.

Regarding the shared heaps, we have no choice but break the 2.5.x ABI
for blackfin and nios2 for fixing them, but for a good reason: they just
could not work on any earlier release.

Recovery from runaway loops in primary mode is introduced by the mayday
patch series; the faulty thread gets relaxed, instead of being killed,
when the nucleus watchdog triggers.

Gilles, please merge.

      uitron: fix wait flag helper
      hal/generic: always track switch to foreign stack
      compat: provide linux/err.h wrapper to linux/fs.h
      nucleus: silence deprecated warnings on __builtin_expect for old compilers
      rtai: mark as deprecated
      skins: sanitize heap binding
      build: check for CONFIG_MMU in user-space
      nucleus: fix heap mapping for nommu
      wrappers: no need to reserve pages passed to vm_insert_page
      x86: upgrade I-pipe support to 2.6.32.15-x86-2.7-00, 2.6.34-x86-2.7-00
      powerpc: upgrade I-pipe support to 2.6.33.5-powerpc-2.10-01, 2.6.34-powerpc-2.10-00
      x86: upgrade I-pipe support to 2.6.32.15-x86-2.7-00, 2.6.34-x86-2.7-00
      arm: upgrade I-pipe support to 2.6.33-arm-1.17-00
      blackfin: upgrade I-pipe support to 2.6.34-blackfin-1.14-00
      nucleus: introduce generic bits for MAYDAY support
      powerpc: enable MAYDAY support
      x86: enable MAYDAY support
      arm: enable MAYDAY support
      blackfin: enable MAYDAY support
      nios2: enable MAYDAY support
      arm: upgrade I-pipe support to 2.6.33-arm-1.17-01
      blackfin: upgrade I-pipe support to 2.6.34-blackfin-1.14-01
      powerpc: upgrade I-pipe support to 2.6.33.5-powerpc-2.10-02, 2.6.34-powerpc-2.10-01
      x86: upgrade I-pipe support to 2.6.32.15-x86-2.7-01, 2.6.34-x86-2.7-01
      common: warn early about missing /dev/rtheap
      nucleus: fix uninit variable
      nios2: upgrade I-pipe support to 2.6.30-nios2-1.2-00
      rtai: disable for MMU-less and 64bit builds
      rtdm: fix memory mapping services for nommu platforms
      powerpc: upgrade I-pipe support to 2.6.34-powerpc-2.10-02
      x86: upgrade I-pipe support to 2.6.34-x86-2.7-02
      blackfin: upgrade I-pipe support to 2.6.34-blackfin-1.14-02
      powerpc: upgrade I-pipe support to 2.6.34-powerpc-2.10-02

-- 
Philippe.

Re: [Xenomai-core] [PULL REQUEST] fixes for 2.5.4

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> This series is mainly about fixing the shared heap management for nommu,
> and introducing a way to break out from syscall-less runaway loops, in
> primary mode.
> 
> Regarding the shared heaps, we have no choice but break the 2.5.x ABI
> for blackfin and nios2 for fixing them, but for a good reason: they just
> could not work on any earlier release.
> 
> Recovery from runaway loops in primary mode is introduced by the mayday
> patch series; the faulty thread gets relaxed, instead of being killed,
> when the nucleus watchdog triggers.
> 
> Gilles, please merge.

Merged, thanks (a bit rebased though).

-- 
					    Gilles.

Re: [Xenomai-help] [Xenomai-core] [PULL REQUEST] fixes for 2.5.4

[Tschaeche IT-Services]

On Fri, Jun 18, 2010 at 07:03:51PM +0200, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > Recovery from runaway loops in primary mode is introduced by the mayday
> > patch series; the faulty thread gets relaxed, instead of being killed,
> > when the nucleus watchdog triggers.

just adapted to Xenomai 2.5.4 with a simple patch,
exporting the xnshadow_call_mayday() symbol from nucleus,
so that we can call it from our watchdog driver.

Should we call xnshadow_call_mayday() in another (official) way?

Regards,

	Olli

Re: [Xenomai-help] [Xenomai-core] [PULL REQUEST] fixes for 2.5.4

[Philippe Gerum]

On Thu, 2010-08-05 at 14:58 +0200, Tschaeche IT-Services wrote:
> On Fri, Jun 18, 2010 at 07:03:51PM +0200, Gilles Chanteperdrix wrote:
> > Philippe Gerum wrote:
> > > Recovery from runaway loops in primary mode is introduced by the mayday
> > > patch series; the faulty thread gets relaxed, instead of being killed,
> > > when the nucleus watchdog triggers.
> 
> just adapted to Xenomai 2.5.4 with a simple patch,
> exporting the xnshadow_call_mayday() symbol from nucleus,
> so that we can call it from our watchdog driver.
> 
> Should we call xnshadow_call_mayday() in another (official) way?

xnshadow_call_mayday() is already exported to modules in 2.5.4.

> 
> Regards,
> 
> 	Olli

-- 
Philippe.

Re: [Xenomai-help] [Xenomai-core] [PULL REQUEST] fixes for 2.5.4

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> On Thu, 2010-08-05 at 14:58 +0200, Tschaeche IT-Services wrote:
>> On Fri, Jun 18, 2010 at 07:03:51PM +0200, Gilles Chanteperdrix wrote:
>>> Philippe Gerum wrote:
>>>> Recovery from runaway loops in primary mode is introduced by the mayday
>>>> patch series; the faulty thread gets relaxed, instead of being killed,
>>>> when the nucleus watchdog triggers.
>> just adapted to Xenomai 2.5.4 with a simple patch,
>> exporting the xnshadow_call_mayday() symbol from nucleus,
>> so that we can call it from our watchdog driver.
>>
>> Should we call xnshadow_call_mayday() in another (official) way?
> 
> xnshadow_call_mayday() is already exported to modules in 2.5.4.

It is exported to GPL modules, maybe that is the issue?

-- 
					    Gilles.

Re: [Xenomai-help] [Xenomai-core] [PULL REQUEST] fixes for 2.5.4

[Tschaeche IT-Services]

On Thu, Aug 05, 2010 at 04:15:27PM +0200, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Thu, 2010-08-05 at 14:58 +0200, Tschaeche IT-Services wrote:
> >> On Fri, Jun 18, 2010 at 07:03:51PM +0200, Gilles Chanteperdrix wrote:
> >>> Philippe Gerum wrote:
> >>>> Recovery from runaway loops in primary mode is introduced by the mayday
> >>>> patch series; the faulty thread gets relaxed, instead of being killed,
> >>>> when the nucleus watchdog triggers.
> >> just adapted to Xenomai 2.5.4 with a simple patch,
> >> exporting the xnshadow_call_mayday() symbol from nucleus,
> >> so that we can call it from our watchdog driver.
> >>
> >> Should we call xnshadow_call_mayday() in another (official) way?
> > 
> > xnshadow_call_mayday() is already exported to modules in 2.5.4.
> 
> It is exported to GPL modules, maybe that is the issue?

yes. EXPORT_SYMBOL_GPL requires the callee to be GPL too, right?
may we GPL patch kernel/xenomai/skin/native/task.c with something like:

	int rt_task_shadow_mayday(RTASK *t)
	{
		return xnshadow_call_mayday(t->thread_base, WATCHDOG_SIGXCPU);
	}
	EXPORT_SYMBOL(rt_task_shadow_mayday)

Native API does not require GPL callees. BTW: why are there different licenses?

did not clarify yet, if our driver code may be open source.
i think, it would be appreciated if not.

thx,

	Olli

Re: [Xenomai-help] [Xenomai-core] [PULL REQUEST] fixes for 2.5.4

[Philippe Gerum]

On Thu, 2010-08-05 at 17:19 +0200, Tschaeche IT-Services wrote:
> On Thu, Aug 05, 2010 at 04:15:27PM +0200, Gilles Chanteperdrix wrote:
> > Philippe Gerum wrote:
> > > On Thu, 2010-08-05 at 14:58 +0200, Tschaeche IT-Services wrote:
> > >> On Fri, Jun 18, 2010 at 07:03:51PM +0200, Gilles Chanteperdrix wrote:
> > >>> Philippe Gerum wrote:
> > >>>> Recovery from runaway loops in primary mode is introduced by the mayday
> > >>>> patch series; the faulty thread gets relaxed, instead of being killed,
> > >>>> when the nucleus watchdog triggers.
> > >> just adapted to Xenomai 2.5.4 with a simple patch,
> > >> exporting the xnshadow_call_mayday() symbol from nucleus,
> > >> so that we can call it from our watchdog driver.
> > >>
> > >> Should we call xnshadow_call_mayday() in another (official) way?
> > > 
> > > xnshadow_call_mayday() is already exported to modules in 2.5.4.
> > 
> > It is exported to GPL modules, maybe that is the issue?
> 
> yes. EXPORT_SYMBOL_GPL requires the callee to be GPL too, right?

It's a strong hint to tell users that the intent of the author of that
code is to provide such service to GPL code. Any other use leaves the
user on his own, with respect to the interpretation of the kernel
license.

> may we GPL patch kernel/xenomai/skin/native/task.c with something like:
> 
> 	int rt_task_shadow_mayday(RTASK *t)
> 	{
> 		return xnshadow_call_mayday(t->thread_base, WATCHDOG_SIGXCPU);
> 	}
> 	EXPORT_SYMBOL(rt_task_shadow_mayday)
> 
> Native API does not require GPL callees.
> BTW: why are there different licenses?
> 

Why do you see different licenses? The nucleus is GPL, as is GPL each
and every bit of the Xenomai kernel code. Only userland libs are LGPL.

The decision to give the EXPORT_GPL hint now to in-kernel users is
precisely there to make this even more clear, and I will extend this to
all in-kernel interfaces in Xenomai 2.6. The reason why I did not push
this change to the 2.5.x series is because some legacy Xenomai-based
apps implemented as non-GPL kernel modules might qualify for the "gray
area" set, as described in this post:
http://marc.info/?l=linux-kernel&m=107049625920022&w=2

However, the days when using a dual-kernel system meant running
application code to kernel land are long gone; we did work quite hard to
provide flexibility, reliability and good performances in userland over
time. Therefore, Xenomai 2.6 will strongly advise users to run
applications in user-space only, and Xenomai 3.x won't export any kernel
space API to kernel-based applications at all (Of course, RTDM will
still export an API to build drivers, and to interface with other
drivers).

If the issue is about driver code, and not application code, then it is
even simpler: driving peripherals is part of the Linux kernel
business's, so the GPL rules. If, for any valid or paranoid reason, some
of the code driving the peripheral could not be disclosed, then there
are options to move it partly or entirely to userland where LGPL
applies, even if that may not be the best technical approach.

The bottom line for the Xenomai licensing policy is quite
straightforward:

- We built our house on the foundations passed on by others, they gave
us the Linux kernel code, we do abide by their license because we are
part of their kernel, so our kernel-based code is licensed under the
terms of the Linux kernel license. People who want to interpret that
license to fit their licensing requirements are on their own. We did not
invent the license, we are simply using it and passing it on our own
users.

- In userland, we provide LGPL interfaces to applications to call our
real-time nucleus services, the same way the glibc provides LGPL
interfaces to applications to call standard Linux services.

> did not clarify yet, if our driver code may be open source.
> i think, it would be appreciated if not.
> 

We can't help in this area, we simply provide some code under a given
license. Whether the license fits your requirements depends on your
assessment of the situation only.

> thx,
> 
> 	Olli
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

-- 
Philippe.

Re: [Xenomai-help] [Xenomai-core] [PULL REQUEST] fixes for 2.5.4

[Tschaeche IT-Services]

On Thu, Aug 05, 2010 at 06:51:37PM +0200, Philippe Gerum wrote:
> Why do you see different licenses? The nucleus is GPL, as is GPL each
> and every bit of the Xenomai kernel code. Only userland libs are LGPL.
> 
> The decision to give the EXPORT_GPL hint now to in-kernel users is
> precisely there to make this even more clear, and I will extend this to
> all in-kernel interfaces in Xenomai 2.6. The reason why I did not push
> this change to the 2.5.x series is because some legacy Xenomai-based
> apps implemented as non-GPL kernel modules might qualify for the "gray
> area" set, as described in this post:
> http://marc.info/?l=linux-kernel&m=107049625920022&w=2
> 
> However, the days when using a dual-kernel system meant running
> application code to kernel land are long gone; we did work quite hard to
> provide flexibility, reliability and good performances in userland over
> time. Therefore, Xenomai 2.6 will strongly advise users to run
> applications in user-space only, and Xenomai 3.x won't export any kernel
> space API to kernel-based applications at all (Of course, RTDM will
> still export an API to build drivers, and to interface with other
> drivers).
> 
> If the issue is about driver code, and not application code, then it is
> even simpler: driving peripherals is part of the Linux kernel
> business's, so the GPL rules. If, for any valid or paranoid reason, some
> of the code driving the peripheral could not be disclosed, then there
> are options to move it partly or entirely to userland where LGPL
> applies, even if that may not be the best technical approach.
> 
> The bottom line for the Xenomai licensing policy is quite
> straightforward:
> 
> - We built our house on the foundations passed on by others, they gave
> us the Linux kernel code, we do abide by their license because we are
> part of their kernel, so our kernel-based code is licensed under the
> terms of the Linux kernel license. People who want to interpret that
> license to fit their licensing requirements are on their own. We did not
> invent the license, we are simply using it and passing it on our own
> users.
> 
> - In userland, we provide LGPL interfaces to applications to call our
> real-time nucleus services, the same way the glibc provides LGPL
> interfaces to applications to call standard Linux services.
> 
> > did not clarify yet, if our driver code may be open source.
> > i think, it would be appreciated if not.
> > 
> 
> We can't help in this area, we simply provide some code under a given
> license. Whether the license fits your requirements depends on your
> assessment of the situation only.

personally i would like GPL used in projects, but companies are afraid
of loosing their intellectual property. Thus, i, in the role of the
consultant, have to find a solution, which you already explained:
move the IP into user space and keep the GPLed module/driver part IP free.

thank you for your detailed explanation,

	Olli

Re: [Xenomai-help] [Xenomai-core] [PULL REQUEST] fixes for 2.5.4

[Philippe Gerum]

On Fri, 2010-08-06 at 11:43 +0200, Tschaeche IT-Services wrote:
> On Thu, Aug 05, 2010 at 06:51:37PM +0200, Philippe Gerum wrote:
> > Why do you see different licenses? The nucleus is GPL, as is GPL each
> > and every bit of the Xenomai kernel code. Only userland libs are LGPL.
> > 
> > The decision to give the EXPORT_GPL hint now to in-kernel users is
> > precisely there to make this even more clear, and I will extend this to
> > all in-kernel interfaces in Xenomai 2.6. The reason why I did not push
> > this change to the 2.5.x series is because some legacy Xenomai-based
> > apps implemented as non-GPL kernel modules might qualify for the "gray
> > area" set, as described in this post:
> > http://marc.info/?l=linux-kernel&m=107049625920022&w=2
> > 
> > However, the days when using a dual-kernel system meant running
> > application code to kernel land are long gone; we did work quite hard to
> > provide flexibility, reliability and good performances in userland over
> > time. Therefore, Xenomai 2.6 will strongly advise users to run
> > applications in user-space only, and Xenomai 3.x won't export any kernel
> > space API to kernel-based applications at all (Of course, RTDM will
> > still export an API to build drivers, and to interface with other
> > drivers).
> > 
> > If the issue is about driver code, and not application code, then it is
> > even simpler: driving peripherals is part of the Linux kernel
> > business's, so the GPL rules. If, for any valid or paranoid reason, some
> > of the code driving the peripheral could not be disclosed, then there
> > are options to move it partly or entirely to userland where LGPL
> > applies, even if that may not be the best technical approach.
> > 
> > The bottom line for the Xenomai licensing policy is quite
> > straightforward:
> > 
> > - We built our house on the foundations passed on by others, they gave
> > us the Linux kernel code, we do abide by their license because we are
> > part of their kernel, so our kernel-based code is licensed under the
> > terms of the Linux kernel license. People who want to interpret that
> > license to fit their licensing requirements are on their own. We did not
> > invent the license, we are simply using it and passing it on our own
> > users.
> > 
> > - In userland, we provide LGPL interfaces to applications to call our
> > real-time nucleus services, the same way the glibc provides LGPL
> > interfaces to applications to call standard Linux services.
> > 
> > > did not clarify yet, if our driver code may be open source.
> > > i think, it would be appreciated if not.
> > > 
> > 
> > We can't help in this area, we simply provide some code under a given
> > license. Whether the license fits your requirements depends on your
> > assessment of the situation only.
> 
> personally i would like GPL used in projects, but companies are afraid
> of loosing their intellectual property. Thus, i, in the role of the
> consultant, have to find a solution, which you already explained:
> move the IP into user space and keep the GPLed module/driver part IP free.

Whatever split between kernel/userland support you may want to implement
to solve this issue, I would strongly recommend to keep the interrupt
handling in the RTDM-based kernel driver, including the device request
acknowledgement part.

Moving this code to userland would require the thread in charge to
always be runnable, so that you don't get either an interrupt flood, or
a device collapse because the interrupt handling is either significantly
delayed or even stopped. It turns out that such requirement would
prevent you from using GDB over the process including the interrupt
handling code, since GDB eagerly stops all threads for single-stepping.
Of course you could implement the interrupt server outside of the main
application process, but this would lead to an overly complex design,
IMO.

In short, keep away from the RT_INTR services. They are wrong by design
for practical reasons - but I noticed it too late, after I implemented
and published them.

> 
> thank you for your detailed explanation,
> 
> 	Olli

-- 
Philippe.

Re: [Xenomai-help] [Xenomai-core] [PULL REQUEST] fixes for 2.5.4

[Peter Soetens]

On Fri, Aug 6, 2010 at 12:43 PM, Philippe Gerum <rpm@xenomai.org> wrote:
> On Fri, 2010-08-06 at 11:43 +0200, Tschaeche IT-Services wrote:
>> On Thu, Aug 05, 2010 at 06:51:37PM +0200, Philippe Gerum wrote:
>> > Why do you see different licenses? The nucleus is GPL, as is GPL each
>> > and every bit of the Xenomai kernel code. Only userland libs are LGPL.
>> >
>> > The decision to give the EXPORT_GPL hint now to in-kernel users is
>> > precisely there to make this even more clear, and I will extend this to
>> > all in-kernel interfaces in Xenomai 2.6. The reason why I did not push
>> > this change to the 2.5.x series is because some legacy Xenomai-based
>> > apps implemented as non-GPL kernel modules might qualify for the "gray
>> > area" set, as described in this post:
>> > http://marc.info/?l=linux-kernel&m=107049625920022&w=2
>> >
>> > However, the days when using a dual-kernel system meant running
>> > application code to kernel land are long gone; we did work quite hard to
>> > provide flexibility, reliability and good performances in userland over
>> > time. Therefore, Xenomai 2.6 will strongly advise users to run
>> > applications in user-space only, and Xenomai 3.x won't export any kernel
>> > space API to kernel-based applications at all (Of course, RTDM will
>> > still export an API to build drivers, and to interface with other
>> > drivers).
>> >
>> > If the issue is about driver code, and not application code, then it is
>> > even simpler: driving peripherals is part of the Linux kernel
>> > business's, so the GPL rules. If, for any valid or paranoid reason, some
>> > of the code driving the peripheral could not be disclosed, then there
>> > are options to move it partly or entirely to userland where LGPL
>> > applies, even if that may not be the best technical approach.
>> >
>> > The bottom line for the Xenomai licensing policy is quite
>> > straightforward:
>> >
>> > - We built our house on the foundations passed on by others, they gave
>> > us the Linux kernel code, we do abide by their license because we are
>> > part of their kernel, so our kernel-based code is licensed under the
>> > terms of the Linux kernel license. People who want to interpret that
>> > license to fit their licensing requirements are on their own. We did not
>> > invent the license, we are simply using it and passing it on our own
>> > users.
>> >
>> > - In userland, we provide LGPL interfaces to applications to call our
>> > real-time nucleus services, the same way the glibc provides LGPL
>> > interfaces to applications to call standard Linux services.
>> >
>> > > did not clarify yet, if our driver code may be open source.
>> > > i think, it would be appreciated if not.
>> > >
>> >
>> > We can't help in this area, we simply provide some code under a given
>> > license. Whether the license fits your requirements depends on your
>> > assessment of the situation only.
>>
>> personally i would like GPL used in projects, but companies are afraid
>> of loosing their intellectual property. Thus, i, in the role of the
>> consultant, have to find a solution, which you already explained:
>> move the IP into user space and keep the GPLed module/driver part IP free.
>
> Whatever split between kernel/userland support you may want to implement
> to solve this issue, I would strongly recommend to keep the interrupt
> handling in the RTDM-based kernel driver, including the device request
> acknowledgement part.
>
> Moving this code to userland would require the thread in charge to
> always be runnable, so that you don't get either an interrupt flood, or
> a device collapse because the interrupt handling is either significantly
> delayed or even stopped. It turns out that such requirement would
> prevent you from using GDB over the process including the interrupt
> handling code, since GDB eagerly stops all threads for single-stepping.

Sorry for the off-topic nitpicking, but GDB 7 supports one-thread-stop/stepping.
This doesn't in any way shed a different light on Philippe's arguments.
It's just removing a nit. On a saturday night. While everyone's sleeping.

Peter

Re: [Xenomai-help] [Xenomai-core] [PULL REQUEST] fixes for 2.5.4

[Philippe Gerum]

On Sun, 2010-08-08 at 00:08 +0200, Peter Soetens wrote:
> On Fri, Aug 6, 2010 at 12:43 PM, Philippe Gerum <rpm@xenomai.org> wrote:
> > On Fri, 2010-08-06 at 11:43 +0200, Tschaeche IT-Services wrote:
> >> On Thu, Aug 05, 2010 at 06:51:37PM +0200, Philippe Gerum wrote:
> >> > Why do you see different licenses? The nucleus is GPL, as is GPL each
> >> > and every bit of the Xenomai kernel code. Only userland libs are LGPL.
> >> >
> >> > The decision to give the EXPORT_GPL hint now to in-kernel users is
> >> > precisely there to make this even more clear, and I will extend this to
> >> > all in-kernel interfaces in Xenomai 2.6. The reason why I did not push
> >> > this change to the 2.5.x series is because some legacy Xenomai-based
> >> > apps implemented as non-GPL kernel modules might qualify for the "gray
> >> > area" set, as described in this post:
> >> > http://marc.info/?l=linux-kernel&m=107049625920022&w=2
> >> >
> >> > However, the days when using a dual-kernel system meant running
> >> > application code to kernel land are long gone; we did work quite hard to
> >> > provide flexibility, reliability and good performances in userland over
> >> > time. Therefore, Xenomai 2.6 will strongly advise users to run
> >> > applications in user-space only, and Xenomai 3.x won't export any kernel
> >> > space API to kernel-based applications at all (Of course, RTDM will
> >> > still export an API to build drivers, and to interface with other
> >> > drivers).
> >> >
> >> > If the issue is about driver code, and not application code, then it is
> >> > even simpler: driving peripherals is part of the Linux kernel
> >> > business's, so the GPL rules. If, for any valid or paranoid reason, some
> >> > of the code driving the peripheral could not be disclosed, then there
> >> > are options to move it partly or entirely to userland where LGPL
> >> > applies, even if that may not be the best technical approach.
> >> >
> >> > The bottom line for the Xenomai licensing policy is quite
> >> > straightforward:
> >> >
> >> > - We built our house on the foundations passed on by others, they gave
> >> > us the Linux kernel code, we do abide by their license because we are
> >> > part of their kernel, so our kernel-based code is licensed under the
> >> > terms of the Linux kernel license. People who want to interpret that
> >> > license to fit their licensing requirements are on their own. We did not
> >> > invent the license, we are simply using it and passing it on our own
> >> > users.
> >> >
> >> > - In userland, we provide LGPL interfaces to applications to call our
> >> > real-time nucleus services, the same way the glibc provides LGPL
> >> > interfaces to applications to call standard Linux services.
> >> >
> >> > > did not clarify yet, if our driver code may be open source.
> >> > > i think, it would be appreciated if not.
> >> > >
> >> >
> >> > We can't help in this area, we simply provide some code under a given
> >> > license. Whether the license fits your requirements depends on your
> >> > assessment of the situation only.
> >>
> >> personally i would like GPL used in projects, but companies are afraid
> >> of loosing their intellectual property. Thus, i, in the role of the
> >> consultant, have to find a solution, which you already explained:
> >> move the IP into user space and keep the GPLed module/driver part IP free.
> >
> > Whatever split between kernel/userland support you may want to implement
> > to solve this issue, I would strongly recommend to keep the interrupt
> > handling in the RTDM-based kernel driver, including the device request
> > acknowledgement part.
> >
> > Moving this code to userland would require the thread in charge to
> > always be runnable, so that you don't get either an interrupt flood, or
> > a device collapse because the interrupt handling is either significantly
> > delayed or even stopped. It turns out that such requirement would
> > prevent you from using GDB over the process including the interrupt
> > handling code, since GDB eagerly stops all threads for single-stepping.
> 
> Sorry for the off-topic nitpicking, but GDB 7 supports one-thread-stop/stepping.
> This doesn't in any way shed a different light on Philippe's arguments.
> It's just removing a nit. On a saturday night. While everyone's sleeping.

Is non-stop debugging available for anything else than x86 these days?

> 
> Peter

-- 
Philippe.

Re: [Xenomai-help] [Xenomai-core] [PULL REQUEST] fixes for 2.5.4

[Peter Soetens]

On Sunday 08 August 2010 10:50:38 Philippe Gerum wrote:
> On Sun, 2010-08-08 at 00:08 +0200, Peter Soetens wrote:
> > On Fri, Aug 6, 2010 at 12:43 PM, Philippe Gerum <rpm@xenomai.org> wrote:
> > > On Fri, 2010-08-06 at 11:43 +0200, Tschaeche IT-Services wrote:
> > >> On Thu, Aug 05, 2010 at 06:51:37PM +0200, Philippe Gerum wrote:
> > >> > Why do you see different licenses? The nucleus is GPL, as is GPL
> > >> > each and every bit of the Xenomai kernel code. Only userland libs
> > >> > are LGPL.
> > >> >
> > >> > The decision to give the EXPORT_GPL hint now to in-kernel users is
> > >> > precisely there to make this even more clear, and I will extend this
> > >> > to all in-kernel interfaces in Xenomai 2.6. The reason why I did not
> > >> > push this change to the 2.5.x series is because some legacy
> > >> > Xenomai-based apps implemented as non-GPL kernel modules might
> > >> > qualify for the "gray area" set, as described in this post:
> > >> > http://marc.info/?l=linux-kernel&m=107049625920022&w=2
> > >> >
> > >> > However, the days when using a dual-kernel system meant running
> > >> > application code to kernel land are long gone; we did work quite
> > >> > hard to provide flexibility, reliability and good performances in
> > >> > userland over time. Therefore, Xenomai 2.6 will strongly advise
> > >> > users to run applications in user-space only, and Xenomai 3.x won't
> > >> > export any kernel space API to kernel-based applications at all (Of
> > >> > course, RTDM will still export an API to build drivers, and to
> > >> > interface with other drivers).
> > >> >
> > >> > If the issue is about driver code, and not application code, then it
> > >> > is even simpler: driving peripherals is part of the Linux kernel
> > >> > business's, so the GPL rules. If, for any valid or paranoid reason,
> > >> > some of the code driving the peripheral could not be disclosed, then
> > >> > there are options to move it partly or entirely to userland where
> > >> > LGPL applies, even if that may not be the best technical approach.
> > >> >
> > >> > The bottom line for the Xenomai licensing policy is quite
> > >> > straightforward:
> > >> >
> > >> > - We built our house on the foundations passed on by others, they
> > >> > gave us the Linux kernel code, we do abide by their license because
> > >> > we are part of their kernel, so our kernel-based code is licensed
> > >> > under the terms of the Linux kernel license. People who want to
> > >> > interpret that license to fit their licensing requirements are on
> > >> > their own. We did not invent the license, we are simply using it and
> > >> > passing it on our own users.
> > >> >
> > >> > - In userland, we provide LGPL interfaces to applications to call
> > >> > our real-time nucleus services, the same way the glibc provides LGPL
> > >> > interfaces to applications to call standard Linux services.
> > >> >
> > >> > > did not clarify yet, if our driver code may be open source.
> > >> > > i think, it would be appreciated if not.
> > >> >
> > >> > We can't help in this area, we simply provide some code under a
> > >> > given license. Whether the license fits your requirements depends on
> > >> > your assessment of the situation only.
> > >>
> > >> personally i would like GPL used in projects, but companies are afraid
> > >> of loosing their intellectual property. Thus, i, in the role of the
> > >> consultant, have to find a solution, which you already explained:
> > >> move the IP into user space and keep the GPLed module/driver part IP
> > >> free.
> > >
> > > Whatever split between kernel/userland support you may want to
> > > implement to solve this issue, I would strongly recommend to keep the
> > > interrupt handling in the RTDM-based kernel driver, including the
> > > device request acknowledgement part.
> > >
> > > Moving this code to userland would require the thread in charge to
> > > always be runnable, so that you don't get either an interrupt flood, or
> > > a device collapse because the interrupt handling is either
> > > significantly delayed or even stopped. It turns out that such
> > > requirement would prevent you from using GDB over the process including
> > > the interrupt handling code, since GDB eagerly stops all threads for
> > > single-stepping.
> >
> > Sorry for the off-topic nitpicking, but GDB 7 supports
> > one-thread-stop/stepping. This doesn't in any way shed a different light
> > on Philippe's arguments. It's just removing a nit. On a saturday night.
> > While everyone's sleeping.
> 
> Is non-stop debugging available for anything else than x86 these days?

Good question. Spent quite some time trying to figure this out, both in docs 
and in gdb(mi) console itself. Couldn't find any way to retrieve this info. 
Only the serial protocol seems to support it using the qSupported command. I 
didn't go that far to figure it out.

The docs say 'some targets' support it. I do know that it is not a 
specific/special target, like required for reverse debugging. I'm also guessing 
that the target needs to support at least the 'async' option, ie, have gdb 
accept commands while the target program executes.

Peter


Peter