* Re: [PATCH] crypto/sha256.c crypto/sha512.c
From: Jean-Luc Cooke @ 2004-01-27 20:22 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <Xine.LNX.4.44.0401271514150.4185-100000@thoron.boston.redhat.com>
If you take a peek in your/Plumb's crypto/md5.c you've reduced the F1() macro
to the identical operation as the new Ch() inline function.
It reduces gcc's tenancy to re-load values in functions such like:
(x & y) ^ (~x & z)
(x & y) ^ (x & z) ^ (y & z)
This works out much nicer:
z ^ (x & (y ^ z))
(x & y) | (z & (x | y))
I've seen this in a few .c files (gcc -S blah.c; vim blah.s)
The Ch() and Maj() operations are used a lot in sha256/512.
JLC
On Tue, Jan 27, 2004 at 03:14:53PM -0500, James Morris wrote:
> On Tue, 27 Jan 2004, Jean-Luc Cooke wrote:
>
> > Optimized the choice and majority fuctions a bit.
> >
> > Patch:
> > http://jlcooke.ca/lkml/faster_sha2.patch
> >
> > Test suite:
> > http://jlcooke.ca/lkml/faster_sha2.c
> > build with:
> > gcc -O3 -s faster_sha2.c -o faster_sha2
> >
>
> What kind of performance improvement does this provide?
--
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6
^ permalink raw reply
* Re: Linux 2.4.25-pre7
From: Marcelo Tosatti @ 2004-01-27 19:46 UTC (permalink / raw)
To: Rusty Russell; +Cc: Marcelo Tosatti, linux-kernel
In-Reply-To: <20040126165421.679327f0.rusty@rustcorp.com.au>
On Mon, 26 Jan 2004, Rusty Russell wrote:
> On Fri, 23 Jan 2004 16:58:24 -0200 (BRST)
> Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote:
> > Here goes -pre number 7 of 2.4.25 series.
>
> Any chance of the forward-compatible module_param patch?
>
> Name: 2.4 module_param Forward Compatibility Macros
> Author: Rusty Russell
> Status: Tested on 2.5.24-pre6
> Version: 2.4
>
> D: Simple uses of module_param() (implemented in 2.6) can be mapped
> D: onto the old MODULE_PARM macros.
> D:
> D: New code should use module_param() because:
> D: 1) Types are checked,
> D: 2) Existence of parameters are checked,
> D: 3) Customized types are possible [1]
> D: 4) Customized set/get routines are possible [1]
> D: 5) Parameters appear as boot params with prefix "<modname>." [1]
> D: 6) Optional viewing and control through sysfs [2]
> D:
> D: [1] Not for 2.4 compatibility macros
> D: [2] Not in 2.6.1 or 2.4, and only if third arg non-zero.
>
> diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .25425-linux-2.4.25-pre6/include/linux/moduleparam.h .25425-linux-2.4.25-pre6.updated/include/linux/moduleparam.h
> --- .25425-linux-2.4.25-pre6/include/linux/moduleparam.h 1970-01-01 10:00:00.000000000 +1000
> +++ .25425-linux-2.4.25-pre6.updated/include/linux/moduleparam.h 2004-01-21 14:24:41.000000000 +1100
> @@ -0,0 +1,25 @@
> +#ifndef _LINUX_MODULE_PARAMS_H
> +#define _LINUX_MODULE_PARAMS_H
> +/* Macros for (very simple) module parameter compatibility with 2.6. */
> +#include <linux/module.h>
> +
> +/* type is byte, short, ushort, int, uint, long, ulong, bool. (2.6
> + has more, but they are not supported). perm is permissions when
> + it appears in sysfs: 0 means doens't appear, 0444 means read-only
> + by everyone, 0644 means changable dynamically by root, etc. name
> + must be in scope (unlike MODULE_PARM).
> +*/
> +#define module_param(name, type, perm) \
> + static inline void *__check_existence_##name(void) { return &name; } \
> + MODULE_PARM(name, _MODULE_PARM_STRING_ ## type)
> +
> +#define _MODULE_PARM_STRING_byte "b"
> +#define _MODULE_PARM_STRING_short "h"
> +#define _MODULE_PARM_STRING_ushort "h"
> +#define _MODULE_PARM_STRING_int "i"
> +#define _MODULE_PARM_STRING_uint "i"
> +#define _MODULE_PARM_STRING_long "l"
> +#define _MODULE_PARM_STRING_ulong "l"
> +#define _MODULE_PARM_STRING_bool "i"
> +
> +#endif /* _LINUX_MODULE_PARAM_TYPES_H */
Hi Rusty,
I think it is suitable. Will apply.
Thank you.
^ permalink raw reply
* Re: [PATCH] volatile may be needed in rwsem
From: Paulo Marques @ 2004-01-27 20:23 UTC (permalink / raw)
To: joe.korty; +Cc: David Howells, akpm, linux-kernel
In-Reply-To: <20040127194343.GA12763@tsunami.ccur.com>
Joe Korty wrote:
> On Tue, Jan 27, 2004 at 07:19:40PM +0000, David Howells wrote:
>
>>>'flags' should be declared volatile as rwsem_down_failed_common() spins
>>>waiting for this to change. Untested.
>>>
>>Is it though? Does this fix an error?
>>
>>The thing is, we make a function call inside of the loop:
>>
>> /* wait to be given the lock */
>> for (;;) {
>> if (!waiter->flags)
>> break;
>> schedule();
>> set_task_state(tsk, TASK_UNINTERRUPTIBLE);
>> }
>>
>>Which might preclude that need. I'm not entirely sure, though... it's one of
>>those compiler black magic things.
>>
>>I suppose it can't hurt...
>>
>>David
>>
>
> Hi David,
> I misspoke. The potentially failing spin is in __down_write and
> __down_read in lib/rwsem-spinlock.c, not in rwsem_down_failed_common.
>
> The problem is is that 'flags' is on the callee's stack and is thus
> subject to be optimized out of the loop if the compiler is smart enough
> to discover that it is on the stack. Apparently gcc is not yet smart
> enough but that doesn't mean it won't be so soon.
>
It seems to me that the compiler did the right thing and was smart enough,
because after the function did:
list_add_tail(&waiter.list,&sem->wait_list);
it "published" the address of the structure, so the compiler can no longer
assume that no outside function will have access to it.
So even if the compiler was extremely smart, it would have to do the same thing.
If you told no one where your structure is, how could it be modified outside
your function, and how could you expect "waiter.flags" to be modified while
inside the loop anyway (even if it was volatile)?
IMHO the code is correct.
--
Paulo Marques - www.grupopie.com
"In a world without walls and fences who needs windows and gates?"
^ permalink raw reply
* Re: [PATCH] volatile may be needed in rwsem
From: Christian Borntraeger @ 2004-01-27 20:20 UTC (permalink / raw)
To: joe.korty, dhowells, akpm; +Cc: linux-kernel
In-Reply-To: <20040127191155.GA12128@tsunami.ccur.com>
Joe Korty wrote:
> 'flags' should be declared volatile as rwsem_down_failed_common() spins
> waiting for this to change. Untested.
You should use barrier() to prevent the compiler from optimizing reads away,
not volatile.
Here the compiler hopefully considers schedule() as a memory barrier. So
everything should be fine.
cheers
Christian
^ permalink raw reply
* Re: partitioning
From: pa3gcu @ 2004-01-27 20:19 UTC (permalink / raw)
To: haltec, linux-newbie
In-Reply-To: <20040127191626.GA603@lnx2.w8mch.ampr.org>
On Tuesday 27 January 2004 20:16, Hal MacArgle wrote:
> OK on the comments received by all.. I'll have to give this more
> thought as to whether or not it's for me... Appreciate!!
>
To be honest i have not seen any replys to your mail, however in the days we
now live in which are;
BIOS's which dont have limitations like the old < 1024 cyl's limit,
Big H/D's 120GB is standard now, (plenty or room)
Multi boot systems via BIOS (choose which drive one wants to boot from,
one must ask one's self, "Is is reallt nessacary to have a /boot prtition now
that bootloaders dont need it beneath the 1023 cylinder.?
I throw everything into one partition thesedays, 20 Gig on a 120Gig disk is
nothing.
Just my thoughts.
--
If the Linux community is a bunch of theives because they
try to imitate windows programs, then the Windows community
is built on organized crime.
Regards Richard
pa3gcu@zeelandnet.nl
http://people.zeelandnet.nl/pa3gcu/
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: PATCH to access old-style FAT fs
From: OGAWA Hirofumi @ 2004-01-27 20:17 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Frodo Looijaard, linux-kernel
In-Reply-To: <4016B316.4060304@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> OGAWA Hirofumi wrote:
> >
> > The new cluster for directory entries must be initialized by 0x00.
> > And, when the directory entry is deleted, the name[0] is updated by
> > 0xe5 not 0x00.
> >
> > So, if the name[0] is 0x00, it after, all bytes in cluster is 0x00.
> >
> > The fat driver can stop at name[0] == 0x00, but this is just optimization.
> > The behavior shouldn't change by this.
>
> I looked at the spec, and yes, that is how the spec reads:
>
> If DIR_Name[0] == 0x00, then the directory entry is free (same as for
> 0xE5), and there are no allocated directory entries after this one (all
> of the DIR_Name[0] bytes in all of the entries after this one are also
> set to 0). The special 0 value, rather than the 0xE5 value, indicates to
> FAT file system driver code that the rest of the entries in this
> directory do not need to be examined because they are all free.
>
> I guess the original poster has found filesystems which have a 0
> followed by garbage. In cases like that, the cardinal rule for FAT is
> WWDD (What Would DOS Do)... since I'm pretty sure DOS stops examining at
> that point, we should do the same.
>
> It's the same thing as with using 0xF8 for ending clusters; it's correct
> according to spec, but WWDD says 0xFF is the right thing.
The new cluster for directory entries must be initialized by 0x00.
This is required by spec.
If cluster has garbage, the fat driver needs to do such the following
part. Stop at DIR_Name[0] == 0 is not enough, and I don't think DOS
does this.
@@ -709,7 +731,20 @@
}
- if (IS_FREE((*de)->name)) {
- if (++row == slots)
+ if ((oldfat && ((*de)->name[0] == EOD_FLAG)))
+ last_entry = 1;
+ if (last_entry || IS_FREE((*de)->name)) {
+ if (++row == slots) {
+ if (last_entry) {
+ /* If we encounter a last_entry, we
+ * need to mark the entry after the
+ * one to be inserted as last_entry
+ * now! */
+ if (fat_get_entry(dir,&curr,bh,de,i_pos) > -1) {
+ (*de)->name[0] = 0;
+ mark_inode_dirty(dir);
+ }
+ }
return offset;
+ }
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
^ permalink raw reply
* Re: [Bluez-users] Logitech Bluetooth Mx900+keyboard support.
From: Terence Rudkin @ 2004-01-27 20:15 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Olivier Bornet, BlueZ Mailing List
In-Reply-To: <1074597908.7088.5.camel@pegasus>
Marcel,
I finally had a chance to patch kernel and try hid2hci with this patch
kernel. I still got success. but hcitool dev never reported any
devices. I looked at the code in hid2hci, my diff is below.
I first made the change at 204. And found that the /dev/usb/hid was not
opening. Finding me /dev to be /dev/usb I changed line 79 to match my
file structure.
Now I get
hciconfig
hci0: Type: USB
BD Address: 00:07:61:07:ED:A9 ACL MTU: 192:8 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:131 acl:0 sco:0 events:14 errors:0
TX bytes:32 acl:0 sco:0 commands:13 errors:0
But not input from mouse and keyboard.
#> cvs diff hid2hci.c
Index: hid2hci.c
===================================================================
RCS file: /cvsroot/bluez/utils2/hid/hid2hci.c,v
retrieving revision 1.3
diff -r1.3 hid2hci.c
79c79
< static char hidpath[PATH_MAX + 1] = "/dev/usb/hid";
---
> static char hidpath[PATH_MAX + 1] = "/dev/usb";
204c204
< int i, fd, err = 0;
---
> int i, fd, err = -1;
On Tue, 2004-01-20 at 04:25, Marcel Holtmann wrote:
> Hi Olivier,
>
> > Look at the thread:
> >
> > http://sourceforge.net/mailarchive/message.php?msg_id=6881178
> >
> > You need to patch your kernel for having hid2hci working. Note also that
> > at this time, you can only switch from hid to hci, and not from hci to
> > hid.
>
> at the moment nobody is quite sure if this patch is really correct and
> don't break any other devices, but it is working for our needs and I
> included it into my latest -mh patches for the 2.4 series.
>
> Regards
>
> Marcel
>
--
^ permalink raw reply
* [ALSA - driver 0000004]: snd.o misses undefined symbol sound_class
From: noreply @ 2004-01-27 20:15 UTC (permalink / raw)
To: alsa-devel
The following NEW bug has been ADDED.
======================================================================
http://bugtrack.alsa-project.org/alsa-bug/bug_view_page.php?bug_id=0000004
======================================================================
Reporter: khali
Handler:
======================================================================
Project: ALSA - driver
Bug ID: 4
Category: OTHERS
Reproducibility: always
Severity: block
Priority: normal
Status: new
Distribution: Slackware 8.0
Kernel Version: 2.4.24
======================================================================
Date Submitted: 01-27-2004 21:15 CET
Last Modified: 01-27-2004 21:15 CET
======================================================================
Summary: snd.o misses undefined symbol sound_class
Description:
After installing the alsa drivers, I am unable to load snd.o. See the
output of "depmod -ae":
depmod: *** Unresolved symbols in
/lib/modules/2.4.24-1/kernel/sound/acore/snd.o
depmod: sound_class
Configure options: --with-oss=yes --with-cards=intel8x0
Compilation successful.
======================================================================
Bug History
Date Modified Username Field Change
======================================================================
01-27-04 21:15 khali New Bug
======================================================================
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: [PATCH] crypto/sha256.c crypto/sha512.c
From: James Morris @ 2004-01-27 20:14 UTC (permalink / raw)
To: Jean-Luc Cooke; +Cc: linux-kernel
In-Reply-To: <20040127193945.GA15559@certainkey.com>
On Tue, 27 Jan 2004, Jean-Luc Cooke wrote:
> Optimized the choice and majority fuctions a bit.
>
> Patch:
> http://jlcooke.ca/lkml/faster_sha2.patch
>
> Test suite:
> http://jlcooke.ca/lkml/faster_sha2.c
> build with:
> gcc -O3 -s faster_sha2.c -o faster_sha2
>
What kind of performance improvement does this provide?
- James
--
James Morris
<jmorris@redhat.com>
^ permalink raw reply
* Re: BitKeeper repo for KGDB
From: Chris Wright @ 2004-01-27 20:07 UTC (permalink / raw)
To: Tom Rini
Cc: akpm, george, amitkale, Andi Kleen, jim.houston,
Kernel Mailing List
In-Reply-To: <20040127184029.GI32525@stop.crashing.org>
* Tom Rini (trini@kernel.crashing.org) wrote:
> Hello everybody. Since I've been talking with George off-list about
> trying to merge the various versions of KGDB around, and I just read the
> thread between Andy and Jim about conflicting on KGDB work, I've put up
> a BitKeeper repository[1] to try and coordinate things.
<snip>
> [1]: If anyone here won't / can't use BitKeeper, I'll happily move over
> to a repo someone else sets up in something else.
seems I missed where the repo is.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
^ permalink raw reply
* Re: [patch] remove null-ifiers
From: Karol Kozimor @ 2004-01-27 20:07 UTC (permalink / raw)
To: Nate Lawson
Cc: Jes Sorensen, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
len.brown-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20040127120357.X37323-Y6VGUYTwhu0@public.gmane.org>
Thus wrote Nate Lawson:
> > We certainly *don't* want to do that, last time I checked C did not
> > actually guarantee to zero out uninitialized variables -- unless it's
> > different in the kernelspace. Are you sure pointers are initialized as
> > NULLs?
> Static variables have always been guaranteed to be initialized to 0, at
> least since K&R.
Right, that's what I was after -- I might have overreacted initially.
The patch seems fine anyway.
Best regards,
--
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Patch for review and testing
From: James Simmons @ 2004-01-27 20:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Geert Uytterhoeven, Linux Fbdev development list
In-Reply-To: <1075188083.6191.181.camel@gaston>
I like to submit this patch to linus today. Could you test it to see if it
works on ppcs.
diff -urN -X /home/jsimmons/dontdiff linus-2.6/arch/i386/boot/video.S fbdev-2.6/arch/i386/boot/video.S
--- linus-2.6/arch/i386/boot/video.S 2004-01-27 14:11:30.000000000 -0800
+++ fbdev-2.6/arch/i386/boot/video.S 2004-01-27 13:28:20.000000000 -0800
@@ -1889,6 +1889,7 @@
ret
store_edid:
+#ifdef CONFIG_EDID_FIRMWARE
pushw %es # just save all registers
pushw %ax
pushw %bx
@@ -1919,6 +1920,7 @@
popw %bx
popw %ax
popw %es
+#endif /* CONFIG_EDID_FIRMWARE */
ret
# VIDEO_SELECT-only variables
diff -urN -X /home/jsimmons/dontdiff linus-2.6/arch/i386/kernel/setup.c fbdev-2.6/arch/i386/kernel/setup.c
--- linus-2.6/arch/i386/kernel/setup.c 2004-01-27 14:11:32.000000000 -0800
+++ fbdev-2.6/arch/i386/kernel/setup.c 2004-01-27 13:46:34.000000000 -0800
@@ -105,7 +105,9 @@
unsigned short length;
unsigned char table[0];
};
+#ifdef CONFIG_EDID_FIRMWARE
struct edid_info edid_info;
+#endif /* CONFIG_EDID_FIRMWARE */
struct ist_info ist_info;
struct e820map e820;
@@ -1060,7 +1062,9 @@
ROOT_DEV = old_decode_dev(ORIG_ROOT_DEV);
drive_info = DRIVE_INFO;
screen_info = SCREEN_INFO;
+#ifdef CONFIG_EDID_FIRMWARE
edid_info = EDID_INFO;
+#endif /* CONFIG_EDID_FIRMWARE */
apm_info.bios = APM_BIOS_INFO;
ist_info = IST_INFO;
saved_videomode = VIDEO_MODE;
diff -urN -X /home/jsimmons/dontdiff linus-2.6/drivers/video/Kconfig fbdev-2.6/drivers/video/Kconfig
--- linus-2.6/drivers/video/Kconfig 2004-01-27 14:17:11.000000000 -0800
+++ fbdev-2.6/drivers/video/Kconfig 2004-01-27 11:46:36.000000000 -0800
@@ -38,6 +38,18 @@
(e.g. an accelerated X server) and that are not frame buffer
device-aware may cause unexpected results. If unsure, say N.
+config EDID_FIRMWARE
+ bool "Get EDID using the platform's firmware"
+ depends on X86
+ default n
+ help
+ If you choose Y, the EDID (useful for setting video modes) will be
+ acquired using a BIOS call before the kernel boots to protected mode.
+ For computers with broken BIOSes, this can hang your computer. This can
+ also be a very slow process.
+
+ If unsure, choose N.
+
config FB_CIRRUS
tristate "Cirrus Logic support"
depends on FB && (AMIGA || PCI) && BROKEN
diff -urN -X /home/jsimmons/dontdiff linus-2.6/drivers/video/fbmon.c fbdev-2.6/drivers/video/fbmon.c
--- linus-2.6/drivers/video/fbmon.c 2004-01-27 14:17:12.000000000 -0800
+++ fbdev-2.6/drivers/video/fbmon.c 2004-01-27 11:55:32.000000000 -0800
@@ -828,42 +828,42 @@
printk("========================================\n");
}
-#ifdef CONFIG_PPC_OF
-char *get_EDID_from_OF(struct pci_dev *pdev)
+#ifdef CONFIG_EDID_FIRMWARE
+char *get_EDID_from_Firmware(struct device *dev)
{
+#ifdef CONFIG_PPC_OF
static char *propnames[] =
{ "DFP,EDID", "LCD,EDID", "EDID", "EDID1", NULL };
unsigned char *pedid = NULL;
struct device_node *dp;
+ struct pci_dev *pdev;
int i;
+ pdev = to_pci_dev(dev);
+
if (pdev == NULL)
return NULL;
dp = pci_device_to_OF_node(pdev);
- while (dp != NULL) {
+ while (dp) {
for (i = 0; propnames[i] != NULL; ++i) {
pedid = (unsigned char *) get_property(dp, propnames[i], NULL);
- if (pedid != NULL)
+ if (pedid)
return pedid;
}
dp = dp->child;
}
- show_edid(pedid);
- return pedid;
-}
#endif
-
#ifdef CONFIG_X86
-char *get_EDID_from_BIOS(void *dummy)
-{
- unsigned char *pedid = edid_info.dummy;
-
+ unsigned char *pedid = NULL;
+
+ pedid = edid_info.dummy;
if (!pedid)
return NULL;
+#endif
show_edid(pedid);
- return pedid;
+ return pedid;
}
-#endif
+#endif /* CONFIG_EDID_FIRMWARE */
/*
* VESA Generalized Timing Formula (GTF)
@@ -1229,11 +1229,8 @@
EXPORT_SYMBOL(parse_edid);
EXPORT_SYMBOL(show_edid);
-#ifdef CONFIG_X86
-EXPORT_SYMBOL(get_EDID_from_BIOS);
-#endif
-#ifdef CONFIG_PPC_OF
-EXPORT_SYMBOL(get_EDID_from_OF);
+#ifdef CONFIG_EDID_FIRMWARE
+EXPORT_SYMBOL(get_EDID_from_Firmware);
#endif
EXPORT_SYMBOL(fb_get_monitor_limits);
EXPORT_SYMBOL(fb_get_mode);
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* udevinfo output broken
From: Olaf Hering @ 2004-01-27 20:06 UTC (permalink / raw)
To: linux-hotplug
udevinfo writes to fd 0, all the output is lost somehow.
olaf@ibook:~> /sbin/udevinfo -r
/dev/
olaf@ibook:~> i="`/sbin/udevinfo -r`"
/dev/
olaf@ibook:~> echo $i
olaf@ibook:~> i="`/sbin/udevinfo -r 2>&1`"
/dev/
olaf@ibook:~> echo $i
olaf@ibook:~>
--
USB is for mice, FireWire is for men!
sUse lINUX ag, n√úRNBERG
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* u_int32_t causes cross-compile problems [PATCH]
From: Pratik Solanki @ 2004-01-27 20:05 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 406 bytes --]
I came across this C standards issue while cross-compiling the Linux
kernel with gcc on Solaris. The file gen_crc32table.c uses the
non-standard type u_int32_t. It's possible that the host machine's
sys/types.h does not define u_int32_t. The attached patch replaces
u_int32_t with the POSIX standard uint32_t and includes POSIX inttypes.h
instead of sys/types.h.
Please CC me when replying.
Pratik.
[-- Attachment #2: gen_crc32table.patch --]
[-- Type: text/plain, Size: 1111 bytes --]
===== lib/gen_crc32table.c 1.1 vs edited =====
--- 1.1/lib/gen_crc32table.c Sun Nov 24 04:58:41 2002
+++ edited/lib/gen_crc32table.c Fri Jan 23 11:06:00 2004
@@ -1,14 +1,14 @@
#include <stdio.h>
#include "crc32defs.h"
-#include <sys/types.h>
+#include <inttypes.h>
#define ENTRIES_PER_LINE 4
#define LE_TABLE_SIZE (1 << CRC_LE_BITS)
#define BE_TABLE_SIZE (1 << CRC_BE_BITS)
-static u_int32_t crc32table_le[LE_TABLE_SIZE];
-static u_int32_t crc32table_be[BE_TABLE_SIZE];
+static uint32_t crc32table_le[LE_TABLE_SIZE];
+static uint32_t crc32table_be[BE_TABLE_SIZE];
/**
* crc32init_le() - allocate and initialize LE table data
@@ -20,7 +20,7 @@
static void crc32init_le(void)
{
unsigned i, j;
- u_int32_t crc = 1;
+ uint32_t crc = 1;
crc32table_le[0] = 0;
@@ -37,7 +37,7 @@
static void crc32init_be(void)
{
unsigned i, j;
- u_int32_t crc = 0x80000000;
+ uint32_t crc = 0x80000000;
crc32table_be[0] = 0;
@@ -48,7 +48,7 @@
}
}
-static void output_table(u_int32_t table[], int len, char *trans)
+static void output_table(uint32_t table[], int len, char *trans)
{
int i;
^ permalink raw reply
* Re: [patch] remove null-ifiers
From: Nate Lawson @ 2004-01-27 20:04 UTC (permalink / raw)
To: Karol Kozimor
Cc: Jes Sorensen, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
len.brown-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20040127150954.GA12740-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org>
On Tue, 27 Jan 2004, Karol Kozimor wrote:
> Thus wrote Jes Sorensen:
> > diff -urN -X /usr/people/jes/exclude-linux orig/linux-2.6.1-mm3-boot/drivers/acpi/asus_acpi.c linux-2.6.1-mm3/drivers/acpi/asus_acpi.c
> > --- orig/linux-2.6.1-mm3-boot/drivers/acpi/asus_acpi.c Wed Dec 17 18:58:39 2003
> > +++ linux-2.6.1-mm3/drivers/acpi/asus_acpi.c Wed Jan 14 05:00:01 2004
> > @@ -73,8 +73,8 @@
> > MODULE_LICENSE("GPL");
> >
> >
> > -static uid_t asus_uid = 0;
> > -static gid_t asus_gid = 0;
> > +static uid_t asus_uid;
> > +static gid_t asus_gid;
> > MODULE_PARM(asus_uid, "i");
> > MODULE_PARM_DESC(uid, "UID for entries in /proc/acpi/asus.\n");
> > MODULE_PARM(asus_gid, "i");
>
> We certainly *don't* want to do that, last time I checked C did not
> actually guarantee to zero out uninitialized variables -- unless it's
> different in the kernelspace. Are you sure pointers are initialized as
> NULLs?
Static variables have always been guaranteed to be initialized to 0, at
least since K&R.
-Nate
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: linux-2.6.1 x86_64 : STACK_TOP and text/data
From: Andi Kleen @ 2004-01-27 19:57 UTC (permalink / raw)
To: dada1; +Cc: linux-kernel, aj
In-Reply-To: <4016BFD4.2040407@cosmosbay.com>
On Tue, 27 Jan 2004 20:45:24 +0100
dada1 <dada1@cosmosbay.com> wrote:
> Another thing I noticed in last glibc CVS (nptl)
>
> Thread stacks are also allocated in the 1GB quadrant :
>
> nptl/sysdeps/x86_64/pthreaddef.h
> /* We prefer to have the stack allocated in the low 4GB since this
> allows faster context switches. */
> #define ARCH_MAP_FLAGS MAP_32BIT
>
> Is this really true ?
> Is memory allocated in the low 4GB is faster on x86_64 (64bit kernel,
> 64 bit user prog ?)
That only applies to areas referenced set by set_thread_area() and
referenced by segment registers. For pointers <4GB it can use a faster method at
context switch.
They probably do that because they put the thread local data at the
bottom of the stack and it has to be referenced using %gs.
They should use a fallback if the MAP_32BIT allocation fails.
I suspect they would be better off if they allocated the thread local
data separately. The 2.4 kernel used to do the same, but switched to
separate allocation because this gives better cache colouring
(stacks tend to be aligned too much and use only parts of the cache)
MAP_32BIT only allocates in the first 2GB BTW, it's really MAP_31BIT.
-Andi
^ permalink raw reply
* Re: Squid only on eth1
From: rgomez @ 2004-01-27 19:55 UTC (permalink / raw)
To: linux-newbie; +Cc: james
In-Reply-To: <010601c3e480$63c445e0$3401a8c0@iih.usyd.edu.au>
It works, but one more, now it takes much time (close a minute) to get response
from proxy, here are all info I think you would need...
# nmap -sS XXX.XXX.XXX.XXX -p 8080
Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
The 1 scanned port on (eth0) is: closed
Nmap run completed -- 1 IP address (1 host up) scanned in 21 seconds
# nmap -sS XXX.XXX.XXX.XXX -p 8080
Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Interesting ports on (eth1):
Port State Service
8080/tcp open http-proxy
Nmap run completed -- 1 IP address (1 host up) scanned in 21 seconds
# echo $http_proxy
http://localhost:8080/
# wget www.tldp.com
--13:44:09-- http://www.tldp.com/
=> `index.html'
Resolving localhost... done.
Connecting to localhost[127.0.0.1]:8080... failed: Connection refused.
# echo $http_proxy
http://eth1:8080/
# wget www.ibm.com
--13:48:57-- http://www.ibm.com/
=> `index.html.4'
Connecting to eth1:8080... connected.
Proxy request sent, awaiting response... 302 Moved Temporarily
Location: http://www.ibm.com/us/ [following]
--13:49:44-- http://www.ibm.com/us/
=> `index.html.4'
Connecting to eth1:8080... connected.
Proxy request sent, awaiting response... 200 OK
Length: 27,087 [text/html]
100%[====================================>] 27,087 5.02K/s ETA
00:00
13:49:51 (5.02 KB/s) - `index.html.4' saved [27087/27087]
$>-- Mensaje Original --
$>From: "James Turnbull" <james@lovedthanlost.net>
$>To: "linux-newbie" <linux-newbie@vger.kernel.org>
$>Subject: Re: Squid only on eth1
$>Date: Tue, 27 Jan 2004 13:50:57 +1100
$>
$>
$>> Hi:
>
> I have 2 eth devices in my Linux box, I want that all squid traffic go
throw
> eth1 an not eth0, how do I configure it?
>
If they have seperate IP addresses you can force squid to use a specific
IP
address in the squid.conf file. Lo
$>k at the http_port config option and
specify an IP, i.e. http_port 10.0.0.5:3128
Regards
James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie"
in
the body of a message to majordomo@vger.kernel.org
More majordomo
$>info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: NAT before IPsec with 2.6
From: Michael Richardson @ 2004-01-27 19:54 UTC (permalink / raw)
To: netfilter-devel
In-Reply-To: <Pine.LNX.4.44.0401271207160.16067-100000@filer.marasystems.com>
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Henrik" == Henrik Nordstrom <hno@marasystems.com> writes:
Henrik> For me it is easier to grasp what is happending with the packet
Henrik> if it is viewed like the original packet is forwarded to the
Henrik> ipsec engine and the ipsec engine then generates a new packet.
Yes, I agree strongly.
Henrik> Even in the Host<->Host IPSec case the tunnel view is most
Henrik> appropriate. As soon as the packets enter the IPSec encapsulation
Henrik> they loose all the relevant propoerties of the original
Henrik> connection and becomes part of the single IPSec Host <-> IPSec
Henrik> Host connection all packets between these two IPSec host is
Henrik> transmitted over.
Actually, there are a number of properities that many will wish to retain.
This includes:
1) VLAN
2) QoS - DSCP, IPv6 flow label, other application set parameters
3) possibly some pieces of nfmark (it will be scenario specific)
4) ECN gets copied
It is my understanding that the stackable dst permits most of this to
be retained - but the IPsec actually needs to decide what to do.
Finally, there are some packets which will enter the IPsec system, but
emerge unchanged - they may excepted. Those packets will not be new.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBQBbCDYqHRg3pndX9AQGjCgP9EWNAvrsEwopZXv1aJhBAyrFbawM5bPI4
CoENcH4FFXURohmE7GDsXl3Ei8Hf7Kuru8EG1WKZCNJXYpgpsMFRXH6YVOzl497o
aVdE2y279vv1JOyY7Jo/Lwj6nm5NMqkv1EMMOMK8IZm3+AgQ6Fzw/IosMpQUEAkR
CrWi68BCtE0=
=usFv
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [Jfs-discussion] md raid + jfs + jfs_fsck
From: Florian Huber @ 2004-01-27 19:52 UTC (permalink / raw)
To: JFS-Discussion; +Cc: Linux-Kernel
In-Reply-To: <1075232395.11203.94.camel@suprafluid>
[-- Attachment #1: Type: text/plain, Size: 229 bytes --]
On Tue, 2004-01-27 at 20:39, Florian Huber wrote:
> Open(...READ/WRITE EXCLUSIVE...) returned rc = 0
I forgot to mention, that the raid device is mounted. But it makes no
difference if I fsck' from from other boot media.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [ALSA - lib 0000003]: alsa-lib-1.0.2: 'make check' fails
From: noreply @ 2004-01-27 19:52 UTC (permalink / raw)
To: alsa-devel
The following bug has been CLOSED
======================================================================
http://bugtrack.alsa-project.org/alsa-bug/bug_view_advanced_page.php?bug_id=0000003
======================================================================
Reporter: ZlatkO
Handler: perex
======================================================================
Project: ALSA - lib
Bug ID: 3
Category: general
Reproducibility: always
Severity: trivial
Priority: low
Status: closed
======================================================================
Date Submitted: 01-27-2004 20:39 CET
Last Modified: 01-27-2004 20:52 CET
======================================================================
Summary: alsa-lib-1.0.2: 'make check' fails
Description:
'make check' fails on a Slackware 8.1 system with gcc-2.95.3 due to three
minor problems (one missing #define/#include statement, two misplaced
variable delarations) in test/code.c and test/queue_timer.c. The attached
patch fixes these problems.
======================================================================
----------------------------------------------------------------------
perex - 01-27-2004 20:52 CET
----------------------------------------------------------------------
The patch was applied to CVS.
Bug History
Date Modified Username Field Change
======================================================================
01-27-04 20:39 ZlatkO New Bug
01-27-04 20:39 ZlatkO File Added: alsa-lib-1.0.2.diff
01-27-04 20:51 perex Assigned To => perex
01-27-04 20:51 perex Priority normal => low
01-27-04 20:51 perex Status new => assigned
01-27-04 20:52 perex Bugnote Added: 0000004
01-27-04 20:52 perex Status assigned => closed
======================================================================
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* [ALSA - lib 0000003]: alsa-lib-1.0.2: 'make check' fails
From: noreply @ 2004-01-27 19:51 UTC (permalink / raw)
To: alsa-devel
The following bug has been ASSIGNED.
======================================================================
http://bugtrack.alsa-project.org/alsa-bug/bug_view_advanced_page.php?bug_id=0000003
======================================================================
Reporter: ZlatkO
Handler: perex
======================================================================
Project: ALSA - lib
Bug ID: 3
Category: general
Reproducibility: always
Severity: trivial
Priority: low
Status: assigned
======================================================================
Date Submitted: 01-27-2004 20:39 CET
Last Modified: 01-27-2004 20:51 CET
======================================================================
Summary: alsa-lib-1.0.2: 'make check' fails
Description:
'make check' fails on a Slackware 8.1 system with gcc-2.95.3 due to three
minor problems (one missing #define/#include statement, two misplaced
variable delarations) in test/code.c and test/queue_timer.c. The attached
patch fixes these problems.
======================================================================
Bug History
Date Modified Username Field Change
======================================================================
01-27-04 20:39 ZlatkO New Bug
01-27-04 20:39 ZlatkO File Added: alsa-lib-1.0.2.diff
01-27-04 20:51 perex Assigned To => perex
01-27-04 20:51 perex Priority normal => low
01-27-04 20:51 perex Status new => assigned
======================================================================
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: NAT before IPsec with 2.6
From: Michael Richardson @ 2004-01-27 19:51 UTC (permalink / raw)
To: netfilter-devel
In-Reply-To: <20040127103917.GC11761@sunbeam.de.gnumonks.org>
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Harald" == Harald Welte <laforge@netfilter.org> writes:
Harald> To do this, somewhen between esp_output() is called and the
Harald> beginning of the modification of the packet payload, we need to
Harald> call nf_hook(POST_ROUTING). This way, conntrack would be able to
Harald> put the connection in the hash, and people can do SNAT-like
Harald> operations in nat-> POSTROUTING. We could even pass a dummy
Harald> output device structure with an interface name "esp" so people
Harald> can SNAT everything heading for esp encapsulation.
I would suggest that many administrators will want to have possibly a
pseudo-interface per SA. These aren't necessarily real interfaces like
ipsecX, but they do need to be named in some way.
(There are a number of scenarios where having a proper virtual interface
is really the best way to interact properly with routing daemons)
The original IPsec implementation that was done at NRL created virtual
tunnels (using the "route" command) with virtual tunnel devices - one per
tunnel. They were criticised that this didn't scale - that's because at the
time (1993/1994) people weren't building kernels that assumed that there
could be thousands of devices.
Linux people *are* doing this, and doing it correct. The examples include:
MPLS, PPP, PPPoE, VLAN
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBQBbBJ4qHRg3pndX9AQEaHAQA3+VNcmq/9RzhqIW/d5ecLN1bnh+/BQYf
hUELO1Drczud1ne1FxUHSDlvDtwRE5EzZ3tJwSA2NH+5s2yEYnk9Ydb+JNYPiWAL
F/KohhfcQxsasloCSpQ6KErazBU240pJfRYjlSwqNPsZLVC64CqyenEwAm4vxXJJ
X7uzK/idyc4=
=eeVc
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: (Wrong ID) USB Crontroller
From: Robert Reardon @ 2004-01-27 19:50 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel
In-Reply-To: <20040126233939.GB7535@kroah.com>
That seems to have fixed part of the problem.
It still wasn't working afterwards though - I couldn't access any
USB devices properly, so I tried booting with noapic and noacpi on -
it seems to have fixed everything, so I'll stick to using them....
Thanks
Rob
---
Robert Reardon
<RReardon@dsl.pipex.com>
On Mon, 2004-01-26 at 23:39, Greg KH wrote:
> On Mon, Jan 26, 2004 at 08:02:28PM +0000, Robert Reardon wrote:
> > Hi all,
> >
> > I've been trying to get USB working with the 2.6 and keep getting
> > the attached error messages. The kernel appears (to me at least)
> > to detect the USB controller correctly on boot, but it still doesn't
> > want to work. This is my first post to the list, so please be gentle
> > :-).
> >
> > The motherboard is a Supermicro 370DDE, currently running
> > kernel-2.6.2-rc1-mm3. I've tried to attached any relevant information
> > but I'm happy to provide more if it's needed.
> >
> > cat /proc/version reports:
> >
> > Linux version 2.6.2-rc1-mm3 (root@mordor) (gcc version 3.3.2 20031218
> > (Gentoo Linux 3.3.2-r5, propolice-3.3-7)) #2 SMP Sun Jan 25 21:16:13 GMT
> > 2004
> >
> > Anyone got any ideas?
>
> Yeah, get rid of your usbmodules binary. It's not needed and is causing
> the problem.
>
> thanks,
>
> greg k-h
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: BitKeeper repo for KGDB
From: Dave Jones @ 2004-01-27 19:46 UTC (permalink / raw)
To: Tom Rini, akpm, george, amitkale, Andi Kleen, jim.houston,
Kernel Mailing List
In-Reply-To: <20040127193149.GA2023@mars.ravnborg.org>
On Tue, Jan 27, 2004 at 08:31:49PM +0100, Sam Ravnborg wrote:
> On Tue, Jan 27, 2004 at 11:40:29AM -0700, Tom Rini wrote:
> >
> > [1]: If anyone here won't / can't use BitKeeper, I'll happily move over
> > to a repo someone else sets up in something else.
>
> Or you could ask Dave Jones if he can take nightly snapshots - as
> he does for sparse and udev.
Hmm, reminds me, the scripts to make those snapshots broke when I migrated to
the new box. I'll go fix them up. But yeah, sure. If you want me to
add them to the snapshot list, just mail me the bk: url and I'll
add it.
Dave
^ permalink raw reply
* [ALSA - driver 0000002]: 1.0.2: intel8x0.c build problem
From: noreply @ 2004-01-27 19:48 UTC (permalink / raw)
To: alsa-devel
The following bug has been CLOSED
======================================================================
http://bugtrack.alsa-project.org/alsa-bug/bug_view_advanced_page.php?bug_id=0000002
======================================================================
Reporter: ZlatkO
Handler:
======================================================================
Project: ALSA - driver
Bug ID: 2
Category: PCI - intel8x0
Reproducibility: always
Severity: block
Priority: normal
Status: closed
Distribution: Slackware 8.1
Kernel Version: 2.4.24
======================================================================
Date Submitted: 01-27-2004 20:11 CET
Last Modified: 01-27-2004 20:48 CET
======================================================================
Summary: 1.0.2: intel8x0.c build problem
Description:
alsa-driver-1.0.2 doesn't build out of the box with gcc-2.95.3. The
attached patch fixes the problem.
======================================================================
----------------------------------------------------------------------
perex - 01-27-2004 20:47 CET
----------------------------------------------------------------------
I have regenerated the alsa-driver package with this fix.
It is dated:
Jan 27 14:15 alsa-driver-1.0.2.tar.bz2
----------------------------------------------------------------------
perex - 01-27-2004 20:48 CET
----------------------------------------------------------------------
The updated package is available at the ALSA FTP site.
Bug History
Date Modified Username Field Change
======================================================================
01-27-04 20:11 ZlatkO New Bug
01-27-04 20:11 ZlatkO File Added: alsa-driver-1.0.2.diff
01-27-04 20:47 perex Bugnote Added: 0000002
01-27-04 20:48 perex Bugnote Added: 0000003
01-27-04 20:48 perex Status new => closed
======================================================================
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.