Re: 2.6.12-rc2-mm2
On Fri, 8 Apr 2005, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm2/ Still doesn't build for me with my usual config (available upon request) unless I enable ACPI : ... CC arch/i386/kernel/setup.o arch/i386/kernel/setup.c:96: error: parse error before acpi_sci_flags arch/i386/kernel/setup.c:96: warning: type defaults to `int' in declaration of `acpi_sci_flags' arch/i386/kernel/setup.c:96: warning: data definition has no type or storage class arch/i386/kernel/setup.c: In function `parse_cmdline_early': arch/i386/kernel/setup.c:811: error: request for member `trigger' in something not a structure or union arch/i386/kernel/setup.c:814: error: request for member `trigger' in something not a structure or union arch/i386/kernel/setup.c:817: error: request for member `polarity' in something not a structure or union arch/i386/kernel/setup.c:820: error: request for member `polarity' in something not a structure or union make[1]: *** [arch/i386/kernel/setup.o] Error 1 make: *** [arch/i386/kernel] Error 2 -- Jesper Juhl - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
On Fri, 8 Apr 2005, Rajesh Venkatasubramanian wrote: Although directory changes are tracked using change-sets, there seems to be no easy way to answer give me the diff corresponding to the commit (change-set) object sha1. That will be really helpful to review the changes. Actually, it is very easy indeed. Here's what you do: - look up the commit object (cat-file commit sha1) This object starts out with tree sha1, followed by a list of parent commit objects: parent sha1 Remember the tree object (it defines what the tree looks like at the time of the commit). Pick the parent object you want to diff against (normally the first one). Also, print the checking messages at the end of the commit object. - look up the parent object (cat-file commit parentsha1) Here you have the same kind of object, but this time you don't care about going deeper, you just pick up the tree sha1 that describes the tree at the parent. - look up the two tree objects. Unlike a commit object, a tree object is a binary data blob, but the format is an _extremely_ simple table of thse guys: ascii octal filemode space pathname NUL character 20-byte sha1 and the reason it's binary is really that that way git doesn't end up having any issues with strange pathnames. If you want to have spaces and newlines in your pathname, go wild. In particular, the tree object is also _sorted_ by the pathname. This makes things simple, because you now have to sorted trees, and the first thing you do is just walk the two trees in lock-step, which is trivial thanks to the sorted nature of the tree array. So now you have three cases: - you have the same name, and the same sha1 ignore it - the file didn't change, you don't even have to look at the contents (although if the file mode changed you might want to note that) - you have the same name in parent and child tree lists, but the sha differs. Now you just need to do a cat-file on both of the SHA1 values, and do a diff -u between them. - you have the filename in only parent or only child. Do a create or delete diff with the content of the sha1 file. See? Very efficient. For any files that didn't change, you didn't have to do anything at all - you didn't even have to look at their data. Also note that the above algorithm really works for _any_ two commit points (apart for the two first steps, which are obviously all about finding the parent tree when you want to diff against a predecessor). It doesn't have to be parent and child. Pick any commit you have. And pick them in the other order, and you'll automatically get the reverse diff. You can even do diffs between unrelated projects this way if you use the shared sha1 directory model, although that obviously doesn't tend to be all that sensible ;) Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Add support for semaphore-like structure with support for asynchronous I/O
fr den 08.04.2005 Klokka 18:39 (-0400) skreiv Benjamin LaHaise: On the aio side of things, I introduced the owner field in the mutex (as opposed to the flag in Trond's iosem) for the next patch in the series to enable something like the following api: int aio_lock_mutex(struct mutex *lock, struct iocb *iocb); Any chance of a more generic interface too? iocbs are fairly high level objects, and so I do not see them helping to resolve low level filesystem problems such as the NFSv4 state cleanup. Cheers, Trond -- Trond Myklebust [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
On Friday 08 April 2005 04:38, Andrea Arcangeli wrote: On Thu, Apr 07, 2005 at 11:41:29PM -0700, Linus Torvalds wrote: The huge number of changesets is the crucial point, there are good distributed SCM already but they are apparently not efficient enough at handling 60k changesets. We'd need a regenerated coherent copy of BKCVS to pipe into those SCM to evaluate how well they scale. OTOH if your git project already allows storing the data in there, that looks nice ;). Hi Andrea, For the immediate future, all we need is something than can _losslessly_ capture the new metadata that's being generated. That buys time to bring one of the promising open source candidates up to full speed. By the way, which one are you working on? :-) Regards, Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
Roman Zippel wrote: Preserving the complete merge history does indeed make repeated merges simpler, but it builds up complex meta data, which has to be managed forever. I doubt that this is really an advantage in the long term. I expect that we were better off serializing changesets in the main repository. For example bk does something like this: A1 - A2 - A3 - BM \- B1 - B2 --^ and instead of creating the merge changeset, one could merge them like this: A1 - A2 - A3 - B1 - B2 This results in a simpler repository, which is more scalable and which is easier for users to work with (e.g. binary bug search). The disadvantage would be it will cause more minor conflicts, when changes are pulled back into the original tree, but which should be easily resolvable most of the time. Both darcs and arch (and arch's siblings) have ways of maintaining the complete history but speeding up operations. Arch use's revision libraries: http://www.gnu.org/software/gnu-arch/tutorial/revision-libraries.html though i'm not all that up on arch so I'll just leave it at that. Darcs uses darcs optimize --checkpoint http://darcs.net/manual/node7.html#SECTION00764000 which allows for users to retrieve a working repository with limited history with a savings of disk space and bandwidth. In darcs case, you can pull a partial repository by doing darcs get --partial, in which case you only grab the state at the point that the repository was optimized and subsequent patches, and all operations only need to work against the set of patches since that optimize. Note, that I'm not promoting darcs for kernel usage because of speed (or the lack thereof) but I am curious why Linus would consider monotone given its speed issues but not consider darcs. -Tupshin - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bootmem.c clean up bad pfn convertions
On Fri, 2005-04-08 at 15:32 +0200, Franck Bui-Huu wrote: As I described in my previous email, bootmem.c does improper pfn convertions into phys addr. This simple patch fixes that. ... - bdata-node_bootmem_map = phys_to_virt(mapstart PAGE_SHIFT); - bdata-node_boot_start = (start PAGE_SHIFT); + bdata-node_bootmem_map = phys_to_virt(pfn_to_phys(mapstart)); + bdata-node_boot_start = pfn_to_phys(start); The only arch with phys_to_pfn() defined is UML, so the patch simply won't compile anything but UML on current kernels (unless I'm missing something). Could you try to give us a more complete description of your problem? I know your memory doesn't start at 0x0, but what problems does that cause? Does the mem_map[] allocation blow up, etc... If it's just mem_map[], That calculation could be fixed pretty easily. Something like +#ifdef CONFIG_CRAZY_MIPS_FOO_MEM_MAP_START... +extern unsigned long mem_map_start_pfn +#else +#define mem_map_start_pfn 0UL +#endif -#define pfn_to_page(pfn)(mem_map + (pfn)) +#define pfn_to_page(pfn)(mem_map + (pfn) - mem_map_start_pfn) (those names are horrid, please improve them, if you plan to do this) All of the zone (and allocator) calculations should be just fine, because it already has a zone_start_pfn. -- Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] silence spinlock/rwlock uninitialized break_lock member warnings
Hi Andrew,
Any chance this patch could be added to -mm (and possibly mainline)?
It removes a bunch of warnings when building with gcc -W, like these:
include/linux/wait.h:82: warning: missing initializer
include/linux/wait.h:82: warning: (near initialization for
`(anonymous).break_lock')
include/asm/rwsem.h:88: warning: missing initializer
include/asm/rwsem.h:88: warning: (near initialization for
`(anonymous).break_lock')
so there's less to sift through when looking for real problems with this
patch applied.
I've been using it for a while with no ill effects.
This patch has surfaced previously, please see the lkml thread
[RFC] spinlock_t rwlock_t break_lock member initialization (patch seeking
comments included)
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
spinlock.h | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
--- linux-2.6.12-rc2-mm2-orig/include/asm-i386/spinlock.h 2005-03-02
08:37:50.0 +0100
+++ linux-2.6.12-rc2-mm2/include/asm-i386/spinlock.h2005-04-09
01:49:48.0 +0200
@@ -32,7 +32,13 @@ typedef struct {
#define SPINLOCK_MAGIC_INIT/* */
#endif
-#define SPIN_LOCK_UNLOCKED (spinlock_t) { 1 SPINLOCK_MAGIC_INIT }
+#ifdef CONFIG_PREEMPT
+#define SPINLOCK_BREAK_INIT, 0
+#else
+#define SPINLOCK_BREAK_INIT/* */
+#endif
+
+#define SPIN_LOCK_UNLOCKED (spinlock_t) { 1 SPINLOCK_MAGIC_INIT
SPINLOCK_BREAK_INIT }
#define spin_lock_init(x) do { *(x) = SPIN_LOCK_UNLOCKED; } while(0)
@@ -182,7 +188,13 @@ typedef struct {
#define RWLOCK_MAGIC_INIT /* */
#endif
-#define RW_LOCK_UNLOCKED (rwlock_t) { RW_LOCK_BIAS RWLOCK_MAGIC_INIT }
+#ifdef CONFIG_PREEMPT
+#define RWLOCK_BREAK_INIT , 0
+#else
+#define RWLOCK_BREAK_INIT /* */
+#endif
+
+#define RW_LOCK_UNLOCKED (rwlock_t) { RW_LOCK_BIAS RWLOCK_MAGIC_INIT
RWLOCK_BREAK_INIT }
#define rwlock_init(x) do { *(x) = RW_LOCK_UNLOCKED; } while(0)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/8] correctly name the Shell sort
On Fri, Apr 08, 2005 at 11:52:10AM -0400, Horst von Brand wrote: [EMAIL PROTECTED] said: As per http://www.nist.gov/dads/HTML/shellsort.html, this should be referred to as a Shell sort. Shell-Metzner is a misnomer. Signed-off-by: Daniel Dickman [EMAIL PROTECTED] Signed-off-by: Domen Puncer [EMAIL PROTECTED] Why not use the sort routine from lib/sort.c? Because the groups are not in an array. They're in a bunch of page-sized blocks and the indexing function knows how to look at the index block and make everything look like an array from the point of view of the shell sort. I couldn't come up with a clean way to handle it. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] radeonfb: (#2) Implement proper workarounds for PLL accesses
This patch adds to the fbdev interface a set_cmap callback that allow the driver to batch palette changes. This is useful for drivers like radeonfb which might require lenghtly workarounds on palette accesses, thus allowing to factor out those workarounds efficiently. This makes it better. But there is still a delay of half a second, and there is an annoying flicker when switching from X to the console. Can you redo the counting of the workarounds with the patch ? Ben. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cosmetic fixes for example programs in Documentation/cdrom/sbpcd
Hi Andrew,
I'm sending this to you directly since Eberhard Moenkeberg already
indicated to me that he approves of the patch.
This patch makes a few minor changes to the example programs in
Documentation/cdrom/sbpcd to kill off some warnings and build failures.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
sbpcd | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
--- linux-2.6.12-rc2-mm2-orig/Documentation/cdrom/sbpcd 2005-03-02
08:38:13.0 +0100
+++ linux-2.6.12-rc2-mm2/Documentation/cdrom/sbpcd 2005-04-09
02:04:11.0 +0200
@@ -419,6 +419,7 @@
*/
#include stdio.h
#include sys/ioctl.h
+#include sys/types.h
#include linux/cdrom.h
static struct cdrom_tochdr hdr;
@@ -429,7 +430,7 @@
static int i, j, limit, track, err;
static char filename[32];
-main(int argc, char *argv[])
+int main(int argc, char *argv[])
{
/*
* open /dev/cdrom
@@ -516,6 +517,7 @@
}
arg.addr.lba++;
}
+return 0;
}
/*= end program */
@@ -564,15 +566,16 @@
#include stdio.h
#include malloc.h
#include sys/ioctl.h
+#include sys/types.h
#include linux/cdrom.h
#ifdef AZT_PRIVATE_IOCTLS
#include linux/../../drivers/cdrom/aztcd.h
-#endif AZT_PRIVATE_IOCTLS
+#endif /* AZT_PRIVATE_IOCTLS */
#ifdef SBP_PRIVATE_IOCTLS
#include linux/../../drivers/cdrom/sbpcd.h
#include linux/fs.h
-#endif SBP_PRIVATE_IOCTLS
+#endif /* SBP_PRIVATE_IOCTLS */
struct cdrom_tochdr hdr;
struct cdrom_tochdr tocHdr;
@@ -590,7 +593,7 @@
struct cdrom_msf msf;
unsigned char buf[CD_FRAMESIZE_RAW];
} azt;
-#endif AZT_PRIVATE_IOCTLS
+#endif /* AZT_PRIVATE_IOCTLS */
int i, i1, i2, i3, j, k;
unsigned char sequence=0;
unsigned char command[80];
@@ -738,7 +741,7 @@
}
}
-main(int argc, char *argv[])
+int main(int argc, char *argv[])
{
printf(\nTesting tool for a CDROM driver's audio functions V0.1\n);
printf((C) 1995 Eberhard Moenkeberg [EMAIL PROTECTED]\n);
@@ -1046,12 +1049,13 @@
rc=ioctl(drive,CDROMAUDIOBUFSIZ,j);
printf(%d frames granted.\n,rc);
break;
-#endif SBP_PRIVATE_IOCTLS
+#endif /* SBP_PRIVATE_IOCTLS */
default:
printf(unknown command: \%s\.\n,command);
break;
}
}
+ return 0;
}
/*==*/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] silence spinlock/rwlock uninitialized break_lock member warnings
Jesper Juhl [EMAIL PROTECTED] wrote: Any chance this patch could be added to -mm (and possibly mainline)? Spose I can stick it in -mm. It removes a bunch of warnings when building with gcc -W, like these: include/linux/wait.h:82: warning: missing initializer include/linux/wait.h:82: warning: (near initialization for `(anonymous).break_lock') include/asm/rwsem.h:88: warning: missing initializer include/asm/rwsem.h:88: warning: (near initialization for `(anonymous).break_lock') so there's less to sift through when looking for real problems with this patch applied. I've been using it for a while with no ill effects. But I'd rather not add a bunch of even-more-ifdefs to support a compiler flag which we're not going to use. It's easy enough for the `gcc -W' user to add the patch himself. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
On Fri, 8 Apr 2005, Andrea Arcangeli wrote: We'd need a regenerated coherent copy of BKCVS to pipe into those SCM to evaluate how well they scale. Yes, that makes most sense, I believe. Especially as BKCVS does the linearization that makes other SCM's _able_ to take the data in the first place. Few enough SCM's really understand the BK merge model, although the distributed ones obviously have to do something similar. OTOH if your git project already allows storing the data in there, that looks nice ;). I can express the data, and I did a sparse .git archive to prove the concept. It doesn't even try to save BK-specific details, but as far as I can tell, my git-conversion did capture all the basic things (ie not just the actual source tree, but hopefully all the who did what parts too). Of course, my git visualization tools are so horribly crappy that it is hard to make sure ;) Also, I suspect that BKCVS actually bothers to get more details out of a BK tree than I cared about. People have pestered Larry about it, so BKCVS exports a lot of the nitty-gritty (per-file comments etc) that just doesn't actually _matter_, but people whine about. Me, I don't care. My sparse-conversion just took the important parts. I don't yet fully understand how the algorithms of the trees are meant to work Well, things like actually merging two git trees is not even something git tries to do. It leaves that to somebody else - you can see what the relationship is, and you can see all the data, but as far as I'm concerned, git is really a filesystem. It's a way of expression revisions, but it's not a way of creating them. It looks similar to a diff -ur of two hardlinked trees Yes. You could really think of it that way. It's not really about hardlinking, but the fact that objects are named by their content does mean that two objects (regardless of their type) can be seen as hardlinked whenever their contents match. But the more interesting part is the hierarchical virtual format it has, ie it is not only hardlinked, but it also has the three different levels of views into those hardlinked objects (blob, tree, revision). So even though the hash tree looks flat in the _physcal_ filesystem, it detinitely isn't flat in its own virtual world. It's just flattened to fit in a normal filesystem ;) [ There's also a fourth level view in trust, but that one hasn't been implemented yet since I think it might as well be done at a higher level. ] Btw, the sha1 file format isn't actually designed for rsync, since rsync is really a hell of a lot more capable than my format needs. The format is really designed for something like a offline http grabber, in that you can just grab files purely by filename (and verify that you got them right by running sha1sum on the resulting local copy). So think wget. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cosmetic fixes for example programs in Documentation/cdrom/sbpcd
Hi, On Sat, 9 Apr 2005, Jesper Juhl wrote: Hi Andrew, I'm sending this to you directly since Eberhard Moenkeberg already indicated to me that he approves of the patch. Yes OK (I didn't say it yet, did I?), but I guess it is only cosmetic, as you already said. Cheers -e -- Eberhard Moenkeberg ([EMAIL PROTECTED], [EMAIL PROTECTED]) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] silence spinlock/rwlock uninitialized break_lock member warnings
On Fri, 8 Apr 2005, Andrew Morton wrote: Jesper Juhl [EMAIL PROTECTED] wrote: Any chance this patch could be added to -mm (and possibly mainline)? Spose I can stick it in -mm. It removes a bunch of warnings when building with gcc -W, like these: include/linux/wait.h:82: warning: missing initializer include/linux/wait.h:82: warning: (near initialization for `(anonymous).break_lock') include/asm/rwsem.h:88: warning: missing initializer include/asm/rwsem.h:88: warning: (near initialization for `(anonymous).break_lock') so there's less to sift through when looking for real problems with this patch applied. I've been using it for a while with no ill effects. But I'd rather not add a bunch of even-more-ifdefs to support a compiler flag which we're not going to use. It's easy enough for the `gcc -W' user to add the patch himself. True, it's trivial to just add the patch when needed (aka building with -W), but the number of such patches add up and having them in the tree by default is less pain (for the -W user). I'm not on a quest to make the tree -W clean, but I find -W useful to find the odd actual problem and a number of the warnings that -W spits out can be silenced without harm, those are the ones I aim to fix. But I see the point of not adding patches to make -W happy if it adds clutter for the non-W case, so I'll see if I can come up with a cleaner way to fix this case that will be more generally acceptable (perhaps Zwane's suggestion about using named initializers could result in something cleaner - I'll look at that)... -- Jesper - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cosmetic fixes for example programs in Documentation/cdrom/sbpcd
On Sat, 9 Apr 2005, Eberhard Moenkeberg wrote: Hi, On Sat, 9 Apr 2005, Jesper Juhl wrote: Hi Andrew, I'm sending this to you directly since Eberhard Moenkeberg already indicated to me that he approves of the patch. Yes OK (I didn't say it yet, did I?), but I guess it is only cosmetic, as you already said. Unless I interpreted you wrong I'd say you did (in the [PATCH] small fixes for example programs in Documentation/cdrom/sbpcd thread): On Thu, 17 Mar 2005, Eberhard Moenkeberg wrote: ... Do it. I'm kind of proud, only cosmetical changes after a whole decennium. ;-)) ... -- Jesper - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
On Fri, 8 Apr 2005, Linus Torvalds wrote: Also note that the above algorithm really works for _any_ two commit points (apart for the two first steps, which are obviously all about finding the parent tree when you want to diff against a predecessor). Btw, if you want to try this, you should get an updated copy. I've pushed a raw git archive of both git and sparse (the latter is much more interesting from an archive standpoint, since it actually has 1400 changesets in it) to kernel.org, but I'm not convinced it gets mirrored out. I think the mirror scripts may mirror only things they understand. I've also added a partial fsck for the git filesystem. It doesn't do the connectivity analysis yet, but that should be pretty straightforward to add - it already parses all the data, it just doesn't save it away (and the connectivity analysis will automatically show how many root changesets you have, and what the different HEADs are). I'll make a tar-file (git-0.03), although at this point I've actually been maintaining it in itself, so to some degree it's almost getting easier if I'd just have a place to rsync it.. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
Bjorn Helgaas wrote: On Fri, 2005-04-01 at 21:23 +0200, Jacek Luczak wrote: Michael Thonke napisa(a): Hello Jacek, I finially got it working :-) my PCI-Express devices working now... I grabbed the last bk-snapshot from kernel.org 2.6.12-rc1-bk3 and et volia everything except the Marvell Yokon PCI-E device working. I hope Andrew will look into the mm-line to find the bug? I've got Marvell Yukon 88E8053 GigE and it works fine with fixed (by myself :]) driver from syskonnect. If you wont I may send it to you! Please post your patch here and copy the maintainers: MARVELL YUKON / SYSKONNECT DRIVER P: Mirko Lindner M: [EMAIL PROTECTED] P: Ralph Roesler M: [EMAIL PROTECTED] W: http://www.syskonnect.com S: Supported Hi I sent my patch to Mirko about 3 weeks ago. Mirko replied that he consider it. Since that time new version of sk98lin driver appeared. Version from syskonnect site require only changing usage of pci_dev-slot_name to pci_name(pci_dev) in skge.c and skethtool.c. After that everything should work fine. So I think there is no need to post my path here but if you really whant I may do this. Whole path agains 2.6.12-rc2 take about 1.2 MB (diffstat attached below). Jacek --- drivers/net/Kconfig | 113 - drivers/net/sk98lin/Makefile | 64 drivers/net/sk98lin/h/lm80.h |4 drivers/net/sk98lin/h/skaddr.h|4 drivers/net/sk98lin/h/skcsum.h|6 drivers/net/sk98lin/h/skdebug.h | 20 drivers/net/sk98lin/h/skdrv1st.h | 41 drivers/net/sk98lin/h/skdrv2nd.h | 978 ++--- drivers/net/sk98lin/h/skerror.h | 12 drivers/net/sk98lin/h/skgedrv.h |4 drivers/net/sk98lin/h/skgehw.h| 1377 ++--- drivers/net/sk98lin/h/skgehwt.h |4 drivers/net/sk98lin/h/skgei2c.h | 210 -- drivers/net/sk98lin/h/skgeinit.h | 369 ++- drivers/net/sk98lin/h/skgepnm2.h | 12 drivers/net/sk98lin/h/skgepnmi.h | 141 - drivers/net/sk98lin/h/skgesirq.h | 40 drivers/net/sk98lin/h/skgetwsi.h | 241 ++ drivers/net/sk98lin/h/ski2c.h | 177 - drivers/net/sk98lin/h/skqueue.h | 13 drivers/net/sk98lin/h/skrlmt.h|4 drivers/net/sk98lin/h/sktimer.h |4 drivers/net/sk98lin/h/sktwsi.h| 177 + drivers/net/sk98lin/h/sktypes.h | 62 drivers/net/sk98lin/h/skversion.h | 34 drivers/net/sk98lin/h/skvpd.h | 84 drivers/net/sk98lin/h/sky2le.h| 891 drivers/net/sk98lin/h/xmac_ii.h | 621 +++--- drivers/net/sk98lin/sk98lin.txt | 203 +- drivers/net/sk98lin/skaddr.c | 79 drivers/net/sk98lin/skcsum.c |6 drivers/net/sk98lin/skdim.c | 1027 +++--- drivers/net/sk98lin/skethtool.c | 1379 ++--- drivers/net/sk98lin/skge.c| 3779 -- drivers/net/sk98lin/skgehwt.c | 52 drivers/net/sk98lin/skgeinit.c| 1683 drivers/net/sk98lin/skgemib.c | 186 + drivers/net/sk98lin/skgepnmi.c| 2282 +++--- drivers/net/sk98lin/skgesirq.c| 1244 +++- drivers/net/sk98lin/ski2c.c | 1296 - drivers/net/sk98lin/sklm80.c | 10 drivers/net/sk98lin/skproc.c | 587 - drivers/net/sk98lin/skqueue.c | 103 - drivers/net/sk98lin/skrlmt.c | 258 +- drivers/net/sk98lin/sktimer.c | 61 drivers/net/sk98lin/sktwsi.c | 1355 + drivers/net/sk98lin/skvpd.c | 195 + drivers/net/sk98lin/skxmac2.c | 2235 +- drivers/net/sk98lin/sky2.c| 2728 +++ drivers/net/sk98lin/sky2le.c | 510 + 50 files changed, 18204 insertions(+), 8761 deletions(-) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A way to smoothly overgive graphics control to an other process/program
Is this technically feasible? It's technically pointless. Take a look at bootsplash, though. -- Måns Rullgård [EMAIL PROTECTED] Bootsplash does exactly what I was complaining about. It controls only some part of the process of *booting* into the desktop without smooth transition (though it's at least a nice toy). The rest of your answer hits me but doesn't help me a little. Sorry if I am a pointless non-geek. Dennis - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
Hi, On Fri, 8 Apr 2005, Tupshin Harper wrote: A1 - A2 - A3 - B1 - B2 This results in a simpler repository, which is more scalable and which is easier for users to work with (e.g. binary bug search). The disadvantage would be it will cause more minor conflicts, when changes are pulled back into the original tree, but which should be easily resolvable most of the time. Both darcs and arch (and arch's siblings) have ways of maintaining the complete history but speeding up operations. Please show me how you would do a binary search with arch. I don't really like the arch model, it's far too restrictive and it's jumping through hoops to get to an acceptable speed. What I expect from a SCM is that it maintains both a version index of the directory structure and a version index of the individual files. Arch makes it especially painful to extract this data quickly. For the common cases it throws disk space at the problem and does a lot of caching, but there are still enough problems (e.g. annotate), which require scanning of lots of tarballs. bye, Roman - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
On 2005-04-08, at 18:15, Matthias-Christian Ott wrote: Linus Torvalds wrote: SQL Databases like SQLite aren't slow. But maybe a Berkeley Database v.4 is a better solution. Yes it sucks less for this purpose. See subversion as reference. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
On 2005-04-07, at 09:44, Jan Hudec wrote:
I have looked at most systems currently available. I would suggest
following for closer look on:
1) GNU Arch/Bazaar. They use the same archive format, simple, have the
concepts right. It may need some scripts or add ons. When Bazaar-NG
is ready, it will be able to read the GNU Arch/Bazaar archives so
switching should be easy.
Arch isn't a sound example of software design. Quite contrary to the
random notes posted by it's author the following issues did strike me
the time I did evaluate it:
The application (tla) claims to have intuitive command names. However
I didn't see that as given. Most of them where difficult to remember
and appeared to be just infantile. I stopped looking further after I
saw:
tla my-id instead of: tla user-id or oeven tla set id ...
tla make-archive instead of tla init
tla my-default-archive [EMAIL PROTECTED]
No more My Compuer please...
Repository addressing requires you to use informally defined
very elaborated and typing error prone conventions:
mkdir ~/{archives}
tla make-archive [EMAIL PROTECTED]
~/{archives}/2005-VersionPatrol
You notice the requirement for two commands to accomplish a single task
already
well denoted by the second command? There is more of the same at quite
a few places
when you try to use it. You notice the triple zero it didn't catch?
As an added bonus it relies on the applications named by accident
patch and diff and installed on the host in question as well as few
other as well to
operate.
Better don't waste your time with looking at Arch. Stick with patches
you maintain by hand combined with some scripts containing a list of
apply commands
and you should be still more productive then when using Arch.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
On 2005-04-06, at 23:13, [EMAIL PROTECTED] wrote: Linus Torvalds wrote: PS. Don't bother telling me about subversion. If you must, start reading up on monotone. That seems to be the most viable alternative, but don't pester the developers so much that they don't get any work done. They are already aware of my problems ;) By the way, the Subversion developers have no argument with the claim that Subversion would not be the right choice for Linux kernel development. We've written an open letter entitled Please Stop Bugging Linus Torvalds About Subversion to explain why: http://subversion.tigris.org/subversion-linus.html Thumbs up Subverters! I just love you. I love your attitude toward high engineering quality. And I appreciate actually very much what you provide as software. Both: from function and in terms of quality of implementation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
On 2005-04-08, at 19:14, Linus Torvalds wrote: You do that with an sql database, and I'll be impressed. It's possible. But what will impress you are either the price tag the DB comes with or the hardware it runs on :-) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
const qualifiers on function returns type
Hi, there are some function who are declared this way: include/linux/cpuset.h:21 extern const cpumask_t cpuset_cpus_allowed(const struct task_struct *p); I was wondering what means const for a function returns type. KR doesn't say anything about this and gcc-4 warns (warning: type qualifiers ignored on function return type) If it is a mistake, there are a few functions who should be modified. Regards, Benoit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
On 2005-04-08, at 20:14, Linus Torvalds wrote: On Fri, 8 Apr 2005, Matthias-Christian Ott wrote: Ok, but if you want to search for information in such big text files it slow, because you do linear search No I don't. I don't search for _anything_. I have my own content-addressable filesystem, and I guarantee you that it's faster than mysql, because it depends on the kernel doing the right thing (which it does). Linus Sorry but you mistake the frequently seen SQL db abuse as DATA storage for what SQL databases are good at storing: well defined RELATIONS. Sure a filesystem is for data. SQL is for relations. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
On Sat, Apr 09, 2005 at 03:00:44AM +0200, Marcin Dalecki wrote: Yes it sucks less for this purpose. See subversion as reference. Whatever solution people come up with, ideally it should be tolerant to minor amounts of corruption (so I can recover the rest of my data if need be) and it should also have decent sanity checks to find corruption as soon as reasonable possible. I've been bitten by problems that subversion didn't catch but bk did. In the subversion case by the time I noticed much data was lost and none of the subversion tools were able to recover the rest of it. In the bk case, the data-loss was almost immediately noticeable and only affected a few files making recovery much easier. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
On 2005-04-08, at 20:28, Jon Smirl wrote: On Apr 8, 2005 2:14 PM, Linus Torvalds [EMAIL PROTECTED] wrote: How do you replicate your database incrementally? I've given you enough clues to do it for git in probably five lines of perl. Efficient database replication is achieved by copying the transaction logs and then replaying them. Most mid to high end databases support this. You only need to copy the parts of the logs that you don't already have. Databases supporting replication are called high end. You forgot the cats dance around the network this issue involves. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sound/oss/emu10k1: fix up warning: ignoring return value of `__copy_to_user'
Here's an attempts at fixing these warnings
sound/oss/emu10k1/cardwi.c:310: warning: ignoring return value of
`__copy_to_user', declared with attribute warn_unused_result
sound/oss/emu10k1/cardwi.c:319: warning: ignoring return value of
`__copy_to_user', declared with attribute warn_unused_result
in a sane way.
If this looks OK, then please apply, if not then comments are very
welcome.
(please keep me on CC)
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
diff -upr linux-2.6.12-rc2-mm2-orig/sound/oss/emu10k1/audio.c
linux-2.6.12-rc2-mm2/sound/oss/emu10k1/audio.c
--- linux-2.6.12-rc2-mm2-orig/sound/oss/emu10k1/audio.c 2005-03-02
08:37:48.0 +0100
+++ linux-2.6.12-rc2-mm2/sound/oss/emu10k1/audio.c 2005-04-09
03:02:40.0 +0200
@@ -110,13 +110,19 @@ static ssize_t emu10k1_audio_read(struct
if ((bytestocopy = wiinst-buffer.fragment_size)
|| (bytestocopy = count)) {
+ unsigned long residue;
bytestocopy = min_t(u32, bytestocopy, count);
- emu10k1_wavein_xferdata(wiinst, (u8 __user *)buffer,
bytestocopy);
-
- count -= bytestocopy;
- buffer += bytestocopy;
- ret += bytestocopy;
+ if ((residue = emu10k1_wavein_xferdata(wiinst, (u8
__user *)buffer, bytestocopy))) {
+ residue = bytestocopy - residue;
+ count -= residue;
+ buffer += residue;
+ ret += residue;
+ } else {
+ count -= bytestocopy;
+ buffer += bytestocopy;
+ ret += bytestocopy;
+ }
}
if (count 0) {
diff -upr linux-2.6.12-rc2-mm2-orig/sound/oss/emu10k1/cardwi.c
linux-2.6.12-rc2-mm2/sound/oss/emu10k1/cardwi.c
--- linux-2.6.12-rc2-mm2-orig/sound/oss/emu10k1/cardwi.c2005-03-02
08:38:12.0 +0100
+++ linux-2.6.12-rc2-mm2/sound/oss/emu10k1/cardwi.c 2005-04-09
03:02:06.0 +0200
@@ -304,10 +304,12 @@ void emu10k1_wavein_getxfersize(struct w
}
}
-static void copy_block(u8 __user *dst, u8 * src, u32 str, u32 len, u8 cov)
+static unsigned long copy_block(u8 __user *dst, u8 * src, u32 str, u32 len, u8
cov)
{
+ unsigned long ret = 0;
+
if (cov == 1)
- __copy_to_user(dst, src + str, len);
+ return __copy_to_user(dst, src + str, len);
else {
u8 byte;
u32 i;
@@ -316,22 +318,24 @@ static void copy_block(u8 __user *dst, u
for (i = 0; i len; i++) {
byte = src[2 * i] ^ 0x80;
- __copy_to_user(dst + i, byte, 1);
+ ret += __copy_to_user(dst + i, byte, 1);
}
}
+
+ return ret;
}
-void emu10k1_wavein_xferdata(struct wiinst *wiinst, u8 __user *data, u32 *
size)
+unsigned long emu10k1_wavein_xferdata(struct wiinst *wiinst, u8 __user *data,
u32 * size)
{
struct wavein_buffer *buffer = wiinst-buffer;
u32 sizetocopy, sizetocopy_now, start;
- unsigned long flags;
+ unsigned long flags, ret = 0;
sizetocopy = min_t(u32, buffer-size, *size);
*size = sizetocopy;
if (!sizetocopy)
- return;
+ return 0;
spin_lock_irqsave(wiinst-lock, flags);
start = buffer-pos;
@@ -345,11 +349,12 @@ void emu10k1_wavein_xferdata(struct wiin
if (sizetocopy sizetocopy_now) {
sizetocopy -= sizetocopy_now;
- copy_block(data, buffer-addr, start, sizetocopy_now,
buffer-cov);
- copy_block(data + sizetocopy_now, buffer-addr, 0, sizetocopy,
buffer-cov);
+ ret += copy_block(data, buffer-addr, start, sizetocopy_now,
buffer-cov);
+ ret += copy_block(data + sizetocopy_now, buffer-addr, 0,
sizetocopy, buffer-cov);
} else {
- copy_block(data, buffer-addr, start, sizetocopy, buffer-cov);
+ ret += copy_block(data, buffer-addr, start, sizetocopy,
buffer-cov);
}
+ return ret;
}
void emu10k1_wavein_update(struct emu10k1_card *card, struct wiinst *wiinst)
diff -upr linux-2.6.12-rc2-mm2-orig/sound/oss/emu10k1/cardwi.h
linux-2.6.12-rc2-mm2/sound/oss/emu10k1/cardwi.h
--- linux-2.6.12-rc2-mm2-orig/sound/oss/emu10k1/cardwi.h2005-03-02
08:38:38.0 +0100
+++ linux-2.6.12-rc2-mm2/sound/oss/emu10k1/cardwi.h 2005-04-09
03:03:20.0 +0200
@@ -83,7 +83,7 @@ void emu10k1_wavein_close(struct emu10k1
void emu10k1_wavein_start(struct emu10k1_wavedevice *);
void emu10k1_wavein_stop(struct emu10k1_wavedevice *);
void emu10k1_wavein_getxfersize(struct wiinst *, u32 *);
-void emu10k1_wavein_xferdata(struct wiinst *, u8 __user *,
Phentermine CHEAPEST ON THE INTERNET
Get Popular Pain Meds Here - http://www.glbrx.com/scripts/default.asp?idaff=92 nothanks - http://www.glbpharma.com/aldfhsdlfh.asp - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
On 2005-04-09, at 03:09, Chris Wedgwood wrote: On Sat, Apr 09, 2005 at 03:00:44AM +0200, Marcin Dalecki wrote: Yes it sucks less for this purpose. See subversion as reference. Whatever solution people come up with, ideally it should be tolerant to minor amounts of corruption (so I can recover the rest of my data if need be) and it should also have decent sanity checks to find corruption as soon as reasonable possible. Yes this is the reason subversion is moving toward an alternative back-end based on a custom DB mapped closely to the file system. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
Roman Zippel wrote: Please show me how you would do a binary search with arch. I don't really like the arch model, it's far too restrictive and it's jumping through hoops to get to an acceptable speed. What I expect from a SCM is that it maintains both a version index of the directory structure and a version index of the individual files. Arch makes it especially painful to extract this data quickly. For the common cases it throws disk space at the problem and does a lot of caching, but there are still enough problems (e.g. annotate), which require scanning of lots of tarballs. bye, Roman I'm not going to defend or attack arch since I haven't used it enough. I will say that darcs largely does suffer from the same problem that you describe since its fundamental unit of storage is individual patches (though it avoids the tarball issue). This is why David Roundy has indicated his intention of eventually having a per-file cache: http://kerneltrap.org/mailarchive/1/message/24317/flat You could then make the argument that if you have a per-file representation of the history, why do you also need/want a per-patch representation as the canonical format, but that's been argued plenty on both the darcs and arch mailing lists and probably isn't worth going into here. -Tupshin - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mtime attribute is not being updated on client
On Fri, 2005-04-08 at 16:54, Linda Dunaphant wrote:
Do you think it would be better for nfs_refresh_inode() to check the mtime,
perform the mtime update if needed, and not set the NFS_INO_INVALID_ATTR
flag if the data_unstable flag is set? This is how nfs_update_inode()
handles its mtime check.
Hi again Trond,
I updated my first patch to nfs_refresh_inode() to be similar to the way
nfs_update_inode() does the check and update of the mtime. nfs_refresh_inode()
now checks to see if the mtime changed, and if so, it does the update of
the mtime. It only sets NFS_INO_INVALID_ATTR if data_unstable is not set.
I temporarily added some printk's to selected functions to monitor some of
the functions called after the data write to the server occurs. With this
latest patch, the sequence that I see with the test program is now the
same as it was originally without any patch - except the mtime is has been
updated:
nfs3_xdr_writeargs
xdr_decode_fattr--- new mtime from server
nfs_refresh_inode --- updates mtime in inode
nfs_attribute_timeout
nfs_attribute_timeout
xdr_decode_fattr
nfs_refresh_inode
With the first patch I proposed this sequence was:
nfs3_xdr_writeargs
xdr_decode_fattr--- new mtime from server
nfs_refresh_inode --- NFS_INO_INVALID_ATTR set
xdr_decode_fattr
nfs_update_inode--- updates mtime in inode
nfs_attribute_timeout
xdr_decode_fattr
Thank you for pointing out that there may be other consequences if the
NFS_INO_INVALID_ATTR is always set by nfs_refresh_inode() when the mtime
values are different. I believe this second patch fixes the original
problem without affecting any other behaviour.
Cheers,
Linda
diff -ura base/fs/nfs/inode.c new/fs/nfs/inode.c
--- base/fs/nfs/inode.c 2005-04-07 16:04:40.0 -0400
+++ new/fs/nfs/inode.c 2005-04-08 19:23:44.151698674 -0400
@@ -1176,9 +1176,17 @@
}
/* Verify a few of the more important attributes */
+ if (!timespec_equal(inode-i_mtime, fattr-mtime)) {
+ memcpy(inode-i_mtime, fattr-mtime, sizeof(inode-i_mtime));
+#ifdef NFS_DEBUG_VERBOSE
+ printk(KERN_DEBUG NFS: mtime change on %s/%ld\n,
inode-i_sb-s_id, inode-i_ino);
+#endif
+ if (!data_unstable)
+ nfsi-flags |= NFS_INO_INVALID_ATTR;
+ }
+
if (!data_unstable) {
- if (!timespec_equal(inode-i_mtime, fattr-mtime)
- || cur_size != new_isize)
+ if (cur_size != new_isize)
nfsi-flags |= NFS_INO_INVALID_ATTR;
} else if (S_ISREG(inode-i_mode) new_isize cur_size)
nfsi-flags |= NFS_INO_INVALID_ATTR;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] make mempool_destroy resilient against NULL pointers.
General rule (as I understand it) is that functions that free resources
should handle being passed NULL pointers - mempool_destroy() will
currently explode if passed a NULL pointer, the patch below makes it safe
to pass it NULL.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
mempool.c |2 ++
1 files changed, 2 insertions(+)
--- linux-2.6.12-rc2-mm2-orig/mm/mempool.c 2005-04-05 21:21:56.0
+0200
+++ linux-2.6.12-rc2-mm2/mm/mempool.c 2005-04-09 03:33:58.0 +0200
@@ -176,6 +176,8 @@ EXPORT_SYMBOL(mempool_resize);
*/
void mempool_destroy(mempool_t *pool)
{
+ if (!pool)
+ return;
if (pool-curr_nr != pool-min_nr)
BUG(); /* There were outstanding elements */
free_pool(pool);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make mempool_destroy resilient against NULL pointers.
Jesper Juhl [EMAIL PROTECTED] wrote: General rule (as I understand it) is that functions that free resources should handle being passed NULL pointers - mempool_destroy() will currently explode if passed a NULL pointer, the patch below makes it safe to pass it NULL. The best response to mempool_destroy(0) is an oops. There's no legitimate reason for doing it. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make mempool_destroy resilient against NULL pointers.
On Fri, 8 Apr 2005, Andrew Morton wrote: Jesper Juhl [EMAIL PROTECTED] wrote: General rule (as I understand it) is that functions that free resources should handle being passed NULL pointers - mempool_destroy() will currently explode if passed a NULL pointer, the patch below makes it safe to pass it NULL. The best response to mempool_destroy(0) is an oops. There's no legitimate reason for doing it. Ok, ignore the patch then. -- Jesper - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] disable built-in modules V2
Magnus Damm [EMAIL PROTECTED] wrote:
Say a kernel shipped with your favourite distribution crashes your
machine during boot-up - wouldn't it be nice to be able to just
disable the problematic module from the kernel command line instead of
Perhaps your favourite distribution could build that as a module to
start with.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm2
On Sat, Apr 09, 2005 at 01:28:47AM +0200, Jesper Juhl wrote: On Fri, 8 Apr 2005, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm2/ Still doesn't build for me with my usual config (available upon request) unless I enable ACPI : ... CC arch/i386/kernel/setup.o arch/i386/kernel/setup.c:96: error: parse error before acpi_sci_flags arch/i386/kernel/setup.c:96: warning: type defaults to `int' in declaration of `acpi_sci_flags' arch/i386/kernel/setup.c:96: warning: data definition has no type or storage class arch/i386/kernel/setup.c: In function `parse_cmdline_early': arch/i386/kernel/setup.c:811: error: request for member `trigger' in something not a structure or union arch/i386/kernel/setup.c:814: error: request for member `trigger' in something not a structure or union arch/i386/kernel/setup.c:817: error: request for member `polarity' in something not a structure or union arch/i386/kernel/setup.c:820: error: request for member `polarity' in something not a structure or union make[1]: *** [arch/i386/kernel/setup.o] Error 1 make: *** [arch/i386/kernel] Error 2 This seem to be the ACPI=y, ACPI_BOOT=n errors we already saw in -mm1 Len will send a patch for. Jesper Juhl cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
On Sat, 9 Apr 2005, Marcin Dalecki wrote: On 2005-04-08, at 20:28, Jon Smirl wrote: On Apr 8, 2005 2:14 PM, Linus Torvalds [EMAIL PROTECTED] wrote: How do you replicate your database incrementally? I've given you enough clues to do it for git in probably five lines of perl. Efficient database replication is achieved by copying the transaction logs and then replaying them. Most mid to high end databases support this. You only need to copy the parts of the logs that you don't already have. Databases supporting replication are called high end. You forgot the cats dance around the network this issue involves. And Postgres (which is Free in all senses of the word) is high end by this definition. I'm not saying that it's an efficiant thing to use for this task, but don't be fooled into thinking you need something on the price of Oracle to do this job. David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm2
On Sat, 9 Apr 2005, Adrian Bunk wrote: On Sat, Apr 09, 2005 at 01:28:47AM +0200, Jesper Juhl wrote: On Fri, 8 Apr 2005, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm2/ Still doesn't build for me with my usual config (available upon request) unless I enable ACPI : ... CC arch/i386/kernel/setup.o arch/i386/kernel/setup.c:96: error: parse error before acpi_sci_flags arch/i386/kernel/setup.c:96: warning: type defaults to `int' in declaration of `acpi_sci_flags' arch/i386/kernel/setup.c:96: warning: data definition has no type or storage class arch/i386/kernel/setup.c: In function `parse_cmdline_early': arch/i386/kernel/setup.c:811: error: request for member `trigger' in something not a structure or union arch/i386/kernel/setup.c:814: error: request for member `trigger' in something not a structure or union arch/i386/kernel/setup.c:817: error: request for member `polarity' in something not a structure or union arch/i386/kernel/setup.c:820: error: request for member `polarity' in something not a structure or union make[1]: *** [arch/i386/kernel/setup.o] Error 1 make: *** [arch/i386/kernel] Error 2 This seem to be the ACPI=y, ACPI_BOOT=n errors we already saw in -mm1 Actually, I get these errors with ACPI=n, ACPI_BOOT=y, not the reverse as you say. Len will send a patch for. Ok, I was not aware of that, will be looking forward to it :) -- Jesper - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE CMD 64x PCI driver (BUG REPORT; CMD 648 DMA INITIALIZATION)
Quick follow up: I decided to disable the DMA controller as a near term solution. This works but it is not optimal for obvious reasons. I believe that the chipset initialization for utilizing the DMA controller is incorrectly setup, for the particular model I am using (CMD 648). I don't know when/if I will look into this further. For more information regarding my analysis of the problem refer to my first email, with the email subject as IDE CMD 64x PCI driver. -Rob - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: turn kmalloc+memset(,0,) into kcalloc
On Wed, 6 Apr 2005, Jörn Engel wrote: On Tue, 5 April 2005 22:01:49 +0200, Jesper Juhl wrote: On Tue, 5 Apr 2005, Roland Dreier wrote: or simply if (!(ptr = kcalloc(n, size, ...))) goto out; and save an additional line of screen realestate while you are at it... No, please don't do that. The general kernel style is to avoid assignments within conditionals. It may be the prefered style to avoid assignments in conditionals, but in that case we have a lot of cleanup to do. What I wrote above is quite common in the current tree - a simple egrep -r if\ *\(\!\(.+= * in 2.6.12-rc2-mm1 will find you somewhere between 1000 and 2000 cases scattered all over the tree. Personally I don't see why thy should not be used. They are short, not any harder to read (IMHO), save screen space are quite common in userspace code as well (so people should be used to seeing them). If such statements are generally frawned upon then I'd suggest an addition be made to Documentation/CodingStyle mentioning that fact, and I wonder if patches to clean up current users would be welcome? I _do_ change them whenever they occur in code I maintain. And each time, it is an improvement. o Functional code always has the same indentation. I can mentally ignore the error path by ignoring all indented code. Getting a quick overview is quite nice. o Rather often, your preferred variant violates the 80 columns rule. If I need the line break anyway,... o Keeping condition and functional code seperate avoids the Lisp-style bracket maze. Some editors can help you here, but not needing any help would be even better, no? Ok, I accept those arguments, they make sense. I may still have a personal preference that differ slightly, but I see your point(s). -- Jesper - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no need to check for NULL before calling kfree() -fs/ext2/
On Wed, 30 Mar 2005, Jesper Juhl wrote: On Tue, 29 Mar 2005, Paul Jackson wrote: Pekka wrote: (4) The cleanups Jesper and others are doing are to remove the _redundant_ NULL checks (i.e. it is now checked twice). Even such obvious changes as removing redundant checks doesn't seem to ensure a performance improvement. Jesper Juhl posted performance data for such changes in his microbenchmark a couple of days ago. As I posted then, I could swear that his numbers show: Just looking at the third run, it seems to me that if (likely(p)) kfree(p); beats a naked kfree(p); everytime, whether p is half NULL's, or very few NULL's, or almost all NULL's. Twice now I have asked Jesper to explain this strange result. I've been kept busy with other things for a while and haven't had the time to reply to your emails, sorry. As I just said in another post I don't know how valid my numbers are, but I'll try and craft a few more tests to see if I can get some more solid results. Maybe we should be following your good advice: You don't know that until you profile! instead of continuing to make these code changes. I'll gather some more numbers and post them along with any conclusions I believe can be drawn from them within a day or two, untill then I'll hold back on the patches... Ok, I never got around to doing some more benchmarks, mainly since it seems that people converged on the oppinion that the kfree() cleanups are OK and we can fix up any regressions by inlining kfree if needed (the difference these changes make to performance seem to be small and in the noice anyway). If anyone would /like/ me to do more benchmarks, then speak up and I will do them - I guess I could also build a kernel with an inline kfree() as a comparison.. but, unless someone speaks up I'll just carry on making these kfree() cleanups and not bother with benchmarks... -- Jesper - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
On Fri, Apr 08, 2005 at 05:12:49PM -0700, Linus Torvalds wrote: really designed for something like a offline http grabber, in that you can just grab files purely by filename (and verify that you got them right by running sha1sum on the resulting local copy). So think wget. I'm not entirely convinced wget is going to be an efficient way to synchronize and fetch your tree, its simplicitly is great though. It's a tradeoff between optimzing and re-using existing tools (like webservers). Perhaps that's why you were compressing the stuff too? It sounds better not to compress the stuff on-disk, and to synchronize with a rsync-like protocol (rsync server would make it) that handles the compression in the network protocol itself, and in turn that can apply compression to a large blob (i.e. the diff between the trees), and not to the single tiny files. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
On Sat, 9 Apr 2005, Andrea Arcangeli wrote: On Fri, Apr 08, 2005 at 05:12:49PM -0700, Linus Torvalds wrote: really designed for something like a offline http grabber, in that you can just grab files purely by filename (and verify that you got them right by running sha1sum on the resulting local copy). So think wget. I'm not entirely convinced wget is going to be an efficient way to synchronize and fetch your tree, its simplicitly is great though. It's a tradeoff between optimzing and re-using existing tools (like webservers). Perhaps that's why you were compressing the stuff too? It sounds better not to compress the stuff on-disk, and to synchronize with a rsync-like protocol (rsync server would make it) that handles the compression in the network protocol itself, and in turn that can apply compression to a large blob (i.e. the diff between the trees), and not to the single tiny files. note that many webservers will compress the data for you on the fly as well, so there's even less need to have it pre-compressed David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: const qualifiers on function returns type
Benoit Boissinot [EMAIL PROTECTED] wrote: extern const cpumask_t cpuset_cpus_allowed(const struct task_struct *p); I was wondering what means const for a function returns type. KR doesn't say anything about this and gcc-4 warns (warning: type qualifiers ignored on function return type) It used to be a hint that the function has no side effect nor depends on any variable besides the parameters. Calls to those functions may be cached or omitted. -- Fun things to slip into your budget Paradigm pro-activator (a whole pack) (you mean beer?) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
On Fri, Apr 08, 2005 at 07:38:30PM -0400, Daniel Phillips wrote: For the immediate future, all we need is something than can _losslessly_ capture the new metadata that's being generated. That buys time to bring one of the promising open source candidates up to full speed. Agreed. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Kernel SCM saga..
Hello,
Dear diary, on Fri, Apr 08, 2005 at 05:50:21PM CEST, I got a letter
where Linus Torvalds [EMAIL PROTECTED] told me that...
On Fri, 8 Apr 2005 [EMAIL PROTECTED] wrote:
Here's a partial solution. It does depend on a modified version of
cat-file that behaves like cat. I found it easier to have cat-file
just dump the object indicated on stdout. Trivial patch for that is
included.
Your trivial patch is trivially incorrect, though. First off, some files
may be binary (and definitely are - the tree type object contains
pathnames, and in order to avoid having to worry about special characters
they are NUL-terminated), and your modified cat-file breaks that.
Secondly, it doesn't check or print the tag.
FWIW, I made few small fixes (to prevent some trivial usage errors to
cause cache corruption) and added scripts gitcommit.sh, gitadd.sh and
gitlog.sh - heavily inspired by what already went through the mailing
list. Everything is available at http://pasky.or.cz/~pasky/dev/git/
(including .dircache, even though it isn't shown in the index), the
cumulative patch can be found below. The scripts aim to provide some
(obviously very interim) more high-level interface for git.
I'm now working on tree-diff.c which will (surprise!) produce a diff
of two trees (I'll finish it after I get some sleep, though), and then I
will probably do some dwimmy gitdiff.sh wrapper for tree-diff and
show-diff. At that point I might get my hand on some pull more kind to
local changes.
Kind regards,
Petr Baudis
diff -ruN git-0.03/gitadd.sh git-devel-clean/gitadd.sh
--- git-0.03/gitadd.sh 1970-01-01 01:00:00.0 +0100
+++ git-devel-clean/gitadd.sh 2005-04-09 03:17:34.220577000 +0200
@@ -0,0 +1,13 @@
+#!/bin/sh
+#
+# Add new file to a GIT repository.
+# Copyright (c) Petr Baudis, 2005
+#
+# Takes a list of file names at the command line, and schedules them
+# for addition to the GIT repository at the next commit.
+#
+# FIXME: Those files are omitted from show-diff output!
+
+for file in $@; do
+ echo $file .dircache/add-queue
+done
diff -ruN git-0.03/gitcommit.sh git-devel-clean/gitcommit.sh
--- git-0.03/gitcommit.sh 1970-01-01 01:00:00.0 +0100
+++ git-devel-clean/gitcommit.sh2005-04-09 03:17:34.220577000 +0200
@@ -0,0 +1,36 @@
+#!/bin/sh
+#
+# Commit into a GIT repository.
+# Copyright (c) Petr Baudis, 2005
+# Based on an example script fragment sent to LKML by Linus Torvalds.
+#
+# Ignores any parameters for now, excepts changelog entry on stdin.
+#
+# FIXME: Gets it wrong for filenames containing spaces.
+
+
+if [ -r .dircache/add-queue ]; then
+ mv .dircache/add-queue .dircache/add-queue-progress
+ addedfiles=$(cat .dircache/add-queue-progress)
+else
+ addedfiles=
+fi
+changedfiles=$(show-diff -s | grep -v ': ok$' | cut -d : -f 1)
+commitfiles=$addedfiles $changedfiles
+if [ ! $commitfiles ]; then
+ echo 'Nothing to commit.' 2
+ exit
+fi
+update-cache $commitfiles
+rm -f .dircache/add-queue-progress
+
+
+oldhead=$(cat .dircache/HEAD)
+treeid=$(write-tree)
+newhead=$(commit-tree $treeid -p $oldhead)
+
+if [ $newhead ]; then
+ echo $newhead .dircache/HEAD
+else
+ echo Error during commit (oldhead $oldhead, treeid $treeid) 2
+fi
diff -ruN git-0.03/gitlog.sh git-devel-clean/gitlog.sh
--- git-0.03/gitlog.sh 1970-01-01 01:00:00.0 +0100
+++ git-devel-clean/gitlog.sh 2005-04-09 04:28:51.227791000 +0200
@@ -0,0 +1,61 @@
+#!/bin/sh
+
+ Call this script with an object and it will produce the change
+ information for all the parents of that object
+
+ This script was originally written by Ross Vandegrift.
+# multiple parents test 1d0f4aec21e5b66c441213643426c770dc6dedc0
+# parents: ffa098b2e187b71b86a76d3cd5eb77d074a2503c
+# 6860e0d9197c7f52155466c225baf39b42d62f63
+
+# regex for parent declarations
+PARENTS=^parent [A-z0-9]{40}$
+
+TMPCL=/tmp/gitlog.$$
+
+# takes an object and generates the object's parent(s)
+function unpack_parents () {
+ echo me $1
+ echo me $1 $TMPCL
+ RENTS=
+
+ TMPCM=$(mktemp)
+ cat-file commit $1 $TMPCM
+ while read line; do
+ if echo $line | egrep -q $PARENTS; then
+ RENTS=$RENTS $(echo $line | sed 's/parent //g')
+ fi
+ echo $line
+ done $TMPCM
+ rm $TMPCM
+
+ echo -e \n--\n
+
+ # if the last object had no parents, return
+ if [ ! $RENTS ]; then
+ return;
+ fi
+
+ #useful for testing
+ #echo $RENTS
+ #read
+ for i in `echo $RENTS`; do
+ # break cycles
+ if grep -q me $i $TMPCL; then
+ echo Already visited $i 2
+ continue
+ else
+ unpack_parents $i
+ fi
+ done
+}
+
+base=$1
+if [ ! $base ]; then
+ base=$(cat
Re: Kernel SCM saga..
Andrea Arcangeli wrote: On Fri, Apr 08, 2005 at 05:12:49PM -0700, Linus Torvalds wrote: really designed for something like a offline http grabber, in that you can just grab files purely by filename (and verify that you got them right by running sha1sum on the resulting local copy). So think wget. I'm not entirely convinced wget is going to be an efficient way to synchronize and fetch your tree, its simplicitly is great though. It's a tradeoff between optimzing and re-using existing tools (like webservers). Perhaps that's why you were compressing the stuff too? It sounds better not to compress the stuff on-disk, and to synchronize with a rsync-like protocol (rsync server would make it) that handles the compression in the network protocol itself, and in turn that can apply compression to a large blob (i.e. the diff between the trees), and not to the single tiny files. It's my understanding that the files don't change. Only new ones are created for each revision. -- Brian gErst - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
On Fri, Apr 08, 2005 at 11:08:58PM -0400, Brian Gerst wrote: It's my understanding that the files don't change. Only new ones are created for each revision. I said diff between the trees, not diff between files ;). When you fetch the new changes with rsync, it'll compress better and in turn it'll be faster (assuming we're network bound and I am with 1mbit and 2.5ghz cpu), if it's rsync applying gzip to the big combined diff between trees instead of us compressing every single small file on disk, that won't compress anymore inside rsync. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
With the patch you provide to me, i did not see the bugcheck
at cn_queue_wrapper() at the console.
Unmatched sequence number messages still happened. We expect
to lose packets under system stressed situation, but i still
observed duplicate messages, which concerned me.
Unmatched seq. Rcvd=79477, expected=79478 === duplicate
Unmatched seq. Rcvd=713823, expected=713422 * loss of 401 msgs
Unmatched seq. Rcvd=80024, expected=79901 * loss of 123 msgs
Unmatched seq. Rcvd=93632, expected=93633 === duplicate
Unmatched seq. Rcvd=94718, expected=93970
Unmatched seq. Rcvd=743576, expected=743502
Unmatched seq. Rcvd=123506, expected=123507 === duplicate
Unmatched seq. Rcvd=773753, expected=773503
Unmatched seq. Rcvd=124111, expected=123938
Unmatched seq. Rcvd=157172, expected=157173 === duplicate
Unmatched seq. Rcvd=813024, expected=812913 === duplicate
Unmatched seq. Rcvd=813024, expected=813025 === duplicate
Unmatched seq. Rcvd=157830, expected=157501
Unmatched seq. Rcvd=158408, expected=158145
Unmatched seq. Rcvd=813678, expected=813438
The test system was a two cpu ia64.
Thanks,
- jay
Evgeniy Polyakov wrote:
On Fri, 08 Apr 2005 15:08:13 -0700
Jay Lan [EMAIL PROTECTED] wrote:
Hi Evgeniy,
Forget about my previous request of a new patch.
The failures were straight forward enough to figure out.
Ok.
The latest sources are always awailable at
http://tservice.net.ru/~s0mbre/archive/connector
- jay
Jay Lan wrote:
My workarea was based on 2.6.12-rc1-mm4 plus Guilluame's patch.
Your patch caused 5 out of 8 hunks failure at connector.c
and one failure at connector.h.
Could you generate a new patch based on my version? A tar
file of complete source of drivers/connector would work
also. :)
Thanks!
- jay
Evgeniy Polyakov wrote:
Could you give attached patch a try instead of previous one.
It adds gfp mask into cn_netlink_send() call also.
If you need updated CBUS sources, feel free to ask, I will send
updated sources with Andrew's comments resolved too.
I do not know exactly your connector version, so patch will probably
be applied with fuzz.
feel free to contact if it does not apply, I will send
the whole sources.
Thank you.
* looking for [EMAIL PROTECTED]/connector--main--0--patch-38 to
compare with
* comparing to [EMAIL PROTECTED]/connector--main--0--patch-38
M connector.c
M connector.h
M cbus.c
* modified files
--- orig/drivers/connector/connector.c
+++ mod/drivers/connector/connector.c
@@ -70,7 +70,7 @@
* then it is new message.
*
*/
-void cn_netlink_send(struct cn_msg *msg, u32 __groups)
+void cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask)
{
struct cn_callback_entry *n, *__cbq;
unsigned int size;
@@ -102,7 +102,7 @@
size = NLMSG_SPACE(sizeof(*msg) + msg-len);
-skb = alloc_skb(size, GFP_ATOMIC);
+skb = alloc_skb(size, gfp_mask);
if (!skb) {
printk(KERN_ERR Failed to allocate new skb with size=%u.\n,
size);
return;
@@ -119,11 +119,11 @@
#endif
NETLINK_CB(skb).dst_groups = groups;
-
-uskb = skb_clone(skb, GFP_ATOMIC);
-if (uskb)
+#if 0
+uskb = skb_clone(skb, gfp_mask);
+if (uskb 0)
netlink_unicast(dev-nls, uskb, 0, 0);
-
+#endif
netlink_broadcast(dev-nls, skb, 0, groups, GFP_ATOMIC);
return;
@@ -158,7 +158,7 @@
}
spin_unlock_bh(dev-cbdev-queue_lock);
-return found;
+return (found)?0:-ENODEV;
}
/*
@@ -181,7 +181,6 @@
requested msg-len=%u[%u], nlh-nlmsg_len=%u,
skb-len=%u.\n,
msg-len, NLMSG_SPACE(msg-len + sizeof(*msg)),
nlh-nlmsg_len, skb-len);
-kfree_skb(skb);
return -EINVAL;
}
#if 0
@@ -215,17 +214,18 @@
skb-len, skb-data_len, skb-truesize, skb-protocol,
skb_cloned(skb), skb_shared(skb));
#endif
-while (skb-len = NLMSG_SPACE(0)) {
+if (skb-len = NLMSG_SPACE(0)) {
nlh = (struct nlmsghdr *)skb-data;
+
if (nlh-nlmsg_len sizeof(struct cn_msg) ||
skb-len nlh-nlmsg_len ||
nlh-nlmsg_len CONNECTOR_MAX_MSG_SIZE) {
-#if 0
+#if 1
printk(KERN_INFO nlmsg_len=%u, sizeof(*nlh)=%u\n,
nlh-nlmsg_len, sizeof(*nlh));
#endif
kfree_skb(skb);
-break;
+goto out;
}
len = NLMSG_ALIGN(nlh-nlmsg_len);
@@ -233,22 +233,11 @@
len = skb-len;
err = __cn_rx_skb(skb, nlh);
-if (err) {
-#if 0
-if (err 0 (nlh-nlmsg_flags NLM_F_ACK))
-netlink_ack(skb, nlh, -err);
-#endif
-break;
-} else {
-#if 0
-if (nlh-nlmsg_flags NLM_F_ACK)
-netlink_ack(skb, nlh, 0);
-#endif
-break;
-}
-skb_pull(skb, len);
+if (err 0)
+kfree_skb(skb);
}
-
+
+out:
kfree_skb(__skb);
}
@@ -310,7 +299,7 @@
m.ack = notify_event;
memcpy(m.id, id, sizeof(m.id));
-cn_netlink_send(m, ctl-group);
Re: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
Version from syskonnect site require only changing usage of pci_dev-slot_name to pci_name(pci_dev) in skge.c and skethtool.c. After that everything should work fine. So I think there is no need to post my path here but if you really whant I may do this. Whole path agains 2.6.12-rc2 take about 1.2 MB (diffstat attached below). I agree, no need to post a whole 1.2MB patch (goodness, what's in this driver, anyway, that it would need a 1.2MB *patch*? :-)) But you seem to be saying that the driver from syskonnect (and possibly the one in 2.6.12-rc1-bk3 as well) does not work as-is, and that you have a small patch that makes it work. If so, I think it's worth posting the small patch, so other users of the device can at least get it working until syskonnect gets things squared away. My apologies if I'm misunderstanding the situation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
$B$h$m$7$/$G$9!y(B
$B?k$K%*!%W%s$7$^$7$?(B(^-^) $B$*6b$,$J$$?M!=P2q$$$?$$?M!$$$^$^$G;E;v$N4X78$G=w$N;R$HIU$-9g$%A%c%s%9$,/(B $B$J$$?M!(B $B$3$3I,8+*(Bhttp://www.getluck.net/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PCMAC: 130US$ == Adobe Photoshop v7 ++ Adobe Premiere v7 ++ Adobe Illustrator v10
www.azwpdrayw3shpta.knalkoxylhe.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
Linus Torvalds wrote: Which is why I'd love to hear from people who have actually used various SCM's with the kernel. There's bound to be people who have already tried. At the end of my Codecon talk, there is a performance comparison of a number of different distributed SCM's with the kernel. http://superbeast.ucsd.edu/~landry/ArX/codecon/codecon.html I develop ArX (http://www.nongnu.org/arx). You may find it of interest ;) Cheers, Walter Landry [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 'BUG: scheduling with irqs disabled' when umounting NFS volume
* Daniel Walker [EMAIL PROTECTED] wrote: I submitted a fix for this a while ago, I think .. interruptible_sleep_on()'s are broken .. sleep_on() is a fundamentally broken interface, it only works on UP - but there it _does_ rely on the behavior your patch removes. (i.e. disabled interrupts until we hit schedule()) the PREEMPT_RT kernel makes the limitations of sleep_on() even more apparent. The patch only removes the warning, it doesnt remove the race. To remove the race, sleep_on() usage should be converted to something else. (e.g. one of the wait_event() variants) Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
$B!y(B10000$B1_J,L5NA!y(B
$B###!V(B1$B1_!WJ,L5NA%]%$%s%HB#Dh%-%c%s%Z!%sB;\Cf!*###(B $B$3$N=U$N=P2q$$$r6/NO$K;Y1g$7$^$9!*(B $B:#$9$0EPO?$7$FD:$$$?J}$K$O!;O$a$K(B1$B1_J,$N%]%$%s%H$rL5NA$G:9$7e$2$^$9!*(B $B!(B1$B1_L5NA%]%$%s%H$H?7$7$$=P2q$$(BGET$B!(B http://awg.qsv20.com/?springm $B!zL5NA$GAjEvM7$Y$^$9$N$G@'Hs$*;n$72$5$$$Mv(B $B!z;HMQ$7$F$_$F!V$3$l$O!*!W$H;W$C$FD:$$$?J}$N$_!VM-NA!W$X$*?J$_2$5$$!#(B - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
easy softball jiffies quest(ion)
hi,
i'm on a quest to get access to jiffies in user space so i can write a
simple stepper motor driver program. i co-opted the #includes list
from alessandro rubini's jit.c file from linux device drivers to write
jfi.c.
this is it:
--
#include linux/config.h
#include linux/module.h
#include linux/moduleparam.h
#include linux/init.h
#include linux/time.h
#include linux/timer.h
#include linux/kernel.h
#include linux/proc_fs.h
#include linux/types.h
#include linux/spinlock.h
#include linux/interrupt.h
#include asm/hardirq.h
int main(void)
{
unsigned long j = jiffies + (50 * HZ);
printf(start jiffies = %9li\n,jiffies);
while(jiffies j)
;
printf(done jiffies = %9li\n, jiffies);
return 0;
}
---
all right, you can giggle, but no laughing out loud, my kernel ego is
nacent and fragile.
when i compile it with:
gcc -o jfi.x jfi.c
i get a handful of errors regarding various #include statements:
-
jfi.c:3:31: linux/moduleparam.h: No such file or directory
In file included from jfi.c:6:
/usr/include/linux/time.h:10: error: syntax error before time_t
/usr/include/linux/time.h:12: error: syntax error before '}' token
/usr/include/linux/time.h:18: error: syntax error before time_t
/usr/include/linux/time.h:44: error: field `it_interval' has incomplete type
/usr/include/linux/time.h:45: error: field `it_value' has incomplete type
/usr/include/linux/time.h:49: error: field `it_interval' has incomplete type
/usr/include/linux/time.h:50: error: field `it_value' has incomplete type
jfi.c:7:25: linux/timer.h: No such file or directory
In file included from /usr/include/linux/interrupt.h:9,
from jfi.c:12:
/usr/include/asm/bitops.h:327:2: warning: #warning This include file is
not available on all architectures.
/usr/include/asm/bitops.h:328:2: warning: #warning Using kernel headers
in userspace: atomicity not guaranteed
In file included from jfi.c:12:
/usr/include/linux/interrupt.h:12:25: asm/hardirq.h: No such file or directory
/usr/include/linux/interrupt.h:13:25: asm/softirq.h: No such file or directory
jfi.c: In function `main':
jfi.c:19: error: `jiffies' undeclared (first use in this function)
jfi.c:19: error: (Each undeclared identifier is reported only once
jfi.c:19: error: for each function it appears in.)
./jfsh: line 8: jfi.x: command not found
-
i kind of figured you guys would know what to do. it's sort of a rarefied
group. anyway, if you can help, i'd really appreciate it, because
alessandro's makefile was somewhat cryptic.
you know, the operating systems class this semester at the university
of maryland, college park, was taught based on that new, exciting os, win xp.
and he managed to turn a 2 day class, where a day has a lecture and a lab,
into a 4 day affair, monday lecture, tuesday lab, wednesday lecture, thursday
lab. i took data structures instead. i am not taking any win xp os
class. it's linux or nothing. can you believe that, win xp?
one more thing, um, i'm paralyzed from the shoulders down, but i can type
with both hands using typing aids, and i also use a kensington expert mouse
trackball. i would like to write a mouse manager where i could assign
different actions for each button, something very similar to the kensington
interface that's available for, um, windows. i found some xwindow functions
for button pressing events, but i don't know how to get into the mouse driver
or button events in xwindows or gnome, etc.
if somebody has a direction to go for that, that would be a big help.
thanks, or tgfl(inux),
philip dahlquist
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] sched: unlocked context-switches
* Luck, Tony [EMAIL PROTECTED] wrote:
tested on x86, and all other arches should work as well, but if an
architecture has irqs-off assumptions in its switch_to() logic
it might break. (I havent found any but there may such assumptions.)
The ia64_switch_to() code includes a section that can change a pinned
MMU mapping (when the stack for the new process is in a different
granule from the stack for the old process). [...]
thanks - updated patch below. Any other architectures that switch the
kernel stack in a nonatomic way? x86/x64 switches it atomically.
Ingo
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
--- linux/kernel/sched.c.orig
+++ linux/kernel/sched.c
@@ -222,7 +222,6 @@ struct runqueue {
unsigned long expired_timestamp;
unsigned long long timestamp_last_tick;
task_t *curr, *idle;
- struct mm_struct *prev_mm;
prio_array_t *active, *expired, arrays[2];
int best_expired_prio;
atomic_t nr_iowait;
@@ -276,71 +275,25 @@ static DEFINE_PER_CPU(struct runqueue, r
#define task_rq(p) cpu_rq(task_cpu(p))
#define cpu_curr(cpu) (cpu_rq(cpu)-curr)
-#ifndef prepare_arch_switch
-# define prepare_arch_switch(next) do { } while (0)
-#endif
-#ifndef finish_arch_switch
-# define finish_arch_switch(prev) do { } while (0)
-#endif
-
-#ifndef __ARCH_WANT_UNLOCKED_CTXSW
-static inline int task_running(runqueue_t *rq, task_t *p)
-{
- return rq-curr == p;
-}
-
-static inline void prepare_lock_switch(runqueue_t *rq, task_t *next)
-{
-}
-
-static inline void finish_lock_switch(runqueue_t *rq, task_t *prev)
-{
- spin_unlock_irq(rq-lock);
-}
-
-#else /* __ARCH_WANT_UNLOCKED_CTXSW */
-static inline int task_running(runqueue_t *rq, task_t *p)
+/*
+ * We can optimise this out completely for !SMP, because the
+ * SMP rebalancing from interrupt is the only thing that cares:
+ */
+static inline void set_task_on_cpu(struct task_struct *p, int val)
{
#ifdef CONFIG_SMP
- return p-oncpu;
-#else
- return rq-curr == p;
+ p-on_cpu = val;
#endif
}
-static inline void prepare_lock_switch(runqueue_t *rq, task_t *next)
+static inline int task_on_cpu(runqueue_t *rq, task_t *p)
{
#ifdef CONFIG_SMP
- /*
-* We can optimise this out completely for !SMP, because the
-* SMP rebalancing from interrupt is the only thing that cares
-* here.
-*/
- next-oncpu = 1;
-#endif
-#ifdef __ARCH_WANT_INTERRUPTS_ON_CTXSW
- spin_unlock_irq(rq-lock);
+ return p-on_cpu;
#else
- spin_unlock(rq-lock);
-#endif
-}
-
-static inline void finish_lock_switch(runqueue_t *rq, task_t *prev)
-{
-#ifdef CONFIG_SMP
- /*
-* After -oncpu is cleared, the task can be moved to a different CPU.
-* We must ensure this doesn't happen until the switch is completely
-* finished.
-*/
- smp_wmb();
- prev-oncpu = 0;
-#endif
-#ifndef __ARCH_WANT_INTERRUPTS_ON_CTXSW
- local_irq_enable();
+ return rq-curr == p;
#endif
}
-#endif /* __ARCH_WANT_UNLOCKED_CTXSW */
/*
* task_rq_lock - lock the runqueue a given task resides on and disable
@@ -855,7 +808,7 @@ static int migrate_task(task_t *p, int d
* If the task is not on a runqueue (and not running), then
* it is sufficient to simply update the task's cpu field.
*/
- if (!p-array !task_running(rq, p)) {
+ if (!p-array !task_on_cpu(rq, p)) {
set_task_cpu(p, dest_cpu);
return 0;
}
@@ -885,9 +838,9 @@ void wait_task_inactive(task_t * p)
repeat:
rq = task_rq_lock(p, flags);
/* Must be off runqueue entirely, not preempted. */
- if (unlikely(p-array || task_running(rq, p))) {
+ if (unlikely(p-array || task_on_cpu(rq, p))) {
/* If it's preempted, we yield. It could be a while. */
- preempted = !task_running(rq, p);
+ preempted = !task_on_cpu(rq, p);
task_rq_unlock(rq, flags);
cpu_relax();
if (preempted)
@@ -1150,7 +1103,7 @@ static int try_to_wake_up(task_t * p, un
this_cpu = smp_processor_id();
#ifdef CONFIG_SMP
- if (unlikely(task_running(rq, p)))
+ if (unlikely(task_on_cpu(rq, p)))
goto out_activate;
new_cpu = cpu;
@@ -1311,9 +1264,7 @@ void fastcall sched_fork(task_t *p, int
#ifdef CONFIG_SCHEDSTATS
memset(p-sched_info, 0, sizeof(p-sched_info));
#endif
-#if defined(CONFIG_SMP) defined(__ARCH_WANT_UNLOCKED_CTXSW)
- p-oncpu = 0;
-#endif
+ set_task_on_cpu(p, 0);
#ifdef CONFIG_PREEMPT
/* Want to start with kernel preemption disabled. */
p-thread_info-preempt_count = 1;
@@ -1458,45 +1409,11 @@ void fastcall sched_exit(task_t * p)
}
/**
- * prepare_task_switch - prepare to switch tasks
- * @rq: the runqueue preparing to switch
- * @next: the task we are going to switch to.
- *
- * This is called
HELP:porting linux PXA audio driver to RTLinux(RTLinux core driver)
Dear Friends, I am trying to port Linux PXA audio driver to RTLinux. I am using pxa-ac7.c and pxa-audio.c and eliminated sound_core.c, and i will register two device /dev/mixer and /dev/dsp to RTLinux kernel. The real need is, i wants to generate a sin wave using audio codec. With in 600us DMA controller should fill the codec FIFO, if that is not met distortion will happen. I think normal linux interrupts and Process scheduling may cause some problems. In porting it seems difficult to port kernel scheduling , dynamic memory allocation(for DMA) and synchronization. Please help me Nobin Mathew __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HELP:porting linux PXA audio driver to RTLinux(RTLinux core driver)
On Fri, 2005-04-08 at 21:03 -0700, nobin matthew wrote: Dear Friends, I am trying to port Linux PXA audio driver to RTLinux. I am using pxa-ac7.c and pxa-audio.c and eliminated sound_core.c, and i will register two device /dev/mixer and /dev/dsp to RTLinux kernel. The real need is, i wants to generate a sin wave using audio codec. With in 600us DMA controller should fill the codec FIFO, if that is not met distortion will happen. I think normal linux interrupts and Process scheduling may cause some problems. In porting it seems difficult to port kernel scheduling , dynamic memory allocation(for DMA) and synchronization. This is the exact same question you posted to linux-audio-dev. And you'll get the same answer here: Don't waste your time with RTLinux. Use a recent 2.6 kernel with Ingo's realtime-preempt patches. Configure with PREEMPT_RT. This will provide deterministic, hard realtime performance for any RT constraint down to about 50 usecs. RTLinux can meet a ~15 usec RT constraint, the RT preempt kernel will be able to do this once the timer ISR is made preemptible again. RTLinux is an obsolescent product that had its place in the 2.4 era but is being superseded by a solution that's both technically superior and 100% free software. Real time preemption is the future of hard realtime on Linux. All the major real time Linux players have recognized this, even the ones who had competing solutions for 2.4 are porting their work to the 2.6 RT-preempt framework. Besides, RTLinux is a commercial product anyway. If this project requires use of RTLinux for political reasons, call your support rep. Lee - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
On Sat, 9 Apr 2005, Andrea Arcangeli wrote: I'm not entirely convinced wget is going to be an efficient way to synchronize and fetch your tree I don't think it's efficient per se, but I think it's important that people can just pass the files along. Ie it's a huge benefit if any everyday mirror script (whether rsync, wget, homebrew or whatever) will just automatically do the right thing. Perhaps that's why you were compressing the stuff too? It sounds better not to compress the stuff on-disk I much prefer to waste some CPU time to save disk cache. Especially since the compression is free if you do it early on (ie it's done only once, since the files are stable). Also, if the difference is a 1.5GB kernel repository or a 3GB kernel repository, I know which one I'll pick ;) Also, I don't want people editing repostitory files by hand. Sure, the sha1 catches it, but still... I'd rather force the low-level ops to use the proper helper routines. Which is why it's a raw zlib compressed blob, not a gzipped file. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: easy softball jiffies quest(ion)
On Sat, 9 Apr 2005, philip dahlquist wrote:
hi,
Hello,
i'm on a quest to get access to jiffies in user space so i can write a
simple stepper motor driver program. i co-opted the #includes list
from alessandro rubini's jit.c file from linux device drivers to write
jfi.c.
Now, I might be _entirely_ off-base here, but... from what I know (which
is, admittedly, less than what many others here do) jiffies are a
kernel-land concept, implemented using a kernel-land variable. The
kernel protects itself from user-land programs, so your user-land
program will never be able to access the jiffies variable directly like
that.
As far as I know, it breaks down like this: If you want jiffies, then
your code should be a kernel module. If you want your code to run in
user-land, then you have to settle for knowing the time using alarm(),
clock_gettime(), gettimeofday(), or similar system-call-based mechanism.
this is it:
--
#include linux/config.h
#include linux/module.h
#include linux/moduleparam.h
#include linux/init.h
#include linux/time.h
#include linux/timer.h
#include linux/kernel.h
#include linux/proc_fs.h
#include linux/types.h
#include linux/spinlock.h
#include linux/interrupt.h
#include asm/hardirq.h
int main(void)
{
unsigned long j = jiffies + (50 * HZ);
printf(start jiffies = %9li\n,jiffies);
while(jiffies j)
;
printf(done jiffies = %9li\n, jiffies);
return 0;
}
---
all right, you can giggle, but no laughing out loud, my kernel ego is
nacent and fragile.
when i compile it with:
gcc -o jfi.x jfi.c
i get a handful of errors regarding various #include statements:
-
jfi.c:3:31: linux/moduleparam.h: No such file or directory
In file included from jfi.c:6:
/usr/include/linux/time.h:10: error: syntax error before time_t
/usr/include/linux/time.h:12: error: syntax error before '}' token
/usr/include/linux/time.h:18: error: syntax error before time_t
/usr/include/linux/time.h:44: error: field `it_interval' has incomplete type
/usr/include/linux/time.h:45: error: field `it_value' has incomplete type
/usr/include/linux/time.h:49: error: field `it_interval' has incomplete type
/usr/include/linux/time.h:50: error: field `it_value' has incomplete type
jfi.c:7:25: linux/timer.h: No such file or directory
In file included from /usr/include/linux/interrupt.h:9,
from jfi.c:12:
/usr/include/asm/bitops.h:327:2: warning: #warning This include file is
not available on all architectures.
/usr/include/asm/bitops.h:328:2: warning: #warning Using kernel headers
in userspace: atomicity not guaranteed
In file included from jfi.c:12:
/usr/include/linux/interrupt.h:12:25: asm/hardirq.h: No such file or directory
/usr/include/linux/interrupt.h:13:25: asm/softirq.h: No such file or directory
jfi.c: In function `main':
jfi.c:19: error: `jiffies' undeclared (first use in this function)
jfi.c:19: error: (Each undeclared identifier is reported only once
jfi.c:19: error: for each function it appears in.)
./jfsh: line 8: jfi.x: command not found
-
All the above errors come from the fact that you're trying to use
kernel-land include files and definitions within a user-program.
Probably not doable.
i kind of figured you guys would know what to do. it's sort of a rarefied
group. anyway, if you can help, i'd really appreciate it, because
alessandro's makefile was somewhat cryptic.
you know, the operating systems class this semester at the university
of maryland, college park, was taught based on that new, exciting os, win xp.
and he managed to turn a 2 day class, where a day has a lecture and a lab,
into a 4 day affair, monday lecture, tuesday lab, wednesday lecture, thursday
lab. i took data structures instead. i am not taking any win xp os
class. it's linux or nothing. can you believe that, win xp?
(Keep in mind that the following is my opinion only.) I'd say that
taking a Windows class might still be educational. Operating systems are
such a thing where learning one helps you understand a great deal about
_all_ of them. If anything, it'll at least give you more educated
reasons for disliking / hating our favorite monopolistic company or
operating system. :-)
one more thing, um, i'm paralyzed from the shoulders down, but i can type
with both hands using typing aids, and i also use a kensington expert mouse
trackball. i would like to write a mouse manager where i could assign
different actions for each button, something very similar to the kensington
interface that's available for, um, windows. i found some xwindow functions
for button pressing events, but i don't know how to get into the mouse driver
or button events in xwindows or gnome, etc.
Depends upon
where the agpcard driver creats its device
Hi, Can anybody tell me where the agpdrivers for the corresponding cards creats its device (ie like hard disks and floppy disks devices r there is /dev likewise) in 2.6 kernel. also where the framebuffer device located in 2.6 kernels, also can we opne it and send ioctls to read or write. Karthik. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
