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

[Peter Soetens <peter@domain.hid>]

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