Re: [Xenomai-core] Future of fusion

[Romain Lenglet]

>  > Gilles already has a tarball of the Debian rules I used for
>  > packaging fusion. With minor changes, these could be used
>  > for a Xenomai package. One possibility is to use the rules
>  > and the compile farm to produce "ready to run"
>  > kernel/Xenomai Debian packages.
>
> Well, quite frankly, I do not know much about the debian
> packages creation process, in any case not enough to do the
> work which remains to be done. The best I can do is add the
> debian directory to the svn repository, letting volunteers
> work on it and submit patches...

I have proposed a few improvements for the Debian packaging in 
"wish" #4523:
https://gna.org/bugs/index.php?func=detailitem&item_id=4523

-- 
Romain Lenglet

Re: [Xenomai-core] Future of fusion

[Gilles Chanteperdrix]

Paul wrote:
 > 
 > Hi Philippe
 > 
 > On Thursday 13 October 2005 09:24, Philippe Gerum wrote:
 > > - Regular automated benchmarking: What is Xenomai currently capable of, how
 > > stable is it, do we progress or regress over time and releases, arch by
 > > arch?
 > 
 > Have a couple of x86 development boxes running 24/7 - Could set one up as a 
 > compile farm for running automated builds. Also have a PowerPC thin client 
 > that I would like to utilise, but could really do with some help in setting 
 > up the tools for cross-compiling the base system under Debian.

Actually, there are ready made debian cross toolchain packages at
debian.speedblue.org 

 > Gilles already has a tarball of the Debian rules I used for packaging 
 > fusion. 
 > With minor changes, these could be used for a Xenomai package. One 
 > possibility is to use the rules and the compile farm to produce "ready to 
 > run" kernel/Xenomai Debian packages.

Well, quite frankly, I do not know much about the debian packages
creation process, in any case not enough to do the work which remains
to be done. The best I can do is add the debian directory to the svn
repository, letting volunteers work on it and submit patches...

-- 


Gilles Chanteperdrix.

Re: [Xenomai-core] Future of fusion

[Gilles Chanteperdrix]

Herman Bruyninckx wrote:
 > The question is: how is the following problem solved? Where the problem is
 > as follows: using Posix threads in realtime requires another library than
 > the standard NPTL library that Linux uses (at least, I think you require
 > another library), but how do you make sure to link to the correct library?

First, Xenomai user-space POSIX library uses the same data structure
definitionss as Linux threading libraries (whether linuxthread or
NPTL). This way, including Xenomai specific headers is not mandatory for
using its POSIX library. Another advantage: Xenomai implementation of
POSIX functions may decide to delegate control to the real ones without
having to touch the user structures.

Of course, if you do not include Xenomai headers, you will not get
declarations of some functions specific to Xenomai, some of these
functions are non portable (such as pthread_make_periodic_np and
pthread_wait_np, which are still the easiest solution to get periodic
tasks in primary mode), other are not yet in all distributions, such as
the message queues API.

Second, Xenomai build a user-space library made for use with the --wrap
option of the GNU linker. Xenomai implementation of the pthread_create
function is called __wrap_pthread_create, and when linking with Xenomai
library, ld replace any call to pthread_create in the user code by
__wrap_pthread_create, so that at run time, Xenomai implementation of
this function gets called.

This solution avoids the unexpected segmentation faults. Users mistake
result either in linker errors (because of the use of a function of
Xenomai which does not exist in Linux threading library without the
--wrap parameters, or conversely because the --wrap option was passed
while trying to link with one of Linux threading libraries). In the
worst case, a user program may run as standard Linux POSIX threads
application if he forgot the --wrap options, but this is easy to see,
since /proc/xenomai/sched shows no real-time thread. Do not get me
wrong, passing the correct arguments to the compiler is as easy as with
any other skin; it is just a matter of calling xeno-config
--posix-cflags andd xeno-config --posix-ldflags. Some examples are
included in skins/posix/demos.

The current implementaion of Xenomai user-space POSIX skin also allow
Linux POSIX threads libraries functions to remain accessible aside
Xenomai calls; for example, you may still create Linux POSIX threads by
calling __real_pthread_create. Actually, now that I think about it,
being able to access easily Linux calls aside Xenomai ones was a
requirement among the most important in our view.


  > Or is NPTL realtime safe? 

the "accuracy" example in skins/posix/demos should help you get an
opinion on that point.

-- 


Gilles Chanteperdrix.

Re: [Xenomai-core] Future of fusion

[Wolfgang Grandegger]

On 10/13/2005 03:33 PM Philippe Gerum wrote:
> Paul wrote:
>> Hi Philippe
>> 
>> On Thursday 13 October 2005 09:24, Philippe Gerum wrote:
>> 
>>>- Regular automated benchmarking: What is Xenomai currently capable of, how
>>>stable is it, do we progress or regress over time and releases, arch by
>>>arch?
>> 
>> 
>> Have a couple of x86 development boxes running 24/7 - Could set one up as a 
>> compile farm for running automated builds.
> 
> That would be great, thanks. Let us know if we could help.
> 
>   Also have a PowerPC thin client
>> that I would like to utilise, but could really do with some help in setting 
>> up the tools for cross-compiling the base system under Debian.
> 
> What about DENX's ELDK?
> 
>> 
>> 
>>>- Configuration, building and packaging issues: Could we make this easier?
>> 
>> 
>> Anything that involves patching/compiling kernels is bound to cause trouble 
>> for new users. Perhaps some tests for kernel options known to cause trouble 
>> (such as APM & REGPARM) that print out large warnings during the config 
>> stage 
>> might help..
>> 
> 
> Ok, I have something rather highly ranked on my TODO list (which ends up by 
> 2117 
> or so), which is about allowing to build all Xenomai's in-kernel support 
> statically in the Linux kernel. The rationale behind that is about making 
> more 
> straightforward and efficient embedded setups; straightforward because 
> modules 
> add more complexity than they would solve in typical embedded systems, and 
> efficient since loading modules in a running kernel doesn't come for free.

That would be great for embedded systems, indeed. Apart from getting rid
of the module infrastructure, it also save TLB misses because modules
are typically placed in vmalloc'ed space. Systems with small TLB entry
tables will benefit, like PowerPC 8xx and 4xx.

> 
> To do that, portions of the Xeno build system which are currently 
> autoconfiscated should move to the target kernel, so that we would only keep 
> the 
> autoconf infrastructure for what it's good at, i.e. building the user-space 
> support. The basic idea is that we would then have a kernel extension part 
> either buildable statically or as modules using Linux's Kconfig/Kbuild 
> infrastructure, and a user-space support package providing the various 
> interface 
> libraries, headers, tools and scripts, ala glibc.
> 
> The immediate advantages would be:
> 
> - The core of the Xenomai support would be statically embeddable in the Linux 
> kernel;
> - No need for a Kconfig duplication like we have now; most of the options 
> currently presented by Xeno's Kconfig sub-system concern the kernel portions, 
> and very few actually concern the user-space stuff. We would then get rid of 
> the 
> former, and rely on the vanilla Linux's one instead.
> - Centralizing Xenomai's kernel-related options with Linux's ones would make 
> easier defining sanity checks (e.g. APM stuff and so on), since we could use 
> the 
> Kconfig language to enforce them in order to obtain sane configurations "by 
> construction" (e.g. CONFIG_XENO disables CONFIG_APM). Currently, Xeno's 
> Kconfig 
> is not aware of the kernel settings, so the checks are performed afterwise by 
> the configure script instead.
> - Removing the module compilation logic from the autoconfiscated Makefiles 
> would 
> be a significant simplification of the Xeno build system, and would make it 
> less 
> dependent on the kernel build system.
> - This build process is still fully automatable.
> - LKML people among my co-workers (Hi Stelian!) would start talking to me 
> again, 
> since I would stop pretending that autoconf is a sane way of controlling 
> builds 
> for kernel-based code. :o>
> 
> The way I see a typical build process would then be along these lines:
> 
> $ tar jxf xenomai-*
> $ mkdir xeno-build && cd xeno-build && ../xenomai-*/configure 
> --kernel=/usr/src/linux --some-option-only-for-uspace-stuff 
> --prefix=
> 
> (the configure script would then prepare the autoconf _and_ make the 
> necessary 
> links from the target kernel to the Xenomai source tree to connect the 
> modules 
> to the kernel's Kbuild/Kconfig infrastructure.
> 
> $ cd /usr/src/linux
> $ make gconfig
> 
> The user would configure his kernel, and all the kernel-based Xenomai stuff, 
> as 
> if they were standard drivers/extensions
> 
> $ make 
> $ cd xeno-build && make install
> 
> And we would be done. Well, in a perfect world, I mean.
> 
>> Gilles already has a tarball of the Debian rules I used for packaging 
>> fusion. 
>> With minor changes, these could be used for a Xenomai package. One 
>> possibility is to use the rules and the compile farm to produce "ready to 
>> run" kernel/Xenomai Debian packages.
>>
> 
> I think we should be able to work this out will Gilles before 2.0 is out 
> since 
> it's a separate build-related issue.
> 
>> 
>> Regards, Paul.
>> 
>> 
>> 
> 
> 

Re: [Xenomai-core] Future of fusion

[Jan Kiszka]

Herman Bruyninckx wrote:
> On Thu, 13 Oct 2005, Philippe Gerum wrote:
> 
>> Herman Bruyninckx wrote:
>>
>>> On Thu, 13 Oct 2005, Gilles Chanteperdrix wrote:
>>>
 Herman Bruyninckx wrote:
 > On Thu, 13 Oct 2005, Philippe Gerum wrote:
 >
 > [...]
 > > - New skins: Any new colors for the "chameleon"?
 > "Perfect POSIX" is, to me, more important than new skins.
 "Perfect" means,
 > among other things, that the interference problem with the Posix
 thread
 > library (libraries) under Linux is solved.

 What is wrong with the current implementation ? 
>>>
>>>
>>> [...]
>>>
 But I assumed the
 interference with the posix thread library was solved. Could you
 elaborate a bit more on the issues you observed ?
>>>
>>>
>>>
>>> Well, if this problem is solved, I'm very happy :-) And maybe I look
>>> at the
>>> wrong places, but where do I find a succint explanation of the solution?
>>>
>>
>> Well, what's your question first? :o>
>>
> Sorry if that was not clear.
> 
> The question is: how is the following problem solved? Where the problem is
> as follows: using Posix threads in realtime requires another library than
> the standard NPTL library that Linux uses (at least, I think you require
> another library), but how do you make sure to link to the correct library?
> Or is NPTL realtime safe?
> 

Nope, that's why there is RT-NPTL. And that library is still in flux,
especially now with the ongoing work on PREEMPT_RT. Let's wait for the
result and see if it is feasible to reuse this userspace infrastructure.

For now, I'm convinced that it is much more comfortable for the user to
obtain kernel extension and userspace library from one hand with a clear
and consistent versioning.

Jan


signature.asc
Description: OpenPGP digital signature

Re: [Xenomai-core] Future of fusion

[Philippe Gerum]

Paul wrote:

Hi Philippe

On Thursday 13 October 2005 09:24, Philippe Gerum wrote:


- Regular automated benchmarking: What is Xenomai currently capable of, how
stable is it, do we progress or regress over time and releases, arch by
arch?



Have a couple of x86 development boxes running 24/7 - Could set one up as a 
compile farm for running automated builds.


That would be great, thanks. Let us know if we could help.

 Also have a PowerPC thin client
that I would like to utilise, but could really do with some help in setting 
up the tools for cross-compiling the base system under Debian.


What about DENX's ELDK?





- Configuration, building and packaging issues: Could we make this easier?



Anything that involves patching/compiling kernels is bound to cause trouble 
for new users. Perhaps some tests for kernel options known to cause trouble 
(such as APM & REGPARM) that print out large warnings during the config stage 
might help..




Ok, I have something rather highly ranked on my TODO list (which ends up by 2117 
or so), which is about allowing to build all Xenomai's in-kernel support 
statically in the Linux kernel. The rationale behind that is about making more 
straightforward and efficient embedded setups; straightforward because modules 
add more complexity than they would solve in typical embedded systems, and 
efficient since loading modules in a running kernel doesn't come for free.


To do that, portions of the Xeno build system which are currently 
autoconfiscated should move to the target kernel, so that we would only keep the 
autoconf infrastructure for what it's good at, i.e. building the user-space 
support. The basic idea is that we would then have a kernel extension part 
either buildable statically or as modules using Linux's Kconfig/Kbuild 
infrastructure, and a user-space support package providing the various interface 
libraries, headers, tools and scripts, ala glibc.


The immediate advantages would be:

- The core of the Xenomai support would be statically embeddable in the Linux 
kernel;
- No need for a Kconfig duplication like we have now; most of the options 
currently presented by Xeno's Kconfig sub-system concern the kernel portions, 
and very few actually concern the user-space stuff. We would then get rid of the 
former, and rely on the vanilla Linux's one instead.
- Centralizing Xenomai's kernel-related options with Linux's ones would make 
easier defining sanity checks (e.g. APM stuff and so on), since we could use the 
Kconfig language to enforce them in order to obtain sane configurations "by 
construction" (e.g. CONFIG_XENO disables CONFIG_APM). Currently, Xeno's Kconfig 
is not aware of the kernel settings, so the checks are performed afterwise by 
the configure script instead.
- Removing the module compilation logic from the autoconfiscated Makefiles would 
be a significant simplification of the Xeno build system, and would make it less 
dependent on the kernel build system.

- This build process is still fully automatable.
- LKML people among my co-workers (Hi Stelian!) would start talking to me again, 
since I would stop pretending that autoconf is a sane way of controlling builds 
for kernel-based code. :o>


The way I see a typical build process would then be along these lines:

$ tar jxf xenomai-*
$ mkdir xeno-build && cd xeno-build && ../xenomai-*/configure 
--kernel=/usr/src/linux --some-option-only-for-uspace-stuff --prefix=


(the configure script would then prepare the autoconf _and_ make the necessary 
links from the target kernel to the Xenomai source tree to connect the modules 
to the kernel's Kbuild/Kconfig infrastructure.


$ cd /usr/src/linux
$ make gconfig

The user would configure his kernel, and all the kernel-based Xenomai stuff, as 
if they were standard drivers/extensions


$ make 
$ cd xeno-build && make install

And we would be done. Well, in a perfect world, I mean.

Gilles already has a tarball of the Debian rules I used for packaging fusion. 
With minor changes, these could be used for a Xenomai package. One 
possibility is to use the rules and the compile farm to produce "ready to 
run" kernel/Xenomai Debian packages.




I think we should be able to work this out will Gilles before 2.0 is out since 
it's a separate build-related issue.




Regards, Paul.






--

Philippe.

Re: [Xenomai-core] Future of fusion

[Paul]

Hi Philippe

On Thursday 13 October 2005 09:24, Philippe Gerum wrote:
> - Regular automated benchmarking: What is Xenomai currently capable of, how
> stable is it, do we progress or regress over time and releases, arch by
> arch?

Have a couple of x86 development boxes running 24/7 - Could set one up as a 
compile farm for running automated builds. Also have a PowerPC thin client 
that I would like to utilise, but could really do with some help in setting 
up the tools for cross-compiling the base system under Debian.

> - Configuration, building and packaging issues: Could we make this easier?

Anything that involves patching/compiling kernels is bound to cause trouble 
for new users. Perhaps some tests for kernel options known to cause trouble 
(such as APM & REGPARM) that print out large warnings during the config stage 
might help..

Gilles already has a tarball of the Debian rules I used for packaging fusion. 
With minor changes, these could be used for a Xenomai package. One 
possibility is to use the rules and the compile farm to produce "ready to 
run" kernel/Xenomai Debian packages.


Regards, Paul.



-- 
From the Klingon book of C:
Klingon function calls do not have 'parameters' - they have 'arguments' - and
they ALWAYS WIN THEM.

Re: [Xenomai-core] Future of fusion

[Jan Kiszka]

Herman Bruyninckx wrote:
> On Thu, 13 Oct 2005, Philippe Gerum wrote:
> [...]
> 
>> - Drivers: Now that we have a deeply integrated port of RTDM, what's
>> next? Field busses and other industrial gizmos anyone?
> 
> 
> That's an interesting avenue for all our machine control oriented realtime
> applications. But this avenue is full of incomplete or non-free
> specifications and interfaces...
> 

Indeed, but we cannot solve all problems at once. Let's start with those
devices which are more or less open (and there are already a lot). Let's
also try to propagate the message that RTDM is the prefered way to
provide real-time drivers. And if someone comes up with a new driver,
check if its interface is generic enough to implement it for similar
devices as well (=>generic device profiles).

Far from being perfect, but there are first efforts for such profiles:
Serial (as it comes with Xenomai), process image (see the Hilscher
Interbus driver I once announced), or CAN (yet a bit in flux, but things
slowly stabilises here). Plans exist to go the same way for low level
access to FireWire or USB. And you can even map whole protocol stacks
onto RTDM, like UDP/IP (RTnet) or also CANopen. The enables thrilling
combinations without the need to rewrite your application.

The interest in such progress is there, not yet on the vendor side, but
on the user side - including many industrial users. And they can push
things forward as well, finally making at least some vendors more
cooperative, too.

Jan


signature.asc
Description: OpenPGP digital signature

Re: [Xenomai-core] Future of fusion

[Herman Bruyninckx]

On Thu, 13 Oct 2005, Philippe Gerum wrote:


Herman Bruyninckx wrote:

On Thu, 13 Oct 2005, Gilles Chanteperdrix wrote:


Herman Bruyninckx wrote:
> On Thu, 13 Oct 2005, Philippe Gerum wrote:
>
> [...]
> > - New skins: Any new colors for the "chameleon"?
> "Perfect POSIX" is, to me, more important than new skins. "Perfect" 
means,

> among other things, that the interference problem with the Posix thread
> library (libraries) under Linux is solved.

What is wrong with the current implementation ? 


[...]


But I assumed the
interference with the posix thread library was solved. Could you
elaborate a bit more on the issues you observed ?



Well, if this problem is solved, I'm very happy :-) And maybe I look at the
wrong places, but where do I find a succint explanation of the solution?



Well, what's your question first? :o>


Sorry if that was not clear.

The question is: how is the following problem solved? Where the problem is
as follows: using Posix threads in realtime requires another library than
the standard NPTL library that Linux uses (at least, I think you require
another library), but how do you make sure to link to the correct library?
Or is NPTL realtime safe?

Herman

--
  K.U.Leuven, Mechanical Eng.,  Mechatronics & Robotics Research Group
 Tel: +32 16 322480

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Re: [Xenomai-core] Future of fusion

[Philippe Gerum]

Herman Bruyninckx wrote:

On Thu, 13 Oct 2005, Gilles Chanteperdrix wrote:


Herman Bruyninckx wrote:
> On Thu, 13 Oct 2005, Philippe Gerum wrote:
>
> [...]
> > - New skins: Any new colors for the "chameleon"?
> "Perfect POSIX" is, to me, more important than new skins. "Perfect" 
means,

> among other things, that the interference problem with the Posix thread
> library (libraries) under Linux is solved.

What is wrong with the current implementation ? 


[...]


But I assumed the
interference with the posix thread library was solved. Could you
elaborate a bit more on the issues you observed ?



Well, if this problem is solved, I'm very happy :-) And maybe I look at the
wrong places, but where do I find a succint explanation of the solution?



Well, what's your question first? :o>

--

Philippe.

Re: [Xenomai-core] Future of fusion

[Herman Bruyninckx]

On Thu, 13 Oct 2005, Gilles Chanteperdrix wrote:


Herman Bruyninckx wrote:
> On Thu, 13 Oct 2005, Philippe Gerum wrote:
>
> [...]
> > - New skins: Any new colors for the "chameleon"?
> "Perfect POSIX" is, to me, more important than new skins. "Perfect" means,
> among other things, that the interference problem with the Posix thread
> library (libraries) under Linux is solved.

What is wrong with the current implementation ? 

[...]

But I assumed the
interference with the posix thread library was solved. Could you
elaborate a bit more on the issues you observed ?


Well, if this problem is solved, I'm very happy :-) And maybe I look at the
wrong places, but where do I find a succint explanation of the solution?

Herman
--
  K.U.Leuven, Mechanical Eng.,  Mechatronics & Robotics Research Group
 Tel: +32 16 322480

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Re: [Xenomai-core] Future of fusion

[Gilles Chanteperdrix]

Herman Bruyninckx wrote:
 > On Thu, 13 Oct 2005, Philippe Gerum wrote:
 > 
 > [...]
 > > - New skins: Any new colors for the "chameleon"?
 > "Perfect POSIX" is, to me, more important than new skins. "Perfect" means,
 > among other things, that the interference problem with the Posix thread
 > library (libraries) under Linux is solved.

What is wrong with the current implementation ? For me, the current
POSIX skin is close to final, in term of functionalities (on my todo
list, remain shared memories, implementation of mq_notify, and maybe
barriers, rwlocks and spinlocks, which are not a big deal). Of course,
some improvements are needed, such as a "process level" cleanup, which
would allow to reclaim automatically the memory used by anonymous
objects at the process death, or real-time signals, since for the
moments signals are handled in secondary mode, and an implementation of
message queues using shared memory, to avoid copies. But I assumed the
interference with the posix thread library was solved. Could you
elaborate a bit more on the issues you observed ?

-- 


Gilles Chanteperdrix.

Re: [Xenomai-core] Future of fusion

[Herman Bruyninckx]

On Thu, 13 Oct 2005, Philippe Gerum wrote:


Marco Cavallini wrote:
I'd like to know (if is possible) the future plans and task schedule of 
fusion into xenomai project.


There are things already going on "under the surface" right now, and others 
that would depend on everyone's input in order to start them or not. The 
roadmap will clearly depend on the combination of both aspects. I will give 
some details shortly about the current or next-to-be-started efforts, but the 
feedback part is important too, so here is the call for discussion once 
posted to this list:



[...]
I propose that we start discussing along the following lines, going into 
deeper detail as needed,


[...]
- Drivers: Now that we have a deeply integrated port of RTDM, what's next? 
Field busses and other industrial gizmos anyone?


That's an interesting avenue for all our machine control oriented realtime
applications. But this avenue is full of incomplete or non-free
specifications and interfaces...

[...]

- New skins: Any new colors for the "chameleon"?

"Perfect POSIX" is, to me, more important than new skins. "Perfect" means,
among other things, that the interference problem with the Posix thread
library (libraries) under Linux is solved.

Herman

--
  K.U.Leuven, Mechanical Eng.,  Mechatronics & Robotics Research Group
 Tel: +32 16 322480

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Re: [Xenomai-core] Future of fusion

[Philippe Gerum]

Marco Cavallini wrote:

Hello,
I'd like to know (if is possible) the future plans and task schedule of 
fusion into xenomai project.

TIA


There are things already going on "under the surface" right now, and others that 
would depend on everyone's input in order to start them or not. The roadmap will 
clearly depend on the combination of both aspects. I will give some details 
shortly about the current or next-to-be-started efforts, but the feedback part 
is important too, so here is the call for discussion once posted to this list:


--

I propose that we start discussing along the following lines, going into deeper 
detail as needed, but in any case, please remember that we don't have infinite 
resources to do everything at once, and that we need to keep an organisation 
that fits our abilities to manage it, so let's keep it modest and efficient. If 
I missed some important issues, please jump in. After that initial work, we 
should be able to define a sensible roadmap.


- Regular automated benchmarking: What is Xenomai currently capable of, how 
stable is it, do we progress or regress over time and releases, arch by arch?


- Documentation effort, dissemination: I'm a potential new user, do I have some 
unambiguous source of information available to get my feet wet with Xenomai?


- Architecture ports: There is life beyond x86.

- Kernel ports: Is there still room for a 2.4 port?

- Configuration, building and packaging issues: Could we make this easier?

- Linux integration issues: Tools we should interface with, features we should 
make more seamless.


- Scalability: Is Xenomai scalable enough? What's missing?

- Drivers: Now that we have a deeply integrated port of RTDM, what's next? Field 
busses and other industrial gizmos anyone?


- Current interfaces: Are we happy with them?

- New skins: Any new colors for the "chameleon"?

--

Philippe.

Re: [Xenomai-core] Future of fusion

[Jan Kiszka]

Marco Cavallini wrote:
> Hello,
> I'd like to know (if is possible) the future plans and task schedule of
> fusion into xenomai project.

Unless I don't misunderstand your question: Xenomai _is_ fusion. Take a
look at the code base, the main difference between fusion-0.9.1 and
current Xenomai SVN is the renaming (besides a lot of bug fixes).

Regarding the roadmap: browse the xenomai-core archive, there were
already a few postings about potential future directions.

HTH

Jan


signature.asc
Description: OpenPGP digital signature