History log of /linux/arch/um/drivers/xterm_kern.c (Results 151 – 162 of 162)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# ea0daab4 23-Jun-2005 Steve French <sfrench@us.ibm.com>

Merge with rsync://rsync.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6.git


# 1bdf7a78 23-Jun-2005 Jeremy Allison <jra@samba.org>

Merge with /pub/scm/linux/kernel/git/torvalds/linux-2.6.git


# 80bd6d7f 22-Jun-2005 Jeff Garzik <jgarzik@pretzel.yyz.us>

Merge /spare/repo/linux-2.6/


# ff40c6d3 22-Jun-2005 Jeff Garzik <jgarzik@pretzel.yyz.us>

Merge upstream kernel changes into 'C/H/S support' branch of libata.


# da04b128 22-Jun-2005 Jaroslav Kysela <perex@petra>

Merge with rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git


# dbce706e 22-Jun-2005 Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>

[PATCH] uml: add and use generic hw_controller_type->release

With Chris Wedgwood <cw@f00f.org>

Currently UML must explicitly call the UML-specific
free_irq_by_irq_and_dev() for each free_irq call i

[PATCH] uml: add and use generic hw_controller_type->release

With Chris Wedgwood <cw@f00f.org>

Currently UML must explicitly call the UML-specific
free_irq_by_irq_and_dev() for each free_irq call it's done.

This is needed because ->shutdown and/or ->disable are only called when the
last "action" for that irq is removed.

Instead, for UML shared IRQs (UML IRQs are very often, if not always,
shared), for each dev_id some setup is done, which must be cleared on the
release of that fd. For instance, for each open console a new instance
(i.e. new dev_id) of the same IRQ is requested().

Exactly, a fd is stored in an array (pollfds), which is after read by a
host thread and passed to poll(). Each event registered by poll() triggers
an interrupt. So, for each free_irq() we must remove the corresponding
host fd from the table, which we do via this -release() method.

In this patch we add an appropriate hook for this, and remove all uses of
it by pointing the hook to the said procedure; this is safe to do since the
said procedure.

Also some cosmetic improvements are included.

This is heavily based on some work by Chris Wedgwood, which however didn't
get the patch merged for something I'd call a "misunderstanding" (the need
for this patch wasn't cleanly explained, thus adding the generic hook was
felt as undesirable).

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
CC: Ingo Molnar <mingo@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

show more ...


Revision tags: v2.6.12
# f2cbb4f0 15-Jun-2005 Tony Luck <tony.luck@intel.com>

Auto merge with /home/aegl/GIT/linus


Revision tags: v2.6.12-rc6
# 7078253c 02-Jun-2005 Dave Kleikamp <shaggy@austin.ibm.com>

Merge with /home/shaggy/git/linus-clean/

Signed-off-by: Dave Kleikamp <shaggy@austin.ibm.com>


Revision tags: v2.6.12-rc5
# 67394f8f 21-May-2005 Anton Altaparmakov <aia21@cantab.net>

Merge with /usr/src/ntfs-2.6.git


# ad34ea2c 20-May-2005 James Bottomley <jejb@titanic.(none)>

merge by hand - fix up rejections in Documentation/DocBook/Makefile


Revision tags: v2.6.12-rc4
# a0b8d320 06-May-2005 Jeff Dike <jdike@addtoit.com>

[PATCH] uml: inclusion cleanup

The completion cleanup got rid of some semaphores, but didn't remove the
inclusion of asm/semaphore.h from xterm_kern.c.

Signed-off-by: Jeff Dike <jdike@addtoit.com>

[PATCH] uml: inclusion cleanup

The completion cleanup got rid of some semaphores, but didn't remove the
inclusion of asm/semaphore.h from xterm_kern.c.

Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

show more ...


Revision tags: v2.6.12-rc3, v2.6.12-rc2
# 1da177e4 17-Apr-2005 Linus Torvalds <torvalds@ppc970.osdl.org>

Linux-2.6.12-rc2

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in

Linux-2.6.12-rc2

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!

show more ...


1234567