Re: vcsa and big endian

Samuel Thibault, le Sun 09 Dec 2007 23:43:49 +0100, a écrit : On big endian machines, /dev/vcsa stores text/attribute bytes in big endian order, while it stores them in little endian order on little endian machines. Is that expected? It looks like ggi considers this as normal. In any case

Re: vcsa and big endian

Samuel Thibault, le Sun 09 Dec 2007 23:50:39 +0100, a écrit : Samuel Thibault, le Sun 09 Dec 2007 23:43:49 +0100, a écrit : On big endian machines, /dev/vcsa stores text/attribute bytes in big endian order, while it stores them in little endian order on little endian machines

[PATCH] Alpha and x86_64 don't use socketcall

Alpha and x86_64 architectures don't use socketcall and don't provide __NR_socketcall. Signed-off-by: Samuel Thibault <[EMAIL PROTECTED]> diff -r 51b2b0d0921c include/asm-alpha/unistd.h --- a/include/asm-alpha/unistd.hWed Nov 21 09:41:11 2007 + +++ b/include/asm-alpha/un

[PATCH] Alpha and x86_64 don't use socketcall

Alpha and x86_64 architectures don't use socketcall and don't provide __NR_socketcall. Signed-off-by: Samuel Thibault [EMAIL PROTECTED] diff -r 51b2b0d0921c include/asm-alpha/unistd.h --- a/include/asm-alpha/unistd.hWed Nov 21 09:41:11 2007 + +++ b/include/asm-alpha/unistd.h

Re: [bisected][mismerge?] Re: [microcode] 2.6.23.git pulled this morning oopses loading P4 microcode

Just to make sure, could you check in System.map that accent_table is correctly 256*3*4=3072 bytes long? Samuel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: [bisected][mismerge?] Re: [microcode] 2.6.23.git pulled this morning oopses loading P4 microcode

Just to make sure, could you check in System.map that accent_table is correctly 256*3*4=3072 bytes long? Samuel - 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

Re: [bisected][mismerge?] Re: [microcode] 2.6.23.git pulled this morning oopses loading P4 microcode

Hi, Mike Galbraith, le Thu 18 Oct 2007 19:56:38 +0200, a écrit : > The winner of a very long git bisect session: > > unicode diacritics support Uh, I fail to see how that could have an impact, I've again checked the boundaries, it looks fine, please people have a look. Could you try

Re: [bisected][mismerge?] Re: [microcode] 2.6.23.git pulled this morning oopses loading P4 microcode

Hi, Mike Galbraith, le Thu 18 Oct 2007 19:56:38 +0200, a écrit : The winner of a very long git bisect session: unicode diacritics support Uh, I fail to see how that could have an impact, I've again checked the boundaries, it looks fine, please people have a look. Could you try something

Re: [PATCH] Console keyboard events and accessibility

Pavel Machek, le Sat 01 Sep 2007 18:18:45 +, a écrit : > > > > Very early is not so early, and loading initrd itself may actually fail. > > > > The kernel may indeed hang, but there are more chances to get some > > > > messages before the hang. Don't _you_ have a VGA screen for getting > > >

Re: [PATCH] Console keyboard events and accessibility

Hi, Pavel Machek, le Sat 01 Sep 2007 17:23:02 +, a écrit : > Hi! > > > > > Because userland only begins quite late in the boot process, and > > > > userland may hang. > > > > > > Initrd means userland is started very early on most machines these > > > days, and kernel may hang, too. > > >

Re: [PATCH] Console keyboard events and accessibility

Hi, Pavel Machek, le Sat 01 Sep 2007 12:32:58 +, a écrit : > > > > > They can use the raw xlation for that. > > > > > > > > For userland, yes. This is for kernel modules. > > > > > > And should speakup be a kernel module? Why? > > > > Because userland only begins quite late in the boot

Re: [PATCH] Console keyboard events and accessibility

Pavel Machek, le Thu 12 Jul 2007 19:19:32 +, a écrit : > On Tue 2007-08-21 22:49:51, Samuel Thibault wrote: > > Hi, > > > > Jan Engelhardt, le Tue 21 Aug 2007 22:42:24 +0200, a écrit : > > > >- keycodes: even before translation into keysym. > >

Re: [PATCH] Console keyboard events and accessibility

Pavel Machek, le Thu 12 Jul 2007 19:19:32 +, a écrit : On Tue 2007-08-21 22:49:51, Samuel Thibault wrote: Hi, Jan Engelhardt, le Tue 21 Aug 2007 22:42:24 +0200, a écrit : - keycodes: even before translation into keysym. They can use the raw xlation for that. For userland

Re: [PATCH] Console keyboard events and accessibility

Hi, Pavel Machek, le Sat 01 Sep 2007 12:32:58 +, a écrit : They can use the raw xlation for that. For userland, yes. This is for kernel modules. And should speakup be a kernel module? Why? Because userland only begins quite late in the boot process, and userland

Re: [PATCH] Console keyboard events and accessibility

Hi, Pavel Machek, le Sat 01 Sep 2007 17:23:02 +, a écrit : Hi! Because userland only begins quite late in the boot process, and userland may hang. Initrd means userland is started very early on most machines these days, and kernel may hang, too. Very early is not so

Re: [PATCH] Console keyboard events and accessibility

Pavel Machek, le Sat 01 Sep 2007 18:18:45 +, a écrit : Very early is not so early, and loading initrd itself may actually fail. The kernel may indeed hang, but there are more chances to get some messages before the hang. Don't _you_ have a VGA screen for getting earliest

Re: [PATCH] Console keyboard events and accessibility

Hi, Adrian Bunk, le Sat 25 Aug 2007 03:07:04 +0200, a écrit : > > If they > > remain in -mm for some time and people don't complain, well that's good > > too: at least we know how speakup may hook into the kernel when it gets > > merged. > >... > > Without any users it's dead code noone uses,

Re: [PATCH] Console keyboard events and accessibility

Hi, Adrian Bunk, le Sat 25 Aug 2007 03:07:04 +0200, a écrit : If they remain in -mm for some time and people don't complain, well that's good too: at least we know how speakup may hook into the kernel when it gets merged. ... Without any users it's dead code noone uses, Not so much

Re: [PATCH] Console events and accessibility

Samuel Thibault, le Thu 23 Aug 2007 19:08:45 +0200, a écrit : > > If you need help in this area, I can see about doing a bit as I did a > > lot of cleanup of this codebase a few years ago. I also know of a few > > users who are willing to help test this stuff out. > >

Re: [PATCH] Console events and accessibility

Hi, Greg KH, le Thu 23 Aug 2007 09:33:18 -0700, a écrit : > Yes I did, sorry. Do you have a pointer for it, all I see is these > patches in -mm: > console-keyboard-events-and-accessibility.patch Here is the patch > console-keyboard-events-and-accessibility-fix.patch >

Re: [PATCH] Console events and accessibility

Greg KH, le Thu 23 Aug 2007 03:04:02 -0700, a écrit : > > I mean: yes, with these three patches, speakup will work fine. > > 3 patches? I only saw 2. Or do you mean the modifications of the 3 > files? Maybe you missed the keyboard notification patch which is already in -mm. > The patches look

Re: [PATCH] Console events and accessibility

Greg KH, le Thu 23 Aug 2007 03:04:02 -0700, a écrit : I mean: yes, with these three patches, speakup will work fine. 3 patches? I only saw 2. Or do you mean the modifications of the 3 files? Maybe you missed the keyboard notification patch which is already in -mm. The patches look sane

Re: [PATCH] Console events and accessibility

Hi, Greg KH, le Thu 23 Aug 2007 09:33:18 -0700, a écrit : Yes I did, sorry. Do you have a pointer for it, all I see is these patches in -mm: console-keyboard-events-and-accessibility.patch Here is the patch console-keyboard-events-and-accessibility-fix.patch

Re: [PATCH] Console events and accessibility

Samuel Thibault, le Thu 23 Aug 2007 19:08:45 +0200, a écrit : If you need help in this area, I can see about doing a bit as I did a lot of cleanup of this codebase a few years ago. I also know of a few users who are willing to help test this stuff out. Oh, great! Maybe Kirk should

Re: [PATCH] Console events and accessibility

Samuel Thibault, le Wed 22 Aug 2007 10:53:55 +0200, a écrit : > Greg KH, le Tue 21 Aug 2007 22:48:55 -0700, a écrit : > > On Tue, Aug 21, 2007 at 11:29:39PM +0200, Samuel Thibault wrote: > > > Some external modules like Speakup need to monitor console output. > > > &g

Re: [PATCH] Console events and accessibility

Greg KH, le Tue 21 Aug 2007 22:48:55 -0700, a écrit : > On Tue, Aug 21, 2007 at 11:29:39PM +0200, Samuel Thibault wrote: > > Some external modules like Speakup need to monitor console output. > > > > This adds a VT notifier that such modules can use to get conso

Re: [PATCH] Console events and accessibility

Greg KH, le Tue 21 Aug 2007 22:48:55 -0700, a écrit : On Tue, Aug 21, 2007 at 11:29:39PM +0200, Samuel Thibault wrote: Some external modules like Speakup need to monitor console output. This adds a VT notifier that such modules can use to get console output events: allocation

Re: [PATCH] Console events and accessibility

Samuel Thibault, le Wed 22 Aug 2007 10:53:55 +0200, a écrit : Greg KH, le Tue 21 Aug 2007 22:48:55 -0700, a écrit : On Tue, Aug 21, 2007 at 11:29:39PM +0200, Samuel Thibault wrote: Some external modules like Speakup need to monitor console output. This adds a VT notifier

[PATCH] Console events and accessibility

Some external modules like Speakup need to monitor console output. This adds a VT notifier that such modules can use to get console output events: allocation, deallocation, writes, other updates (cursor position, switch, etc.) Signed-off-by: Samuel Thibault <[EMAIL PROTEC

Re: [PATCH] Console keyboard events and accessibility

Hi, Jan Engelhardt, le Tue 21 Aug 2007 22:42:24 +0200, a écrit : > >- keycodes: even before translation into keysym. > > They can use the raw xlation for that. For userland, yes. This is for kernel modules. Samuel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

Re: [PATCH] Console keyboard events and accessibility

Hi, Andrew Morton, le Tue 21 Aug 2007 13:02:33 -0700, a écrit : > On Tue, 21 Aug 2007 02:57:18 +0200 > Samuel Thibault <[EMAIL PROTECTED]> wrote: > > > Some external modules like Speakup need to use the PC keyboard to control > > them and also need to get keyboard feed

Re: [PATCH] Console keyboard events and accessibility

Hi, Andrew Morton, le Tue 21 Aug 2007 13:02:33 -0700, a écrit : On Tue, 21 Aug 2007 02:57:18 +0200 Samuel Thibault [EMAIL PROTECTED] wrote: Some external modules like Speakup need to use the PC keyboard to control them and also need to get keyboard feedback (caps lock status, etc

Re: [PATCH] Console keyboard events and accessibility

Hi, Jan Engelhardt, le Tue 21 Aug 2007 22:42:24 +0200, a écrit : - keycodes: even before translation into keysym. They can use the raw xlation for that. For userland, yes. This is for kernel modules. Samuel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body

[PATCH] Console events and accessibility

Some external modules like Speakup need to monitor console output. This adds a VT notifier that such modules can use to get console output events: allocation, deallocation, writes, other updates (cursor position, switch, etc.) Signed-off-by: Samuel Thibault [EMAIL PROTECTED

[PATCH] Console keyboard events and accessibility

.) This also provides access to k_handler so as to permit simulation of keypresses. Signed-off-by: Samuel Thibault <[EMAIL PROTECTED]> --- Hi, Some blind people use a kernel engine called Speakup which uses hardware synthesis to speak what gets displayed on the screen. They use the PC ke

[PATCH] 10-dots braille keyboards

Hi, Some braille keyboards have 10 dots, so extend the Input braille keys definitions. Signed-off-by: Samuel Thibault <[EMAIL PROTECTED]> diff --git a/include/linux/input.h b/include/linux/input.h index e02c6a6..17df5a7 100644 --- a/include/linux/input.h +++ b/include/linux/input.h @@

[PATCH] 10-dots braille keyboards

Hi, Some braille keyboards have 10 dots, so extend the Input braille keys definitions. Signed-off-by: Samuel Thibault [EMAIL PROTECTED] diff --git a/include/linux/input.h b/include/linux/input.h index e02c6a6..17df5a7 100644 --- a/include/linux/input.h +++ b/include/linux/input.h @@ -552,6

[PATCH] Console keyboard events and accessibility

.) This also provides access to k_handler so as to permit simulation of keypresses. Signed-off-by: Samuel Thibault [EMAIL PROTECTED] --- Hi, Some blind people use a kernel engine called Speakup which uses hardware synthesis to speak what gets displayed on the screen. They use the PC keyboard

Keyboard CapsShift Lock

Hi, There exists a CapsShift lock called KG_CAPSSHIFT, but no associated lock/slock, here is a patch. Samuel Add CapsShift lock and slock. Signed-off-by: Samuel Thibault <[EMAIL PROTECTED]> diff --git a/include/linux/keyboard.h b/include/linux/keyboard.h index d97066f..61f12d4

Keyboard CapsShift Lock

Hi, There exists a CapsShift lock called KG_CAPSSHIFT, but no associated lock/slock, here is a patch. Samuel Add CapsShift lock and slock. Signed-off-by: Samuel Thibault [EMAIL PROTECTED] diff --git a/include/linux/keyboard.h b/include/linux/keyboard.h index d97066f..61f12d4 100644

Re: 2.6.23-rc2-mm2: drivers/s390/char/keyboard.c compile error

BDIACR. New function int conv_uni_to_8bit(u32 uni) for converting unicode into 8bit _input_. No, we don't want to store the translation, as it is potentially sparse and large. Signed-off-by: Samuel Thibault <[EMAIL PROTECTED]> diff --git a/drivers/acorn/char/defkeymap-l7200.c b/drivers/ac

Re: 2.6.23-rc2-mm2: drivers/s390/char/keyboard.c compile error

function int conv_uni_to_8bit(u32 uni) for converting unicode into 8bit _input_. No, we don't want to store the translation, as it is potentially sparse and large. Signed-off-by: Samuel Thibault [EMAIL PROTECTED] diff --git a/drivers/acorn/char/defkeymap-l7200.c b/drivers/acorn/char/defkeymap-l7200.c

Re: [PATCH] unicode diacritics support

Hi, Andrew Morton, le Thu 09 Aug 2007 12:46:42 -0700, a écrit : > > Turn the kernel accent_table into unicode, and extend ioctls KDGKBDIACR > > and KDSKBDIACR into their equivalents KDGKBDIACRUC and KDSKBDIACR. > > > > New function int conv_uni_to_8bit(u32 uni) for converting unicode into 8bit >

Re: [PATCH] unicode diacritics support

Hi, Andrew Morton, le Thu 09 Aug 2007 12:46:42 -0700, a écrit : Turn the kernel accent_table into unicode, and extend ioctls KDGKBDIACR and KDSKBDIACR into their equivalents KDGKBDIACRUC and KDSKBDIACR. New function int conv_uni_to_8bit(u32 uni) for converting unicode into 8bit

[PATCH] unicode diacritics support

, and extend ioctls KDGKBDIACR and KDSKBDIACR into their equivalents KDGKBDIACRUC and KDSKBDIACR. New function int conv_uni_to_8bit(u32 uni) for converting unicode into 8bit _input_. No, we don't want to store the translation, as it is potentially sparse and large. Signed-off-by: Samuel Thibault

[PATCH] unicode diacritics support

, and extend ioctls KDGKBDIACR and KDSKBDIACR into their equivalents KDGKBDIACRUC and KDSKBDIACR. New function int conv_uni_to_8bit(u32 uni) for converting unicode into 8bit _input_. No, we don't want to store the translation, as it is potentially sparse and large. Signed-off-by: Samuel Thibault

Re: console UTF-8 fixes

Hi, Egmont got some UTF-8 fixes in mainline, Andrew Morton suggested it might be a good time to remember about bug 7746 Support for unicode dead keys: http://bugzilla.kernel.org/show_bug.cgi?id=7746 : « Quoting a mail from Vojtech Pavlik: "Several languages (polish, czech, slovak, ...) use dead

Re: console UTF-8 fixes

Hi, Egmont got some UTF-8 fixes in mainline, Andrew Morton suggested it might be a good time to remember about bug 7746 Support for unicode dead keys: http://bugzilla.kernel.org/show_bug.cgi?id=7746 : « Quoting a mail from Vojtech Pavlik: Several languages (polish, czech, slovak, ...) use dead

Re: [PATCH] Use tty_schedule in VT code.

James Simmons, le Tue 17 Jul 2007 19:37:57 +0100, a écrit : > - schedule_delayed_work(>buf.work, 0); It was schedule_delayed_work(>buf.work, 1); in con_schedule_flip() ; could that matter? Samuel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a

Re: [PATCH] Use tty_schedule in VT code.

James Simmons, le Tue 17 Jul 2007 19:37:57 +0100, a écrit : - schedule_delayed_work(t-buf.work, 0); It was schedule_delayed_work(t-buf.work, 1); in con_schedule_flip() ; could that matter? Samuel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a

[PATCH] Oddity in mxcsr_feature_mask_init()

onsidering the code around, it doesn't do much difference, but it makes more sense (i.e. we just fill fxsave). Samuel Signed-off-by: Samuel Thibault <[EMAIL PROTECTED]> --- linux-2.6.21-orig/arch/i386/kernel/i387.c.orig 2007-06-08 18:18:10.0 +0800 +++ linux-2.6.21-orig/arch/i386/

[PATCH] Oddity in mxcsr_feature_mask_init()

, but it makes more sense (i.e. we just fill fxsave). Samuel Signed-off-by: Samuel Thibault [EMAIL PROTECTED] --- linux-2.6.21-orig/arch/i386/kernel/i387.c.orig 2007-06-08 18:18:10.0 +0800 +++ linux-2.6.21-orig/arch/i386/kernel/i387.c 2007-06-08 18:18:22.0 +0800 @@ -32,7

[PATCH] Fix pata_qdi.c probe code

Hi, There is a small typo in the probe code of pata_qdi.c, here is a patch. Samuel diff --git a/drivers/ata/pata_qdi.c b/drivers/ata/pata_qdi.c index 27685ce..fb8c9e1 100644 --- a/drivers/ata/pata_qdi.c +++ b/drivers/ata/pata_qdi.c @@ -375,7 +375,7 @@ static __init int qdi_init(void)

[PATCH] Fix pata_qdi.c probe code

Hi, There is a small typo in the probe code of pata_qdi.c, here is a patch. Samuel diff --git a/drivers/ata/pata_qdi.c b/drivers/ata/pata_qdi.c index 27685ce..fb8c9e1 100644 --- a/drivers/ata/pata_qdi.c +++ b/drivers/ata/pata_qdi.c @@ -375,7 +375,7 @@ static __init int qdi_init(void)

Re: Add a norecovery option to ext3/4?

Eric Sandeen, le Sun 08 Apr 2007 22:24:50 -0500, a écrit : > Samuel Thibault wrote: > >Distribution installers usually try to probe OSes for building a suited > >grub menu. Unfortunately, mounting an ext3 partition, even in read-only > >mode, does perform some operations o

Add a norecovery option to ext3/4?

Hi, Distribution installers usually try to probe OSes for building a suited grub menu. Unfortunately, mounting an ext3 partition, even in read-only mode, does perform some operations on the filesystem (log recovery). This is not a good idea since it may silently garbage data. XFS has a

Add a norecovery option to ext3/4?

Hi, Distribution installers usually try to probe OSes for building a suited grub menu. Unfortunately, mounting an ext3 partition, even in read-only mode, does perform some operations on the filesystem (log recovery). This is not a good idea since it may silently garbage data. XFS has a

Re: Add a norecovery option to ext3/4?

Eric Sandeen, le Sun 08 Apr 2007 22:24:50 -0500, a écrit : Samuel Thibault wrote: Distribution installers usually try to probe OSes for building a suited grub menu. Unfortunately, mounting an ext3 partition, even in read-only mode, does perform some operations on the filesystem (log recovery

Re: mbind and alignment

Hi, Andi Kleen, le Wed 04 Apr 2007 13:52:04 +0200, a écrit : > > So one of those should probably be done to free people from headaches: > > > > - document "start" requirement in the manual page > > - require len to be aligned too, and document the requirements in the > > manual page > > - drop

Re: mbind and alignment

Hi, Andi Kleen, le Wed 04 Apr 2007 13:52:04 +0200, a écrit : So one of those should probably be done to free people from headaches: - document start requirement in the manual page - require len to be aligned too, and document the requirements in the manual page - drop the start

mbind and alignment

Hi, mbind(start, len, ...) currently requires that "start" be page-aligned, but not "len" (which automatically gets page-rounded up). This is a bit odd: - the userland type of start is void*, which people would expect to be a pointer to some variable. - start needing to be page-aligned but

mbind and alignment

Hi, mbind(start, len, ...) currently requires that start be page-aligned, but not len (which automatically gets page-rounded up). This is a bit odd: - the userland type of start is void*, which people would expect to be a pointer to some variable. - start needing to be page-aligned but len

Re: differences between MADV_FREE and MADV_DONTNEED

Hi, Eric wrote: > > We should implement a real MADV_DONTNEED and rename the current one > > to MADV_FREE, but that's 2.6.17 material. > > We definitely need to check this. I am fairly certain I have seen > this conversation before. Yes, it was back in 2005:

Re: differences between MADV_FREE and MADV_DONTNEED

Hi, Eric wrote: We should implement a real MADV_DONTNEED and rename the current one to MADV_FREE, but that's 2.6.17 material. We definitely need to check this. I am fairly certain I have seen this conversation before. Yes, it was back in 2005:

Re: Experimental driver for Ricoh Bay1Controller SD Card readers

Pierre Ossman, le Tue 13 Feb 2007 06:47:41 +0100, a écrit : > Sascha Sommer wrote: > > I still consider this driver experimental, but without documentation this > > is > > probably not going to change anytime soon. > > The question is now what I should do with the driver? > > Is it worth to be

Re: Experimental driver for Ricoh Bay1Controller SD Card readers

Pierre Ossman, le Tue 13 Feb 2007 06:47:41 +0100, a écrit : Sascha Sommer wrote: I still consider this driver experimental, but without documentation this is probably not going to change anytime soon. The question is now what I should do with the driver? Is it worth to be included in

Re: [PATCH] [NETDEV] [000] dmfe : fix bugs and add features

Hi, Jeff Garzik, le Fri 09 Feb 2007 16:15:26 -0500, a écrit : > Levitsky Maxim wrote: > >Before some time I decided to fix suspend/resume on my Davicom > >network card. During development I also fixed couple of bugs and > >added support for link detection and WOL Note : 2.6.20 already has >

Re: [PATCH] [NETDEV] [000] dmfe : fix bugs and add features

Hi, Jeff Garzik, le Fri 09 Feb 2007 16:15:26 -0500, a écrit : Levitsky Maxim wrote: Before some time I decided to fix suspend/resume on my Davicom network card. During development I also fixed couple of bugs and added support for link detection and WOL Note : 2.6.20 already has support for

Re: [ANN] Userspace M-on-N threading model implementation. Alpha release.

Evgeniy Polyakov, le Tue 30 Jan 2007 12:53:16 +0300, a écrit : > > You may want to have a look at some existing implementations: > > I saw most of them. > As far as I recall, only PTL (is not shown here) has preemptible > scheduler. NTL has it too, but is based on different approach. Marcel has

Re: [ANN] Userspace M-on-N threading model implementation. Alpha release.

Evgeniy Polyakov, le Tue 30 Jan 2007 12:53:16 +0300, a écrit : You may want to have a look at some existing implementations: I saw most of them. As far as I recall, only PTL (is not shown here) has preemptible scheduler. NTL has it too, but is based on different approach. Marcel has a

Re: [ANN] Userspace M-on-N threading model implementation. Alpha release.

Hi, Evgenity, le Mon 29 Jan 2007 16:47:36 +0100, a écrit : > Userspace M-on-N threading model is based on the idea, that when signal > is delivered, kernel saves all information related to previous context > in stack, so it is possible to find it and replace. You may want to have a look at some

Re: [ANN] Userspace M-on-N threading model implementation. Alpha release.

Hi, Evgenity, le Mon 29 Jan 2007 16:47:36 +0100, a écrit : Userspace M-on-N threading model is based on the idea, that when signal is delivered, kernel saves all information related to previous context in stack, so it is possible to find it and replace. You may want to have a look at some

Re: Experimental driver for Ricoh Bay1Controller SD Card readers

Hi, Sascha Sommer, le Sun 07 Jan 2007 00:32:26 +0100, a écrit : > Attached is a very experimental driver for a Ricoh SD Card reader that can be > found in some notebooks like the Samsung P35. Yehaaaw! That reader can be found on DELL X300 too. It works almost fine for me, see attached dmesg.

Re: Experimental driver for Ricoh Bay1Controller SD Card readers

Hi, Sascha Sommer, le Sun 07 Jan 2007 00:32:26 +0100, a écrit : Attached is a very experimental driver for a Ricoh SD Card reader that can be found in some notebooks like the Samsung P35. Yehaaaw! That reader can be found on DELL X300 too. It works almost fine for me, see attached dmesg.

Re: Linux should define ENOTSUP

H. Peter Anvin, le Wed 06 Dec 2006 07:35:49 -0800, a écrit : > Samuel Thibault wrote: > >>The two can't be done at the same time. In fact, the two probably can't > >>be done without a period of quite a few *years* between them. > > > >Not a reason for not

Re: Linux should define ENOTSUP

H. Peter Anvin, le Wed 06 Dec 2006 07:26:44 -0800, a écrit : > Samuel Thibault wrote: > >H. Peter Anvin, le Wed 06 Dec 2006 07:16:39 -0800, a écrit : > >>Arjan van de Ven wrote: > >>>>Is there any way to fix this? Glibc people don't seem to want to fix it &g

Re: Linux should define ENOTSUP

H. Peter Anvin, le Wed 06 Dec 2006 07:16:39 -0800, a écrit : > Arjan van de Ven wrote: > >>Is there any way to fix this? Glibc people don't seem to want to fix it > >>on their part, see > >>http://sources.redhat.com/bugzilla/show_bug.cgi?id=2363 > > > >Hi, > > > >Ulrich asked you to go to us once

Re: Linux should define ENOTSUP

Hi, Arjan van de Ven, le Wed 06 Dec 2006 15:25:14 +0100, a écrit : > > > Is there any way to fix this? Glibc people don't seem to want to fix it > > on their part, see > > http://sources.redhat.com/bugzilla/show_bug.cgi?id=2363 > > Ulrich asked you to go to us once your time travel machine was

Linux should define ENOTSUP

Hi, ENOTSUP is not used at all by linux (though it is defined for parisc), while as susv3 specifies, ENOTSUP shall be different than EOPNOTSUPP. Is there a reason for doing so? (except history) Currently, code like switch(errno) { ENOTSUP: foo(); break;

Linux should define ENOTSUP

Hi, ENOTSUP is not used at all by linux (though it is defined for parisc), while as susv3 specifies, ENOTSUP shall be different than EOPNOTSUPP. Is there a reason for doing so? (except history) Currently, code like switch(errno) { ENOTSUP: foo(); break;

Re: Linux should define ENOTSUP

Hi, Arjan van de Ven, le Wed 06 Dec 2006 15:25:14 +0100, a écrit : Is there any way to fix this? Glibc people don't seem to want to fix it on their part, see http://sources.redhat.com/bugzilla/show_bug.cgi?id=2363 Ulrich asked you to go to us once your time travel machine was

Re: Linux should define ENOTSUP

H. Peter Anvin, le Wed 06 Dec 2006 07:16:39 -0800, a écrit : Arjan van de Ven wrote: Is there any way to fix this? Glibc people don't seem to want to fix it on their part, see http://sources.redhat.com/bugzilla/show_bug.cgi?id=2363 Hi, Ulrich asked you to go to us once your time travel

Re: Linux should define ENOTSUP

H. Peter Anvin, le Wed 06 Dec 2006 07:26:44 -0800, a écrit : Samuel Thibault wrote: H. Peter Anvin, le Wed 06 Dec 2006 07:16:39 -0800, a écrit : Arjan van de Ven wrote: Is there any way to fix this? Glibc people don't seem to want to fix it on their part, see http://sources.redhat.com

Re: Linux should define ENOTSUP

H. Peter Anvin, le Wed 06 Dec 2006 07:35:49 -0800, a écrit : Samuel Thibault wrote: The two can't be done at the same time. In fact, the two probably can't be done without a period of quite a few *years* between them. Not a reason for not doing it ;) No, but breakage is. There has

SAK and screen readers

Hi, BrlTTY is a screen reader: it is a deamon run as root on machines used by blind users for getting the content of the screen via braille or speech. BrlTTY, like other screen readers (susebl, yasr, ...) needs to open /dev/tty0 for performing various actions, namely: - VT_ACTIVATE -

SAK and screen readers

Hi, BrlTTY is a screen reader: it is a deamon run as root on machines used by blind users for getting the content of the screen via braille or speech. BrlTTY, like other screen readers (susebl, yasr, ...) needs to open /dev/tty0 for performing various actions, namely: - VT_ACTIVATE -

Re: Tulip dmfe carrier detection

Hi, Samuel Thibault, le Fri 10 Nov 2006 15:49:19 +0100, a écrit : > The dmfe module lacks netif stuff for carrier detection, while the board > does report carrier status. Here is a patch. Just an additional fixup: the default state should be carrier off. This fixes boot carrier det

Re: Tulip dmfe carrier detection

Hi, Samuel Thibault, le Fri 10 Nov 2006 15:49:19 +0100, a écrit : The dmfe module lacks netif stuff for carrier detection, while the board does report carrier status. Here is a patch. Just an additional fixup: the default state should be carrier off. This fixes boot carrier detection. Samuel

[PATCH] vga text console and stty cols/rows

, which can be great for some people (see http://dept-info.labri.fr/~thibault/ls.jpg ). Regards, Samuel Signed-off-by: Samuel Thibault <[EMAIL PROTECTED]> --- linux-2.6.13/drivers/video/console/vgacon.c 2005-09-02 18:18:38.0 +0200 +++ linux/drivers/video/console/vgacon.c2005

[PATCH] vga text console and stty cols/rows

, which can be great for some people (see http://dept-info.labri.fr/~thibault/ls.jpg ). Regards, Samuel Signed-off-by: Samuel Thibault [EMAIL PROTECTED] --- linux-2.6.13/drivers/video/console/vgacon.c 2005-09-02 18:18:38.0 +0200 +++ linux/drivers/video/console/vgacon.c2005-09-03

Re: idle task's task_t allocation on NUMA machines

Samuel Thibault, le Thu 18 Aug 2005 21:49:41 +0200, a écrit : > Eric Dumazet, le Thu 18 Aug 2005 17:18:55 +0200, a écrit : > > I believe IRQ stacks are also allocated on node 0, that seems more serious. > > For the i386 architecture at least, yes: they are statically defined in >

Re: idle task's task_t allocation on NUMA machines

Eric Dumazet, le Thu 18 Aug 2005 17:18:55 +0200, a écrit : > I believe IRQ stacks are also allocated on node 0, that seems more serious. For the i386 architecture at least, yes: they are statically defined in arch/i386/kernel/irq.c, while they could be per_cpu. Regards, Samuel - To unsubscribe

Re: idle task's task_t allocation on NUMA machines

Eric Dumazet, le Thu 18 Aug 2005 17:18:55 +0200, a écrit : > An idle task should block itself, hence not touching its task_t structure > very much. Indeed, but I guess there are a lot of such little optimizations here and there that could be relatively easily fixed, for a not-so little benefit.

idle task's task_t allocation on NUMA machines

Hi, Currently, the task_t structure of the idle task is always allocated on CPU0, hence on node 0: while booting, for each CPU, CPU 0 calls fork_idle(), hence copy_process(), hence dup_task_struct(), hence alloc_task_struct(), hence kmem_cache_alloc(), which picks up memory from the allocation

idle task's task_t allocation on NUMA machines

Hi, Currently, the task_t structure of the idle task is always allocated on CPU0, hence on node 0: while booting, for each CPU, CPU 0 calls fork_idle(), hence copy_process(), hence dup_task_struct(), hence alloc_task_struct(), hence kmem_cache_alloc(), which picks up memory from the allocation

Re: idle task's task_t allocation on NUMA machines

Eric Dumazet, le Thu 18 Aug 2005 17:18:55 +0200, a écrit : An idle task should block itself, hence not touching its task_t structure very much. Indeed, but I guess there are a lot of such little optimizations here and there that could be relatively easily fixed, for a not-so little benefit.

Re: idle task's task_t allocation on NUMA machines

Eric Dumazet, le Thu 18 Aug 2005 17:18:55 +0200, a écrit : I believe IRQ stacks are also allocated on node 0, that seems more serious. For the i386 architecture at least, yes: they are statically defined in arch/i386/kernel/irq.c, while they could be per_cpu. Regards, Samuel - To unsubscribe

Re: idle task's task_t allocation on NUMA machines

Samuel Thibault, le Thu 18 Aug 2005 21:49:41 +0200, a écrit : Eric Dumazet, le Thu 18 Aug 2005 17:18:55 +0200, a écrit : I believe IRQ stacks are also allocated on node 0, that seems more serious. For the i386 architecture at least, yes: they are statically defined in arch/i386/kernel/irq.c

Re: Update Linux 2.4 Status/TODO list

--- Andre Hedrick <[EMAIL PROTECTED]> a écrit : > > Ted and LT, > > I think this are the two things you wanted that were located in: > > /src/tar-files/testing/direct_add/ht6560b.c > /src/tar-files/testing/direct_add/qd65xx.c > /src/tar-files/testing/direct_add/qd65xx.h > > First Petr and

Re: Update Linux 2.4 Status/TODO list

--- Andre Hedrick [EMAIL PROTECTED] a écrit : Ted and LT, I think this are the two things you wanted that were located in: /src/tar-files/testing/direct_add/ht6560b.c /src/tar-files/testing/direct_add/qd65xx.c /src/tar-files/testing/direct_add/qd65xx.h First Petr and Samuel, are

<    2   3   4   5   6   7   8   >