Philippe Gerum wrote:
> Jim Cromie wrote:
> > Jim Cromie wrote:
> >> Niklaus Giger wrote:
> >>> Hi
> >>>
> >>> Following a suggestion from Philippe Gerum I propose to
> >>> collect and prepare like this:
> >>>
> >>> a) Make it easy to collect information
> >>>
> >>> add -s/-c option to xeno-test, h
Sorry, actually, 2.6.17 is not ready yet. I've read it on hurry... it is
actually a 2.6.16.7... Working perfectly fine with current patch...
Sorry for the confusion,
Rodrigo.
Em Terça 18 Abril 2006 18:08, Jan Kiszka escreveu:
>Rodrig
--- include/posix/pthread.h (revision 946)
+++ include/posix/pthread.h (working copy)
@@ -137,6 +137,7 @@ typedef struct
#include
#include_next
+#include
struct timespec;
[In order to use PTHREAD_WARNSW in userspace.]
Jan
signature.asc
Description: OpenPGP digital signature
__
Rodrigo Rosenfeld Rosas wrote:
> Just informing... (in the hope of downloading a new adeos patch soon ;) )
>
Go ahead and give it a try: my "port" for x86 to 2.6.16 was about fixing
4 failing hunks in the 2.6.15-patch (+ some minor namespace collision in
the posix skin).
Jan
signature.asc
De
heres another try, adjusting per Rodrigo's, Gilles' feedback,
and filling in from linux Kconfig and wikipedia on ACPI.
FYI, the latter is quite informative, esp on sleep states.
The speculative content continues - I dont mind being wrong,
esp when its temporary / corrected :-)
I held back a bi
Just informing... (in the hope of downloading a new adeos patch soon ;) )
Regards,
Rodrigo.
___
Abra sua conta no Yahoo! Mail: 1GB de espaço, alertas de e-mail no celular e
anti-spam realmente eficaz.
http://br.info.mail.yah
Niklaus Giger wrote:
> But I would be very interested in knowing exactly which kind of information
> the core developers are interested in. How should it be presented? In
> tabular
> form? Graphs, which ones? And kind of feedback will be evaluated and
> integrated.
I did some similar work
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
> > Is this worth doing also ?
>
> Some deeply embedded stuff (something like buried in the silicon
> actually...) might configure out CONFIG_PROC_FS, so we can't rely on
> this pseudo-fs to be always present.
Maybe we could use the info
Jim Cromie wrote:
> perhaps as a 4th number on the version, that way xeno-config can stay as is.
>
> [EMAIL PROTECTED] bin]# ./xeno-config --version
> 2.1.50
> Id like instead:
> 2.1.50.941
>
> This seems better than pokinh around a filesystem, looking for the
> xenomai svn
> (which ma
Philippe Gerum wrote:
> > Is this worth doing also ?
>
> Some deeply embedded stuff (something like buried in the silicon
> actually...) might configure out CONFIG_PROC_FS, so we can't rely on
> this pseudo-fs to be always present.
Maybe we could use the information if available?
--
Jim Cromie wrote:
> The -M option works, since I just received an email Id sent earlier,
> but I also sent one to xenomai-core, and it hasnt shown up yet.
In order to avoid spam, the xenomai-core list probably only accept mail
from registered members.
--
Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
> > Philippe Gerum wrote:
> > >
> > > -ENOPARSE here. Which code is expected to call xeno_mlock_alert_end()?
> >
> > pthread_set_mode_np and rt_task_set_mode. Sorry.
>
> The issue I see doing so, is that you are going to trigger a SIG
just to follow up:
I built a xeno-kernel for my laptop, the sep flag was on,
so it was Fedora specific. I asked on fedora-list,
got this answer:
> This is pretty obscure, and I havent seen any problems because of it,
> but it is a bit odd.
>
> Can someone(s)
> - confirm its absence on 2.6.1
Jim Cromie wrote:
Jim Cromie wrote:
Niklaus Giger wrote:
Hi
Following a suggestion from Philippe Gerum I propose to collect and
prepare like this:
a) Make it easy to collect information
add -s/-c option to xeno-test, help text would look like -s
send output of xeno-test to [EMAI
Jim Cromie wrote:
Gilles Chanteperdrix wrote:
For review...
+#ifndef __KERNEL__
+#include
+#include
+#include
+#include
+
+static inline void xeno_x86_features_check(void)
+{
+#ifdef CONFIG_XENO_X86_SEP
+ size_t n = confstr(_CS_GNU_LIBPTHREAD_VERSION, NULL, 0);
+ if (n > 0)
+ {
Jim Cromie wrote:
Niklaus Giger wrote:
Hi
Following a suggestion from Philippe Gerum I propose to collect and
prepare like this:
a) Make it easy to collect information
add -s/-c option to xeno-test, help text would look like -s
send output of xeno-test to [EMAIL PROTECTED]
-c if
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
>
> -ENOPARSE here. Which code is expected to call xeno_mlock_alert_end()?
pthread_set_mode_np and rt_task_set_mode. Sorry.
The issue I see doing so, is that you are going to trigger a SIGXCPU
right after setting the XNTRAPSW bit for the c
Gilles Chanteperdrix wrote:
For review...
+#ifndef __KERNEL__
+#include
+#include
+#include
+#include
+
+static inline void xeno_x86_features_check(void)
+{
+#ifdef CONFIG_XENO_X86_SEP
+ size_t n = confstr(_CS_GNU_LIBPTHREAD_VERSION, NULL, 0);
+ if (n > 0)
+ {
since this is u
Philippe Gerum wrote:
>
> -ENOPARSE here. Which code is expected to call xeno_mlock_alert_end()?
pthread_set_mode_np and rt_task_set_mode. Sorry.
--
Gilles Chanteperdrix.
Index: include/asm-i386/features.h
=
Gilles Chanteperdrix wrote:
For review...
Index: include/asm-i386/features.h
===
--- include/asm-i386/features.h (revision 941)
+++ include/asm-i386/feature
For review...
--
Gilles Chanteperdrix.
Index: include/asm-i386/features.h
===
--- include/asm-i386/features.h (revision 941)
+++ include/asm-i386/features.h (working copy)
@@ -76,4 +76,3
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi,
this patch aims at avoiding to select unneeded nucleus features if no
user is requiring it in the skins. Particularly, it addresses the
nucleus registry and the pipes.
I have spent no
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>
>>> Jan Kiszka wrote:
>>>
Hi,
this patch aims at avoiding to select unneeded nucleus features if no
user is requiring it in the skins. Particularly, it addresses the
nucleus registry and the pipes.
>
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi,
this patch aims at avoiding to select unneeded nucleus features if no
user is requiring it in the skins. Particularly, it addresses the
nucleus registry and the pipes.
I have spent no effort on 2.4 yet as I first want to wait for
24 matches
Mail list logo
