Hi,
On Thu, 25 Aug 2005, Al Viro wrote:
> On Thu, Aug 25, 2005 at 11:15:24AM +0200, Roman Zippel wrote:
> > >
> > > - *ti = *orig->thread_info;
> > > *tsk = *orig;
> > > + setup_thread_info(tsk, ti);
> > > tsk->thread_info = ti;
> > > ti->task = tsk;
> >
> > This introduces a subtle orde
On Thu, Aug 25, 2005 at 09:59:05AM -0400, Sam Creasey wrote:
> I have been a little out of it for a while on the sun3 stuffs, I'll admit
> (cursed day job), but I really, really intend to get recent 2.6 running
> again. Knowing that the rest of m68k is at least compiling is a good
> start point.
Hi all,
Attached below is a patch heavily based on Jon Escombe's patch, but
implemented as a sysfs attribute as Jens described, with a timeout
(configurable by module/kernel parameter) to ensure the queue isn't
stopped forever.
The driver creates a sysfs attribute "/sys/block/hdX/device/freeze",
On Thu, 2005-08-25 at 16:03 +0200, Johannes Berg wrote:
> On Thu, 2005-08-25 at 09:47 -0400, Robert Love wrote:
>
> > Let's just pass zero for the "above" parameter in idr_get_new_above(),
> > which is I believe the behavior of the other interface, and see if the
> > 1024-multiple problem goes awa
> Ray Fucillo <[EMAIL PROTECTED]> writes:
> >
> > The application is a database system called Caché. We allocate a
> > large shared memory segment for database cache, which in a large
> > production environment may realistically be 1+GB on 32-bit platforms
> > and much larger on 64-bit. At these
On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote:
> I really wanted to release a 2.6.13, but there's been enough changes
> while we've been waiting for other issues to resolve that I think it's
> best to do a -rc7 first.
There's something strange going on with either ACPI or cpufr
On Thu, 2005-08-25 at 09:47 -0400, Robert Love wrote:
> Let's just pass zero for the "above" parameter in idr_get_new_above(),
> which is I believe the behavior of the other interface, and see if the
> 1024-multiple problem goes away. We definitely did not have that
> before.
Will we then need t
On Thu, 2005-08-25 at 15:50 +0200, Johannes Berg wrote:
> On Thu, 2005-08-25 at 09:40 -0400, John McCutchan wrote:
>
> > On 2.6.13-rc7 the test program fails. It always fails when a wd == 1024.
> > If I skip inotify_rm_watch when wd == 1024, it will fail at wd == 2048.
> > It seems the idr layer h
On Thu, 25 Aug 2005, Geert Uytterhoeven wrote:
> Can't you use the plain m68k toolchain? I always used a m68k-linux-gcc 3.3.3
> for my uClinux experiments.
>
> > sun3 is seriously broken and I doubt that we'll see any takers for testing
> > 2.6 on those anyway ;-)
Hey, I'm writing this on a sun
On Thu, Aug 25, 2005 at 02:07:38PM +0100, Al Viro wrote:
> Fine, as long as that merge is done before your s/thread_info/stack/ patches.
> It should be the first step before doing 200Kb worth of cosmetical stuff
> that affects every architecture out there, not something that depends on
> it done.
>
On Thu, 2005-08-25 at 09:40 -0400, John McCutchan wrote:
> On 2.6.13-rc7 the test program fails. It always fails when a wd == 1024.
> If I skip inotify_rm_watch when wd == 1024, it will fail at wd == 2048.
> It seems the idr layer has an aversion to multiples of 1024.
>
> When I run your test pro
On Thu, Aug 25, 2005 at 12:35:22AM -0400, [EMAIL PROTECTED] wrote:
> I don't know, because tar is probably more widely used and
> consequently people are more familiar with how to use it.
As I said before, the cpio format is cleaner/easier to parse in the
kernel. Everyone has cpio probably so us
On Thu, 2005-08-25 at 09:40 -0400, John McCutchan wrote:
> I get that message a lot. I know I have said this before (and was wrong)
> but I think the idr layer is busted.
This time I think I agree with you. ;-)
Let's just pass zero for the "above" parameter in idr_get_new_above(),
which is I be
Hmm, haven't yet figured out why, but something in this patchset
doesn't work for power5. Oops attached, as well as the assembly
for selinux_task_create (which I'm weeding through right now).
thanks,
-serge
Oops output from console:
Security Framework v1.0.0 initialized
SELinux: Initializing.
On Thu, Aug 25, 2005 at 12:32:50AM -0400, [EMAIL PROTECTED] wrote:
> Right, but it would be nice to have that option if initramfs
> using tmpfs becomes part of the kernel.
But it's not needed so why add bloat?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
Doug Warzecha wrote:
>This patch adds the Dell Systems Management Base Driver with sysfs support.
>
>This patch incorporates changes based on comments from the previous posting.
>
>Summary of changes:
>
>* Changed permissions on sysfs files so that only owner can read.
>* Changed to use __uNN/__sN
On Thu, 2005-08-25 at 14:18 +0200, Johannes Berg wrote:
> Hi,
>
> > I have also observed another problem with inotify with dovecot - so I spoke
> > with Johannes Berg who wrote the inotify code in dovecot. He suggested I
> > post
> > here to LKML since his opinion is that this to be a kernel b
Howdy, and excuse me for crossposting - feel free to zap CC to
unrelated, if any, mailing lists.
just gave PeerGuardian a spin on my eDonkey home box and
said box didn't last half a day before oopsing in netlink/nf/tcp
related routines (or so it seems to my untrained eye).
K7800, 256MB RAM
On Thu, 2005-08-25 at 22:07 +1200, Reuben Farrelly wrote:
> Hi,
>
> I have also observed another problem with inotify with dovecot - so I spoke
> with Johannes Berg who wrote the inotify code in dovecot. He suggested I
> post
> here to LKML since his opinion is that this to be a kernel bug.
>
Hello everyone,
using two different USB memory cardreader I have a problem which I am able to
reproduce on serveral machines (x86 and x86_64, Kernel 2.6.x) and with
different memory cards (Compact Flash, SD-Card, Sony Memory-Stick):
When I plug them in, they will be recognized by hotplug (I'm us
Ray Fucillo <[EMAIL PROTECTED]> writes:
>
> The application is a database system called Caché. We allocate a
> large shared memory segment for database cache, which in a large
> production environment may realistically be 1+GB on 32-bit platforms
> and much larger on 64-bit. At these sizes fork(
On Thu, Aug 25, 2005 at 10:41:27AM +0200, Geert Uytterhoeven wrote:
> >
> > +static inline void setup_thread_info(struct task_struct *p, struct
> > thread_info *ti)
> ^
> const struct task_struct *p?
Nick Piggin wrote:
fork() can be changed so as not to set up page tables for
MAP_SHARED mappings. I think that has other tradeoffs like
initially causing several unavoidable faults reading
libraries and program text.
What kind of application are you using?
The application is a database system
On Thu, Aug 25, 2005 at 11:15:24AM +0200, Roman Zippel wrote:
> >
> > - *ti = *orig->thread_info;
> > *tsk = *orig;
> > + setup_thread_info(tsk, ti);
> > tsk->thread_info = ti;
> > ti->task = tsk;
>
> This introduces a subtle ordering requirement, where setup_thread_info
> magic
On Thu, Aug 25, 2005 at 01:24:40AM -0700, Andrew Morton wrote:
> > IMO sys_readahead() doesn't make sense if the file is opened with
> > O_DIRECT, because the page cache is stuffed but never used. Therefore
> > this patch changes that by letting the call return with -EINVAL.
> >
>
> a) It doesn't
On Tue, 2005-08-23 at 16:23 +0100, Jamie Lokier wrote:
> ...
> if (any_dnotify_or_inotify_events_pending) {
> read_dnotify_or_inotify_events();
> if (any_events_related_to(file)) {
> store_in_userspace_stat_cache(file, stat(file));
> }
> }
> stat_
On 8/25/05, Pekka J Enberg <[EMAIL PROTECTED]> wrote:
>
> @@ -392,6 +585,23 @@ otherwise noted.
>fasync: called by the fcntl(2) system call when asynchronous
> (non-blocking) mode is enabled for a file
>
> + lock: called by the fcntl(2) system call for F_GETLK, F_SETLK, and F_SETLKW
Nick Piggin a écrit :
On Thu, 2005-08-25 at 12:41 +0200, Eric Dumazet wrote:
OK, here is a new clean patch that address this problem (nothing assumed about
atomics)
Would you just be able to add the atomic sysctl handler that
Christoph suggested?
Quite a lot of work indeed, and it woul
Hello all,
I am a newbee tryinging for serial port
multiplexing. Currently my driver supports for one
port
(/dev/ttyS0). However i want to use the same physical
port for 2 virtual ports.I am NOT sending two type of
data simultaneously. I want to first reigister my
driver for /dev/ttyS0. When
Hi,
> I have also observed another problem with inotify with dovecot - so I spoke
> with Johannes Berg who wrote the inotify code in dovecot. He suggested I
> post
> here to LKML since his opinion is that this to be a kernel bug.
Allow me to jump in at this point. The small tool below trigger
Andrew Morton schrieb:
>
> a) It doesn't hurt, it's just a bit of a silly thing to do.
IMO it may hurt the performance.
>
> b) posix_fadvise(POSIX_FADV_WILLNEED) should get the same treatment (and
>it's the preferred way of doing readahead).
Yes, of course.
>
> c) O_DIRECT fd's should, a
Hi,
On Thu, Aug 25, 2005 at 11:48:46AM +0200, Pavel Machek wrote:
> Something went wrong with PCMCIA on this X32. I inserted CF card, but
> it detected both hde *and* hdf, mount took forever. At that point I
> decided that I want my CF card back, took it back, it started
> producing different I/O
On Iau, 2005-08-25 at 13:19 +0200, Jens Axboe wrote:
> > Aug 25 11:35:23 amd kernel: hdf: probing with STATUS(0x50) instead of
> > ALTSTATUS(0x0a)
> > Aug 25 11:35:24 amd kernel: hdf:
> > ^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H(^H^H^H(^H^H^H^H,
> > ATA DISK drive
> > Aug 25
o There are minor changes in command line options in kexec-tools for kdump.
This patch updates the documentation to reflect those changes.
Signed-off-by: Vivek Goyal <[EMAIL PROTECTED]>
---
linux-2.6.13-rc7-root/Documentation/kdump/kdump.txt | 16
1 files changed, 8 insert
Hello,
your patch works!
first a box booting from a gdth:
a01:~# lsscsi
[0:0:0:0]diskICP Host Drive #00/dev/sda
[0:2:6:0]process SUPERGEM318 0 -
[1:0:0:10] diskIFT A16F-R1211 334B /dev/sdb
[1:0:0:12] diskIFT A16F-R1
On Thu, Aug 25 2005, Pavel Machek wrote:
> Hi!
>
> Something went wrong with PCMCIA on this X32. I inserted CF card, but
> it detected both hde *and* hdf, mount took forever. At that point I
> decided that I want my CF card back, took it back, it started
> producing different I/O errors , and then
On Thu, Aug 25 2005, Ingo Molnar wrote:
>
> * Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > There can quite easily be lots of pending IO for the io_context (and,
> > in CFQ's case, below cfq_io_contexts), task exiting is completely
> > decoupled from any pending io.
>
> yes, but that only affect
On Thu, 2005-08-25 at 12:41 +0200, Eric Dumazet wrote:
> OK, here is a new clean patch that address this problem (nothing assumed
> about
> atomics)
>
Would you just be able to add the atomic sysctl handler that
Christoph suggested?
This introduces lost update problems. 2 CPUs may store to nr
This removes one trap for a programmer, few unused macros, and one
unused struct. Please apply,
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
--- clean-mm/drivers/net/wireless/ipw2200.c 2005-08-24 20:25:09.0
+0200
+++ linux-mm/drivers/net/wireless/ipw2200.c 2005-08-25 12:50:19.
This removes support for old (and non-mainline) kernels from
ipw2200. Please apply,
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
--- clean-mm/drivers/net/wireless/ipw2200.c 2005-08-24 20:25:09.0
+0200
+++ linux-mm/drivers/net/wireless/ipw2200.c 2005-08-25 12:50:19.0
+
On Thu, Aug 25, 2005 at 03:56:23PM +0900, Tomita, Haruo wrote:
> Hi Jeff,
>
> 2.6.13- rc7-libata1.patch.bz2 was used.
> A combined mode of ata_piix seems not to work.
> Is the following patches correct?
>
> diff -urN linux-2.6.13-rc7.orig/drivers/scsi/Kconfig
> linux-2.6.13-rc7/drivers/scsi/K
Christoph Hellwig a écrit :
On Thu, Aug 25, 2005 at 11:17:23AM +0200, Eric Dumazet wrote:
But that's not true. You need to write you own sysctl handler for it,
probably worth adding a generic atomic_t sysctl handler while you're
at it.
I checked linux-2.6.13-rc7 tree, and atomic_read() is j
On Thu, 2005-08-25 at 16:10 +0530, P.Manohar wrote:
>
> In RH9 the starting function of keyboard.c is handle_scancode,
> this is
> the function to which the scancode is given by the keyboard interrupt
> handler, its fine, but in FC2 , this handle_scancode is not there,
> it's
> functionalit
On Wed, 24 Aug 2005, Andy Isaacson wrote:
> You might benefit by running your source code through gcc -E and seeing
> what the writel() expands to. (I do something like "rm drivers/mydev.o;
> make V=1" and then copy-n-paste the gcc line, replacing the "-c -o mydev.o"
> options with -E.)
Well, `
You need the kernel side timeout. Consider this case
One page of memory holds the parking code
A second page is swapped to disk and holds the resume code
You park the disk
You wakeup
You got to page in the resume code
So you really do want the kernel helping to avoid a deadlock
@@ -1661,6 +1671
Hi,
On 22/08/2005 9:10 p.m., John McCutchan wrote:
On Sat, 2005-08-20 at 23:52 -0700, Andrew Morton wrote:
Reuben Farrelly <[EMAIL PROTECTED]> wrote:
Hi,
On 19/08/2005 11:37 a.m., Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc6/2.6.13-rc6-mm1/
-
Hi Eric,
>> If I understand correctly, packets sent to the all-ones
>> broadcast address only go out through a single interface.
>
> I have some blur memories about this kind of issue, so my
> answer my be wrong on some points...
It turns out you are exactly right on all points. :-)
>> My questi
Hi!
Something went wrong with PCMCIA on this X32. I inserted CF card, but
it detected both hde *and* hdf, mount took forever. At that point I
decided that I want my CF card back, took it back, it started
producing different I/O errors , and then it oopsed.
Two cases:
# uname -a; free | grep Mem; ls -l /proc/kcore
Linux v100 2.6.11-1.1166sp1 #1 Fri Mar 4 20:41:51 EST 2005 sparc64 sparc64
sparc64 GNU/Linux
Mem: 1031152 100976 930176 0 22208 32232
-r 1 root root 3756826624 Aug 25 11:28 /proc/kcore
# uname -
On 8/25/05, Shwetha V <[EMAIL PROTECTED]> wrote:
>
> Could anyone inform which will be a good guide to start learning the linux
> kernel programming.
>
Personally I've greatly enjoyed
"Linux Kernel Development, 2ed" http://rlove.org/kernel_book/
and
"Linux Device Drivers, Third Edition" http://
On Iau, 2005-08-25 at 11:14 +0200, moreau francis wrote:
> I'm compiling Linux kernel for a MIPS32 cpu. On my platform, writel seems
> expand to:
>
> static inline writel(u32 val, volatile void __iomem *mem)
> {
> volatile u32 *__mem;
> u32 __val;
>
> _
On Thu, Aug 25, 2005 at 02:24:56AM -0700, Zachary Amsden wrote:
> Yes, agree totally, i386 _requires_ asm/segment.h. It is used in
> low-level trap handling and bootup code from assembly files. In
> addition,
but keeping the header under that name will just encorage people
to put it back into
> >
> > this patch adds atomic ops where there were none before
>
> nope... a spinlock/spinunlock contains atomic ops.
unlock usually doesn't but ok
>
> > for those architectures that need atomics for read (parisc? arm?)
>
> not today. No atomic needed for read.
>
> >
> > however.. wouldn't
On Wed, 24 Aug 2005, Al Viro wrote:
> It does, no (build) regressions. BTW, tree is not far from allmodconfig
> buildable on a bunch of targets now - yesterday pile of fixes was about
> half of the set needed for that. Most of the remaining stuff is for
> m68k (and applies both to Linus' tree and
Alan Cox wrote:
On Mer, 2005-08-24 at 11:43 -0500, Kumar Gala wrote:
The following set of patches removes the use and existence of
asm/segment.h from the architecture ports
You've broken various things by doing this because some driver code
rightly or wrongly uses segment.h. That is
On Thu, Aug 25, 2005 at 11:17:23AM +0200, Eric Dumazet wrote:
> >But that's not true. You need to write you own sysctl handler for it,
> >probably worth adding a generic atomic_t sysctl handler while you're
> >at it.
> >
>
> I checked linux-2.6.13-rc7 tree, and atomic_read() is just a wrapper to
Arjan van de Ven a écrit :
On Thu, 2005-08-25 at 10:45 +0200, Eric Dumazet wrote:
This patch removes filp_count_lock spinlock, used to protect
files_stat.nr_files.
Just use atomic_t type and atomic_inc()/atomic_dec() operations.
This patch assumes that atomic_read() is a plain {return v->cou
Christoph Hellwig a écrit :
On Thu, Aug 25, 2005 at 10:45:12AM +0200, Eric Dumazet wrote:
This patch assumes that atomic_read() is a plain {return v->counter;} on
all architectures. (keywords : sysctl, /proc/sys/fs/file-nr, proc_dointvec)
But that's not true. You need to write you own sysct
Hi,
On Thu, 25 Aug 2005, Al Viro wrote:
>
> +static inline void setup_thread_info(struct task_struct *p, struct
> thread_info *ti)
> +{
> + *ti = *p->thread_info;
> +}
> +
>
> - *ti = *orig->thread_info;
> *tsk = *orig;
> + setup_thread_info(tsk, ti);
> tsk->thread_in
On Wed, Aug 24, 2005 at 02:09:55PM -0600, Bjorn Helgaas wrote:
> On Wednesday 24 August 2005 10:53 am, Kumar Gala wrote:
> > Removed IA64 architecture specific users of asm/segment.h and
> > asm-ia64/segment.h itself
>
> I posted a similar patch a month ago, but I only removed the
> arch/ia64 inc
--- Andy Isaacson <[EMAIL PROTECTED]> a écrit :
>
> The first register write will be completed before the second register
> write because you use writel, which is defined to have the semantics you
> want. (It uses a platform-specific method to guarantee this, possibly
> "volatile" or "asm("eiei
On Thu, 2005-08-25 at 10:45 +0200, Eric Dumazet wrote:
> This patch removes filp_count_lock spinlock, used to protect
> files_stat.nr_files.
>
> Just use atomic_t type and atomic_inc()/atomic_dec() operations.
>
> This patch assumes that atomic_read() is a plain {return v->counter;} on all
> ar
On Čt 25-08-05 10:36:31, Shaohua Li wrote:
> On Wed, 2005-08-24 at 10:50 +0200, Pavel Machek wrote:
> > Hi!
> >
> > > > > diff -puN arch/i386/power/cpu.c~mcheck_resume arch/i386/power/cpu.c
> > > > > --- linux-2.6.13-rc6/arch/i386/power/cpu.c~mcheck_resume
> > > > > 2005-08-23 09:32:13.05400
Hi,
On Thu, 25 Aug 2005, Al Viro wrote:
>
> diff -urN RC13-rc7-sun3_pgtable/include/asm-m68k/amigaints.h
> RC13-rc7-amigaints/include/asm-m68k/amigaints.h
> --- RC13-rc7-sun3_pgtable/include/asm-m68k/amigaints.h2005-06-17
> 15:48:29.0 -0400
> +++ RC13-rc7-amigaints/include/
On Thu, Aug 25, 2005 at 10:45:12AM +0200, Eric Dumazet wrote:
> This patch assumes that atomic_read() is a plain {return v->counter;} on
> all architectures. (keywords : sysctl, /proc/sys/fs/file-nr, proc_dointvec)
But that's not true. You need to write you own sysctl handler for it,
probably wo
Hi,
On Thu, 25 Aug 2005, Al Viro wrote:
> diff -urN RC13-rc7/sound/oss/dmasound/dmasound_paula.c
> RC13-rc7-dmasound-lvalues/sound/oss/dmasound/dmasound_paula.c
> --- RC13-rc7/sound/oss/dmasound/dmasound_paula.c 2005-06-17
> 15:48:29.0 -0400
> +++ RC13-rc7-dmasound-lvalues/sound/os
> Just a bit of food for thought. There seem to be two different kinds
> of workloads for non-local filesystems. Bandwidth intensive workloads
> where files are read and written. Cache intensive workloads (like
> kernel compiles) where performance directly relates to how
> efficiently you can ma
On Wed, Aug 24, 2005 at 06:20:31PM -0700, Chris Wright wrote:
> Call security hooks conditionally if the security_op is filled out.
> Branches can be more efficient than the unconditional indirect function
> call. Inspired by patch from Kurt Garloff <[EMAIL PROTECTED]>.
>
> Signed-off-by: Chris W
This patch removes filp_count_lock spinlock, used to protect
files_stat.nr_files.
Just use atomic_t type and atomic_inc()/atomic_dec() operations.
This patch assumes that atomic_read() is a plain {return v->counter;} on all
architectures. (keywords : sysctl, /proc/sys/fs/file-nr, proc_dointvec
Thanks a lot, Al!
On Thu, 25 Aug 2005, Al Viro wrote:
> encapsulates the rest of arch-dependent operations with thread_info access.
> Two new helpers - setup_thread_info() and end_of_stack(). For normal
> case the former consists of copying thread_info of parent to new thread_info
> and the latt
Hello,
This optimizes bh_lru_install(). It's a hot spot I think. The bh_lru is well
manipulated now so we can use put_bh() as a substitute for the first __brelse()
here, and a bogus BUG_ON() can be removed safely. We evict at the right place
too. Boot tested.
Coywolf
Signed-off-by: C
Hello,
This cleanups up alloc_buffer_head(), by using a single get_cpu_var().
Boot tested.
Coywolf
Signed-off-by: Coywolf Qi Hunt <[EMAIL PROTECTED]>
---
buffer.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
--- 2.6.13-rc6-mm2/fs/buffer.c~orig 2005-08-23 13:42:0
Jan Blunck <[EMAIL PROTECTED]> wrote:
>
> IMO sys_readahead() doesn't make sense if the file is opened with
> O_DIRECT, because the page cache is stuffed but never used. Therefore
> this patch changes that by letting the call return with -EINVAL.
>
a) It doesn't hurt, it's just a bit of a silly t
Hi,
AMD's CodeAnalyst is the right tool for you. It is based on Oprofile.
It can be free downloaded from AMD website.
Best Regards
Bill Xie
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sushant Sharma
Sent: Thursday, August 25, 2005 10:52 AM
To: lin
25.08.2005 03:02, Daniel Brockman wrote/a écrit:
Hi list,
If I understand correctly, packets sent to the all-ones
broadcast address only go out through a single interface.
Hello,
I have some blur memories about this kind of issue, so my answer my be
wrong on some points...
My question is
On Thu, 2005-08-25 at 09:54 +0530, raja wrote:
[...]
> Is There Any function in c to caliculate the exact time taken to
> execute block of code(in micro sec and milli sec and minuits and hours).
> thanking you,
Do you mean system-time, user-space-time or the time it took in the real
world?
DocBook: fix kernel-api documentation generation
This patch changes a macro definition so that kernel-doc can understand it.
Signed-off-by: Martin Waitz <[EMAIL PROTECTED]>
---
include/sound/pcm.h |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
Index: linux-docbook/include/sound/
On Wed, 2005-08-24 at 14:46 -0700, Ravikiran G Thirumalai wrote:
> Following patch moves a few static 'read mostly' variables to the
> .data.read_mostly section. Typically these are vector - irq tables,
> boot_cpu_data, node_maps etc., which are initialized once and read from
> often and rarely
* Jens Axboe <[EMAIL PROTECTED]> wrote:
> There can quite easily be lots of pending IO for the io_context (and,
> in CFQ's case, below cfq_io_contexts), task exiting is completely
> decoupled from any pending io.
yes, but that only affects the io_context reference count. Actual new
use of tsk
* Esben Nielsen <[EMAIL PROTECTED]> wrote:
> Yes, spin_lock(lock) is blocking since lock is mutex, not a spinlock
> under preempt-rt. But isn't it easy to fix? Replace the two lines by
> spin_lock_irqsave(flags). That would work for both preempt-rt and
> !preempt-rt.
at this moment we do not
look at http://www.kernelnewbies.org
also it has a section on books. you can also use IRC #kernelnewbies
On 8/25/05, Shwetha V <[EMAIL PROTECTED]> wrote:
>
> Could anyone inform which will be a good guide to start learning the linux
> kernel programming.
>
> --
> Shwetha V
> Software Engineer
On Wed, Aug 24, 2005 at 10:38:59PM +0100, Al Viro wrote:
> On Thu, Aug 25, 2005 at 12:13:02AM +0400, Alexey Dobriyan wrote:
> > On Wed, Aug 24, 2005 at 08:15:44PM +0100, Al Viro wrote:
> > > Most of the remaining stuff is for
> > > m68k (and applies both to Linus' tree and m68k CVS); I'll send that
201 - 282 of 282 matches
Mail list logo
