[Xenomai-core] Re: [Xenomai-help] v2.1 becomes trunk.
Gilles Chanteperdrix wrote: > > Now that the 2.1 branch is becoming the branch where Philippe is > working, errh... I mean, where the main development effort occurs, it is > time for this branch to become trunk, and for the old branch retirement. > > So, a rename will occur in two hours (that is, at 22:00 GMT). > > Before the rename, the svn repository for the 2.0 branch is : > svn://svn.gna.org/svn/xenomai/trunk > the svn repository for the 2.1 branch is : > svn://svn.gna.org/svn/xenomai/branches/v2.1 > > After the rename, the svn repository for the 2.0 branch will be: > svn://svn.gna.org/svn/xenomai/branches/v2.0.x > the svn repository for the 2.1 branch will be : > svn://svn.gna.org/svn/xenomai/trunk > > I will post another mail when the rename is done. It is done. Please also note that branch 2.0 is not really retired, 2.0.x maintenance will take place in this branch. -- Gilles Chanteperdrix.
[Xenomai-core] v2.1 becomes trunk.
Now that the 2.1 branch is becoming the branch where Philippe is working, errh... I mean, where the main development effort occurs, it is time for this branch to become trunk, and for the old branch retirement. So, a rename will occur in two hours (that is, at 22:00 GMT). Before the rename, the svn repository for the 2.0 branch is : svn://svn.gna.org/svn/xenomai/trunk the svn repository for the 2.1 branch is : svn://svn.gna.org/svn/xenomai/branches/v2.1 After the rename, the svn repository for the 2.0 branch will be: svn://svn.gna.org/svn/xenomai/branches/v2.0.x the svn repository for the 2.1 branch will be : svn://svn.gna.org/svn/xenomai/trunk I will post another mail when the rename is done. -- Gilles Chanteperdrix.
[Xenomai-core] Re: [Xenomai-help] Blocking reads from pipes
On Thursday 17 November 2005 20:17, you wrote: > Dmitry Adamushko wrote: > > On Thursday 17 November 2005 18:24, Gilles Chanteperdrix wrote: > > > Dmitry Adamushko wrote: > > > > > >As a conclusion, the behaviour that you observed with Xenomai > > > > > >pipes seems consistent with that of Linux' named pipes, except > > > > > >that in Linux read() returns 0, and not an error code as you > > > > > >observed with Xenomai. > > > > > > > > > > The read() call does *not* return when you close the *same* file > > > > > handle from another pthread in the same process. > > > > > > > > I confirm that and as I pointed it out in my previous mail - this > > > > is not how it's supposed to be. > > > > I'm currently on it. More news later. > > > > > > I am not sure about that: Linux regular pipes follow the same > > > behaviour (the real destruction of the file descriptor is delayed > > > until read() really returns). > > > > My assertion was only based on the idea that nucleus::xnpipe_release() > > must be > > > > called as a result of any close() from the user space. > > If we have a look at the sources, sys_read uses fput_light and > fget_light, which increment and decrement the file descriptor > reference count (member f_count of the file structure) used by fget and > fput when the file descriptor is shared between. open and close call > fget and fput. > > "release" only get called through __fput when f_count reaches 0. Exactly, I have just found out that and posted actually a long mail just before getting this mail from you :o) Yep, and before getting blocked, read() increments the counter as well, that's why we don't have a xnpipe_realease() called as a result of close(). So everything is correct. --- Dmitry
[Xenomai-core] Re: [Xenomai-help] Blocking reads from pipes
On Thursday 17 November 2005 18:24, Gilles Chanteperdrix wrote: > Dmitry Adamushko wrote: > > > >As a conclusion, the behaviour that you observed with Xenomai > > > >pipes seems consistent with that of Linux' named pipes, except > > > >that in Linux read() returns 0, and not an error code as you > > > >observed with Xenomai. > > > > > > The read() call does *not* return when you close the *same* file > > > handle from another pthread in the same process. > > > > I confirm that and as I pointed it out in my previous mail - this is not > > how it's supposed to be. > > I'm currently on it. More news later. > > I am not sure about that: Linux regular pipes follow the same behaviour > (the real destruction of the file descriptor is delayed until read() > really returns). Ok, it's me who is a stupid uneducated zorr... I mean bozzo :o) The reason is quite simple indeed. The file_operations::release() is called when a object is about to be destroyed (file * object is created for each open file). It happens when its refference count becomes 0. Rigth after open() the counter == 1. As one may guess, close() decrease it on 1. There is another entity - file_operations::flush() which is called on each close() call. But file_operations::release() is called only when all the references on the object have been closed. There can be N:1 relation. Imagine, dup() or fork() make a copy of the file descriptor and as a result - the regerence is increased appropriately. Now what happens is that read/write() calls increase the counter before using a file object and decrease it right before returning. thread1::open() --> file_operations::open() == xnpipe_open() ---> counter=1 thread1::read() --> ... counter=2 .. -> file_operations::read() == xnpipe_read() - blocked ... (*) thread2::close() --> ... -> file_operations::flush() [ we don't make use of this one in pipe.c ] --> counter = 1 So that's why xnpipe_release() is not called! 10 seconds have elapsed thread1::read (*) - unblocked() --> copies data to the user's buffer ---> counter = 0. Oooops! As a result -> file_operations::release() is called! Next thread1::read() call returns an error code. So that's what happens. We can define file_operations::flush() and wake up all the readers there. But we can't know that this is a last reference on the file (ok, we can actually but with a bit of hacking). I mean : f = open() -> 1 reference f2 = dup(f)-> the 2-nd close(f); close(f2); 2 flush() calls but only 1 release() so do we need to wake up all the readers if the file is still valid? So well, at least, there is no problem with the xenomai codebase, that's good :o) --- Dmitry
[Xenomai-core] Re: [Xenomai-help] Blocking reads from pipes
Dmitry Adamushko wrote: > On Thursday 17 November 2005 18:24, Gilles Chanteperdrix wrote: > > Dmitry Adamushko wrote: > > > > >As a conclusion, the behaviour that you observed with Xenomai > > > > >pipes seems consistent with that of Linux' named pipes, except > > > > >that in Linux read() returns 0, and not an error code as you > > > > >observed with Xenomai. > > > > > > > > The read() call does *not* return when you close the *same* file > > > > handle from another pthread in the same process. > > > > > > I confirm that and as I pointed it out in my previous mail - this is not > > > how it's supposed to be. > > > I'm currently on it. More news later. > > > > I am not sure about that: Linux regular pipes follow the same behaviour > > (the real destruction of the file descriptor is delayed until read() > > really returns). > > My assertion was only based on the idea that nucleus::xnpipe_release() must > be > called as a result of any close() from the user space. If we have a look at the sources, sys_read uses fput_light and fget_light, which increment and decrement the file descriptor reference count (member f_count of the file structure) used by fget and fput when the file descriptor is shared between. open and close call fget and fput. "release" only get called through __fput when f_count reaches 0. -- Gilles Chanteperdrix.
Re: [Xenomai-core] Official logo
Bruno Rouchouse wrote: > ... > Don't hesitate if you have any comments or suggestions about any of these > subjects. > A section for links to related projects and other stuff would be nice. I would have a few to offer: o http://rtfirewire.berlios.de o http://developer.berlios.de/projects/usb4rt o http://www.rtnet.org o http://www.rts.uni-hannover.de/xenomai/lxr o http://www.rts.uni-hannover.de/mitarbeiter/kiszka/rtaddon And there are certainly more. :) Jan signature.asc Description: OpenPGP digital signature
[Xenomai-core] Announce: RTDM CAN Device Profile and Driver
Hello list, as a result of a student research project of mine (kind of bachelor thesis), here is a CAN device profile for RTDM including a driver for the SJA1000-based eNET PHYTEC card. See RT-Add-On-Repository at the University of Hannover: http://www.rts.uni-hannover.de/mitarbeiter/kiszka/rtaddon/ Have fun! ;-) Sebastian
[Xenomai-core] Re: [Xenomai-help] Blocking reads from pipes
On Thursday 17 November 2005 18:24, Gilles Chanteperdrix wrote:
> Dmitry Adamushko wrote:
> > > >As a conclusion, the behaviour that you observed with Xenomai
> > > >pipes seems consistent with that of Linux' named pipes, except
> > > >that in Linux read() returns 0, and not an error code as you
> > > >observed with Xenomai.
> > >
> > > The read() call does *not* return when you close the *same* file
> > > handle from another pthread in the same process.
> >
> > I confirm that and as I pointed it out in my previous mail - this is not
> > how it's supposed to be.
> > I'm currently on it. More news later.
>
> I am not sure about that: Linux regular pipes follow the same behaviour
> (the real destruction of the file descriptor is delayed until read()
> really returns).
My assertion was only based on the idea that nucleus::xnpipe_release() must be
called as a result of any close() from the user space. And it, in turn, wakes
up all the blocked readers. So the current implementation at least should
have worked in sych a case. But, well, below is what I have observed.
Maybe your assertion may explain that.
The reason is actually not because of some problem in the xenomai codebase but
because of the fact that nucleus::xnpipe_release() is _not_ called as I
expected it to be :o)
The experiment was as follows (a slightly changed klatency test):
latency_module.ko uses a 10-second wait-interval for sending data
int fd; // pipe
thread#2
{
sleep(3);
close(fd);
// closing a pipe. Here I expected that nucleus::xnpipe_release() would be
// called as a result (== file_operations::release ).
}
thread#1
{
fd = open(/dev/rtpN);
pthread_create(thread#2);
read(fd, ...); // blocked at least for 10 seconds so thread#2 closes a pipe
//earlier
...
if (error)
break;
...
close(fd);
}
So xnpipe_release() is _not_ called as a result of the close() call in
thread#2. close() returns 0 indeed.
10 seconds after its starting, thread#1 :: read() returns a valid block of
data from the latency module and right after that - an error code is returned
that the pipe is no longer valid.
I have taken a very brief look at the linux sources but it was not enough to
get an explanation. So I'll take a closer look now :o)
---
Dmitry
[Xenomai-core] v2.1 status
Here is an update regarding the way things progress on the v2.1 branch: o The build system has been deeply revamped, so that we now fully leave the burden of building Xenomai's kernel support to Linux. To this end, the code tree has been reorganized in two major sections, the first one contains the kernel-related sources (ksrc/), the other is hosting the user-space support (src/). Since the user-space portion does not need to know about the kernel sources anymore, several issues have been solved in the same move. All in all, things are way simpler than before, which seems to indicate that we are heading to the right direction. The documentation for the installation process needs to be updated though. o Also as a matter of build system (and a bit more), v2.1 has been backported to Linux 2.4, starting with the ppc32 support. We rely on Denx's 2_4-devel tree as our 2.4 kernel of reference for this port [1]. A second backport to 2.4/x86 will happen when this combo is I-pipe ready. We are ahead of schedule regarding this backport, since it was initially planned for Q12006, but since we are going to add more supported architectures in the next months, it's better to have a stable build system for that. o PowerPC-wise (again), we should be close to ready for 2.6.15, since Heikki merged both the 32 and 64-bit trees in a single one. All other tasks planned are undergoing. For my part, I'm going to fiddle now with ADI's Blackfin for which we already have the required Adeos support, and create the Xenomai port for it. Since this one is uClinux based, we should be able to check that the new build system is ok to host any kind of port sanely. [1] http://www.denx.de/en/Software/CVS/ -- Philippe.
[Xenomai-core] Re: [Xenomai-help] v2.1 becomes trunk.
Gilles Chanteperdrix wrote: > > Now that the 2.1 branch is becoming the branch where Philippe is > working, errh... I mean, where the main development effort occurs, it is > time for this branch to become trunk, and for the old branch retirement. > > So, a rename will occur in two hours (that is, at 22:00 GMT). > > Before the rename, the svn repository for the 2.0 branch is : > svn://svn.gna.org/svn/xenomai/trunk > the svn repository for the 2.1 branch is : > svn://svn.gna.org/svn/xenomai/branches/v2.1 > > After the rename, the svn repository for the 2.0 branch will be: > svn://svn.gna.org/svn/xenomai/branches/v2.0.x > the svn repository for the 2.1 branch will be : > svn://svn.gna.org/svn/xenomai/trunk > > I will post another mail when the rename is done. It is done. Please also note that branch 2.0 is not really retired, 2.0.x maintenance will take place in this branch. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] v2.1 becomes trunk.
Now that the 2.1 branch is becoming the branch where Philippe is working, errh... I mean, where the main development effort occurs, it is time for this branch to become trunk, and for the old branch retirement. So, a rename will occur in two hours (that is, at 22:00 GMT). Before the rename, the svn repository for the 2.0 branch is : svn://svn.gna.org/svn/xenomai/trunk the svn repository for the 2.1 branch is : svn://svn.gna.org/svn/xenomai/branches/v2.1 After the rename, the svn repository for the 2.0 branch will be: svn://svn.gna.org/svn/xenomai/branches/v2.0.x the svn repository for the 2.1 branch will be : svn://svn.gna.org/svn/xenomai/trunk I will post another mail when the rename is done. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Official logo
On Wed, 2005-11-16 at 14:38 +0100, Bruno Rouchouse wrote: > > The URL is : http://snail.fsffrance.org/www.xenomai.org/index.php > Well I have a small comment too. On the frontpage there is a boc with "welcome to Xenomai" and in the bootom of this box there is a link saying "read more" but when following this link i get the same text as is in the frontpage bax, only now on its own page. My point being, that there is no more to read. And a socond thing that I guess is not Your task. I would really like to se some description on the skin concept. -- Med venlig hilsen/mojn/regards Martin Hansen Center for Software Innovation Stenager 2, DK-6400 Sønderborg, Web: www.cfsi.dk
[Xenomai-core] Re: [Xenomai-help] Blocking reads from pipes
On Thursday 17 November 2005 20:17, you wrote: > Dmitry Adamushko wrote: > > On Thursday 17 November 2005 18:24, Gilles Chanteperdrix wrote: > > > Dmitry Adamushko wrote: > > > > > >As a conclusion, the behaviour that you observed with Xenomai > > > > > >pipes seems consistent with that of Linux' named pipes, except > > > > > >that in Linux read() returns 0, and not an error code as you > > > > > >observed with Xenomai. > > > > > > > > > > The read() call does *not* return when you close the *same* file > > > > > handle from another pthread in the same process. > > > > > > > > I confirm that and as I pointed it out in my previous mail - this > > > > is not how it's supposed to be. > > > > I'm currently on it. More news later. > > > > > > I am not sure about that: Linux regular pipes follow the same > > > behaviour (the real destruction of the file descriptor is delayed > > > until read() really returns). > > > > My assertion was only based on the idea that nucleus::xnpipe_release() > > must be > > > > called as a result of any close() from the user space. > > If we have a look at the sources, sys_read uses fput_light and > fget_light, which increment and decrement the file descriptor > reference count (member f_count of the file structure) used by fget and > fput when the file descriptor is shared between. open and close call > fget and fput. > > "release" only get called through __fput when f_count reaches 0. Exactly, I have just found out that and posted actually a long mail just before getting this mail from you :o) Yep, and before getting blocked, read() increments the counter as well, that's why we don't have a xnpipe_realease() called as a result of close(). So everything is correct. --- Dmitry ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [Xenomai-help] Blocking reads from pipes
On Thursday 17 November 2005 18:24, Gilles Chanteperdrix wrote: > Dmitry Adamushko wrote: > > > >As a conclusion, the behaviour that you observed with Xenomai > > > >pipes seems consistent with that of Linux' named pipes, except > > > >that in Linux read() returns 0, and not an error code as you > > > >observed with Xenomai. > > > > > > The read() call does *not* return when you close the *same* file > > > handle from another pthread in the same process. > > > > I confirm that and as I pointed it out in my previous mail - this is not > > how it's supposed to be. > > I'm currently on it. More news later. > > I am not sure about that: Linux regular pipes follow the same behaviour > (the real destruction of the file descriptor is delayed until read() > really returns). Ok, it's me who is a stupid uneducated zorr... I mean bozzo :o) The reason is quite simple indeed. The file_operations::release() is called when a object is about to be destroyed (file * object is created for each open file). It happens when its refference count becomes 0. Rigth after open() the counter == 1. As one may guess, close() decrease it on 1. There is another entity - file_operations::flush() which is called on each close() call. But file_operations::release() is called only when all the references on the object have been closed. There can be N:1 relation. Imagine, dup() or fork() make a copy of the file descriptor and as a result - the regerence is increased appropriately. Now what happens is that read/write() calls increase the counter before using a file object and decrease it right before returning. thread1::open() --> file_operations::open() == xnpipe_open() ---> counter=1 thread1::read() --> ... counter=2 .. -> file_operations::read() == xnpipe_read() - blocked ... (*) thread2::close() --> ... -> file_operations::flush() [ we don't make use of this one in pipe.c ] --> counter = 1 So that's why xnpipe_release() is not called! 10 seconds have elapsed thread1::read (*) - unblocked() --> copies data to the user's buffer ---> counter = 0. Oooops! As a result -> file_operations::release() is called! Next thread1::read() call returns an error code. So that's what happens. We can define file_operations::flush() and wake up all the readers there. But we can't know that this is a last reference on the file (ok, we can actually but with a bit of hacking). I mean : f = open() -> 1 reference f2 = dup(f)-> the 2-nd close(f); close(f2); 2 flush() calls but only 1 release() so do we need to wake up all the readers if the file is still valid? So well, at least, there is no problem with the xenomai codebase, that's good :o) --- Dmitry ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [Xenomai-help] Blocking reads from pipes
Dmitry Adamushko wrote: > On Thursday 17 November 2005 18:24, Gilles Chanteperdrix wrote: > > Dmitry Adamushko wrote: > > > > >As a conclusion, the behaviour that you observed with Xenomai > > > > >pipes seems consistent with that of Linux' named pipes, except > > > > >that in Linux read() returns 0, and not an error code as you > > > > >observed with Xenomai. > > > > > > > > The read() call does *not* return when you close the *same* file > > > > handle from another pthread in the same process. > > > > > > I confirm that and as I pointed it out in my previous mail - this is not > > > how it's supposed to be. > > > I'm currently on it. More news later. > > > > I am not sure about that: Linux regular pipes follow the same behaviour > > (the real destruction of the file descriptor is delayed until read() > > really returns). > > My assertion was only based on the idea that nucleus::xnpipe_release() must > be > called as a result of any close() from the user space. If we have a look at the sources, sys_read uses fput_light and fget_light, which increment and decrement the file descriptor reference count (member f_count of the file structure) used by fget and fput when the file descriptor is shared between. open and close call fget and fput. "release" only get called through __fput when f_count reaches 0. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Official logo
Hi Dmitry, first of all and before I answer each one of your points, you have to know that I used for the website a CMS called Joomla. The template has been found on Internet in order to save time on webdesign which requires real design skills. My goal was to set up a, let's say, enough good looking website as soon as possible. That said, CMS have their advantages as well as drawbacks in the sense that they are not always very easy to customize. Of course it is just PHP combined with HTML but it takes time to tune everything because web technologies suck :) You change one little thing here and the whole layout of the page is messed up (and I don't even talk about the different versions of browsers !) So let's examine the points now : On 11/16/05, Dmitry Adamushko <[EMAIL PROTECTED]> wrote: Hi Bruno,I have a few remarks on the new web-site :)- lots of blank space at the bottom/left/right side of the page (width isabout 3 cm. approx.) err.. is it really necessary (functionality ordesign-wise)? ok, it's difficult to argue on the design side since it's, well, very subjective :) On the left: it depends on the length of the header of the article, sorry but can't do anything about that beside resizing the whole table. Is it really disturbing ? On the right side, it is normal because this area is reserved for adding logos, special ads etc. It is not used at the moment. All in one: yes you may be right and I guess I could get rid of this area and resize then the whole thing to avoid blank areas. - "Main menu" is not that easily accessable. e.g. I need to scroll the page a bit down in order to get access to the login form or even (when my mozillahas a "personal toolbar" switched on) - to the "Development Source Code"sub-menu Don't really understant that one ! I use a laptop with 15in screen and don't have this problem. What screen size and resolution do you use ? As far as I am concerned, the whole website is visible on an entire page. - default font is too small and a bit faded (grey on white background or white on gray one) I used the template as it is (I didn't change the CSS). I trust webdesigners for that and I'm not sure black fonts would look any better. I can try though. - Opera and Mozilla show some news/topic headers adjusted differently.Actually, everything is left-adjusted with Mozilla and some parts are centered with Opera, e.g. it may look like:HomeXenomai v2.0.1Written by AdministratorSunday, 13 November 2005Ok, it's not that important and likely easily fixable. I didn't try the website on all browsers. I will have a look at this particular point. - the picture of sky with "Real-Time framework for Linux" and "NewsFlash" boxtake too much space (almost a whole bottom half of the page). I would not saythat part is so informative and so "deserves" that amount of space. Again, the template has been designed by professionals, some people may like it others don't ;) The most important thing is that the load time has to be short. As far as the size is concerned, I don't want to change it at the moment since the banner will for sure be redesigned in the near future (just need the idea for that). I guess we can make it a bit smaller then. that's what I have in my mind at the moment :o) Thanks for the remarks. Regards, Bruno---Best regards,Dmitry
Re: [Xenomai-core] Official logo
Bruno Rouchouse wrote: > ... > Don't hesitate if you have any comments or suggestions about any of these > subjects. > A section for links to related projects and other stuff would be nice. I would have a few to offer: o http://rtfirewire.berlios.de o http://developer.berlios.de/projects/usb4rt o http://www.rtnet.org o http://www.rts.uni-hannover.de/xenomai/lxr o http://www.rts.uni-hannover.de/mitarbeiter/kiszka/rtaddon And there are certainly more. :) Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Announce: RTDM CAN Device Profile and Driver
Hello list, as a result of a student research project of mine (kind of bachelor thesis), here is a CAN device profile for RTDM including a driver for the SJA1000-based eNET PHYTEC card. See RT-Add-On-Repository at the University of Hannover: http://www.rts.uni-hannover.de/mitarbeiter/kiszka/rtaddon/ Have fun! ;-) Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [Xenomai-help] Blocking reads from pipes
On Thursday 17 November 2005 18:24, Gilles Chanteperdrix wrote:
> Dmitry Adamushko wrote:
> > > >As a conclusion, the behaviour that you observed with Xenomai
> > > >pipes seems consistent with that of Linux' named pipes, except
> > > >that in Linux read() returns 0, and not an error code as you
> > > >observed with Xenomai.
> > >
> > > The read() call does *not* return when you close the *same* file
> > > handle from another pthread in the same process.
> >
> > I confirm that and as I pointed it out in my previous mail - this is not
> > how it's supposed to be.
> > I'm currently on it. More news later.
>
> I am not sure about that: Linux regular pipes follow the same behaviour
> (the real destruction of the file descriptor is delayed until read()
> really returns).
My assertion was only based on the idea that nucleus::xnpipe_release() must be
called as a result of any close() from the user space. And it, in turn, wakes
up all the blocked readers. So the current implementation at least should
have worked in sych a case. But, well, below is what I have observed.
Maybe your assertion may explain that.
The reason is actually not because of some problem in the xenomai codebase but
because of the fact that nucleus::xnpipe_release() is _not_ called as I
expected it to be :o)
The experiment was as follows (a slightly changed klatency test):
latency_module.ko uses a 10-second wait-interval for sending data
int fd; // pipe
thread#2
{
sleep(3);
close(fd);
// closing a pipe. Here I expected that nucleus::xnpipe_release() would be
// called as a result (== file_operations::release ).
}
thread#1
{
fd = open(/dev/rtpN);
pthread_create(thread#2);
read(fd, ...); // blocked at least for 10 seconds so thread#2 closes a pipe
//earlier
...
if (error)
break;
...
close(fd);
}
So xnpipe_release() is _not_ called as a result of the close() call in
thread#2. close() returns 0 indeed.
10 seconds after its starting, thread#1 :: read() returns a valid block of
data from the latency module and right after that - an error code is returned
that the pipe is no longer valid.
I have taken a very brief look at the linux sources but it was not enough to
get an explanation. So I'll take a closer look now :o)
---
Dmitry
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] v2.1 status
Here is an update regarding the way things progress on the v2.1 branch: o The build system has been deeply revamped, so that we now fully leave the burden of building Xenomai's kernel support to Linux. To this end, the code tree has been reorganized in two major sections, the first one contains the kernel-related sources (ksrc/), the other is hosting the user-space support (src/). Since the user-space portion does not need to know about the kernel sources anymore, several issues have been solved in the same move. All in all, things are way simpler than before, which seems to indicate that we are heading to the right direction. The documentation for the installation process needs to be updated though. o Also as a matter of build system (and a bit more), v2.1 has been backported to Linux 2.4, starting with the ppc32 support. We rely on Denx's 2_4-devel tree as our 2.4 kernel of reference for this port [1]. A second backport to 2.4/x86 will happen when this combo is I-pipe ready. We are ahead of schedule regarding this backport, since it was initially planned for Q12006, but since we are going to add more supported architectures in the next months, it's better to have a stable build system for that. o PowerPC-wise (again), we should be close to ready for 2.6.15, since Heikki merged both the 32 and 64-bit trees in a single one. All other tasks planned are undergoing. For my part, I'm going to fiddle now with ADI's Blackfin for which we already have the required Adeos support, and create the Xenomai port for it. Since this one is uClinux based, we should be able to check that the new build system is ok to host any kind of port sanely. [1] http://www.denx.de/en/Software/CVS/ -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Official logo
On Wed, 2005-11-16 at 14:38 +0100, Bruno Rouchouse wrote: > > The URL is : http://snail.fsffrance.org/www.xenomai.org/index.php > Well I have a small comment too. On the frontpage there is a boc with "welcome to Xenomai" and in the bootom of this box there is a link saying "read more" but when following this link i get the same text as is in the frontpage bax, only now on its own page. My point being, that there is no more to read. And a socond thing that I guess is not Your task. I would really like to se some description on the skin concept. -- Med venlig hilsen/mojn/regards Martin Hansen Center for Software Innovation Stenager 2, DK-6400 Sønderborg, Web: www.cfsi.dk ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Official logo
> > I have a few remarks on the new web-site :) > > - lots of blank space at the bottom/left/right side of the page (width is > about 3 cm. approx.) err.. is it really necessary (functionality or > design-wise)? ok, it's difficult to argue on the design side since it's, > well, very subjective :) > > > On the left: it depends on the length of the header of the article, > sorry but can't do anything about that beside resizing the whole > table. Is it really disturbing ? > On the right side, it is normal because this area is reserved for > adding logos, special ads etc. It is not used at the moment. > All in one: yes you may be right and I guess I could get rid of this > area and resize then the whole thing to avoid blank areas. I am sorry if my description was not clear. The "table" with useful information seems to be centered and it takes about 3/5 of the screen width while 1/5 is left as blank space on the left and another 1/5 - on the right. I'd suggest, if it's possible of course, to resize the page so it may take about 4/5 of the screen width and adjust it to the left in the same time. In such a case, there is still 1/5 of the blank scree on the right for banners, etc. now: [ 1/5 : blank space] [ 3/5 : useful data ] [ 1/5 : blank space (for banners) ] alternative: [ 4/5 : useful data ] [ 1/5 : blank space (for banners) ] > > - "Main menu" is not that easily accessable. e.g. I need to scroll the page a > bit down in order to get access to the login form or even (when my mozilla > has a "personal toolbar" switched on) - to the "Development Source Code" > sub-menu > > Don't really understant that one ! I use a laptop with 15in screen > and don't have this problem. What screen size and resolution do you > use ? As far as I am concerned, the whole website is visible on an > entire page. It looks fine on my 19" (1280:1024) screen at work and the whole page is (almost) visible. I use a laptop with 13,3" (1024:768) at home and the page there looks differently (I may do a screenshot later). I wonder how it looks like on a generic 15" tube-monitor (800:600) :o) > > - default font is too small and a bit faded (grey on white background or white > on gray one) > > I used the template as it is (I didn't change the CSS). I trust > webdesigners for that and I'm not sure black fonts would look any > better. I can try though. Don't worry about that, it's too subjective in any case :) > > - Opera and Mozilla show some news/topic headers adjusted differently. > Actually, everything is left-adjusted with Mozilla and some parts are > centered with Opera, e.g. it may look like: > > Home > Xenomai v2.0.1 > Written by Administrator > Sunday, 13 November 2005 > > Ok, it's not that important and likely easily fixable. > > I didn't try the website on all browsers. I will have a look at this > particular point. It doesn't matter so much really. > > - the picture of sky with "Real-Time framework for Linux" and "NewsFlash" box > take too much space (almost a whole bottom half of the page). I would not say > that part is so informative and so "deserves" that amount of space. > > Again, the template has been designed by professionals, some people > may like it others don't ;) The most important thing is that the > load time has to be short. As far as the size is concerned, I don't > want to change it at the moment since the banner will for sure be > redesigned in the near future (just need the idea for that). I guess > we can make it a bit smaller then. As I pointed out above, it looks much nicer on a bigger screen (but still I'd make it smaller :) Anyway, the main goal is not about getting a main prize for the best design so don't pay too much attention to my comments ;) Some things can be always adjusted later. --- Best regards, Dmitry ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Official logo
Hi Dmitry, first of all and before I answer each one of your points, you have to know that I used for the website a CMS called Joomla. The template has been found on Internet in order to save time on webdesign which requires real design skills. My goal was to set up a, let's say, enough good looking website as soon as possible. That said, CMS have their advantages as well as drawbacks in the sense that they are not always very easy to customize. Of course it is just PHP combined with HTML but it takes time to tune everything because web technologies suck :) You change one little thing here and the whole layout of the page is messed up (and I don't even talk about the different versions of browsers !) So let's examine the points now : On 11/16/05, Dmitry Adamushko <[EMAIL PROTECTED]> wrote: Hi Bruno,I have a few remarks on the new web-site :)- lots of blank space at the bottom/left/right side of the page (width isabout 3 cm. approx.) err.. is it really necessary (functionality ordesign-wise)? ok, it's difficult to argue on the design side since it's, well, very subjective :) On the left: it depends on the length of the header of the article, sorry but can't do anything about that beside resizing the whole table. Is it really disturbing ? On the right side, it is normal because this area is reserved for adding logos, special ads etc. It is not used at the moment. All in one: yes you may be right and I guess I could get rid of this area and resize then the whole thing to avoid blank areas. - "Main menu" is not that easily accessable. e.g. I need to scroll the page a bit down in order to get access to the login form or even (when my mozillahas a "personal toolbar" switched on) - to the "Development Source Code"sub-menu Don't really understant that one ! I use a laptop with 15in screen and don't have this problem. What screen size and resolution do you use ? As far as I am concerned, the whole website is visible on an entire page. - default font is too small and a bit faded (grey on white background or white on gray one) I used the template as it is (I didn't change the CSS). I trust webdesigners for that and I'm not sure black fonts would look any better. I can try though. - Opera and Mozilla show some news/topic headers adjusted differently.Actually, everything is left-adjusted with Mozilla and some parts are centered with Opera, e.g. it may look like:HomeXenomai v2.0.1Written by AdministratorSunday, 13 November 2005Ok, it's not that important and likely easily fixable. I didn't try the website on all browsers. I will have a look at this particular point. - the picture of sky with "Real-Time framework for Linux" and "NewsFlash" boxtake too much space (almost a whole bottom half of the page). I would not saythat part is so informative and so "deserves" that amount of space. Again, the template has been designed by professionals, some people may like it others don't ;) The most important thing is that the load time has to be short. As far as the size is concerned, I don't want to change it at the moment since the banner will for sure be redesigned in the near future (just need the idea for that). I guess we can make it a bit smaller then. that's what I have in my mind at the moment :o) Thanks for the remarks. Regards, Bruno---Best regards,Dmitry ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
