[Xenomai-core] RTnet over Xenomai
Hi, after some interruptions it's done now: RTnet compiles at least against Xenomai SVN, I have not checked yet if it runs as well. Who would like to give it a try may check-out RTnet's SVN repository. Note that due to the required renaming, support of old fusion 0.9 and 0.9.1 was dropped. Earlier fusion versions were not supported anyway, as they lack up-to-date RTDM support. And we are still looking forward to the RTAI community completing RTDM support as well - the infrastructure of RTnet is ready... Have fun, Jan signature.asc Description: OpenPGP digital signature
[Xenomai-core] Welcome home
Hi, Welcome home. Before I'm giving you an update of the things undergoing, and since JimC jumped the gun on this list, I'd like to thank all the people who wished me an happy retir^H^H^H^H^Hbirthday recently. With such a huge number of candles on my birthday cake, I'm pretty sure that each and every space tourist wandering in the ISS henceforth knows where I'm living, just by looking down to the Earth through the porthole! Anyway, here is a short update: - The former fusion code base has been reworked in order to switch back to the Xenomai naming scheme, and the result is now available as a SVN tree on GNA [1]. Additional features and fixes have been added very recently to this tree, like a NMI watchdog for chasing unexpected latencies using a brute force approach on x86, or udev support for the pseudo-devices (message pipes and heap). Glitches may still exist here and there, but AFAICT reading this list, things get fixed gradually. - A new Xenomai.org website is in preparation. Bruno handles this, and we should be able to switch to it in a week or so. For the time being, we are aiming at simple and most informative contents given the short time frame and the time Bruno can devote to this task. If you have specific wishes regarding this site for the future, please post them to this list. For the time being Xenomai.org simply points at the project's workspace on GNA. - Two mailing lists have been created: xenomai-core and xenomai-help. In short, the first one is the place where all aspects of the Xenomai project's life should be debated (including patches and bug reports). The second one handles discussions about configuration, compilation or installation of Xenomai, as well as common usage of its features and interfaces. My hope is that at some point in time, the latter becomes a coherent and searchable repository that reflects the collective experience of Xenomai users. - The plan is to release Xenomai 2.0 on October 22 at the latest, which leaves us a few days to finish testing the new codebase. Since the changes required by the transition are only syntactical ones, and do not impact the documented APIs, things should stabilize reasonably fast. Until then, we clearly are in feature freeze from now on. Only obvious bug fixes will be merged. Aside of this, I'd like that we start a discussion on this list about the matters of importance asap. There are a lot, some of them are organisational, others are purely technical. My TODO list would not even fit on my hard-drive, and since I'm not alone to have an opinion about what we should do next, how and when, it's likely that the official list would be even ten times longer than mine. 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? [1] https://gna.org/svn/?group=xenomai -- Philippe.
[Xenomai-core] fusion just disappeared
Hi, I have got a message from a collegue of mine who asked what has happened with Fusion, all the information disappered from the rtai.org. I'm not sure whether he's reading the rtai mailing list and anyway, Philippe, the subject of the message was not that informative, probably should have been something like Fusion is out of rtai :) I don't know whether it could be a good idea to ask Paolo and DIAPM, but again, IMHO it could be better if they would be agreed on keeping some redirecting information about ex-fusion for some time or, at least, some a proper mentioning in the news area. What's your opinion? Anyway, when the site is completed, I guess it will be a right moment to announce the project all over the map, starting from the lkml, etc. -- Best regards, Dmitry Adamushko
[Xenomai-core] Re: fusion just disappeared
Dmitry Adamushko wrote: Hi, I have got a message from a collegue of mine who asked what has happened with Fusion, all the information disappered from the rtai.org. I'm not sure whether he's reading the rtai mailing list and anyway, Philippe, the subject of the message was not that informative, probably should have been something like Fusion is out of rtai :) I don't know whether it could be a good idea to ask Paolo and DIAPM, but again, IMHO it could be better if they would be agreed on keeping some redirecting information about ex-fusion for some time or, at least, some a proper mentioning in the news area. What's your opinion? Well, this is true, but we can't have it all. AFAIK, the DIAPM people are going to revamp rtai.org asap, so it's unlikely that they'd wish to keep such link in place once the refactoring has taken place. This said, I'm going to try leaving an ultimate news on the old/current site pointing fusion users at Xenomai, which should survive until the web site is fully reorganized by the DIAPM. I will also post an information note to the RTAI list today with the same information. Anyway, when the site is completed, I guess it will be a right moment to announce the project all over the map, starting from the lkml, etc. Yes, it's the plan, we should be doing this asap. -- Philippe.
Re: [Xenomai-core] [16550-patch] detect required context of RTSER_RTIOC_WAIT_EVENT
Jan Kiszka wrote:
Hi,
again thanks to a smart student reviewing my ugly code, here is another
minor fix for the serial driver.
Applied, thanks.
Jan
Index: drivers/16550A/16550A.c
===
--- drivers/16550A/16550A.c (revision 14)
+++ drivers/16550A/16550A.c (working copy)
@@ -516,8 +516,8 @@
}
-int rt_16550_ioctl_rt(struct rtdm_dev_context *context,
- rtdm_user_info_t *user_info, int request, void *arg)
+int rt_16550_ioctl(struct rtdm_dev_context *context,
+ rtdm_user_info_t *user_info, int request, void *arg)
{
struct rt_16550_context *ctx;
int ret = 0;
@@ -639,6 +639,9 @@
rtdm_lockctx_t lock_ctx;
rtdm_toseq_ttimeout_seq;
+if (!rtdm_in_rt_context())
+return -EPERM;
+
/* only one waiter allowed, stop any further attempts here */
if (test_and_set_bit(0, ctx-ioc_event_lock))
return -EBUSY;
@@ -980,8 +983,8 @@
close_rt: rt_16550_close,
close_nrt: rt_16550_close,
-ioctl_rt: rt_16550_ioctl_rt,
-ioctl_nrt: rt_16550_ioctl_rt,
+ioctl_rt: rt_16550_ioctl,
+ioctl_nrt: rt_16550_ioctl,
read_rt:rt_16550_read,
read_nrt: NULL,
@@ -999,7 +1002,7 @@
device_class: RTDM_CLASS_SERIAL,
device_sub_class: RTDM_SUBCLASS_16550A,
driver_name:rt_16550A,
-driver_version: RTDM_DRIVER_VER(1, 1, 0),
+driver_version: RTDM_DRIVER_VER(1, 1, 1),
peripheral_name:UART 16550A,
provider_name: Jan Kiszka,
};
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
--
Philippe.
[Xenomai-core] Re: [syscall.c] rt_bind_queue/heap()
Dmitry Adamushko wrote:
Philippe Gerum [EMAIL PROTECTED] wrote on 10.10.2005 13:09:13:
Dmitry Adamushko wrote:
Philippe Gerum [EMAIL PROTECTED] wrote on 05.10.2005 14:13:07:
Your patch is ok, my implementation was uselessly convoluted.
Ok, then it's enclosed.
2005-10-05 Dmitry Adamushko [EMAIL PROTECTED]
Applied, thanks.
...
btw,
It looks like something wrong with the xenomai mailing list. I have got
your answer but only one copy (you specified my own e-mail) and I
haven't got my own message on the list (but I've cc'ed xenomai-core).
Your mail to the list was blocked since you used an unregistered address to send
it (datacon.at).
One more thing. I had a discussion with Steven Seeger regarding the use
of NULL-named objects from the user space. I cc'ed you but probably you
were too buzy at that time. The problem is that one may create
successfully a NULL-named object but then there is no way to use it
since all further calls give an error (some funny stuff there indeed :)
So a simple fix would look like:
for all rt_OBJECT_create() calls in libnative:
int rt_mutex_create(RT_MUTEX *mutex, const char *name)
{
+ if (!name)
+ return -E_SOMETHING; // E_INVAL?
return XENOMAI_SKINCALL2(__xeno_muxid,
__xeno_mutex_create,
mutex,
name);
}
What do you think? Or are there any reasons to keep it as is now?
The reason is to allow anonymous objects to be created, so that the descriptor
could only be shared by tasks belonging to the same address space if they happen
to all have access to the descriptor's memory. Kind of semi-private object if
you want. The fact that such an object is non-bindable should not make it
unusable actually.
p.s. I have cc'ed xenomai-core@gna.org for both reasons to test the
mailing list and, well, maybe someone else has an opinion on the matter.
--
Philippe.
---
Best regards,
Dmitry
--
Philippe.
[Xenomai-core] Re: [syscall.c] rt_bind_queue/heap()
Philippe Gerum [EMAIL PROTECTED] wrote on 10.10.2005 13:09:13:
Dmitry Adamushko wrote:
Philippe Gerum [EMAIL PROTECTED] wrote on 05.10.2005 14:13:07:
Your patch is ok, my implementation was uselessly convoluted.
Ok, then it's enclosed.
2005-10-05 Dmitry Adamushko [EMAIL PROTECTED]
Applied, thanks.
...
btw,
It looks like something wrong with the xenomai mailing list. I have got your answer but only one copy (you specified my own e-mail) and I haven't got my own message on the list (but I've cc'ed xenomai-core).
One more thing. I had a discussion with Steven Seeger regarding the use of NULL-named objects from the user space. I cc'ed you but probably you were too buzy at that time. The problem is that one may create successfully a NULL-named object but then there is no way to use it since all further calls give an error (some funny stuff there indeed :)
So a simple fix would look like:
for all rt_OBJECT_create() calls in libnative:
int rt_mutex_create(RT_MUTEX *mutex, const char *name)
{
+ if (!name)
+ return -E_SOMETHING; // E_INVAL?
return XENOMAI_SKINCALL2(__xeno_muxid,
__xeno_mutex_create,
mutex,
name);
}
What do you think? Or are there any reasons to keep it as is now?
p.s. I have cc'ed xenomai-core@gna.org for both reasons to test the mailing list and, well, maybe someone else has an opinion on the matter.
--
Philippe.
---
Best regards,
Dmitry
[Xenomai-core] Re: [syscall.c] rt_bind_queue/heap()
Dmitry Adamushko wrote: snip So it must be fixed. There must be an explicit prohibition on creating NULL-named objects from the user-mode. ...Or, we might auto-generate some dummy name in native/syscalls.c we would pass to the registry when this situation arises, so that anonymous creation and use from user-space would still be possible. -- Philippe.
[Xenomai-core] Re: [syscall.c] rt_bind_queue/heap()
As you noticed below, the point is that this feature should be active for kernel-based code only; for user-space, we're toast: typical chicken-and-egg problem since we need the registry to cross the space boundaries but the registry requires a name to index the object first. So yes, we need to check for anonymous calls in every service taking a symbolic name in native/syscalls.c, and return -EINVAL when applicable. I thought that libnative would be a better place since this way we would avoid the user mode - kernel mode switch. ...Or, we might auto-generate some dummy name in native/syscalls.c we would pass to the registry when this situation arises, so that anonymous creation and use from user-space would still be possible. Yep, in this case a name would be a string == object's address, thus it's unique. Ok, I'd probably vote for the 2-nd approach. -- Philippe. --- Best regards, Dmitry
[Xenomai-core] Re: [syscall.c] rt_bind_queue/heap()
Dmitry Adamushko wrote: As you noticed below, the point is that this feature should be active for kernel-based code only; for user-space, we're toast: typical chicken-and-egg problem since we need the registry to cross the space boundaries but the registry requires a name to index the object first. So yes, we need to check for anonymous calls in every service taking a symbolic name in native/syscalls.c, and return -EINVAL when applicable. I thought that libnative would be a better place since this way we would avoid the user mode - kernel mode switch. ...Or, we might auto-generate some dummy name in native/syscalls.c we would pass to the registry when this situation arises, so that anonymous creation and use from user-space would still be possible. Yep, in this case a name would be a string == object's address, thus it's unique. Ok, I'd probably vote for the 2-nd approach. Definitely better since this keeps the semantics consistent across execution spaces. -- Philippe.
[Xenomai-core] Re: [syscall.c] rt_bind_queue/heap()
On 10/10/05, Philippe Gerum [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: As you noticed below, the point is that this feature should be active for kernel-based code only; for user-space, we're toast: typical chicken-and-egg problem since we need the registry to cross the space boundaries but the registry requires a name to index the object first. So yes, we need to check for anonymous calls in every service taking a symbolic name in native/syscalls.c, and return -EINVAL when applicable. I thought that libnative would be a better place since this way we would avoid the user mode - kernel mode switch. ...Or, we might auto-generate some dummy name in native/syscalls.c we would pass to the registry when this situation arises, so that anonymous creation and use from user-space would still be possible. Yep, in this case a name would be a string == object's address, thus it's unique. Ok, I'd probably vote for the 2-nd approach. Definitely better since this keeps the semantics consistent across execution spaces. Ok, will be done. -- Philippe. -- Best regards, Dmitry Adamushko
[Xenomai-core] Linux powerpc merger
Hello, As people following powerpc kernel mailing lists probably know, the Linux ppc and ppc64 architectures are merging into a single powerpc arch. I think the same should be done to fusion. It would seem quite easy and there's already lots of redundant code there, but possible problems arise from being able to work with both the old unmerged kernels and the future merged arch kernels. Is there any ideas regarding or work being done on this front? -- Heikki Lindholm
