* Re: Git 1.3.2 on Solaris
From: Jason Riedy @ 2006-05-17 16:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Stefan Pfetzing, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605170919290.10823@g5.osdl.org>
And Linus Torvalds writes:
-
- Now, I'm told pkgsrc is horrible, but it can't be so horrid as to not
- allow private directories?
Works fine.
1) Depend on the GNU tools through the buildlink, um, stuff.
2) Add a config.mak via a local patch that sets gitexecprefix.
3) Add another local patch that sets up links within that
gitexecprefix to the GNU tools. Remember to check if the
GNU tools were installed without the silly g prefix.
And pkgsrc itself works just fine without the silly g prefix,
or at least does for me as a mere user (and as well as it does
work). But if you intend on adding the package upstream, it'll
need something to cope with the g. And pkgsrc handles local
patches...
Jason
^ permalink raw reply
* Re: [PATCH] MTD: mtdconcat NAND/Sibley support (rev.2)
From: David Woodhouse @ 2006-05-17 16:33 UTC (permalink / raw)
To: Jörn Engel; +Cc: Linux MTD mailing list
In-Reply-To: <20060517162702.GB26351@wohnheim.fh-wedel.de>
On Wed, 2006-05-17 at 18:27 +0200, Jörn Engel wrote:
> Maybe I tricked him into forcing you to finally read my patches. If
> that's the only possible way to do it...
No, it isn't. Actually I'd gone through the 'MTD striping' thread and
seen the discussion which those patches originated from -- a coherent
explanation I hadn't previously been treated to, and having cleaned up
the majority of the CVS->git merge I was getting round to them. But I
can't set a precedent like that, even by coincidence -- so they'll have
to wait until next week.
--
dwmw2
^ permalink raw reply
* Do "git add" as a builtin
From: Linus Torvalds @ 2006-05-17 16:33 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
First try. Let's see how well this works.
In many ways, the hard parts of "git commit" are not so different from
this, and a builtin commit would share a lot of the code, I think.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
It passes the tests for me. I dropped the strange "--error-unmatch" test,
because it was really ugly and I didn't see the point. It seems to do all
the right things, but hey, a mistake here is obviously a bad thing.
I suspect that if I get around to "git commit", we'd be getting to the
point where most of the core/easy/often-used/whatever commands would be
all built-in.
diff --git a/Makefile b/Makefile
index f43ac63..e6f7794 100644
--- a/Makefile
+++ b/Makefile
@@ -218,7 +218,7 @@ LIB_OBJS = \
BUILTIN_OBJS = \
builtin-log.o builtin-help.o builtin-count.o builtin-diff.o builtin-push.o \
- builtin-grep.o
+ builtin-grep.o builtin-add.o
GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
LIBS = $(GITLIBS) -lz
diff --git a/builtin-add.c b/builtin-add.c
new file mode 100644
index 0000000..e815b3d
--- /dev/null
+++ b/builtin-add.c
@@ -0,0 +1,228 @@
+/*
+ * "git add" builtin command
+ *
+ * Copyright (C) 2006 Linus Torvalds
+ */
+#include <fnmatch.h>
+
+#include "cache.h"
+#include "builtin.h"
+#include "dir.h"
+
+static const char builtin_add_usage[] =
+"git-add [-n] [-v] <filepattern>...";
+
+static int common_prefix(const char **pathspec)
+{
+ const char *path, *slash, *next;
+ int prefix;
+
+ if (!pathspec)
+ return 0;
+
+ path = *pathspec;
+ slash = strrchr(path, '/');
+ if (!slash)
+ return 0;
+
+ prefix = slash - path + 1;
+ while ((next = *++pathspec) != NULL) {
+ int len = strlen(next);
+ if (len >= prefix && !memcmp(path, next, len))
+ continue;
+ for (;;) {
+ if (!len)
+ return 0;
+ if (next[--len] != '/')
+ continue;
+ if (memcmp(path, next, len+1))
+ continue;
+ prefix = len + 1;
+ break;
+ }
+ }
+ return prefix;
+}
+
+static int match(const char **pathspec, const char *name, int namelen, int prefix)
+{
+ const char *match;
+
+ name += prefix;
+ namelen -= prefix;
+
+ while ((match = *pathspec++) != NULL) {
+ int matchlen;
+
+ match += prefix;
+ matchlen = strlen(match);
+ if (!matchlen)
+ return 1;
+ if (!strncmp(match, name, matchlen)) {
+ if (match[matchlen-1] == '/')
+ return 1;
+ switch (name[matchlen]) {
+ case '/': case '\0':
+ return 1;
+ }
+ }
+ if (!fnmatch(match, name, 0))
+ return 1;
+ }
+ return 0;
+}
+
+static void prune_directory(struct dir_struct *dir, const char **pathspec, int prefix)
+{
+ int i;
+ struct dir_entry **src, **dst;
+
+ src = dst = dir->entries;
+ i = dir->nr;
+ while (--i >= 0) {
+ struct dir_entry *entry = *src++;
+ if (!match(pathspec, entry->name, entry->len, prefix)) {
+ free(entry);
+ continue;
+ }
+ *dst++ = entry;
+ }
+ dir->nr = dst - dir->entries;
+}
+
+static void fill_directory(struct dir_struct *dir, const char **pathspec)
+{
+ const char *path, *base;
+ int baselen;
+
+ /* Set up the default git porcelain excludes */
+ memset(dir, 0, sizeof(*dir));
+ dir->exclude_per_dir = ".gitignore";
+ path = git_path("info/exclude");
+ if (!access(path, R_OK))
+ add_excludes_from_file(dir, path);
+
+ /*
+ * Calculate common prefix for the pathspec, and
+ * use that to optimize the directory walk
+ */
+ baselen = common_prefix(pathspec);
+ path = ".";
+ base = "";
+ if (baselen) {
+ char *common = xmalloc(baselen + 1);
+ common = xmalloc(baselen + 1);
+ memcpy(common, *pathspec, baselen);
+ common[baselen] = 0;
+ path = base = common;
+ }
+
+ /* Read the directory and prune it */
+ read_directory(dir, path, base, baselen);
+ if (pathspec)
+ prune_directory(dir, pathspec, baselen);
+}
+
+static int add_file_to_index(const char *path, int verbose)
+{
+ int size, namelen;
+ struct stat st;
+ struct cache_entry *ce;
+
+ if (lstat(path, &st))
+ die("%s: unable to stat (%s)", path, strerror(errno));
+
+ if (!S_ISREG(st.st_mode) && !S_ISLNK(st.st_mode))
+ die("%s: can only add regular files or symbolic links", path);
+
+ namelen = strlen(path);
+ size = cache_entry_size(namelen);
+ ce = xcalloc(1, size);
+ memcpy(ce->name, path, namelen);
+ ce->ce_flags = htons(namelen);
+ fill_stat_cache_info(ce, &st);
+
+ ce->ce_mode = create_ce_mode(st.st_mode);
+ if (!trust_executable_bit) {
+ /* If there is an existing entry, pick the mode bits
+ * from it.
+ */
+ int pos = cache_name_pos(path, namelen);
+ if (pos >= 0)
+ ce->ce_mode = active_cache[pos]->ce_mode;
+ }
+
+ if (index_path(ce->sha1, path, &st, 1))
+ die("unable to index file %s", path);
+ if (add_cache_entry(ce, ADD_CACHE_OK_TO_ADD))
+ die("unable to add %s to index",path);
+ if (verbose)
+ printf("add '%s'\n", path);
+ return 0;
+}
+
+static struct cache_file cache_file;
+
+int cmd_add(int argc, const char **argv, char **envp)
+{
+ int i, newfd;
+ int verbose = 0, show_only = 0;
+ const char *prefix = setup_git_directory();
+ const char **pathspec;
+ struct dir_struct dir;
+
+ git_config(git_default_config);
+
+ newfd = hold_index_file_for_update(&cache_file, get_index_file());
+ if (newfd < 0)
+ die("unable to create new cachefile");
+
+ if (read_cache() < 0)
+ die("index file corrupt");
+
+ for (i = 1; i < argc; i++) {
+ const char *arg = argv[i];
+
+ if (arg[0] != '-')
+ break;
+ if (!strcmp(arg, "--")) {
+ i++;
+ break;
+ }
+ if (!strcmp(arg, "-n")) {
+ show_only = 1;
+ continue;
+ }
+ if (!strcmp(arg, "-v")) {
+ verbose = 1;
+ continue;
+ }
+ die(builtin_add_usage);
+ }
+ git_config(git_default_config);
+ pathspec = get_pathspec(prefix, argv + i);
+
+ fill_directory(&dir, pathspec);
+
+ if (show_only) {
+ const char *sep = "", *eof = "";
+ for (i = 0; i < dir.nr; i++) {
+ printf("%s%s", sep, dir.entries[i]->name);
+ sep = " ";
+ eof = "\n";
+ }
+ fputs(eof, stdout);
+ return 0;
+ }
+
+ for (i = 0; i < dir.nr; i++)
+ add_file_to_index(dir.entries[i]->name, verbose);
+
+ if (active_cache_changed) {
+ if (write_cache(newfd, active_cache, active_nr) ||
+ commit_index_file(&cache_file))
+ die("Unable to write new index file");
+ }
+
+ return 0;
+}
diff --git a/builtin.h b/builtin.h
index 7744f7d..1b77f4b 100644
--- a/builtin.h
+++ b/builtin.h
@@ -24,5 +24,6 @@ extern int cmd_count_objects(int argc, c
extern int cmd_push(int argc, const char **argv, char **envp);
extern int cmd_grep(int argc, const char **argv, char **envp);
+extern int cmd_add(int argc, const char **argv, char **envp);
#endif
diff --git a/git.c b/git.c
index a94d9ee..fac46af 100644
--- a/git.c
+++ b/git.c
@@ -50,6 +50,7 @@ static void handle_internal_command(int
{ "count-objects", cmd_count_objects },
{ "diff", cmd_diff },
{ "grep", cmd_grep },
+ { "add", cmd_add },
};
int i;
^ permalink raw reply related
* MMAP failure after creating an HVM guest
From: Dugger, Donald D @ 2006-05-17 16:33 UTC (permalink / raw)
To: Xen devel list
[-- Attachment #1: Type: text/plain, Size: 730 bytes --]
In tracking down an X windows problem I've discovered that an `mmap' on
Dom0 fails after an HVM guest is created. The problem is with the 2
system calls:
fd = open("/dev/mem", O_RDWR);
p = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
These calls work fine until after the first HVM guest is created and
then the `mmap' fails with an EFAULT. Interestingly enough, the `mmap'
works if `/dev/mem' is opened read only and the failure only happens
after the HVM guest goes into protected mode, if you destroy an HVM
Linux guest while it's still in Grub then this `mmap' will still work.
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Donald.D.Dugger@intel.com
Ph: (303)440-1368
[-- Attachment #2: mmap.c --]
[-- Type: application/octet-stream, Size: 461 bytes --]
#
#include <stdio.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
main(int argc, char *argv[])
{
int fd;
void *p;
if ((fd = open("/dev/mem", O_RDWR)) < 0) {
perror("can't open /dev/mem, maybe you should run as root");
return 1;
}
p = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
if ((long)p == -1) {
perror("mmap failed");
return 1;
}
munmap(p, 4096);
printf("Success!\n");
return 0;
}
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: /dev/disk/by-label/* not populated by initrd
From: Greg KH @ 2006-05-17 16:30 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20060517145820.GK12875@smart.physik.fu-berlin.de>
On Wed, May 17, 2006 at 04:58:20PM +0200, Jens Dreger wrote:
> Hi!
>
> A few days ago I installed debian/testing amd64 on one of our servers
> to test some 64bit stuff. Upon bootup the machine loaded the SAN
> modules (qla*) before the modules for the system disk, so it didn't
> make it. I could fix this by blacklisting the modules.
>
> After reading up on udev I understood that I am supposed to write
> some rules which make sure the system disks get's a persistent
> name. So I gave the disk a label and udevtest shows that it would be
> assigned:
>
> root@zs11:~> udevtest /block/sda/sda1 | grep label
> udev_rules_get_name: add symlink 'disk/by-label/zs11_system'
> create_node: creating symlink '/dev/disk/by-label/zs11_system' to '../../sda1'
>
> The problem is that this does not work inside initrd, but I obviously
> need that link for the rootfs. I unpacked the initrd and init has
> support for this:
>
> root@zs11:/boot/initrd.img-2.6.15-1-amd64-generic.unpack> grep LABEL init
> LABEL=*)
> ROOT="/dev/disk/by-label/${ROOT#LABEL=}"
>
> Booting with kernel-commandline root=LABEL=zs11_system didn't work.
>
> I copied udevtest to the initrd. It shows:
>
> [...]
> main: looking at device '/block/sda/sda1' from subsystem 'block'
> udev_rules_get_name: no node name set, will use kernel name 'sda1'
> lookup_group: specified group unknown 'disk'
> create_node: creating device node '/dev/sda1', major = '8', minor = '1', mode = '0660', uid = '0', gid = '0'
> main: run: 'socket:/org/kernel/udev/monitor'
> [...]
>
> I know that this is probably a debian issue
Yes, it is.
> but I would like to know how to debug this further.
Try putting the rules and helper scripts that create the by-label/
symlinks into the initrd so that udev can create them.
good luck,
greg k-h
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x120709&bid&3057&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: replacing X Window System !
From: Valdis.Kletnieks @ 2006-05-17 16:29 UTC (permalink / raw)
To: linux-os (Dick Johnson); +Cc: linux cbon, Jesper Juhl, Linux kernel
In-Reply-To: <Pine.LNX.4.61.0605171129570.31662@chaos.analogic.com>
[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]
On Wed, 17 May 2006 11:30:46 EDT, "linux-os (Dick Johnson)" said:
> The X window system was an excellent design
> that just isn't used properly if you really
> need a high security environment. All you
> need is a "display machine" that runs X.
But now your "display machine" is inside the security perimeter,
and as such, has to be treated as high security as well.
Otherwise, you're basically doing the equivalent of granting
insufficiently authenticated VPN access into the high security
part of the net.
A more deployable answer is for the X server to compartmentalize the clients,
be aware of their security classifications, and mediate interactions (for
instance, if a "cut" is done in a high-security window, only allow it to
be "paste" into other high-security windows). The X Security Extension
was one effort to start doing this, and more recently, there have been
patches to allow SELinux mediation of the interactions.
Of course, there will still be those applications where the user ends
up with 2 computers, monitors, keyboards, and mice on their desk,
each connected to a different level network.
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: [PATCH] MTD: mtdconcat NAND/Sibley support (rev.2)
From: Jörn Engel @ 2006-05-17 16:27 UTC (permalink / raw)
To: David Woodhouse; +Cc: Linux MTD mailing list
In-Reply-To: <1147881919.3875.24.camel@pmac.infradead.org>
On Wed, 17 May 2006 17:05:19 +0100, David Woodhouse wrote:
> On Wed, 2006-05-17 at 18:00 +0200, Jörn Engel wrote:
> >
> > [ No objections from my side. Thanks, Alexander. ]
> >
> > Does that mean you have applied the writesize patch as well?
>
> Hm, no. Did you trick Alexander into submitting a broken patch?
Maybe I tricked him into forcing you to finally read my patches. If
that's the only possible way to do it...
Jörn
--
A defeated army first battles and then seeks victory.
-- Sun Tzu
^ permalink raw reply
* Re: Kernel vs drivers releases?
From: Daniel Drake @ 2006-05-17 16:45 UTC (permalink / raw)
To: Fortier,Vincent [Montreal]; +Cc: LKML
In-Reply-To: <8E8F647D7835334B985D069AE964A4F7024640@ECQCMTLMAIL1.quebec.int.ec.gc.ca>
Fortier,Vincent [Montreal] wrote:
> On the other hand many people want's to get a full stabilisation of the
> actual API...
Not meaning to sound harsh, I think you belong in this category:
You think you want a stable kernel interface, but you really do
not, and you don't even know it.
See Documentation/stable_api_nonsense.txt
Daniel
^ permalink raw reply
* Re: Git 1.3.2 on Solaris
From: Linus Torvalds @ 2006-05-17 16:24 UTC (permalink / raw)
To: Stefan Pfetzing; +Cc: Git Mailing List
In-Reply-To: <f3d7535d0605170808l21d9f6d0gff1afaa10db17af9@mail.gmail.com>
On Wed, 17 May 2006, Stefan Pfetzing wrote:
>
> Ok, if I would do so, my prefix would be /usr/pkg, and the bindir would be
> /usr/pkg/bin. So I would need to have an xargs and so on symlink in
> /usr/pkg/bin.
> But this is simply not acceptable, because it breaks other NetBSD
> pkgsrc scripts.
DON'T USE /usr/pkg then.
Use /usr/pkg/git-core/share/ or something that is normally not on your
path.
And then install _just_ the "git" binary in /usr/pkg/bin.
That must be allowable by whatever solaris packaging rules: it's not like
other projects don't have their own internal library files.
Then you install the GNU symlinks under that same
/usr/pkg/git-core/share/bin
and you're all set. The only binary you can _see_ is "git", and when that
executes any scripts or other git binaries, it will set up the path to
include that magic hidden directory.
> Besides that, installing git to a different location is not an option
> for me, because I want to have git packaged by pkgsrc.
Now, I'm told pkgsrc is horrible, but it can't be so horrid as to not
allow private directories?
Linus
^ permalink raw reply
* Re: Real simple cache that removes most of the lookups in mcstrans
From: James Antill @ 2006-05-17 16:22 UTC (permalink / raw)
To: SE Linux
In-Reply-To: <446AFED3.9010800@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1505 bytes --]
On Wed, 2006-05-17 at 06:45 -0400, Daniel J Walsh wrote:
> Basically check if the previous lookup was the same context, if yes
> return the same translation. Otherwise do the lookup.
Are we sure one is enough, lsof -Z does both s0 and s0-s0:c0.c255 and
they are basically mixed (I appreciate it is much easier to code a cache
of 1 than >1 though).
Also:
+ } else {
+ free(prev_t2r_trans);
+ free(prev_t2r_raw);
+ if (trans_to_raw_context(trans, rawp))
+ *rawp = strdup(trans);
+ prev_t2r_trans=strdup(trans);
+ prev_t2r_raw=strdup(*rawp);
...this is bad when trans_to_raw_context, the first strdup() fails or
the last strdup() fails.
> Also included Russells patch for avcstat.
- printf("%10u %10u %10u %10u %10u %10u\n",
+ printf("%10Lu %10Lu %10Lu %10Lu %10Lu %10Lu\n",
It's somewhat minor, but that should be %llu %Lu is a somewhat common
extension. From man printf:
ll (ell-ell). A following integer conversion corresponds to a long
long int or unsigned long long int argument, or a following n
conversion corresponds to a pointer to a long long int argument.
L A following a, A, e, E, f, F, g, or G conversion corresponds to
a long double argument. (C99 allows %LF, but SUSv2 does not.)
--
James Antill
<james.antill@redhat.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Another asinine question
From: Juan Carlos Castro y Castro @ 2006-05-17 16:22 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
In-Reply-To: <s5hmzdg3c93.wl%tiwai@suse.de>
Takashi Iwai wrote:
>>>>Another thing: you'll see I just "hung" another snd_pcm_file_t structure at the bottom of the original one. I'll understand if that offends people's coding sensibilities -- it offended mine. :-/
>>>>
>>>>
>>>Does't only one file descriptor instead of the whole snd_pcm_file struct suffice? Actually, it's used only in readi().
>>>
>>>
>>Not really, especially when I finally tackle _readn. And even in the noninterleaved case, there's always the possibility read() will return a number of bytes that's not a multiple of the frame size (especially if the file is a named pipe). I'll need ->wbuf and some of those indexes to keep the remaining bytes for the next read.
>>
>>
>Then let's create another object type. It's confusing to use the existing object for completly another purpose.
>
>Also, "nextfile" doesn't sound intuitive in this case. (it sounds like a linked chain of data.)
>
>
Agree and agree. I DID say it was offensive. In my defense, boss was
swinging the whip and I had to churn out code rather quickly. OK, that
was a lame excuse. :-/
For the noninterleaved case, I think a plain dumb byte FIFO (buffer,
head, tail) would be enough. I'll only be able to code on that tomorrow
-- got an unrelated deadline to meet today.
Juan
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
^ permalink raw reply
* Re: [patch 15/50] genirq: doc: add design documentation
From: Randy.Dunlap @ 2006-05-17 16:23 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linux-kernel, tglx, benh, rmk, akpm, hch, linux-arm-kernel
In-Reply-To: <20060517001623.GP12877@elte.hu>
On Wed, 17 May 2006 02:16:23 +0200 Ingo Molnar wrote:
> From: Thomas Gleixner <tglx@linutronix.de>
>
> Add docbook file - includes API documentation.
Thanks. :)
> Index: linux-genirq.q/Documentation/DocBook/genericirq.tmpl
> ===================================================================
> --- /dev/null
> +++ linux-genirq.q/Documentation/DocBook/genericirq.tmpl
> @@ -0,0 +1,453 @@
> + <chapter id="rationale">
> + <title>Rationale</title>
> + <para>
> + The original implementation of interrupt handling in Linux is using
> + the __do_IRQ() super-handler, which is able to deal with every
> + type of interrupt logic.
> + </para>
> + <para>
> + Originally, Russell King identified different types of handlers to
> + build a quite universal set for the ARM interrupt handler
> + implementation in Linux 2.5/2.6. He distiguished between:
distinguished
> + <para>
> + The original general IRQ implementation used hw_interrupt_type
> + structures and their ->ack(), ->end() [etc.] callbcks to
> + differentiate the flow control in the super-handler. This leads to
> + a mix of flow logic and lowlevel hardware logic, and it also leads
> + to unnecessary code duplication: for example in i386, there is a
> + ioapic_level_irq and a ioapic_edge_irq irq-type which share many
> + of the lowlevel details but have different flow handling.
> + </para>
> + <para>
> + A more natural abstraction is the clean seperation of the
separation (multiple locations)
(or as my wife says, "there's 'a rat' in separate.")
> + 'irq flow' and the 'chip details'.
> + </para>
> + <para>
> + Analysing a couple of architecture's IRQ subsystem implementations
> + reveals that most of them can use a generic set of 'irq flow'
> + methods and only need to add the chip level specific code.
> + The seperation is also valuable for (sub)architectures
> + which need specific quirks in the irq flow itself but not in the
> + chip-details - and thus provides a more transparent IRQ subsystem
> + design.
> + </para>
> + <para>
> + Each interrupt descriptor has assigned its own highlevel flow
s/has/is/
> + handler, which is normally one of the generic
> + implementations. (This highlevel flow handler implementation also
> + makes it simple to provide demultiplexing handlers which can be
> + found in embedded platforms on various architectures.)
> + </para>
> + <para>
> + The seperation makes the generic interrupt handling layer more
> + flexible and extensible. For example, an (sub)architecture can
> + use a generic irq-flow implementation for 'level type' interrupts
> + and add a (sub)architecture specific 'edge type' implementation.
> + </para>
> + <para>
> + To make the transition to the new model easier and prevent the
> + breakage of existing implementations the __do_IRQ() super-handler
add comma after "implementations"
> + is still available. This leads to a kind of duality for the time
> + being. Over time the new model should be used in more and more
> + architectures, as it enables smaller and cleaner IRQ subsystems.
> + </para>
> + </chapter>
> + <chapter id="bugs">
> + <title>Known Bugs And Assumptions</title>
> + <para>
> + None (knock on wood).
> + </para>
> + </chapter>
> +
> + <sect2>
> + <title>Default flow implementations</title>
> + <sect3>
> + <title>Helper functions</title>
> + <para>
> + The helper functions call the chip primitives and
> + are used by the default flow implementations.
> + Following helper functions are implemented (simplified excerpt):
The following ... (multiple locations)
> + <sect3>
> + <title>Default Edge IRQ flow handler</title>
> + <para>
> + handle_edge_irq provides a generic implementation
> + for edge interrupts.
edge-triggered interrupts. (IMO)
> + <chapter id="doirq">
> + <title>__do_IRQ entry point</title>
> + <para>
> + The original implementation __do_IRQ() is an alternative entry
> + point for all types of interrupts.
> + </para>
> + <para>
> + This handler turned out to be not suitable for all
> + interrupt hardware and was therefor reimplemented with split
therefore
> + functionality for egde/level/simple/percpu interrupts. This is not
> + only a functional optimization. It also shortenes code pathes for
shortens code paths
> + interrupts.
HTH.
---
~Randy
^ permalink raw reply
* Re: Real simple cache that removes most of the lookups in mcstrans
From: Daniel J Walsh @ 2006-05-17 16:21 UTC (permalink / raw)
To: Joshua Brindle; +Cc: Stephen Smalley, Steve Grubb, SE Linux
In-Reply-To: <446B3E11.6040302@gentoo.org>
Joshua Brindle wrote:
> Daniel J Walsh wrote:
>> Joshua Brindle wrote:
>>> Daniel J Walsh wrote:
>>>> Basically check if the previous lookup was the same context, if yes
>>>> return the same translation. Otherwise do the lookup.
>>>>
>>>> Also included Russells patch for avcstat.
>>> Is this used on MLS? If so this cache needs to be cleared on policy
>>> reload for proper revocation of translation access. Further, this
>>> has no way of checking to see if the actual translations changed
>>> between the last query and this one.
>> Yes, you mean translation change, I think. Since I do not see where
>> policy reload would effect this. We could add some kind of timer to
>> this, but refreshing the cache is a small problem, but this same
>> problem existed with shared libraries.
>>
> Because on an MLS system the server will be deciding whether or not
> you have permission to see a particular translation and a policy
> reload would affect that. The same problem did exist with the shared
> libraries but we aren't using them anymore :) the server should be
> smart enough to handle this. If client side caching is really desired
> it needs to work like an avc where you can get flush notifications
> from the server.
One suggestion I have heard is to allow the administrator to turn off
the cache, perhaps via /etc/selinux/config???
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: AcpiGetFirmwareTable
From: Joel Bretz @ 2006-05-17 16:20 UTC (permalink / raw)
To: linux-acpi
In-Reply-To: <1147881519.20702.40.camel@zion.rsn.hp.com>
I guess I should also note, that I know that AcpiOsGetRootPointer
returns the correct value since I can successfully use
AcpiWalkNamespace (ACPI_TYPE_ANY, Handle, 0xffffffff,
DecodeOneDevice, (void*)p, NULL);
Thanks
On Wed, 2006-05-17 at 10:58 -0500, Joel Bretz wrote:
> Hmm something is wrong. :(
>
>
> Here's the code that I'm using to get the Debug Port:
> //----- <snip> -----
> ACPI_STATUS Status;
> ACPI_TABLE_HEADER *pAcpiTableHeader;
>
> printf("JOEL: Get DGBP\n")
> Status = AcpiGetFirmwareTable("DBGP",1,ACPI_PHYSICAL_ADDRESSING,
> &pAcpiTableHeader);
> if(ACPI_FAILURE(Status))
> {
> FAIL_STOP("AcpiGetFirmwareTable failed.\n"); //<
> }
>
> //----- </snip> -----
>
> Here's the output from my system
>
> //----- <snip> -----
> I> JOEL: Get DBGP
> I> AcpiOsGetRootPointer
> I> ACPI Error (tbget-0259): Invalid address flags X [X]
> I> ERROR: file: ../src/acpi.c, line: 846, func: GetAcpiDGBP, p:008d37e0:
> I> AcpiGetFirmwareTable failed.
> I> There has been a failure.
> //----- </snip> -----
>
> I follow the error message and go take a look at
> acpica-unix-20060317/tables/tbget.c
>
> the error message comes from a switch statement on
> Address->PointerType for which there are 3 handled cases:
> ACPI_PHYSMODE_PHYSPTR
> ACPI_LOGMODE_LOGPTR
> ACPI_LOGMODE_PHYSPTR
>
> I should be executing the ACPI_PHYSMODE_PHYSMODE branch..
> since OsGetRootPointer returns a PHYSICAL_POINTER & I specified
> ACPI_PHYSICAL_ADDRESSING when I called AcpiGetFirmwareTable
>
> does anyone know what's going wrong here?
> Thanks,
>
> //--------------------------------
> Joel Bretz
> Hardware Engineer
> Hewlett Packard, Systems VLSI Lab
> email: joel.bretz@hp.com
> //--------------------------------
>
>
>
> On Tue, 2006-05-16 at 14:38 -0700, Moore, Robert wrote:
> > This is the interface that you want to use:
> >
> > ACPI_STATUS
> > AcpiGetFirmwareTable (
> > ACPI_STRING Signature,
> > UINT32 Instance,
> > UINT32 Flags,
> > ACPI_TABLE_HEADER **TablePointer)
> >
> >
> > Also, we recently added support for DBGP in the table headers
> >
> >
> >
> > > -----Original Message-----
> > > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> > > owner@vger.kernel.org] On Behalf Of Joel Bretz
> > > Sent: Tuesday, May 16, 2006 2:23 PM
> > > To: linux-acpi@vger.kernel.org
> > > Subject: AcpiGetTable( ? )
> > >
> > > Hi,
> > > I need some information that lives in the DBGP and the HPET Tables.. I
> > > don't see a way that I can get either of those tables.
> > >
> > > I'm guessing that
> > > AcpiGetTable(ACPI_TABLE_TYPE,UINT32,ACPI_BUFFER*)
> > > provides the functionality that I need, but I can not find the correct
> > > table types for either of those.
> > >
> > > I'm using a slightly older version of acpica (acpica-unix-20060317),
> > but
> > > I didn't see entries for
> > > ACPI_TABLE_DGBP or ACPI_TABLE_HPET
> > > in actypes.h in the latest version either...
> > >
> > > Is there a way that I can get the information from these 2 tables?
> > >
> > > Thanks,
> > > Joel
> > >
> > > //--------------------------------
> > > Joel Bretz
> > > Hardware Engineer
> > > Hewlett Packard, Systems VLSI Lab
> > > email: joel.bretz@hp.com
> > > //--------------------------------
> > >
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-acpi"
> > in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 2/2] kbuild: fix modpost segfault for 64bit mipsel kernel
From: Atsushi Nemoto @ 2006-05-17 16:20 UTC (permalink / raw)
To: linux-kernel; +Cc: sam, ralf
Here is an updated r_info layout fix. Please apply "check SHT_REL
sections" patch before this.
64bit mips has different r_info layout. This patch fixes modpost
segfault for 64bit little endian mips kernel.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
diff -u linux/scripts/mod/modpost.c linux-mips/scripts/mod/modpost.c
--- linux/scripts/mod/modpost.c 2006-05-18 00:27:05.439421552 +0900
+++ linux-mips/scripts/mod/modpost.c 2006-05-18 01:01:43.584495480 +0900
@@ -700,6 +700,7 @@
const char *name = secstrings + sechdrs[i].sh_name;
const char *secname;
Elf_Rela r;
+ unsigned int r_sym;
/* We want to process only relocation sections and not .init */
if (sechdrs[i].sh_type == SHT_RELA) {
Elf_Rela *rela;
@@ -711,9 +712,20 @@
for (rela = start; rela < stop; rela++) {
r.r_offset = TO_NATIVE(rela->r_offset);
- r.r_info = TO_NATIVE(rela->r_info);
+#if KERNEL_ELFCLASS == ELFCLASS64
+ if (hdr->e_machine == EM_MIPS) {
+ r_sym = ELF64_MIPS_R_SYM(rela->r_info);
+ r_sym = TO_NATIVE(r_sym);
+ } else {
+ r.r_info = TO_NATIVE(rela->r_info);
+ r_sym = ELF_R_SYM(r.r_info);
+ }
+#else
+ r.r_info = TO_NATIVE(rela->r_info);
+ r_sym = ELF_R_SYM(r.r_info);
+#endif
r.r_addend = TO_NATIVE(rela->r_addend);
- sym = elf->symtab_start + ELF_R_SYM(r.r_info);
+ sym = elf->symtab_start + r_sym;
/* Skip special sections */
if (sym->st_shndx >= SHN_LORESERVE)
continue;
@@ -734,9 +746,20 @@
for (rel = start; rel < stop; rel++) {
r.r_offset = TO_NATIVE(rel->r_offset);
- r.r_info = TO_NATIVE(rel->r_info);
+#if KERNEL_ELFCLASS == ELFCLASS64
+ if (hdr->e_machine == EM_MIPS) {
+ r_sym = ELF64_MIPS_R_SYM(rel->r_info);
+ r_sym = TO_NATIVE(r_sym);
+ } else {
+ r.r_info = TO_NATIVE(rel->r_info);
+ r_sym = ELF_R_SYM(r.r_info);
+ }
+#else
+ r.r_info = TO_NATIVE(rel->r_info);
+ r_sym = ELF_R_SYM(r.r_info);
+#endif
r.r_addend = 0;
- sym = elf->symtab_start + ELF_R_SYM(r.r_info);
+ sym = elf->symtab_start + r_sym;
/* Skip special sections */
if (sym->st_shndx >= SHN_LORESERVE)
continue;
diff -u linux/scripts/mod/modpost.h linux-mips/scripts/mod/modpost.h
--- linux/scripts/mod/modpost.h 2006-05-18 00:18:14.222178848 +0900
+++ linux-mips/scripts/mod/modpost.h 2006-05-17 23:47:21.581822992 +0900
@@ -41,6 +41,25 @@
#define ELF_R_TYPE ELF64_R_TYPE
#endif
+/* The 64-bit MIPS ELF ABI uses an unusual reloc format. */
+typedef struct
+{
+ Elf32_Word r_sym; /* Symbol index */
+ unsigned char r_ssym; /* Special symbol for 2nd relocation */
+ unsigned char r_type3; /* 3rd relocation type */
+ unsigned char r_type2; /* 2nd relocation type */
+ unsigned char r_type1; /* 1st relocation type */
+} _Elf64_Mips_R_Info;
+
+typedef union
+{
+ Elf64_Xword r_info_number;
+ _Elf64_Mips_R_Info r_info_fields;
+} _Elf64_Mips_R_Info_union;
+
+#define ELF64_MIPS_R_SYM(i) \
+ ((__extension__ (_Elf64_Mips_R_Info_union)(i)).r_info_fields.r_sym)
+
#if KERNEL_ELFDATA != HOST_ELFDATA
static inline void __endian(const void *src, void *dest, unsigned int size)
^ permalink raw reply
* Re: Real simple cache that removes most of the lookups in mcstrans
From: Daniel J Walsh @ 2006-05-17 16:19 UTC (permalink / raw)
To: James Antill; +Cc: Stephen Smalley, Steve Grubb, SE Linux
In-Reply-To: <1147879972.3469.139.camel@code.and.org>
James Antill wrote:
> On Wed, 2006-05-17 at 06:45 -0400, Daniel J Walsh wrote:
>
>> Basically check if the previous lookup was the same context, if yes
>> return the same translation. Otherwise do the lookup.
>>
>
> Are we sure one is enough, lsof -Z does both s0 and s0-s0:c0.c255 and
> they are basically mixed (I appreciate it is much easier to code a cache
> of 1 than >1 though).
>
> Also:
>
> + } else {
> + free(prev_t2r_trans);
> + free(prev_t2r_raw);
> + if (trans_to_raw_context(trans, rawp))
> + *rawp = strdup(trans);
> + prev_t2r_trans=strdup(trans);
> + prev_t2r_raw=strdup(*rawp);
>
> ...this is bad when trans_to_raw_context, the first strdup() fails or
> the last strdup() fails.
>
>
Only reason strdup fails is ENOMEM. With ENOMEM you are almost
garanteed you are going to crash anyways. gstrdup does a exit when it
runs out of memory.
So we can messy up the code with a lot of checks that end up doing
little. Your choice.
>> Also included Russells patch for avcstat.
>>
>
> - printf("%10u %10u %10u %10u %10u %10u\n",
> + printf("%10Lu %10Lu %10Lu %10Lu %10Lu %10Lu\n",
>
> It's somewhat minor, but that should be %llu %Lu is a somewhat common
> extension. From man printf:
>
> ll (ell-ell). A following integer conversion corresponds to a long
> long int or unsigned long long int argument, or a following n
> conversion corresponds to a pointer to a long long int argument.
>
> L A following a, A, e, E, f, F, g, or G conversion corresponds to
> a long double argument. (C99 allows %LF, but SUSv2 does not.)
>
>
>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* [PATCH 2/2] kbuild: fix modpost segfault for 64bit mipsel kernel <20060424183958.GA22911@mars.ravnborg.org> <20060425.015343.05598987.anemo@mba.ocn.ne.jp> kernell
From: Atsushi Nemoto @ 2006-05-17 16:19 UTC (permalink / raw)
To: linux-kernel; +Cc: sam, ralf
Here is an updated r_info layout fix. Please apply "check SHT_REL
sections" patch before this.
64bit mips has different r_info layout. This patch fixes modpost
segfault for 64bit little endian mips kernel.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
diff -u linux/scripts/mod/modpost.c linux-mips/scripts/mod/modpost.c
--- linux/scripts/mod/modpost.c 2006-05-18 00:27:05.439421552 +0900
+++ linux-mips/scripts/mod/modpost.c 2006-05-18 01:01:43.584495480 +0900
@@ -700,6 +700,7 @@
const char *name = secstrings + sechdrs[i].sh_name;
const char *secname;
Elf_Rela r;
+ unsigned int r_sym;
/* We want to process only relocation sections and not .init */
if (sechdrs[i].sh_type == SHT_RELA) {
Elf_Rela *rela;
@@ -711,9 +712,20 @@
for (rela = start; rela < stop; rela++) {
r.r_offset = TO_NATIVE(rela->r_offset);
- r.r_info = TO_NATIVE(rela->r_info);
+#if KERNEL_ELFCLASS == ELFCLASS64
+ if (hdr->e_machine == EM_MIPS) {
+ r_sym = ELF64_MIPS_R_SYM(rela->r_info);
+ r_sym = TO_NATIVE(r_sym);
+ } else {
+ r.r_info = TO_NATIVE(rela->r_info);
+ r_sym = ELF_R_SYM(r.r_info);
+ }
+#else
+ r.r_info = TO_NATIVE(rela->r_info);
+ r_sym = ELF_R_SYM(r.r_info);
+#endif
r.r_addend = TO_NATIVE(rela->r_addend);
- sym = elf->symtab_start + ELF_R_SYM(r.r_info);
+ sym = elf->symtab_start + r_sym;
/* Skip special sections */
if (sym->st_shndx >= SHN_LORESERVE)
continue;
@@ -734,9 +746,20 @@
for (rel = start; rel < stop; rel++) {
r.r_offset = TO_NATIVE(rel->r_offset);
- r.r_info = TO_NATIVE(rel->r_info);
+#if KERNEL_ELFCLASS == ELFCLASS64
+ if (hdr->e_machine == EM_MIPS) {
+ r_sym = ELF64_MIPS_R_SYM(rel->r_info);
+ r_sym = TO_NATIVE(r_sym);
+ } else {
+ r.r_info = TO_NATIVE(rel->r_info);
+ r_sym = ELF_R_SYM(r.r_info);
+ }
+#else
+ r.r_info = TO_NATIVE(rel->r_info);
+ r_sym = ELF_R_SYM(r.r_info);
+#endif
r.r_addend = 0;
- sym = elf->symtab_start + ELF_R_SYM(r.r_info);
+ sym = elf->symtab_start + r_sym;
/* Skip special sections */
if (sym->st_shndx >= SHN_LORESERVE)
continue;
diff -u linux/scripts/mod/modpost.h linux-mips/scripts/mod/modpost.h
--- linux/scripts/mod/modpost.h 2006-05-18 00:18:14.222178848 +0900
+++ linux-mips/scripts/mod/modpost.h 2006-05-17 23:47:21.581822992 +0900
@@ -41,6 +41,25 @@
#define ELF_R_TYPE ELF64_R_TYPE
#endif
+/* The 64-bit MIPS ELF ABI uses an unusual reloc format. */
+typedef struct
+{
+ Elf32_Word r_sym; /* Symbol index */
+ unsigned char r_ssym; /* Special symbol for 2nd relocation */
+ unsigned char r_type3; /* 3rd relocation type */
+ unsigned char r_type2; /* 2nd relocation type */
+ unsigned char r_type1; /* 1st relocation type */
+} _Elf64_Mips_R_Info;
+
+typedef union
+{
+ Elf64_Xword r_info_number;
+ _Elf64_Mips_R_Info r_info_fields;
+} _Elf64_Mips_R_Info_union;
+
+#define ELF64_MIPS_R_SYM(i) \
+ ((__extension__ (_Elf64_Mips_R_Info_union)(i)).r_info_fields.r_sym)
+
#if KERNEL_ELFDATA != HOST_ELFDATA
static inline void __endian(const void *src, void *dest, unsigned int size)
^ permalink raw reply
* [PATCH 1/2] kbuild: check SHT_REL sections
From: Atsushi Nemoto @ 2006-05-17 16:19 UTC (permalink / raw)
To: linux-kernel; +Cc: sam, ralf
I found that modpost can not detect section mismatch on mips and i386.
On mips64, the modpost (with r_info layout fix) can detect it. The
current modpst only checks SHT_RELA section but I suppose SHT_REL
section should be checked also. This patch does not contain r_info
layout fix. I'll post an updated r_info layout fix on next mail.
Check SHT_REL sections as like as SHT_RELA sections to detect section
mismatch.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 6d04504..1aa52a8 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -697,29 +697,56 @@ static void check_sec_ref(struct module
/* Walk through all sections */
for (i = 0; i < hdr->e_shnum; i++) {
- Elf_Rela *rela;
- Elf_Rela *start = (void *)hdr + sechdrs[i].sh_offset;
- Elf_Rela *stop = (void*)start + sechdrs[i].sh_size;
- const char *name = secstrings + sechdrs[i].sh_name +
- strlen(".rela");
+ const char *name = secstrings + sechdrs[i].sh_name;
+ const char *secname;
+ Elf_Rela r;
/* We want to process only relocation sections and not .init */
- if (section_ref_ok(name) || (sechdrs[i].sh_type != SHT_RELA))
- continue;
+ if (sechdrs[i].sh_type == SHT_RELA) {
+ Elf_Rela *rela;
+ Elf_Rela *start = (void *)hdr + sechdrs[i].sh_offset;
+ Elf_Rela *stop = (void*)start + sechdrs[i].sh_size;
+ name += strlen(".rela");
+ if (section_ref_ok(name))
+ continue;
- for (rela = start; rela < stop; rela++) {
- Elf_Rela r;
- const char *secname;
- r.r_offset = TO_NATIVE(rela->r_offset);
- r.r_info = TO_NATIVE(rela->r_info);
- r.r_addend = TO_NATIVE(rela->r_addend);
- sym = elf->symtab_start + ELF_R_SYM(r.r_info);
- /* Skip special sections */
- if (sym->st_shndx >= SHN_LORESERVE)
+ for (rela = start; rela < stop; rela++) {
+ r.r_offset = TO_NATIVE(rela->r_offset);
+ r.r_info = TO_NATIVE(rela->r_info);
+ r.r_addend = TO_NATIVE(rela->r_addend);
+ sym = elf->symtab_start + ELF_R_SYM(r.r_info);
+ /* Skip special sections */
+ if (sym->st_shndx >= SHN_LORESERVE)
+ continue;
+
+ secname = secstrings +
+ sechdrs[sym->st_shndx].sh_name;
+ if (section(secname))
+ warn_sec_mismatch(modname, name,
+ elf, sym, r);
+ }
+ } else if (sechdrs[i].sh_type == SHT_REL) {
+ Elf_Rel *rel;
+ Elf_Rel *start = (void *)hdr + sechdrs[i].sh_offset;
+ Elf_Rel *stop = (void*)start + sechdrs[i].sh_size;
+ name += strlen(".rel");
+ if (section_ref_ok(name))
continue;
- secname = secstrings + sechdrs[sym->st_shndx].sh_name;
- if (section(secname))
- warn_sec_mismatch(modname, name, elf, sym, r);
+ for (rel = start; rel < stop; rel++) {
+ r.r_offset = TO_NATIVE(rel->r_offset);
+ r.r_info = TO_NATIVE(rel->r_info);
+ r.r_addend = 0;
+ sym = elf->symtab_start + ELF_R_SYM(r.r_info);
+ /* Skip special sections */
+ if (sym->st_shndx >= SHN_LORESERVE)
+ continue;
+
+ secname = secstrings +
+ sechdrs[sym->st_shndx].sh_name;
+ if (section(secname))
+ warn_sec_mismatch(modname, name,
+ elf, sym, r);
+ }
}
}
}
diff --git a/scripts/mod/modpost.h b/scripts/mod/modpost.h
index b14255c..086fa46 100644
--- a/scripts/mod/modpost.h
+++ b/scripts/mod/modpost.h
@@ -21,6 +21,7 @@
#define ELF_ST_BIND ELF32_ST_BIND
#define ELF_ST_TYPE ELF32_ST_TYPE
+#define Elf_Rel Elf32_Rel
#define Elf_Rela Elf32_Rela
#define ELF_R_SYM ELF32_R_SYM
#define ELF_R_TYPE ELF32_R_TYPE
@@ -34,6 +35,7 @@
#define ELF_ST_BIND ELF64_ST_BIND
#define ELF_ST_TYPE ELF64_ST_TYPE
+#define Elf_Rel Elf64_Rel
#define Elf_Rela Elf64_Rela
#define ELF_R_SYM ELF64_R_SYM
#define ELF_R_TYPE ELF64_R_TYPE
^ permalink raw reply related
* Re: [Fwd: [RFT] major libata update]
From: Jeff Garzik @ 2006-05-17 16:17 UTC (permalink / raw)
To: James Bottomley, Jens Axboe
Cc: SCSI Mailing List, linux-ide@vger.kernel.org, Tejun Heo,
Andrew Morton, Linus Torvalds
In-Reply-To: <1147881002.3463.23.camel@mulgrave.il.steeleye.com>
James Bottomley wrote:
> On Wed, 2006-05-17 at 11:06 -0400, Jeff Garzik wrote:
>> storage device and storage host are key objects included in the
>
> This is one of the questions. Currently block has no concept of "host".
> All it knows about are queues (which may be per host or per device
> depending on the implementation). Do we need to introduce the concept
> of something like queue grouping (a sort of lightweight infrastructure
> that could be used by the underlying transport to implement a host
> concept without introducing hosts at the block layer)?
Yes, and not only that... you must describe the queue pipeline too.
i.e. N logical devices can be bottlenecked behind a bridge (expander,
port multiplier, tunnel) of queue depth Q, which may in turn be behind
another bottleneck. :)
But overall, libata and SAS controllers are forced to deal with the
reality of the situation: they all wind up either using, or recreating
from scratch, objects for host/device/bus/etc. in order to sanely allow
all the infrastructure to interoperate.
You'll all note that struct Scsi_Host and struct scsi_cmnd have very
little to do with SCSI. Its almost all infrastructure and driver
management. That's the _useful_ stuff that libata uses SCSI for.
Thus, moving libata to the block layer entails either
s/Scsi_Host/Storage_Host/g or a highly similar infrastructure, to
achieve the same gains.
It is _trivial_ to write a new SCSI driver [even if your hardware is not
SCSI], and there are good reasons for that. Please all, examine those
reasons...
Jeff
^ permalink raw reply
* Re: the medstcations
From: Edmund Mickel @ 2006-05-17 16:13 UTC (permalink / raw)
To: alsa-devel
[-- Attachment #1.1: Type: text/plain, Size: 1071 bytes --]
http://www.coserwuision.com
----- Original Message -----
ha! ha.
So they laughed and sang in the trees; and pretty fair nonsense
I
daresay you think it. Not that they would care they would only
laugh all
the more if you told them so. They were elves of course. Soon
Bilbo
caught glimpses of them as the darkness deepened. He loved
elves, though
he seldom met them; but he was a little frightened of them too.
Dwarves
dont get on well with them. Even decent enough dwarves like
Thorin and
his friends think them foolish (which is a very foolish thing to
think),
or get annoyed with them. For some elves tease them and laugh at
them,
and most of all at their beards. Well, well! said a voice. Just
look!
Bilbo the hobbit on a pony, my dear! Isnt it delicious!
Most astonishing wonderful!
Then off they went into another song as ridiculous as the one I
have
written down in full. At last one, a tall young fellow, came out
from
the trees and bowed to Gandalf and to Thorin.
Welcome to the valley! he said.
[-- Attachment #1.2: Type: text/html, Size: 1757 bytes --]
[-- Attachment #2: dissociative3.gif --]
[-- Type: image/gif, Size: 3181 bytes --]
^ permalink raw reply
* Re: 2.6.17-rc4-mm1 nfsroot build err, looks related to klibc
From: H. Peter Anvin @ 2006-05-17 16:14 UTC (permalink / raw)
To: Jim Cromie; +Cc: Adrian Bunk, Linux kernel
In-Reply-To: <446ACCCF.1030406@gmail.com>
Jim Cromie wrote:
>>
> Ok, it built clean, but broke on boot.
>
What does the full command line look like?
-hpa
^ permalink raw reply
* Re: klibc build broken on UML
From: H. Peter Anvin @ 2006-05-17 16:14 UTC (permalink / raw)
To: Miklos Szeredi; +Cc: linux-kernel, user-mode-linux-devel, akpm
In-Reply-To: <E1FgNkr-00024G-00@dorka.pomaz.szeredi.hu>
Miklos Szeredi wrote:
> [resent because prev. post bounced on hpa and akpm due to mail problems here]
>
> I get this on 2.6.17-rc4-mm1:
>
> CHK include/linux/compile.h
> /usr/src/quilt/linux/scripts/Kbuild.klibc:60: /usr/src/quilt/linux/usr/klibc/arch/um/MCONFIG: No such file or directory
> usr/klibc/Kbuild:71: usr/klibc/arch/um/Makefile.inc: No such file or directory
> make[2]: *** No rule to make target `usr/klibc/arch/um/Makefile.inc'. Stop.
> make[1]: *** [_usr_klibc] Error 2
> make: *** [usr] Error 2
>
> Miklos
Known and fixed in my git tree already.
-hpa
^ permalink raw reply
* [uml-devel] Re: klibc build broken on UML
From: H. Peter Anvin @ 2006-05-17 16:14 UTC (permalink / raw)
To: Miklos Szeredi; +Cc: linux-kernel, user-mode-linux-devel, akpm
In-Reply-To: <E1FgNkr-00024G-00@dorka.pomaz.szeredi.hu>
Miklos Szeredi wrote:
> [resent because prev. post bounced on hpa and akpm due to mail problems here]
>
> I get this on 2.6.17-rc4-mm1:
>
> CHK include/linux/compile.h
> /usr/src/quilt/linux/scripts/Kbuild.klibc:60: /usr/src/quilt/linux/usr/klibc/arch/um/MCONFIG: No such file or directory
> usr/klibc/Kbuild:71: usr/klibc/arch/um/Makefile.inc: No such file or directory
> make[2]: *** No rule to make target `usr/klibc/arch/um/Makefile.inc'. Stop.
> make[1]: *** [_usr_klibc] Error 2
> make: *** [usr] Error 2
>
> Miklos
Known and fixed in my git tree already.
-hpa
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* Re: replacing X Window System !
From: Stas Myasnikov @ 2006-05-17 16:12 UTC (permalink / raw)
To: linux cbon; +Cc: Valdis.Kletnieks, linux-kernel
In-Reply-To: <20060517155325.68734.qmail@web26604.mail.ukl.yahoo.com>
Hi,
>>>> But that would greatly simplify the whole
>> system.
>>
>>> Yeah, adding 124 meg to a 4.2M kernel will
>> simplify it...
>>
>> Still quadruples the size and even worse on
>> complexity...
>
>
> Are all those 124 meg *really* usefull ?
> Thats why it should be rewritten from scratch or
> better, redesigned...
So, do it :-)
Stas
^ permalink raw reply
* Re: replacing X Window System !
From: Stas Myasnikov @ 2006-05-17 16:11 UTC (permalink / raw)
To: linux cbon; +Cc: Alan Cox, linux-kernel
In-Reply-To: <20060517154926.35649.qmail@web26606.mail.ukl.yahoo.com>
Hi,
>>> We dont need 2 kernels like today.
>>> All "dangerous code" should be in kernel.
>> The kernel is even more privileged than the X server
>> so putting
>> dangerous code there is counterproductive. Security
>> comes about through
>> intelligent design decisions, compartmentalisation,
>> isolation of
>> security critical code segments and the like. If you
>> merely put shit in
>> a different bucket you still have a bad smell.
> With "dangerous code" I meant : code which *could be
> potentially dangerous* like accessing directly the
> hardware etc.
> That code should be only in the kernel.
It's your opinion only.
Stas
^ 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.