* [Xenomai-help] Re: Problems using Xenoscope
From: Bernhard Walle @ 2006-04-09 9:00 UTC (permalink / raw)
To: xenomai
In-Reply-To: <443826D4.9070507@domain.hid>
Hello,
Philippe Gerum <rpm@xenomai.org> [2006-04-08]:
> Bernhard Walle wrote:
> > Hello,
> >
> > I have problems using Xenoscope (Xenomai 2.1.0, Xenosim 2.1). The
> > simulation works, i.e. text messages are printed on the console. I use
> > the example from
> > http://www.mail-archive.com/xenomai@xenomai.org.
> >
> > The problem is that the traces dialog is empty, there are also no items
> > in the tree, only
> >
> > - System
> > -RT/Interfaces
> >
>
> It's not a bug, it's just that the tracer and some other interface
> objects are still missing.
Just wondering at
http://www.linux-automation.de/konferenz/papers/Jan_Kiszka_UNI-HANNOVER_RTAI/RTAI-fusion.pdf
I can see more functionality? Is this because this is RTAI Fusion 0.9
and I'm trying Xenomai 2.1?
Regards,
Bernhard
^ permalink raw reply
* [PATCH] log-tree: separate major part of diff-tree.
From: Junio C Hamano @ 2006-04-09 9:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
This separates out the part that deals with one-commit diff-tree
(and --stdin form) into a separate log-tree module.
There are two goals with this. The more important one is to be
able to make this part available to "git log --diff", so that we
can have a native "git whatchanged" command. Another is to
simplify the commit log generation part simpler.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* I tried to be very careful while doing this, to make sure
there is no behaviour change. This is a preparation step for
the next one, which is...
Makefile | 4 +
diff-tree.c | 226 ++++++-----------------------------------------------------
log-tree.c | 175 ++++++++++++++++++++++++++++++++++++++++++++++
log-tree.h | 23 ++++++
4 files changed, 224 insertions(+), 204 deletions(-)
create mode 100644 log-tree.c
create mode 100644 log-tree.h
5f1c3f07b7f4a8436c7773b8e7a04998190c125e
diff --git a/Makefile b/Makefile
index 6b10eaa..b272146 100644
--- a/Makefile
+++ b/Makefile
@@ -194,12 +194,12 @@ LIB_H = \
blob.h cache.h commit.h csum-file.h delta.h \
diff.h object.h pack.h pkt-line.h quote.h refs.h \
run-command.h strbuf.h tag.h tree.h git-compat-util.h revision.h \
- tree-walk.h
+ tree-walk.h log-tree.h
DIFF_OBJS = \
diff.o diffcore-break.o diffcore-order.o diffcore-pathspec.o \
diffcore-pickaxe.o diffcore-rename.o tree-diff.o combine-diff.o \
- diffcore-delta.o
+ diffcore-delta.o log-tree.o
LIB_OBJS = \
blob.o commit.o connect.o csum-file.o \
diff --git a/diff-tree.c b/diff-tree.c
index d1265d7..2a088d1 100644
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -1,152 +1,16 @@
#include "cache.h"
#include "diff.h"
#include "commit.h"
+#include "log-tree.h"
-static int show_root_diff = 0;
-static int no_commit_id = 0;
-static int verbose_header = 0;
-static int ignore_merges = 1;
-static int combine_merges = 0;
-static int dense_combined_merges = 0;
-static int read_stdin = 0;
-static int always_show_header = 0;
+static struct log_tree_opt log_tree_opt;
-static const char *header = NULL;
-static const char *header_prefix = "";
-static enum cmit_fmt commit_format = CMIT_FMT_RAW;
-
-static struct diff_options diff_options;
-
-static int call_diff_flush(void)
-{
- diffcore_std(&diff_options);
- if (diff_queue_is_empty()) {
- int saved_fmt = diff_options.output_format;
- diff_options.output_format = DIFF_FORMAT_NO_OUTPUT;
- diff_flush(&diff_options);
- diff_options.output_format = saved_fmt;
- return 0;
- }
- if (header) {
- if (!no_commit_id)
- printf("%s%c", header, diff_options.line_termination);
- header = NULL;
- }
- diff_flush(&diff_options);
- return 1;
-}
-
-static int diff_tree_sha1_top(const unsigned char *old,
- const unsigned char *new, const char *base)
-{
- int ret;
-
- ret = diff_tree_sha1(old, new, base, &diff_options);
- call_diff_flush();
- return ret;
-}
-
-static int diff_root_tree(const unsigned char *new, const char *base)
-{
- int retval;
- void *tree;
- struct tree_desc empty, real;
-
- tree = read_object_with_reference(new, tree_type, &real.size, NULL);
- if (!tree)
- die("unable to read root tree (%s)", sha1_to_hex(new));
- real.buf = tree;
-
- empty.buf = "";
- empty.size = 0;
- retval = diff_tree(&empty, &real, base, &diff_options);
- free(tree);
- call_diff_flush();
- return retval;
-}
-
-static const char *generate_header(const unsigned char *commit_sha1,
- const unsigned char *parent_sha1,
- const struct commit *commit)
-{
- static char this_header[16384];
- int offset;
- unsigned long len;
- int abbrev = diff_options.abbrev;
- const char *msg = commit->buffer;
-
- if (!verbose_header)
- return sha1_to_hex(commit_sha1);
-
- len = strlen(msg);
-
- offset = sprintf(this_header, "%s%s ",
- header_prefix,
- diff_unique_abbrev(commit_sha1, abbrev));
- if (commit_sha1 != parent_sha1)
- offset += sprintf(this_header + offset, "(from %s)\n",
- parent_sha1
- ? diff_unique_abbrev(parent_sha1, abbrev)
- : "root");
- else
- offset += sprintf(this_header + offset, "(from parents)\n");
- offset += pretty_print_commit(commit_format, commit, len,
- this_header + offset,
- sizeof(this_header) - offset, abbrev);
- if (always_show_header) {
- puts(this_header);
- return NULL;
- }
- return this_header;
-}
-
-static int diff_tree_commit(struct commit *commit)
-{
- struct commit_list *parents;
- unsigned const char *sha1 = commit->object.sha1;
-
- /* Root commit? */
- if (show_root_diff && !commit->parents) {
- header = generate_header(sha1, NULL, commit);
- diff_root_tree(sha1, "");
- }
-
- /* More than one parent? */
- if (commit->parents && commit->parents->next) {
- if (ignore_merges)
- return 0;
- else if (combine_merges) {
- header = generate_header(sha1, sha1, commit);
- header = diff_tree_combined_merge(sha1, header,
- dense_combined_merges,
- &diff_options);
- if (!header && verbose_header)
- header_prefix = "\ndiff-tree ";
- return 0;
- }
- }
-
- for (parents = commit->parents; parents; parents = parents->next) {
- struct commit *parent = parents->item;
- header = generate_header(sha1, parent->object.sha1, commit);
- diff_tree_sha1_top(parent->object.sha1, sha1, "");
- if (!header && verbose_header) {
- header_prefix = "\ndiff-tree ";
- /*
- * Don't print multiple merge entries if we
- * don't print the diffs.
- */
- }
- }
- return 0;
-}
-
static int diff_tree_commit_sha1(const unsigned char *sha1)
{
struct commit *commit = lookup_commit_reference(sha1);
if (!commit)
return -1;
- return diff_tree_commit(commit);
+ return log_tree_commit(&log_tree_opt, commit);
}
static int diff_tree_stdin(char *line)
@@ -184,7 +48,7 @@ static int diff_tree_stdin(char *line)
pos += 41;
}
}
- return diff_tree_commit(commit);
+ return log_tree_commit(&log_tree_opt, commit);
}
static const char diff_tree_usage[] =
@@ -200,13 +64,15 @@ int main(int argc, const char **argv)
char line[1000];
unsigned char sha1[2][20];
const char *prefix = setup_git_directory();
+ static struct log_tree_opt *opt = &log_tree_opt;
+ int read_stdin = 0;
git_config(git_diff_config);
nr_sha1 = 0;
- diff_setup(&diff_options);
+ init_log_tree_opt(opt);
for (;;) {
- int diff_opt_cnt;
+ int opt_cnt;
const char *arg;
argv++;
@@ -223,84 +89,39 @@ int main(int argc, const char **argv)
break;
}
- diff_opt_cnt = diff_opt_parse(&diff_options, argv, argc);
- if (diff_opt_cnt < 0)
+ opt_cnt = log_tree_opt_parse(opt, argv, argc);
+ if (opt_cnt < 0)
usage(diff_tree_usage);
- else if (diff_opt_cnt) {
- argv += diff_opt_cnt - 1;
- argc -= diff_opt_cnt - 1;
+ else if (opt_cnt) {
+ argv += opt_cnt - 1;
+ argc -= opt_cnt - 1;
continue;
}
-
if (!strcmp(arg, "--")) {
argv++;
argc--;
break;
- }
- if (!strcmp(arg, "-r")) {
- diff_options.recursive = 1;
- continue;
- }
- if (!strcmp(arg, "-t")) {
- diff_options.recursive = 1;
- diff_options.tree_in_recursive = 1;
- continue;
- }
- if (!strcmp(arg, "-m")) {
- ignore_merges = 0;
- continue;
}
- if (!strcmp(arg, "-c")) {
- combine_merges = 1;
- continue;
- }
- if (!strcmp(arg, "--cc")) {
- dense_combined_merges = combine_merges = 1;
- continue;
- }
- if (!strcmp(arg, "-v")) {
- verbose_header = 1;
- header_prefix = "diff-tree ";
- continue;
- }
- if (!strncmp(arg, "--pretty", 8)) {
- verbose_header = 1;
- header_prefix = "diff-tree ";
- commit_format = get_commit_format(arg+8);
- continue;
- }
if (!strcmp(arg, "--stdin")) {
read_stdin = 1;
- continue;
- }
- if (!strcmp(arg, "--root")) {
- show_root_diff = 1;
- continue;
- }
- if (!strcmp(arg, "--no-commit-id")) {
- no_commit_id = 1;
- continue;
- }
- if (!strcmp(arg, "--always")) {
- always_show_header = 1;
continue;
}
usage(diff_tree_usage);
}
- if (combine_merges)
- ignore_merges = 0;
+ if (opt->combine_merges)
+ opt->ignore_merges = 0;
/* We can only do dense combined merges with diff output */
- if (dense_combined_merges)
- diff_options.output_format = DIFF_FORMAT_PATCH;
+ if (opt->dense_combined_merges)
+ opt->diffopt.output_format = DIFF_FORMAT_PATCH;
- if (diff_options.output_format == DIFF_FORMAT_PATCH)
- diff_options.recursive = 1;
+ if (opt->diffopt.output_format == DIFF_FORMAT_PATCH)
+ opt->diffopt.recursive = 1;
diff_tree_setup_paths(get_pathspec(prefix, argv));
- diff_setup_done(&diff_options);
+ diff_setup_done(&opt->diffopt);
switch (nr_sha1) {
case 0:
@@ -311,15 +132,16 @@ int main(int argc, const char **argv)
diff_tree_commit_sha1(sha1[0]);
break;
case 2:
- diff_tree_sha1_top(sha1[0], sha1[1], "");
+ diff_tree_sha1(sha1[0], sha1[1], "", &opt->diffopt);
+ log_tree_diff_flush(opt);
break;
}
if (!read_stdin)
return 0;
- if (diff_options.detect_rename)
- diff_options.setup |= (DIFF_SETUP_USE_SIZE_CACHE |
+ if (opt->diffopt.detect_rename)
+ opt->diffopt.setup |= (DIFF_SETUP_USE_SIZE_CACHE |
DIFF_SETUP_USE_CACHE);
while (fgets(line, sizeof(line), stdin))
diff_tree_stdin(line);
diff --git a/log-tree.c b/log-tree.c
new file mode 100644
index 0000000..3d40482
--- /dev/null
+++ b/log-tree.c
@@ -0,0 +1,175 @@
+#include "cache.h"
+#include "diff.h"
+#include "commit.h"
+#include "log-tree.h"
+
+void init_log_tree_opt(struct log_tree_opt *opt)
+{
+ memset(opt, 0, sizeof *opt);
+ opt->ignore_merges = 1;
+ opt->header_prefix = "";
+ opt->commit_format = CMIT_FMT_RAW;
+ diff_setup(&opt->diffopt);
+}
+
+int log_tree_opt_parse(struct log_tree_opt *opt, const char **av, int ac)
+{
+ const char *arg;
+ int cnt = diff_opt_parse(&opt->diffopt, av, ac);
+ if (0 < cnt)
+ return cnt;
+ arg = *av;
+ if (!strcmp(arg, "-r"))
+ opt->diffopt.recursive = 1;
+ else if (!strcmp(arg, "-t")) {
+ opt->diffopt.recursive = 1;
+ opt->diffopt.tree_in_recursive = 1;
+ }
+ else if (!strcmp(arg, "-m"))
+ opt->ignore_merges = 0;
+ else if (!strcmp(arg, "-c"))
+ opt->combine_merges = 1;
+ else if (!strcmp(arg, "--cc")) {
+ opt->dense_combined_merges = 1;
+ opt->combine_merges = 1;
+ }
+ else if (!strcmp(arg, "-v")) {
+ opt->verbose_header = 1;
+ opt->header_prefix = "diff-tree ";
+ }
+ else if (!strncmp(arg, "--pretty", 8)) {
+ opt->verbose_header = 1;
+ opt->header_prefix = "diff-tree ";
+ opt->commit_format = get_commit_format(arg+8);
+ }
+ else if (!strcmp(arg, "--root"))
+ opt->show_root_diff = 1;
+ else if (!strcmp(arg, "--no-commit-id"))
+ opt->no_commit_id = 1;
+ else if (!strcmp(arg, "--always"))
+ opt->always_show_header = 1;
+ else
+ return 0;
+ return 1;
+}
+
+int log_tree_diff_flush(struct log_tree_opt *opt)
+{
+ diffcore_std(&opt->diffopt);
+ if (diff_queue_is_empty()) {
+ int saved_fmt = opt->diffopt.output_format;
+ opt->diffopt.output_format = DIFF_FORMAT_NO_OUTPUT;
+ diff_flush(&opt->diffopt);
+ opt->diffopt.output_format = saved_fmt;
+ return 0;
+ }
+ if (opt->header) {
+ if (!opt->no_commit_id)
+ printf("%s%c", opt->header,
+ opt->diffopt.line_termination);
+ opt->header = NULL;
+ }
+ diff_flush(&opt->diffopt);
+ return 1;
+}
+
+static int diff_root_tree(struct log_tree_opt *opt,
+ const unsigned char *new, const char *base)
+{
+ int retval;
+ void *tree;
+ struct tree_desc empty, real;
+
+ tree = read_object_with_reference(new, tree_type, &real.size, NULL);
+ if (!tree)
+ die("unable to read root tree (%s)", sha1_to_hex(new));
+ real.buf = tree;
+
+ empty.buf = "";
+ empty.size = 0;
+ retval = diff_tree(&empty, &real, base, &opt->diffopt);
+ free(tree);
+ log_tree_diff_flush(opt);
+ return retval;
+}
+
+static const char *generate_header(struct log_tree_opt *opt,
+ const unsigned char *commit_sha1,
+ const unsigned char *parent_sha1,
+ const struct commit *commit)
+{
+ static char this_header[16384];
+ int offset;
+ unsigned long len;
+ int abbrev = opt->diffopt.abbrev;
+ const char *msg = commit->buffer;
+
+ if (!opt->verbose_header)
+ return sha1_to_hex(commit_sha1);
+
+ len = strlen(msg);
+
+ offset = sprintf(this_header, "%s%s ",
+ opt->header_prefix,
+ diff_unique_abbrev(commit_sha1, abbrev));
+ if (commit_sha1 != parent_sha1)
+ offset += sprintf(this_header + offset, "(from %s)\n",
+ parent_sha1
+ ? diff_unique_abbrev(parent_sha1, abbrev)
+ : "root");
+ else
+ offset += sprintf(this_header + offset, "(from parents)\n");
+ offset += pretty_print_commit(opt->commit_format, commit, len,
+ this_header + offset,
+ sizeof(this_header) - offset, abbrev);
+ if (opt->always_show_header) {
+ puts(this_header);
+ return NULL;
+ }
+ return this_header;
+}
+
+static int do_diff_combined(struct log_tree_opt *opt, struct commit *commit)
+{
+ unsigned const char *sha1 = commit->object.sha1;
+
+ opt->header = generate_header(opt, sha1, sha1, commit);
+ opt->header = diff_tree_combined_merge(sha1, opt->header,
+ opt->dense_combined_merges,
+ &opt->diffopt);
+ if (!opt->header && opt->verbose_header)
+ opt->header_prefix = "\ndiff-tree ";
+ return 0;
+}
+
+int log_tree_commit(struct log_tree_opt *opt, struct commit *commit)
+{
+ struct commit_list *parents;
+ unsigned const char *sha1 = commit->object.sha1;
+
+ /* Root commit? */
+ if (opt->show_root_diff && !commit->parents) {
+ opt->header = generate_header(opt, sha1, NULL, commit);
+ diff_root_tree(opt, sha1, "");
+ }
+
+ /* More than one parent? */
+ if (commit->parents && commit->parents->next) {
+ if (opt->ignore_merges)
+ return 0;
+ else if (opt->combine_merges)
+ return do_diff_combined(opt, commit);
+ }
+
+ for (parents = commit->parents; parents; parents = parents->next) {
+ struct commit *parent = parents->item;
+ unsigned const char *psha1 = parent->object.sha1;
+ opt->header = generate_header(opt, sha1, psha1, commit);
+ diff_tree_sha1(psha1, sha1, "", &opt->diffopt);
+ log_tree_diff_flush(opt);
+
+ if (!opt->header && opt->verbose_header)
+ opt->header_prefix = "\ndiff-tree ";
+ }
+ return 0;
+}
diff --git a/log-tree.h b/log-tree.h
new file mode 100644
index 0000000..da166c6
--- /dev/null
+++ b/log-tree.h
@@ -0,0 +1,23 @@
+#ifndef LOG_TREE_H
+#define LOG_TREE_H
+
+struct log_tree_opt {
+ struct diff_options diffopt;
+ int show_root_diff;
+ int no_commit_id;
+ int verbose_header;
+ int ignore_merges;
+ int combine_merges;
+ int dense_combined_merges;
+ int always_show_header;
+ const char *header_prefix;
+ const char *header;
+ enum cmit_fmt commit_format;
+};
+
+void init_log_tree_opt(struct log_tree_opt *);
+int log_tree_diff_flush(struct log_tree_opt *);
+int log_tree_commit(struct log_tree_opt *, struct commit *);
+int log_tree_opt_parse(struct log_tree_opt *, const char **, int);
+
+#endif
--
1.2.6.gad0b
^ permalink raw reply related
* (no subject)
From: root @ 2006-04-09 9:04 UTC (permalink / raw)
To: linux-kernel
^ permalink raw reply
* [PATCH] git log [diff-tree options]...
From: Junio C Hamano @ 2006-04-09 9:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
And this makes "git log" to take common diff-tree options, so
that it can be used as "git whatchanged".
The recent revision walker updates by Linus to make path
limiting low-latency helps this quite a bit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git.c | 32 +++++++++++++++++++++++++++++++-
1 files changed, 31 insertions(+), 1 deletions(-)
52b70d56bd23811003a72866cc23a0a44b9da1b7
diff --git a/git.c b/git.c
index fa58232..8776088 100644
--- a/git.c
+++ b/git.c
@@ -16,6 +16,8 @@ #include "common-cmds.h"
#include "cache.h"
#include "commit.h"
#include "revision.h"
+#include "diff.h"
+#include "log-tree.h"
#ifndef PATH_MAX
# define PATH_MAX 4096
@@ -285,7 +287,10 @@ static int cmd_log(int argc, const char
int abbrev = DEFAULT_ABBREV;
int abbrev_commit = 0;
const char *commit_prefix = "commit ";
+ struct log_tree_opt opt;
+ int do_diff = 0;
+ init_log_tree_opt(&opt);
argc = setup_revisions(argc, argv, &rev, "HEAD");
while (1 < argc) {
const char *arg = argv[1];
@@ -310,9 +315,31 @@ static int cmd_log(int argc, const char
else if (40 < abbrev)
abbrev = 40;
}
- else
+ else {
+ int cnt = log_tree_opt_parse(&opt, argv+1, argc-1);
+ if (0 < cnt) {
+ do_diff = 1;
+ argv += cnt;
+ argc -= cnt;
+ continue;
+ }
die("unrecognized argument: %s", arg);
+ }
+
argc--; argv++;
+ }
+ if (do_diff) {
+ opt.diffopt.abbrev = abbrev;
+ opt.verbose_header = 0;
+ opt.always_show_header = 0;
+ opt.no_commit_id = 1;
+ if (opt.combine_merges)
+ opt.ignore_merges = 0;
+ if (opt.dense_combined_merges)
+ opt.diffopt.output_format = DIFF_FORMAT_PATCH;
+ if (opt.diffopt.output_format == DIFF_FORMAT_PATCH)
+ opt.diffopt.recursive = 1;
+ diff_setup_done(&opt.diffopt);
}
prepare_revision_walk(&rev);
@@ -350,6 +377,9 @@ static int cmd_log(int argc, const char
pretty_print_commit(commit_format, commit, ~0, buf,
LOGSIZE, abbrev);
printf("%s\n", buf);
+
+ if (do_diff)
+ log_tree_commit(&opt, commit);
}
free(buf);
return 0;
--
1.2.6.gad0b
^ permalink raw reply related
* Re: [PATCH] git log [diff-tree options]...
From: Junio C Hamano @ 2006-04-09 9:16 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <7v7j5zce7x.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> And this makes "git log" to take common diff-tree options, so
> that it can be used as "git whatchanged".
BTW, this is *not* "whatchanged" in that it does not omit the
log when there is no diff output. It may not matter much --
when we give paths limiter to the command, the commits that are
shown are already limited by those paths limiter.
^ permalink raw reply
* Re: [Devel] Re: [PATCH 3/7] uts namespaces: use init_utsname when appropriate
From: Eric W. Biederman @ 2006-04-09 9:25 UTC (permalink / raw)
To: Kir Kolyshkin
Cc: devel, Sam Vilain, linux-kernel, herbert, Serge E. Hallyn,
James Morris
In-Reply-To: <4438518A.1040801@openvz.org>
Kir Kolyshkin <kir@openvz.org> writes:
> Sam Vilain wrote:
>
>>On Sat, 2006-04-08 at 01:09 -0600, Eric W. Biederman wrote:
>>
>>
>>>>-#define ELF_PLATFORM (system_utsname.machine)
>>>>+#define ELF_PLATFORM (init_utsname()->machine)
>>>> #ifdef __KERNEL__
>>>> #define SET_PERSONALITY(ex, ibcs2) do { } while (0)
>>>>
>>>>
>>>I think this one needs to be utsname()->machine.
>>>Currently it doesn't matter. But Herbert has expressed
>>>the desire to make a machine appear like an older one.
>>>
>>>
>>
>>This is extremely useful for faking it as "i386" on x86_64 systems, for
>>instance.
>>
>>
> Could 'setarch' be of any help here? Works fine for us. Or am I missing
> something?
For the specific case that is clearly the better solution,
as it already exists, and it handles the weird 32/64bit
logic. The ELF_PLATFORM bit I was commenting on was 32bit
only.
I'm not ready to implement any new functionality at the moment,
but what I heard suggested and was it may be reasonable to allow
machine to be modified on a per uts namespace basis. If that
kind of thing is ever to happen ELF_PLATFORM needs to be per
uts on x86. Actually allowing modification of machine is
an entirely different conversation.
Eric
^ permalink raw reply
* Re: [Xenomai-core] Frozen timer IRQ - now traced with kgdb :)
From: Philippe Gerum @ 2006-04-09 9:40 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai-core
In-Reply-To: <4436A8D2.2060603@domain.hid>
Jan Kiszka wrote:
>
>
> Yep, I dug deeper meanwhile and also came across this.
>
> I already have a trivial hack running here. The most tricky part for me
> was to learn quilt, but now I start to love it :). Here is a snapshot
> series for 2.6.15.5:
>
> <kgdb series from CVS>
> prepare-ipipe-x86.patch
> adeos-ipipe-2.6.15-i386-1.2-01.patch
> kgdb-ipipe-x86.patch
>
In order to ease patch maintenance, we should move the relevant portions
of this infrastructure to the I-pipe patch directly (i.e. I-pipe
specific kgdb-ipipe-* code).
> I'm currently wondering if it makes sense to register a kgdb domain and
> "officially" capture all involved IRQs and events. So far the serial
> line IRQ is hard-coded (should be retrieved from some internal kgdb
> structure later). Anyway, it seems to work quite well, I'm currently
> stepping through a network IRQ at ipipe-level.
>
Having a separate domain would allow to break into any runaway code from
lower priority domains even with disabled interrupts, except the ipipe
itself. This said, pushing a domain on top of Xenomai would break the
assumption that hw interrupts are indeed disabled when operating due to
the 'last domain optimization' feature, and introduce additional
jittery. The other option would be to install a KGDB 'redirector' in
__ipipe_handle_irq so that serial or network interrupts to KGDB would
never be blocked by the stall bit; I would actually prefer this one.
>
> While playing with this tool a bit, displaying the the ipipe structures,
> and thinking about the original problem again, I wondered what could
> cause a temporary (as I think to found out now) stalled xeno domain
> without locking up the system? Some irq-lock leaks at driver level (i.e.
> inside our own code)?
>
At first sight, it might be related to the way __ipipe_unstall_iret_root
operates. Basically, the idea is to make sure that the stall flag of the
root domain upon return from the pipelining process always reflects the
state of the hw interrupt flag at the time the processed event was taken
by the CPU. It seems that your testcase shows that under some
cicumstances, the root stage might be spuriously left in a stalled state
by __ipipe_unstall_iret_root.
--
Philippe.
^ permalink raw reply
* [lm-sensors] i2c-i801 and i2c-i810 can't see 82845G
From: Andrew @ 2006-04-09 9:42 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <44389EC6.4060402@donehue.net>
An HTML attachment was scrubbed...
URL: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060409/10bcc98c/attachment.html
^ permalink raw reply
* [ALSA - driver 0002013]: no digital output
From: bugtrack @ 2006-04-09 9:43 UTC (permalink / raw)
To: alsa-devel
The following issue has been SUBMITTED.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2013>
======================================================================
Reported By: SamiH
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 2013
Category: PCI - via82xx
Reproducibility: always
Severity: major
Priority: normal
Status: new
Distribution: BLFS
Kernel Version: 2.6.15.4
======================================================================
Date Submitted: 04-09-2006 11:43 CEST
Last Modified: 04-09-2006 11:43 CEST
======================================================================
Summary: no digital output
Description:
Shortly: Digital output doesn't work at all, or I don't know how to use
it.
This has been my problem quite long time now. I have upgraded my kernel
from 2.6.8 to 2.6.15.4 with some steps bitween those versions, and the
problem is still here. I have tried some live-cds with same results as my
stable system.
Analog stereo output works with no problems. If someone did tell me what I
should test on my system so that I could give the results to you.
These aren't broken:
* my external amplifier
* the digital coaxial cable
* speakers etc.
Please tell me at least what to do, what to search for, or something...
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
04-09-06 11:43 SamiH New Issue
04-09-06 11:43 SamiH Distribution => BLFS
04-09-06 11:43 SamiH Kernel Version => 2.6.15.4
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: Union diff
From: Junio C Hamano @ 2006-04-09 9:45 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060326102100.GF18185@pasky.or.cz>
Petr Baudis <pasky@ucw.cz> writes:
> Now, the -c option documentation says:
>
> It shows the differences from each of the parents to the merge
> result simultaneously, instead of showing pairwise diff between
> a parent and the result one at a time, which '-m' option output
> does.
>
> This sounds as exactly what I want. Well, the only problem is that the
> same diff command as above with -c option added produces no diff at all,
> just the header and commit messages. Did I misunderstand the -c
> description and does it do something different?
The --combined diff option is to show merges more sensibly than
plain -m option. Now, the definition of "sensible" is to say
that a merge is not interesting if it takes a version from one
of the parents. The paths whose results do not match any of the
parents' version are deemed interesting and are shown.
I think you could tweak and give an option to intersect_paths()
in combine-diff.c, so that paths that match one of the parents
are also included in the output. I haven't thought about it too
much, but my gut feeling is it would not be very involved
change.
^ permalink raw reply
* Re: [PATCH 3/7] uts namespaces: use init_utsname when appropriate
From: Eric W. Biederman @ 2006-04-09 9:44 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: linux-kernel, Kirill Korotaev, herbert, devel, sam, xemul,
James Morris
In-Reply-To: <20060408202701.GA26403@sergelap.austin.ibm.com>
"Serge E. Hallyn" <serue@us.ibm.com> writes:
>> This also probably makes sense as utsname(). It doesn't
>> really matter as this is before init is executed. But logically
>> this is a user space or per namespace action.
>
> Right, I was kind of favoring using init_utsname() for anything
> __init. But utsname() will of course work just as well there.
Basically anything that should move to klibc I favor using
utsname() for. That tends to make it clear it follows
the usual user space rules.
With a little luck HPA might actually have this code deleted
in -mm before we get to far.
>> > diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
>> > index aa8965e..97c8439 100644
>> > --- a/net/sunrpc/clnt.c
>> > +++ b/net/sunrpc/clnt.c
>> > @@ -176,10 +176,10 @@ rpc_new_client(struct rpc_xprt *xprt, ch
>> > }
>> >
>> > /* save the nodename */
>> > - clnt->cl_nodelen = strlen(system_utsname.nodename);
>> > + clnt->cl_nodelen = strlen(init_utsname()->nodename);
>> > if (clnt->cl_nodelen > UNX_MAXNODENAME)
>> > clnt->cl_nodelen = UNX_MAXNODENAME;
>> > - memcpy(clnt->cl_nodename, system_utsname.nodename, clnt->cl_nodelen);
>> > + memcpy(clnt->cl_nodename, init_utsname()->nodename, clnt->cl_nodelen);
>> > return clnt;
>> >
>> > out_no_auth:
>>
>> Using nodename is practically the definition of something
>> that should per namespace I think. Plus it would be really inconsistent
>> to use utsname() and the init_utsname for the nfs rpc calls.
>>
>> Unless I am missing something.
>
> It seemed like this would be happening in any old context, so that
> current->uts_ns could be any process'. Tracing it back further,
> it seems like nfs+lockd should have the context available. So I'll
> switch this as well.
I have not traced that path recently. So I don't remember.
This is one of those odd cases that makes a real difference.
This reminds me of another piece of the conversation.
kernel_thread vs. kthread, and the oddities of daemonize.
In general user space cannot kill kernel threads, so having
a kernel thread inside a namespace is dangerous because it
means the namespace can never exit.
There are two ways to avoid the associated problems.
- modify daemonize to always use the instance of that
namespace associated with init_task.
- modify all interesting kernel threads to use the
kthread api instead of kernel_thread. Using kthread
makes the kernel threads children of keventd and always
in the initial namespace instance. As such we know
we aren't inside of any user space namespace instance.
Eric
^ permalink raw reply
* How to correct ELCR? - was Re: [PATCH 2.6.16] Shared interrupts sometimes lost
From: Neil Brown @ 2006-04-09 9:48 UTC (permalink / raw)
To: Robert Hancock; +Cc: linux-kernel
In-Reply-To: <4437C45E.8010503@shaw.ca>
On Saturday April 8, hancockr@shaw.ca wrote:
> Neil Brown wrote:
> > However there is room for a race here. If an event occurs between
> > the read and the write, then this will NOT de-assert the IRQ line.
> > It will remain asserted throughout.
> >
> > Now if the IRQ is handled as an edge-triggered line (which I believe
> > they are in Linux), then losing this race will mean that we don't see
> > any more interrupts on this line.
>
> PCI interrupts should always be level triggered, not edge triggered
Ok... so I guess I jumped to the wrong conclusion. Thanks for
straightening me out.
But it is behaving like edge-triggered..
So I have explored about the i8259 (wikipedia helped) and discovered
the ELCR (Edge/Level Control Register). Apparently this is meant to
be set up by the BIOS to the correct values. It seems that this isn't
happening.
It seems to get the value 0x0800 which corresponds to IRQ11 being the
only level-triggered interrupt. But I need IRQ10 to be level
triggered. I hacked the code to set the 0x0400 bit, and it seems to
work OK without my other patch.
Now I just need a way to set this correctly at boot time without a
hack.
I currently have Linux compiled without ACPI support (as I don't
really want that and being an oldish notebook I gather it has a good
chance of causing problems) so that isn't fiddling with the ELCR.
So thank you for helping me a step further in understand, but now I
have a new question:
How can I make sure the ELCR is set correctly?
and I guess,
What is the correct setting?
My /proc/interrupts is below.
Thanks.
NeilBrown
CPU0
0: 505852 XT-PIC timer
1: 10 XT-PIC i8042
2: 0 XT-PIC cascade
4: 10 XT-PIC serial
8: 4 XT-PIC rtc
10: 16442 XT-PIC yenta, yenta, ohci_hcd:usb1, ohci_hcd:usb2, ehci_hcd:usb4, eth0
11: 0 XT-PIC uhci_hcd:usb3
12: 110 XT-PIC i8042
14: 5114 XT-PIC ide0
15: 38 XT-PIC ide1
NMI: 0
ERR: 0
^ permalink raw reply
* [lm-sensors] i2c-i801 and i2c-i810 can't see 82845G
From: Jean Delvare @ 2006-04-09 9:53 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <44389EC6.4060402@donehue.net>
Andrew,
No HTML mail to the list please...
> Thank you for the speedy reply (and detailed explanation). Considering
> that the chipset doesn't have temp or voltage sensors, I wouldn't
> consider a module for this chip as very useful to me (so please feel
> free to remove the request you have put in - I don't want anyone
> wasting their time on my behalf).
It's still useful for us to have pointers to potential testers if a
driver is ever written, so I think I'll leave the reference to your
post. The number of requests is also a good hint of how popular a chip
is, even if you are not particularly interested in a driver.
> If I can get my C skills up in the future, I might have a crack at
> writing it myself.
Sure, why not. If you do, please let us know so that we avoid
duplicating the effort.
--
Jean Delvare
^ permalink raw reply
* Re: add new code section for kernel code
From: saeed bishara @ 2006-04-09 9:53 UTC (permalink / raw)
To: Arjan van de Ven, saeed bishara, Paolo Ornati, linux-kernel,
linux-arm-kernel, Linux-arm-toolchain
In-Reply-To: <20060407154349.GB31458@flint.arm.linux.org.uk>
> I'd prefer not to paper over such bugs. Maybe the following patch will
> fix the decompressor for saeed?
yes, this patch fixed the problem.
>
> diff --git a/arch/arm/boot/compressed/vmlinux.lds.in b/arch/arm/boot/compressed/vmlinux.lds.in
> --- a/arch/arm/boot/compressed/vmlinux.lds.in
> +++ b/arch/arm/boot/compressed/vmlinux.lds.in
> @@ -18,6 +18,7 @@ SECTIONS
> _start = .;
> *(.start)
> *(.text)
> + *(.text.*)
> *(.fixup)
> *(.gnu.warning)
> *(.rodata)
>
>
> --
> Russell King
> Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
> maintainer of: 2.6 Serial core
>
^ permalink raw reply
* [lm-sensors] i2c-i801 and i2c-i810 can't see 82845G
From: Andrew @ 2006-04-09 10:01 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <44389EC6.4060402@donehue.net>
Hi Jean,
Sorry for the HTML - normally Mozilla prompts me (and I use text), if
this comes through as HTML - let me know and i'll double check my settings.
I am happy to test any modules if they get written before I can look at
it. I have about 40 more servers to install lm-sensors on with most of
them varying in hardware spec, so i'll let you know if I have any other
hardware that could be used in testing.
Ironically, the next server I installed sensors on had a IT8712F
chipset... (which has fan and temp, and works well with the it87 module).
Cheers,
Andrew.
Jean Delvare wrote:
>Andrew,
>
>No HTML mail to the list please...
>
>
>
>>Thank you for the speedy reply (and detailed explanation). Considering
>>that the chipset doesn't have temp or voltage sensors, I wouldn't
>>consider a module for this chip as very useful to me (so please feel
>>free to remove the request you have put in - I don't want anyone
>>wasting their time on my behalf).
>>
>>
>
>It's still useful for us to have pointers to potential testers if a
>driver is ever written, so I think I'll leave the reference to your
>post. The number of requests is also a good hint of how popular a chip
>is, even if you are not particularly interested in a driver.
>
>
>
>>If I can get my C skills up in the future, I might have a crack at
>>writing it myself.
>>
>>
>
>Sure, why not. If you do, please let us know so that we avoid
>duplicating the effort.
>
>
>
^ permalink raw reply
* [LARTC] Re: source routing does not work with extra ip addresses
From: richard lucassen @ 2006-04-09 10:12 UTC (permalink / raw)
To: lartc
On Sat, 8 Apr 2006 15:31:24 -0500
"Martin A. Brown" <martin-lartc@wonderfrog.net> wrote:
> Only way I have done this myself, although I recall somebody else on
> LARTC using connmark with nfmark and/or the ROUTE target to solve
> this problem using only a single IP. Perhaps the archive will help
> you here....
Ok. I have a working workaround now using fwmarks and a second ip on the
server. That was a very good idea. Thnx! Bu so far so good. Now I'd
like to get it working with 1 ip..
> : That's a very nice idea, but packets keep on entering the wrong
> : table (default), I think it's a bug somewhere in the kernel.
>
> While the kernel certainly has seen bugs before and will see more, I
> hope you don't mind if I continue to entertain a bit of skepticism
> on this point. :)
Ok, it's not a bug in the kernel, it's a bug in the docs :)
[..]
> Routing tables t_eth0 and t_eth1 look fine, although t_eth0 and main
> should be exactly the same. I believe your two host routes (for
> 192.168.201.3 and 10.1.3.100) are unnecessary and simply complicate
> your scenario.
Hmm. You're right. I just need 1 extra table, not two. I just followed
the docs in the lartc-howto, I'll have a closer look at their example
there. I think that 1 extra table does the same job in that example
http://www.lartc.org/lartc.html#LARTC.RPDB.MULTIPLE-LINKS
> I still think your problem is in the RPDB and addressing of the
> packet at routing time. I do not believe (check the KPTD and its
> offspring [0] [1]) that the packet's source address has yet been
> rewritten. Think about this, and look at your RPDB:
>
> : # ip ru s
> : 0: from all lookup local
> : 32762: from all fwmark 0x1 lookup t_eth1
> : 32764: from 192.168.201.2 lookup t_eth1
> : 32765: from 10.1.3.101 lookup t_eth0
> : 32766: from all lookup main
> : 32767: from all lookup default
>
> The addresses you have entered are the public side addresses. When
> the server transmits packets, these packets will have the 10.0.2.1
> and 10.0.2.3 addresses for source addresses. The RPDB should
> include references to these private addresses instead of the
> addresses available on the public side.
Once again you're right. I accidently commented out the necessary
"ip r f c" (flush cache) in the script, that's why it didn't work
(immediately).
But finally I resolved the problem using the CONNMARK. This is the setup
I'm talking about:
http://www.lucassen.org/divers/ar-test.pdf
I don't know if this is the right way to do this, but it seems to work
well. I mark all packets coming in to 192.168.201.3 through eth1 with
mark 1:
iptables -t mangle -A PREROUTING -i eth1 -d 192.168.201.3 \
-j CONNMARK --set-mark 1
I mark the return packets with the same mark:
iptables -t mangle -A PREROUTING -i eth2 -s 10.0.2.1 \
-j CONNMARK --restore-mark
A simple
ip rule add fwmark 1 table t_eth1
ip r f c
does the rest. I have now 1 ip address on the server and two routes to
the internet. And 1 extra table instead of two ;-)
Thnx for your help,
R.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.
+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: [PATCH 3/7] uts namespaces: use init_utsname when appropriate
From: Christoph Hellwig @ 2006-04-09 10:14 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Serge E. Hallyn, linux-kernel, Kirill Korotaev, herbert, devel,
sam, xemul, James Morris
In-Reply-To: <m164ljjd70.fsf@ebiederm.dsl.xmission.com>
On Sun, Apr 09, 2006 at 03:44:19AM -0600, Eric W. Biederman wrote:
> There are two ways to avoid the associated problems.
> - modify daemonize to always use the instance of that
> namespace associated with init_task.
> - modify all interesting kernel threads to use the
> kthread api instead of kernel_thread. Using kthread
> makes the kernel threads children of keventd and always
> in the initial namespace instance. As such we know
> we aren't inside of any user space namespace instance.
I've added a deprecation entry for the kernel_thread export and plan
to convert all users to the kthread API. Any help on that is of course
greatly appreciated.
^ permalink raw reply
* [lm-sensors] Question on my mainboard
From: Dieter Jurzitza @ 2006-04-09 10:16 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <200603282150.16130.dieter.jurzitza@t-online.de>
Dear Rudolf,
would you kindly tell me where activate this debugging stuff? I looked a bit
through the sensors-sources but I haven't got a clue.
Thank you very much,
take care
Dieter
Am Mittwoch, 5. April 2006 10:28 schrieb Rudolf Marek:
*******
> If you wish to help solve the issue continue using the w93781d and
> tick in the config of i2c the debug stuff. (Bus driver debug) So we will
*******
--
-----------------------------------------------------------
|
\
/\_/\ |
| ~x~ |/-----\ /
\ /- \_/
^^__ _ / _ ____ /
<??__ \- \_/ | |/ | |
|| || _| _| _| _|
if you really want to see the pictures above - use some font
with constant spacing like courier! :-)
-----------------------------------------------------------
^ permalink raw reply
* Re: [PATCH 3/7] uts namespaces: use init_utsname when appropriate
From: Christoph Hellwig @ 2006-04-09 10:25 UTC (permalink / raw)
To: Christoph Hellwig, Eric W. Biederman, Serge E. Hallyn,
linux-kernel, Kirill Korotaev, herbert, sam, xemul, James Morris
In-Reply-To: <20060409101436.GA20084@infradead.org>
And folks, please remove devel@openvz.org from this thead, it's subscribers
only and gives everyone else nasty bounces.
^ permalink raw reply
* [lm-sensors] Question on my mainboard
From: Rudolf Marek @ 2006-04-09 10:29 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <200603282150.16130.dieter.jurzitza@t-online.de>
Dieter Jurzitza wrote:
> Dear Rudolf,
> would you kindly tell me where activate this debugging stuff? I looked a bit
> through the sensors-sources but I haven't got a clue.
If you have the 2.6 kernel and I think you have so it should be
in kernel menu in i2c section.
Regards
Rudolf
^ permalink raw reply
* Re: [RFC] Patch to fix cdrom being confused on using kdump
From: Jens Axboe @ 2006-04-09 10:29 UTC (permalink / raw)
To: Rachita Kothiyal; +Cc: linux-kernel
In-Reply-To: <20060407135714.GA25569@in.ibm.com>
On Fri, Apr 07 2006, Rachita Kothiyal wrote:
> Hi Jens
>
> As we had discussed earlier, I had seen the cdrom drive appearing
> confused on using kdump on certain x86_64 systems. During the booting
> up of the second kernel, the following message would keep flooding
> the console, and the booting would not proceed any further.
>
> hda: cdrom_pc_intr: The drive appears confused (ireason = 0x01)
>
> In this patch, whenever we are hitting a confused state in the interrupt
> handler with the DRQ set, we clear the DSC bit of the status register and
> return 'ide_stopped' from the interrupt handler.
>
> Please provide your comments and feedback.
>
> Thanks
> Rachita
>
>
> Signed-off-by: Rachita Kothiyal <rachita@in.ibm.com>
> ---
>
> drivers/ide/ide-cd.c | 5 +++++
> 1 files changed, 5 insertions(+)
>
> diff -puN drivers/ide/ide-cd.c~cdrom-confused-clrinterrupt drivers/ide/ide-cd.c
> --- linux-2.6.16-mm2/drivers/ide/ide-cd.c~cdrom-confused-clrinterrupt 2006-03-29 11:23:18.000000000 +0530
> +++ linux-2.6.16-mm2-rachita/drivers/ide/ide-cd.c 2006-04-07 19:05:48.962710872 +0530
> @@ -1450,6 +1450,11 @@ static ide_startstop_t cdrom_pc_intr (id
> rq->sense_len += thislen;
> } else {
> confused:
> + if (( stat & DRQ_STAT) == DRQ_STAT) {
if (stat & DRQ_STAT)
checking for DRQ_STAT again doesn't make sense, how can it ever be
anything but DRQ_STAT if DRQ_STAT is set?
> + /* DRQ is set. Interrupt not welcome now. Ignore */
> + HWIF(drive)->OUTB((stat & 0xEF), IDE_STATUS_REG);
> + return ide_stopped;
And this looks very wrong, you can't write to the status register. Well
you can, but then it's the command register! Writing stat & 0xef to the
command register is an odd thing to do. I think you just want to clear
the DRQ bit, which should be fine after it was read initially. How about
if (stat & DRQ_STAT)
return ide_stopped;
Can you test that?
--
Jens Axboe
^ permalink raw reply
* [ALSA - driver 0001857]: regression in snd-cs4281 in recent 2.6.16-rcX kernels
From: bugtrack @ 2006-04-09 10:29 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1857>
======================================================================
Reported By: hoffmajs
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 1857
Category: PCI - cs4281
Reproducibility: always
Severity: major
Priority: normal
Status: new
Distribution: Ubuntu (Dapper)
Kernel Version: 2.6.16-rc4
======================================================================
Date Submitted: 02-19-2006 06:11 CET
Last Modified: 04-09-2006 12:29 CEST
======================================================================
Summary: regression in snd-cs4281 in recent 2.6.16-rcX
kernels
Description:
In the recent 2.6.16-rc kernels snd-cs4281 broke for me.
(I think since 2.6.16-rc2, but Im not sure atm. In 2.6.15 the card works
fine.)
# > modprobe snd-cs4281
ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [LNKC] -> GSI 5 (level, low)
-> IRQ 5
never read ISV3 and ISV4 from AC'97
ACPI: PCI interrupt for device 0000:00:08.0 disabled
CS4281: probe of 0000:00:08.0 failed with error -5
and no soundcard is found.
If you need more info or want me to test something, please say so.
kind regards,
Jens
======================================================================
----------------------------------------------------------------------
tiwai - 04-07-06 19:16
----------------------------------------------------------------------
Hm, how 2.6.17rc1? The timeout check in the probe routine was fixed.
----------------------------------------------------------------------
Mo6eB - 04-09-06 12:29
----------------------------------------------------------------------
2.6.17-rc1 fixed it for me.
Issue History
Date Modified Username Field Change
======================================================================
02-19-06 06:11 hoffmajs New Issue
02-19-06 06:11 hoffmajs Distribution => Ubuntu (Dapper)
02-19-06 06:11 hoffmajs Kernel Version => 2.6.16-rc4
03-02-06 16:05 tiwai Note Added: 0008319
04-05-06 10:33 julienbras Note Added: 0009119
04-07-06 13:11 Mo6eB Note Added: 0009138
04-07-06 19:16 tiwai Note Added: 0009142
04-09-06 12:29 Mo6eB Note Added: 0009178
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* AHCI suspend support
From: Bastian Blank @ 2006-04-09 10:30 UTC (permalink / raw)
To: jgarzik; +Cc: linux-ide
Hi Jeff
Do you know what the current state of suspend support in the AHCI driver
is? There was a patch from Hannes Reinecke some weeks ago.
Bastian
--
But Captain -- the engines can't take this much longer!
^ permalink raw reply
* Error with OpenVPN
From: Claudia Scotti @ 2006-04-09 10:35 UTC (permalink / raw)
To: linux-hotplug
Dear list,
I am trying to connect a client to a server by OpenVPN using DynDNS but I
get the follwoing error message.
Apr 9 12:35:27 localhost wait_for_sysfs[4506]: either wait_for_sysfs (udev
039) needs an update to handle the device '/class/net/tun0' properly (no
device symlink) or the sysfs-support of your device's driver needs to be
fixed, please report to <linux-hotplug-devel@lists.sourceforge.net>
I am a novice, any suggestions, please?
Many thanks.
Claudia
Claudia Scotti
Dipartimento di Medicina Sperimentale
Sezione di Patologia Generale
Universita' di Pavia
Piazza Botta, 10
27100 Pavia
Italia
Tel. 0039 0382 986335/8/1
Facs 0039 0382 303673
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: [Qemu-devel] Unified device model
From: Paul Brook @ 2006-04-09 10:38 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <E1FSSRx-0004OR-Eg@lists.gnu.org>
> >>I am wondering about making unified device models architecture for open
> >>source simulators.
> >>The device models will be used in QEMU, Bochs, Xen and other open source
> >>simulators which would use the device models.
> >
> >I would support this idea, if it was possible.
>
> Why not ?
> You always could consider to add simple modules C++ to QEMU or build C++
> device -> C device interface bridge ...
I think to be acceptable to qemu (and probably also for Xen) the devices would
have to be written in C. C++ is more pain that it's worth in this context.
Of course there's no reason why we couldn't use the subset of C that's also
valid C++. You could also write C++ wrappers round the interface for bochs to
use.
I'm not a fan of binary plugins (for the same reasons I'm don't like binary
kernel modules), and don't think there's any real need to them. I can't see
any good reasons why open source devices would need to be broken out into a
separate shared library.
If you do want to accommodate proprietary binary plugins then C++ is a really
bad idea. The C++/libstdc++ ABI simply isn't stable enough to make this a
realistic option.
Paul
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.