Re: [patch 2.6.13-rc3] i386: clean up user_mode macros

2005-07-25 Thread randy_dunlap
On Mon, 25 Jul 2005 18:34:13 -0700 Andrew Morton wrote:

> Miles Bader <[EMAIL PROTECTED]> wrote:
> >
> > Linus Torvalds <[EMAIL PROTECTED]> writes:
> >  > Ask a hundred random C programmers what "!!x" means, versus what "x != 0"
> >  > means, and time their replies.
> > 
> >  I've always thought of "!!" as the "canonicalize boolean" operator...
> 
> Me too.  Once you get used to it, it's just the "convert non-zero to 1"
> operator.
> 
> But whatever.

I call it "truth value" (true or false), but once I got used to it,
I thought it was OK too.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch 2.6.13-rc3] i386: clean up user_mode macros

2005-07-25 Thread randy_dunlap
On Mon, 25 Jul 2005 18:34:13 -0700 Andrew Morton wrote:

 Miles Bader [EMAIL PROTECTED] wrote:
 
  Linus Torvalds [EMAIL PROTECTED] writes:
Ask a hundred random C programmers what !!x means, versus what x != 0
means, and time their replies.
  
   I've always thought of !! as the canonicalize boolean operator...
 
 Me too.  Once you get used to it, it's just the convert non-zero to 1
 operator.
 
 But whatever.

I call it truth value (true or false), but once I got used to it,
I thought it was OK too.

---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch 1/2] Touchscreen support for sharp sl-5500

2005-07-24 Thread randy_dunlap
On Sun, 24 Jul 2005 17:47:56 +0100 Russell King wrote:

> On Fri, Jul 22, 2005 at 08:01:09PM +0200, Pavel Machek wrote:
> > This adds support for reading ADCs (etc), neccessary to operate touch
> > screen on Sharp Zaurus sl-5500.
> 
> I would like to know what the diffs are between my version (attached)
> and this version before they get applied.
> 
> The only reason my version has not been submitted is because it lives
> in the drivers/misc directory, and mainline kernel folk don't like
> drivers which clutter up that directory.  In fact, I had been told
> that drivers/misc should remain completely empty - which makes this
> set of miscellaneous drivers homeless.

but clearly drivers/misc/ is not empty, unless you mean at its
top level.

The IBM ASM service processor driver is there (added in 2.6.x)
as well as some hdpuftrs/ driver, which is not in any Kconfig file
or defconfig file.  :(

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch 1/2] Touchscreen support for sharp sl-5500

2005-07-24 Thread randy_dunlap
On Sun, 24 Jul 2005 17:47:56 +0100 Russell King wrote:

 On Fri, Jul 22, 2005 at 08:01:09PM +0200, Pavel Machek wrote:
  This adds support for reading ADCs (etc), neccessary to operate touch
  screen on Sharp Zaurus sl-5500.
 
 I would like to know what the diffs are between my version (attached)
 and this version before they get applied.
 
 The only reason my version has not been submitted is because it lives
 in the drivers/misc directory, and mainline kernel folk don't like
 drivers which clutter up that directory.  In fact, I had been told
 that drivers/misc should remain completely empty - which makes this
 set of miscellaneous drivers homeless.

but clearly drivers/misc/ is not empty, unless you mean at its
top level.

The IBM ASM service processor driver is there (added in 2.6.x)
as well as some hdpuftrs/ driver, which is not in any Kconfig file
or defconfig file.  :(

---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt

2005-07-23 Thread randy_dunlap
On Fri, 15 Jul 2005 05:46:44 +0200 Jesper Juhl wrote:

> +static int __init jiffies_increment_setup(char *str)
> +{
> + printk(KERN_NOTICE "setting up jiffies_increment : ");
> + if (str) {
> + printk("kernel_hz = %s, ", str);
> + } else {
> + printk("kernel_hz is unset, ");
> + }
> + if (!strncmp("100", str, 3)) {

BTW, if someone enters "kernel_hz=1000", this check (above) for "100"
matches (detects) 100, not 1000.

> + jiffies_increment = 10;
> + printk("jiffies_increment set to 10, effective HZ will be 
> 100\n");
> + } else if (!strncmp("250", str, 3)) {
> + jiffies_increment = 4;
> + printk("jiffies_increment set to 4, effective HZ will be 
> 250\n");
> + } else {
> + jiffies_increment = 1;
> + printk("jiffies_increment set to 1, effective HZ will be 
> 1000\n");
> + }
> +
> + return 1;
> +}

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt

2005-07-23 Thread randy_dunlap
On Sat, 16 Jul 2005 23:55:17 -0400 Lee Revell wrote:

> On Sat, 2005-07-16 at 19:35 -0700, Nish Aravamudan wrote: 
> > As you've seen, I think it depends on the timesource: for the PIT, it
> > would be arch/i386/kernel/timers/timer_pit.c::setup_pit_timer().
> 
> That one looks pretty straightforward.
> arch/i386/kernel/timers/timer_tsc.c really looks like fun.  So many
> corner cases...
> 
> BTW shouldn't this code from mark_offset_tsc():
> 
> 402 if (pit_latch_buggy) {
> 403 /* get center value of last 3 time lutch */
> 404 if ((count2 >= count && count >= count1)
> 405 || (count1 >= count && count >= count2)) {
> 406 count2 = count1; count1 = count;
> 407 } else if ((count1 >= count2 && count2 >= count)
> 408|| (count >= count2 && count2 >= count1)) {
> 409 countmp = count;count = count2;
> 410 count2 = count1;count1 = countmp;
> 411 } else {
> 412 count2 = count1; count1 = count; count = count1;
> 413 }
> 414 }
> 
> use an ifdef?  It only applies to cyrix_55x0, and mark_offset_tsc is a
> pretty hot path.

I see your point, but several distros build kernels that run on
almost any x86-32 machine, so I think that it's there as is
for universal-kernel support.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt

2005-07-23 Thread randy_dunlap
On Sat, 16 Jul 2005 23:55:17 -0400 Lee Revell wrote:

 On Sat, 2005-07-16 at 19:35 -0700, Nish Aravamudan wrote: 
  As you've seen, I think it depends on the timesource: for the PIT, it
  would be arch/i386/kernel/timers/timer_pit.c::setup_pit_timer().
 
 That one looks pretty straightforward.
 arch/i386/kernel/timers/timer_tsc.c really looks like fun.  So many
 corner cases...
 
 BTW shouldn't this code from mark_offset_tsc():
 
 402 if (pit_latch_buggy) {
 403 /* get center value of last 3 time lutch */
 404 if ((count2 = count  count = count1)
 405 || (count1 = count  count = count2)) {
 406 count2 = count1; count1 = count;
 407 } else if ((count1 = count2  count2 = count)
 408|| (count = count2  count2 = count1)) {
 409 countmp = count;count = count2;
 410 count2 = count1;count1 = countmp;
 411 } else {
 412 count2 = count1; count1 = count; count = count1;
 413 }
 414 }
 
 use an ifdef?  It only applies to cyrix_55x0, and mark_offset_tsc is a
 pretty hot path.

I see your point, but several distros build kernels that run on
almost any x86-32 machine, so I think that it's there as is
for universal-kernel support.

---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt

2005-07-23 Thread randy_dunlap
On Fri, 15 Jul 2005 05:46:44 +0200 Jesper Juhl wrote:

 +static int __init jiffies_increment_setup(char *str)
 +{
 + printk(KERN_NOTICE setting up jiffies_increment : );
 + if (str) {
 + printk(kernel_hz = %s, , str);
 + } else {
 + printk(kernel_hz is unset, );
 + }
 + if (!strncmp(100, str, 3)) {

BTW, if someone enters kernel_hz=1000, this check (above) for 100
matches (detects) 100, not 1000.

 + jiffies_increment = 10;
 + printk(jiffies_increment set to 10, effective HZ will be 
 100\n);
 + } else if (!strncmp(250, str, 3)) {
 + jiffies_increment = 4;
 + printk(jiffies_increment set to 4, effective HZ will be 
 250\n);
 + } else {
 + jiffies_increment = 1;
 + printk(jiffies_increment set to 1, effective HZ will be 
 1000\n);
 + }
 +
 + return 1;
 +}

---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] [1/5+1] menu -> menuconfig part 1

2005-07-22 Thread randy_dunlap
On Sun, 17 Jul 2005 13:29:03 +0200 (CEST) Bodo Eggert wrote:

> On Sun, 17 Jul 2005, Bodo Eggert wrote:
> 
> > These patches change some menus into menuconfig options.
> > 
> > Reworked to apply to linux-2.6.13-rc3-git3
> 
> Mostly robotic works.


The SCSI drivers menu has problems similar to the MTD drivers menu.
I.e., some items are displayed on the left panel of xconfig
when they should appear on the right panel.  E.g., these are all
on the left-side panel but should be on the right side:

  SCSI Transport Attributes
  SCSI low-level drivers
Fusion MPT device support
PCMCIA SCSI adapter support


Similar comments for the Sound menu.

Are you testing with menuconfig/xconfig/gconfig ?

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] [1/5+1] menu - menuconfig part 1

2005-07-22 Thread randy_dunlap
On Sun, 17 Jul 2005 13:29:03 +0200 (CEST) Bodo Eggert wrote:

 On Sun, 17 Jul 2005, Bodo Eggert wrote:
 
  These patches change some menus into menuconfig options.
  
  Reworked to apply to linux-2.6.13-rc3-git3
 
 Mostly robotic works.


The SCSI drivers menu has problems similar to the MTD drivers menu.
I.e., some items are displayed on the left panel of xconfig
when they should appear on the right panel.  E.g., these are all
on the left-side panel but should be on the right side:

  SCSI Transport Attributes
  SCSI low-level drivers
Fusion MPT device support
PCMCIA SCSI adapter support


Similar comments for the Sound menu.

Are you testing with menuconfig/xconfig/gconfig ?

---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] [1/5+1] menu -> menuconfig part 1

2005-07-21 Thread randy_dunlap
On Sun, 17 Jul 2005 13:29:03 +0200 (CEST) Bodo Eggert wrote:

> On Sun, 17 Jul 2005, Bodo Eggert wrote:
> 
> > These patches change some menus into menuconfig options.
> > 
> > Reworked to apply to linux-2.6.13-rc3-git3
> 
> Mostly robotic works.

Hi,

When using xconfig (not menuconfig), the drivers/MTD menu
needs some help IMO, but it's not clear where/why.

Before the patch, there was only "Memory Technology
Devices (MTD)" in the left xconfig panel.  After the patch,
under that heading there are 4 other MTD entries,
which are in the right-side panel before the patch and should
remain there.  These are:

  RAM/ROM/Flash chip drivers
  Mapping drivers for chip access
  Self-contained MTD device drivers
  NAND Flash Device support

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] [2/5+1] menu -> menuconfig part 1

2005-07-21 Thread randy_dunlap
On Sun, 17 Jul 2005 13:31:23 +0200 (CEST) Bodo Eggert wrote:

> On Sun, 17 Jul 2005, Bodo Eggert wrote:
> 
> > These patches change some menus into menuconfig options.
> > 
> > Reworked to apply to linux-2.6.13-rc3-git3
> 
> The USB menu.

The USB Gadgets menu is also wacky.

  ? ? <*> USB Gadgets (device side)  ---> ? ?
  ? ? USB Peripheral Controller (NetChip 2280)  --->  ? ?
  ? ?   NetChip 2280 (NEW)? ?
  ? ?  USB Gadget Drivers  ? ?
  ? ? < >   Gadget Zero (DEVELOPMENT) (NEW)   ? ?
  ? ? < >   Ethernet Gadget (with CDC Ethernet support) (NEW) ? ?
  ? ? < >   Gadget Filesystem (EXPERIMENTAL) (NEW)? ?
  ? ? < >   File-backed Storage Gadget (NEW)  ? ?
  ? ? < >   Serial Gadget (with CDC ACM support) (NEW)

Those should all be visible only after pressing Enter on the
USB Gadgets menu item; they should not be expanded inline
in the Device Drivers menu.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] [1b/5+1] menu -> menuconfig part 1

2005-07-21 Thread randy_dunlap
On Sun, 17 Jul 2005 19:03:09 +0200 (CEST) Bodo Eggert wrote:

> On Sun, 17 Jul 2005, Bodo Eggert wrote:
> > On Sun, 17 Jul 2005, Bodo Eggert wrote:
> 
> > > These patches change some menus into menuconfig options.
> > > 
> > > Reworked to apply to linux-2.6.13-rc3-git3
> > 
> > Mostly robotic works.
> 
> Fixup: unbreak i2c menu

Hi Bodo,

Was there supposed to be a patch here?
I do see that the I2C menu is broken...

Thanks,
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] [1b/5+1] menu - menuconfig part 1

2005-07-21 Thread randy_dunlap
On Sun, 17 Jul 2005 19:03:09 +0200 (CEST) Bodo Eggert wrote:

 On Sun, 17 Jul 2005, Bodo Eggert wrote:
  On Sun, 17 Jul 2005, Bodo Eggert wrote:
 
   These patches change some menus into menuconfig options.
   
   Reworked to apply to linux-2.6.13-rc3-git3
  
  Mostly robotic works.
 
 Fixup: unbreak i2c menu

Hi Bodo,

Was there supposed to be a patch here?
I do see that the I2C menu is broken...

Thanks,
---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] [2/5+1] menu - menuconfig part 1

2005-07-21 Thread randy_dunlap
On Sun, 17 Jul 2005 13:31:23 +0200 (CEST) Bodo Eggert wrote:

 On Sun, 17 Jul 2005, Bodo Eggert wrote:
 
  These patches change some menus into menuconfig options.
  
  Reworked to apply to linux-2.6.13-rc3-git3
 
 The USB menu.

The USB Gadgets menu is also wacky.

  ? ? * USB Gadgets (device side)  --- ? ?
  ? ? USB Peripheral Controller (NetChip 2280)  ---  ? ?
  ? ?   NetChip 2280 (NEW)? ?
  ? ? M USB Gadget Drivers  ? ?
  ? ? Gadget Zero (DEVELOPMENT) (NEW)   ? ?
  ? ? Ethernet Gadget (with CDC Ethernet support) (NEW) ? ?
  ? ? Gadget Filesystem (EXPERIMENTAL) (NEW)? ?
  ? ? File-backed Storage Gadget (NEW)  ? ?
  ? ? Serial Gadget (with CDC ACM support) (NEW)

Those should all be visible only after pressing Enter on the
USB Gadgets menu item; they should not be expanded inline
in the Device Drivers menu.

---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] [1/5+1] menu - menuconfig part 1

2005-07-21 Thread randy_dunlap
On Sun, 17 Jul 2005 13:29:03 +0200 (CEST) Bodo Eggert wrote:

 On Sun, 17 Jul 2005, Bodo Eggert wrote:
 
  These patches change some menus into menuconfig options.
  
  Reworked to apply to linux-2.6.13-rc3-git3
 
 Mostly robotic works.

Hi,

When using xconfig (not menuconfig), the drivers/MTD menu
needs some help IMO, but it's not clear where/why.

Before the patch, there was only Memory Technology
Devices (MTD) in the left xconfig panel.  After the patch,
under that heading there are 4 other MTD entries,
which are in the right-side panel before the patch and should
remain there.  These are:

  RAM/ROM/Flash chip drivers
  Mapping drivers for chip access
  Self-contained MTD device drivers
  NAND Flash Device support

---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2.6.12] printk: add sysctl to control printk_time

2005-07-20 Thread randy_dunlap
On Wed, 20 Jul 2005 16:08:35 -0400 (EDT) Mark Whittington wrote:

> Added a sysctl (KERN_PRINTK_TIME) and by proxy an entry in 
> /proc/sys/kernel to enable and disable printk interval information when 
> CONFIG_PRINTK_TIME is compiled in.

1/  That explains "what."  How about "why?"

2/  The patch does not apply cleanly.  It looks like some tabs
are messed up, but I'm not sure about it.

[EMAIL PROTECTED]:linux-2612> patch -p1 -b --dry-run < ~/fixes/printk_time.patch
patching file Documentation/sysctl/kernel.txt
Hunk #1 FAILED at 39.
Hunk #2 FAILED at 261.
2 out of 2 hunks FAILED -- saving rejects to file 
Documentation/sysctl/kernel.txt.rej
patching file include/linux/sysctl.h
Hunk #1 FAILED at 136.
1 out of 1 hunk FAILED -- saving rejects to file include/linux/sysctl.h.rej
patching file kernel/printk.c
Hunk #1 FAILED at 473.
1 out of 1 hunk FAILED -- saving rejects to file kernel/printk.c.rej
patching file kernel/sysctl.c
Hunk #1 FAILED at 63.
Hunk #2 FAILED at 590.
2 out of 2 hunks FAILED -- saving rejects to file kernel/sysctl.c.rej
patching file lib/Kconfig.debug
Hunk #1 FAILED at 6.
1 out of 1 hunk FAILED -- saving rejects to file lib/Kconfig.debug.rej

3/  The patch should be made against a more recent kernel version,
like 2.6.13-rc3 or 2.6.13-rc3-git4.


> Signed-off-by: Mark Whittington <[EMAIL PROTECTED]>
> 
> diff -ruN linux-2.6.12/kernel/printk.c linux-2.6.12-work/kernel/printk.c
> --- linux-2.6.12/kernel/printk.c  2005-06-17 15:48:29.0 -0400
> +++ linux-2.6.12-work/kernel/printk.c 2005-07-20 15:32:03.0 -0400
> @@ -473,7 +473,8 @@
>   }
> 
>   #if defined(CONFIG_PRINTK_TIME)
> -static int printk_time = 1;
> +int printk_time = 1;
> +EXPORT_SYMBOL(printk_time);

I wouldn't think that the EXPORT_SYMBOL() is needed.  That just
makes it visible to modules.  Not being 'static' should be enough
to make it visible to other built-in-kernel files...
so, did you try it without the EXPORT_SYMBOL()?

>   #else
>   static int printk_time = 0;
>   #endif
> diff -ruN linux-2.6.12/lib/Kconfig.debug linux-2.6.12-work/lib/Kconfig.debug
> --- linux-2.6.12/lib/Kconfig.debug2005-06-17 15:48:29.0 -0400
> +++ linux-2.6.12-work/lib/Kconfig.debug   2005-07-20 15:09:07.0 
> -0400
> @@ -6,7 +6,9 @@
> included in printk output.  This allows you to measure
> the interval between kernel operations, including bootup
> operations.  This is useful for identifying long delays
> -   in kernel startup.
> +   in kernel startup.  If this option is enabled, you can turn
> +  off and on the timing information by echoing a 1 or 0 to
> +  /proc/kernel/sys/printk_time.

Those last 2 lines should line up with the lines above them.
However, the last 2 lines use only spaces and not tab(s),
which is incorrect.

Basically, fix your email client and justify the patch.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2.6.12] printk: add sysctl to control printk_time

2005-07-20 Thread randy_dunlap
On Wed, 20 Jul 2005 16:08:35 -0400 (EDT) Mark Whittington wrote:

 Added a sysctl (KERN_PRINTK_TIME) and by proxy an entry in 
 /proc/sys/kernel to enable and disable printk interval information when 
 CONFIG_PRINTK_TIME is compiled in.

1/  That explains what.  How about why?

2/  The patch does not apply cleanly.  It looks like some tabs
are messed up, but I'm not sure about it.

[EMAIL PROTECTED]:linux-2612 patch -p1 -b --dry-run  ~/fixes/printk_time.patch
patching file Documentation/sysctl/kernel.txt
Hunk #1 FAILED at 39.
Hunk #2 FAILED at 261.
2 out of 2 hunks FAILED -- saving rejects to file 
Documentation/sysctl/kernel.txt.rej
patching file include/linux/sysctl.h
Hunk #1 FAILED at 136.
1 out of 1 hunk FAILED -- saving rejects to file include/linux/sysctl.h.rej
patching file kernel/printk.c
Hunk #1 FAILED at 473.
1 out of 1 hunk FAILED -- saving rejects to file kernel/printk.c.rej
patching file kernel/sysctl.c
Hunk #1 FAILED at 63.
Hunk #2 FAILED at 590.
2 out of 2 hunks FAILED -- saving rejects to file kernel/sysctl.c.rej
patching file lib/Kconfig.debug
Hunk #1 FAILED at 6.
1 out of 1 hunk FAILED -- saving rejects to file lib/Kconfig.debug.rej

3/  The patch should be made against a more recent kernel version,
like 2.6.13-rc3 or 2.6.13-rc3-git4.


 Signed-off-by: Mark Whittington [EMAIL PROTECTED]
 
 diff -ruN linux-2.6.12/kernel/printk.c linux-2.6.12-work/kernel/printk.c
 --- linux-2.6.12/kernel/printk.c  2005-06-17 15:48:29.0 -0400
 +++ linux-2.6.12-work/kernel/printk.c 2005-07-20 15:32:03.0 -0400
 @@ -473,7 +473,8 @@
   }
 
   #if defined(CONFIG_PRINTK_TIME)
 -static int printk_time = 1;
 +int printk_time = 1;
 +EXPORT_SYMBOL(printk_time);

I wouldn't think that the EXPORT_SYMBOL() is needed.  That just
makes it visible to modules.  Not being 'static' should be enough
to make it visible to other built-in-kernel files...
so, did you try it without the EXPORT_SYMBOL()?

   #else
   static int printk_time = 0;
   #endif
 diff -ruN linux-2.6.12/lib/Kconfig.debug linux-2.6.12-work/lib/Kconfig.debug
 --- linux-2.6.12/lib/Kconfig.debug2005-06-17 15:48:29.0 -0400
 +++ linux-2.6.12-work/lib/Kconfig.debug   2005-07-20 15:09:07.0 
 -0400
 @@ -6,7 +6,9 @@
 included in printk output.  This allows you to measure
 the interval between kernel operations, including bootup
 operations.  This is useful for identifying long delays
 -   in kernel startup.
 +   in kernel startup.  If this option is enabled, you can turn
 +  off and on the timing information by echoing a 1 or 0 to
 +  /proc/kernel/sys/printk_time.

Those last 2 lines should line up with the lines above them.
However, the last 2 lines use only spaces and not tab(s),
which is incorrect.

Basically, fix your email client and justify the patch.

---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.12-rc2 and as-iosched

2005-07-17 Thread randy_dunlap
On 17 Jul 2005 06:06:08 GMT Kenneth Parrish wrote:

> 
>  System: FamilyNet HQ
>Area: Internet-Email, Internet E-mail
>Date: Jul 16 2005  22:45
>From: Kenneth Parrish
>  To: linux-kernel@vger.kernel.org
>Subj: 2.6.12-rc2 and as-iosched
> 
> v2.6.13-rc2 as-iosched.c and /sys/block/hda/queue/iosched/* values differ:
> [..]
> Oops, HZ=250, so correct.

Hi,

My ESP isn't working so well tonight.

What are you trying to report here?
Need more info.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.12-rc2 and as-iosched

2005-07-17 Thread randy_dunlap
On 17 Jul 2005 06:06:08 GMT Kenneth Parrish wrote:

 
  System: FamilyNet HQ
Area: Internet-Email, Internet E-mail
Date: Jul 16 2005  22:45
From: Kenneth Parrish
  To: linux-kernel@vger.kernel.org
Subj: 2.6.12-rc2 and as-iosched
 
 v2.6.13-rc2 as-iosched.c and /sys/block/hda/queue/iosched/* values differ:
 [..]
 Oops, HZ=250, so correct.

Hi,

My ESP isn't working so well tonight.

What are you trying to report here?
Need more info.

---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [2.6 patch] SCSI_QLA2ABC mustn't select SCSI_FC_ATTRS

2005-07-16 Thread randy_dunlap
On Sat, 16 Jul 2005 23:11:26 -0400 Lee Revell wrote:

> On Sun, 2005-07-17 at 04:38 +0200, Adrian Bunk wrote:
> > SCSI_QLA2XXX is automatically enabled for (SCSI && PCI).
> 
> This has bugged me for a while.  Why does this one SCSI driver default
> to Y in the first place?

It's not a driver, it's a subdirectory.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Module option for compiled-in parts

2005-07-16 Thread randy_dunlap
On Sat, 16 Jul 2005 10:45:17 +0200 (MEST) Jan Engelhardt wrote:

> Hi,
> 
> 
> I have added a module_param() to a component that is compiled in
> (drivers/char/vt.c). Since it's not a module, will it still show a 
> /sys/module/WhatGoesHere/parameters/myvariablename file? What will be put as 
> "WhatGoesHere" as vt.c does not become vt.ko?

Interesting question.

Are you adding one/some module parameters to vt.c ?
I don't see any there.


I have usbcore built-in (not a loadable module), and I still see
in /sys/module/usbcore/parameters these files:

blinkenlights
old_scheme_first
usbfs_snoop
use_both_schemes

but usbcore is "defined" as containing a list of .o files
in drivers/usb/core/Makefile.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Module option for compiled-in parts

2005-07-16 Thread randy_dunlap
On Sat, 16 Jul 2005 10:45:17 +0200 (MEST) Jan Engelhardt wrote:

 Hi,
 
 
 I have added a module_param() to a component that is compiled in
 (drivers/char/vt.c). Since it's not a module, will it still show a 
 /sys/module/WhatGoesHere/parameters/myvariablename file? What will be put as 
 WhatGoesHere as vt.c does not become vt.ko?

Interesting question.

Are you adding one/some module parameters to vt.c ?
I don't see any there.


I have usbcore built-in (not a loadable module), and I still see
in /sys/module/usbcore/parameters these files:

blinkenlights
old_scheme_first
usbfs_snoop
use_both_schemes

but usbcore is defined as containing a list of .o files
in drivers/usb/core/Makefile.

---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [2.6 patch] SCSI_QLA2ABC mustn't select SCSI_FC_ATTRS

2005-07-16 Thread randy_dunlap
On Sat, 16 Jul 2005 23:11:26 -0400 Lee Revell wrote:

 On Sun, 2005-07-17 at 04:38 +0200, Adrian Bunk wrote:
  SCSI_QLA2XXX is automatically enabled for (SCSI  PCI).
 
 This has bugged me for a while.  Why does this one SCSI driver default
 to Y in the first place?

It's not a driver, it's a subdirectory.

---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2.6.13-rc3] kbuild: When checking depmod version, redirect stderr

2005-07-15 Thread randy_dunlap
On Fri, 15 Jul 2005 14:38:54 -0700 Tom Rini wrote:

> On Fri, Jul 15, 2005 at 02:24:32PM -0700, randy_dunlap wrote:
> > On Fri, 15 Jul 2005 07:56:36 -0700 Tom Rini wrote:
> > 
> > > When running depmod to check for the correct version number, extra
> > > output we don't need to see, such as "depmod: QM_MODULES: Function not
> > > implemented" may show up.  Redirect stderr to /dev/null as the version
> > > information that we do care about comes to stdout.
> > > 
> > > Signed-off-by: Tom Rini <[EMAIL PROTECTED]>
> > > 
> > > diff --git a/Makefile b/Makefile
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -875,7 +875,7 @@ modules_install: _modinst_ _modinst_post
> > >  
> > >  .PHONY: _modinst_
> > >  _modinst_:
> > > - @if [ -z "`$(DEPMOD) -V | grep module-init-tools`" ]; then \
> > > + @if [ -z "`$(DEPMOD) -V 2>/dev/null | grep module-init-tools`" ]; then \
> > >   echo "Warning: you may need to install module-init-tools"; \
> > >   echo "See 
> > > http://www.codemonkey.org.uk/docs/post-halloween-2.6.txt";\
> > >   sleep 1; \
> > 
> > Well, seeing "QM_MODULES" is a great indicator that someone is using
> > modutils instead of module-init-tools, so I'd like to see it stay.
> > IOW, I somewhat disagree with "extra output we don't need to see."
> 
> This shows up when building a 2.6 kernel with incorrect tools installed.
> What shows up when building a 2.6 kernel on a 2.4 machine that's
> properly setup to do both is "depmod: Can't open
> /lib/modules/.../modules.dep for writing".

I see.  Thanks for clarifying.  No problem then (with the patch).

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2.6.13-rc3] kbuild: When checking depmod version, redirect stderr

2005-07-15 Thread randy_dunlap
On Fri, 15 Jul 2005 07:56:36 -0700 Tom Rini wrote:

> When running depmod to check for the correct version number, extra
> output we don't need to see, such as "depmod: QM_MODULES: Function not
> implemented" may show up.  Redirect stderr to /dev/null as the version
> information that we do care about comes to stdout.
> 
> Signed-off-by: Tom Rini <[EMAIL PROTECTED]>
> 
> diff --git a/Makefile b/Makefile
> --- a/Makefile
> +++ b/Makefile
> @@ -875,7 +875,7 @@ modules_install: _modinst_ _modinst_post
>  
>  .PHONY: _modinst_
>  _modinst_:
> - @if [ -z "`$(DEPMOD) -V | grep module-init-tools`" ]; then \
> + @if [ -z "`$(DEPMOD) -V 2>/dev/null | grep module-init-tools`" ]; then \
>   echo "Warning: you may need to install module-init-tools"; \
>   echo "See 
> http://www.codemonkey.org.uk/docs/post-halloween-2.6.txt";\
>   sleep 1; \

Well, seeing "QM_MODULES" is a great indicator that someone is using
modutils instead of module-init-tools, so I'd like to see it stay.
IOW, I somewhat disagree with "extra output we don't need to see."

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2.6.13-rc3] kbuild: When checking depmod version, redirect stderr

2005-07-15 Thread randy_dunlap
On Fri, 15 Jul 2005 07:56:36 -0700 Tom Rini wrote:

 When running depmod to check for the correct version number, extra
 output we don't need to see, such as depmod: QM_MODULES: Function not
 implemented may show up.  Redirect stderr to /dev/null as the version
 information that we do care about comes to stdout.
 
 Signed-off-by: Tom Rini [EMAIL PROTECTED]
 
 diff --git a/Makefile b/Makefile
 --- a/Makefile
 +++ b/Makefile
 @@ -875,7 +875,7 @@ modules_install: _modinst_ _modinst_post
  
  .PHONY: _modinst_
  _modinst_:
 - @if [ -z `$(DEPMOD) -V | grep module-init-tools` ]; then \
 + @if [ -z `$(DEPMOD) -V 2/dev/null | grep module-init-tools` ]; then \
   echo Warning: you may need to install module-init-tools; \
   echo See 
 http://www.codemonkey.org.uk/docs/post-halloween-2.6.txt;\
   sleep 1; \

Well, seeing QM_MODULES is a great indicator that someone is using
modutils instead of module-init-tools, so I'd like to see it stay.
IOW, I somewhat disagree with extra output we don't need to see.

---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2.6.13-rc3] kbuild: When checking depmod version, redirect stderr

2005-07-15 Thread randy_dunlap
On Fri, 15 Jul 2005 14:38:54 -0700 Tom Rini wrote:

 On Fri, Jul 15, 2005 at 02:24:32PM -0700, randy_dunlap wrote:
  On Fri, 15 Jul 2005 07:56:36 -0700 Tom Rini wrote:
  
   When running depmod to check for the correct version number, extra
   output we don't need to see, such as depmod: QM_MODULES: Function not
   implemented may show up.  Redirect stderr to /dev/null as the version
   information that we do care about comes to stdout.
   
   Signed-off-by: Tom Rini [EMAIL PROTECTED]
   
   diff --git a/Makefile b/Makefile
   --- a/Makefile
   +++ b/Makefile
   @@ -875,7 +875,7 @@ modules_install: _modinst_ _modinst_post

.PHONY: _modinst_
_modinst_:
   - @if [ -z `$(DEPMOD) -V | grep module-init-tools` ]; then \
   + @if [ -z `$(DEPMOD) -V 2/dev/null | grep module-init-tools` ]; then \
 echo Warning: you may need to install module-init-tools; \
 echo See 
   http://www.codemonkey.org.uk/docs/post-halloween-2.6.txt;\
 sleep 1; \
  
  Well, seeing QM_MODULES is a great indicator that someone is using
  modutils instead of module-init-tools, so I'd like to see it stay.
  IOW, I somewhat disagree with extra output we don't need to see.
 
 This shows up when building a 2.6 kernel with incorrect tools installed.
 What shows up when building a 2.6 kernel on a 2.4 machine that's
 properly setup to do both is depmod: Can't open
 /lib/modules/.../modules.dep for writing.

I see.  Thanks for clarifying.  No problem then (with the patch).

---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [announce] linux kernel performance project launch at sourceforge.net

2005-07-14 Thread randy_dunlap
On Fri, 15 Jul 2005 00:27:48 +0200 Andi Kleen wrote:

> > > Some oprofile listings from a few of the test runs would be also nice.
> > 
> > That is in the works.  We will upload profile data.  I'm having problem
> > with oprofile on some versions of kernel and that is being investigated
> > right now.
> 
> If you run statically compiled kernels you could as well use the
> old style readprofile.  It just doesn't work with modules.

It can be made to work with modules (and has been)[1],
but I'd just stick with not using modules, given a choice.

---
~Randy

[1] http://developer.osdl.org/rddunlap/modprofile/
(against 2.6.6)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [announce] linux kernel performance project launch at sourceforge.net

2005-07-14 Thread randy_dunlap
On Fri, 15 Jul 2005 00:27:48 +0200 Andi Kleen wrote:

   Some oprofile listings from a few of the test runs would be also nice.
  
  That is in the works.  We will upload profile data.  I'm having problem
  with oprofile on some versions of kernel and that is being investigated
  right now.
 
 If you run statically compiled kernels you could as well use the
 old style readprofile.  It just doesn't work with modules.

It can be made to work with modules (and has been)[1],
but I'd just stick with not using modules, given a choice.

---
~Randy

[1] http://developer.osdl.org/rddunlap/modprofile/
(against 2.6.6)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: OOPS in 2.6.13-rc1-mm1 -- EIP is at sysfs_release+0x49/0xb0

2005-07-13 Thread randy_dunlap
On Wed, 13 Jul 2005 09:54:10 -0500 Miles Lane wrote:

> On 7/13/05, Dave Airlie <[EMAIL PROTECTED]> wrote:
> > > Thanks Dave,
> > >
> > > I switched to the i915 kernel driver and still got the OOPS.
> > > I also continue to get the overlapping mtrr message.  I am currently
> > > testing 2.6.13-rc2-git3.  I have tried to run strace with hald, but
> > > cannot reproduce the problem this way.  I am not sure I am invoking the
> > > command corrently.  I have written to the hal developers, but have not
> > > received a response yet.  Here's the current output:
> > >
> > 
> > Can you try and see if you apply the patch from
> > 
> > http://lkml.org/lkml/2005/7/8/257
> > 
> > It should apply to your kernel.. I cannot get this to happen on my
> > system... the mtrr overlaps are just vesafb setting up the mtrrs, you
> > might try without vesafb...
> 
> I will try booting without vesafb enabled.
> 
> I get an error building with the patch applied to 2.6.13-rc2-git3:
> 
> arch/i386/kernel/built-in.o(.text+0x4010): In function `die':
> arch/i386/kernel/traps.c:343: undefined reference to `last_sysfs_name'
> make: *** [.tmp_vmlinux1] Error 1

Miles,
Here is an updated version of the patch that builds for me.
(uses last_sysfs_file instead of last_sysfs_name)

---
~Randy



Track and print last_sysfs_file on oops.
---

 arch/i386/kernel/traps.c |6 ++
 fs/sysfs/file.c  |7 +++
 2 files changed, 13 insertions(+)

diff -Naurp linux-2613-rc1-mm1/arch/i386/kernel/traps.c~last_sysfs_file 
linux-2613-rc1-mm1/arch/i386/kernel/traps.c
--- linux-2613-rc1-mm1/arch/i386/kernel/traps.c~last_sysfs_file 2005-07-13 
12:28:25.0 -0700
+++ linux-2613-rc1-mm1/arch/i386/kernel/traps.c 2005-07-13 12:38:41.0 
-0700
@@ -370,6 +370,12 @@ void die(const char * str, struct pt_reg
 #endif
if (nl)
printk("\n");
+   {
+   extern char last_sysfs_file[];
+
+   printk(KERN_ALERT "last sysfs file: %s\n",
+   last_sysfs_file);
+   }
 #ifdef CONFIG_KGDB
/* This is about the only place we want to go to kgdb even if in
 * user mode.  But we must go in via a trap so within kgdb we will
diff -Naurp linux-2613-rc1-mm1/fs/sysfs/file.c~last_sysfs_file 
linux-2613-rc1-mm1/fs/sysfs/file.c
--- linux-2613-rc1-mm1/fs/sysfs/file.c~last_sysfs_file  2005-07-13 
12:13:35.0 -0700
+++ linux-2613-rc1-mm1/fs/sysfs/file.c  2005-07-13 12:26:26.0 -0700
@@ -6,6 +6,8 @@
 #include 
 #include 
 #include 
+#include 
+
 #include 
 #include 
 
@@ -324,8 +326,13 @@ static int check_perm(struct inode * ino
return error;
 }
 
+char last_sysfs_file[PATH_MAX];
+
 static int sysfs_open_file(struct inode * inode, struct file * filp)
 {
+   d_path(filp->f_dentry, sysfs_mount, last_sysfs_file,
+   sizeof(last_sysfs_file));
+
return check_perm(inode,filp);
 }
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: dependency bug in gconfig?

2005-07-13 Thread randy_dunlap
On Wed, 13 Jul 2005 13:54:56 +0200 (CEST) Roman Zippel wrote:

> Hi,
> 
> On Tue, 12 Jul 2005, randy_dunlap wrote:
> 
> > This appears to be a dependency bug in gconfig to me.
> > 
> > If I enable NETCONSOLE to y, NETPOLL becomes y.  (OK)
> > If I then disable NETCONSOLE to n, NETPOLL remains y.
> > 
> > If I enable NETCONSOLE to m, NETPOLL remains n.  Why is that?
> > 
> > config NETPOLL
> > def_bool NETCONSOLE
> > 
> > Should this cause NETCONSOLE to track NETPOLL?
> 
> It should (although it doesn't show it immediately).
> Did you compare the saved config files?

If I disable NETCONSOLE but NETPOLL is still presented as enabled,
and then save and exit gconfig, both NETCONOLE and NETPOLL are
disabled in the .config file, as it should be, so it appears (to me)
to just be a presentation problem in gconfig.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: dependency bug in gconfig?

2005-07-13 Thread randy_dunlap
On Wed, 13 Jul 2005 13:54:56 +0200 (CEST) Roman Zippel wrote:

 Hi,
 
 On Tue, 12 Jul 2005, randy_dunlap wrote:
 
  This appears to be a dependency bug in gconfig to me.
  
  If I enable NETCONSOLE to y, NETPOLL becomes y.  (OK)
  If I then disable NETCONSOLE to n, NETPOLL remains y.
  
  If I enable NETCONSOLE to m, NETPOLL remains n.  Why is that?
  
  config NETPOLL
  def_bool NETCONSOLE
  
  Should this cause NETCONSOLE to track NETPOLL?
 
 It should (although it doesn't show it immediately).
 Did you compare the saved config files?

If I disable NETCONSOLE but NETPOLL is still presented as enabled,
and then save and exit gconfig, both NETCONOLE and NETPOLL are
disabled in the .config file, as it should be, so it appears (to me)
to just be a presentation problem in gconfig.

---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: OOPS in 2.6.13-rc1-mm1 -- EIP is at sysfs_release+0x49/0xb0

2005-07-13 Thread randy_dunlap
On Wed, 13 Jul 2005 09:54:10 -0500 Miles Lane wrote:

 On 7/13/05, Dave Airlie [EMAIL PROTECTED] wrote:
   Thanks Dave,
  
   I switched to the i915 kernel driver and still got the OOPS.
   I also continue to get the overlapping mtrr message.  I am currently
   testing 2.6.13-rc2-git3.  I have tried to run strace with hald, but
   cannot reproduce the problem this way.  I am not sure I am invoking the
   command corrently.  I have written to the hal developers, but have not
   received a response yet.  Here's the current output:
  
  
  Can you try and see if you apply the patch from
  
  http://lkml.org/lkml/2005/7/8/257
  
  It should apply to your kernel.. I cannot get this to happen on my
  system... the mtrr overlaps are just vesafb setting up the mtrrs, you
  might try without vesafb...
 
 I will try booting without vesafb enabled.
 
 I get an error building with the patch applied to 2.6.13-rc2-git3:
 
 arch/i386/kernel/built-in.o(.text+0x4010): In function `die':
 arch/i386/kernel/traps.c:343: undefined reference to `last_sysfs_name'
 make: *** [.tmp_vmlinux1] Error 1

Miles,
Here is an updated version of the patch that builds for me.
(uses last_sysfs_file instead of last_sysfs_name)

---
~Randy



Track and print last_sysfs_file on oops.
---

 arch/i386/kernel/traps.c |6 ++
 fs/sysfs/file.c  |7 +++
 2 files changed, 13 insertions(+)

diff -Naurp linux-2613-rc1-mm1/arch/i386/kernel/traps.c~last_sysfs_file 
linux-2613-rc1-mm1/arch/i386/kernel/traps.c
--- linux-2613-rc1-mm1/arch/i386/kernel/traps.c~last_sysfs_file 2005-07-13 
12:28:25.0 -0700
+++ linux-2613-rc1-mm1/arch/i386/kernel/traps.c 2005-07-13 12:38:41.0 
-0700
@@ -370,6 +370,12 @@ void die(const char * str, struct pt_reg
 #endif
if (nl)
printk(\n);
+   {
+   extern char last_sysfs_file[];
+
+   printk(KERN_ALERT last sysfs file: %s\n,
+   last_sysfs_file);
+   }
 #ifdef CONFIG_KGDB
/* This is about the only place we want to go to kgdb even if in
 * user mode.  But we must go in via a trap so within kgdb we will
diff -Naurp linux-2613-rc1-mm1/fs/sysfs/file.c~last_sysfs_file 
linux-2613-rc1-mm1/fs/sysfs/file.c
--- linux-2613-rc1-mm1/fs/sysfs/file.c~last_sysfs_file  2005-07-13 
12:13:35.0 -0700
+++ linux-2613-rc1-mm1/fs/sysfs/file.c  2005-07-13 12:26:26.0 -0700
@@ -6,6 +6,8 @@
 #include linux/fsnotify.h
 #include linux/kobject.h
 #include linux/namei.h
+#include linux/limits.h
+
 #include asm/uaccess.h
 #include asm/semaphore.h
 
@@ -324,8 +326,13 @@ static int check_perm(struct inode * ino
return error;
 }
 
+char last_sysfs_file[PATH_MAX];
+
 static int sysfs_open_file(struct inode * inode, struct file * filp)
 {
+   d_path(filp-f_dentry, sysfs_mount, last_sysfs_file,
+   sizeof(last_sysfs_file));
+
return check_perm(inode,filp);
 }
 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


dependency bug in gconfig?

2005-07-12 Thread randy_dunlap

Hi,

(2.6.13-rc2 or later)

This appears to be a dependency bug in gconfig to me.

If I enable NETCONSOLE to y, NETPOLL becomes y.  (OK)
If I then disable NETCONSOLE to n, NETPOLL remains y.

If I enable NETCONSOLE to m, NETPOLL remains n.  Why is that?

config NETPOLL
def_bool NETCONSOLE

Should this cause NETCONSOLE to track NETPOLL?



xconfig and menuconfig have much stricter tracking of
NETCONSOLE -> NETPOLL.  E.g.,
enabling NETCONSOLE=m or y in xconfig also enables NETPOLL=y
and disabling NETCONSOLE also disables NETPOLL.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch] suspend: update documentation

2005-07-12 Thread randy_dunlap
On Tue, 12 Jul 2005 11:05:10 +0200 Pavel Machek wrote:

| Update suspend documentation.
| 
| Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
| 
| ---
| 
| diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt
| --- a/Documentation/power/swsusp.txt
| +++ b/Documentation/power/swsusp.txt
| @@ -318,3 +318,10 @@ As a rule of thumb use encrypted swap to
|  system is shut down or suspended. Additionally use the encrypted
|  suspend image to prevent sensitive data from being stolen after
|  resume.
| +
| +Q: Why we cannot suspend to a swap file?

Q: Why can't we suspend to a swap file?
or
Q: Why can we not suspend to a swap file?

| +
| +A: Because accessing swap file needs the filesystem mounted, and
| +filesystem might do something wrong (like replaying the journal)
| +during mount. [Probably could be solved by modifying every filesystem
| +to support some kind of "really read-only!" option. Patches welcome.]
| diff --git a/Documentation/power/video.txt b/Documentation/power/video.txt
| --- a/Documentation/power/video.txt
| +++ b/Documentation/power/video.txt
| @@ -46,6 +46,12 @@ There are a few types of systems where v
|POSTing bios works. Ole Rohne has patch to do just that at
|http://dev.gentoo.org/~marineam/patch-radeonfb-2.6.11-rc2-mm2.
|  
| +(8) on some systems, you can use the video_post utility mentioned here:
| +  http://bugzilla.kernel.org/show_bug.cgi?id=3670. Do echo 3 > 
/sys/power/state

That attachment is weird for me.  It downloads as "attachment.cgi", but
it's a tar.gz file.  :((using firefox if it matters)

| +  && /usr/sbin/video_post - which will initialize the display in console 
mode.
| +  If  you are in X, you can switch to a virtual terminal and back to X using
| +  CTRL+ALT+F1 - CTRL+ALT+F7 to get the display working in graphical mode 
again.


---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


dependency bug in gconfig?

2005-07-12 Thread randy_dunlap

Hi,

(2.6.13-rc2 or later)

This appears to be a dependency bug in gconfig to me.

If I enable NETCONSOLE to y, NETPOLL becomes y.  (OK)
If I then disable NETCONSOLE to n, NETPOLL remains y.

If I enable NETCONSOLE to m, NETPOLL remains n.  Why is that?

config NETPOLL
def_bool NETCONSOLE

Should this cause NETCONSOLE to track NETPOLL?



xconfig and menuconfig have much stricter tracking of
NETCONSOLE - NETPOLL.  E.g.,
enabling NETCONSOLE=m or y in xconfig also enables NETPOLL=y
and disabling NETCONSOLE also disables NETPOLL.

---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch] suspend: update documentation

2005-07-12 Thread randy_dunlap
On Tue, 12 Jul 2005 11:05:10 +0200 Pavel Machek wrote:

| Update suspend documentation.
| 
| Signed-off-by: Pavel Machek [EMAIL PROTECTED]
| 
| ---
| 
| diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt
| --- a/Documentation/power/swsusp.txt
| +++ b/Documentation/power/swsusp.txt
| @@ -318,3 +318,10 @@ As a rule of thumb use encrypted swap to
|  system is shut down or suspended. Additionally use the encrypted
|  suspend image to prevent sensitive data from being stolen after
|  resume.
| +
| +Q: Why we cannot suspend to a swap file?

Q: Why can't we suspend to a swap file?
or
Q: Why can we not suspend to a swap file?

| +
| +A: Because accessing swap file needs the filesystem mounted, and
| +filesystem might do something wrong (like replaying the journal)
| +during mount. [Probably could be solved by modifying every filesystem
| +to support some kind of really read-only! option. Patches welcome.]
| diff --git a/Documentation/power/video.txt b/Documentation/power/video.txt
| --- a/Documentation/power/video.txt
| +++ b/Documentation/power/video.txt
| @@ -46,6 +46,12 @@ There are a few types of systems where v
|POSTing bios works. Ole Rohne has patch to do just that at
|http://dev.gentoo.org/~marineam/patch-radeonfb-2.6.11-rc2-mm2.
|  
| +(8) on some systems, you can use the video_post utility mentioned here:
| +  http://bugzilla.kernel.org/show_bug.cgi?id=3670. Do echo 3  
/sys/power/state

That attachment is weird for me.  It downloads as attachment.cgi, but
it's a tar.gz file.  :((using firefox if it matters)

| +   /usr/sbin/video_post - which will initialize the display in console 
mode.
| +  If  you are in X, you can switch to a virtual terminal and back to X using
| +  CTRL+ALT+F1 - CTRL+ALT+F7 to get the display working in graphical mode 
again.


---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: CDs which hang kernel

2005-07-11 Thread randy_dunlap
On Tue, 12 Jul 2005 04:11:03 +0300 Nerijus Baliunas wrote:

| On Mon, 11 Jul 2005 23:10:37 +0300 Nerijus Baliunas <[EMAIL PROTECTED]> wrote:
| 
| > I have 2 cdroms which hang PC - one when trying to mount, another when
| > inserted. Kernel 2.6.12-1.1390_FC4, Lite-On SOHW-1673S,
| > hdc: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
| > I can send them by mail if anyone wants.
| 
| Actually it hangs with first one, when trying to mount, with second I get 
oops.

Hi,
Can you post the oops for the second one?

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Add kerneldoc reference to CodingStyle

2005-07-11 Thread randy_dunlap
On Mon, 11 Jul 2005 09:32:00 +0300 (EEST) Pekka J Enberg wrote:

| Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
| ---
| 
|  CodingStyle |3 +++
|  1 files changed, 3 insertions(+)
| 
| Index: 2.6/Documentation/CodingStyle
| ===
| --- 2.6.orig/Documentation/CodingStyle
| +++ 2.6/Documentation/CodingStyle
| @@ -236,6 +236,9 @@ ugly), but try to avoid excess.  Instead
|  of the function, telling people what it does, and possibly WHY it does
|  it.
|  
| +When commenting the kernel API functions, please use the kerneldoc format.
| +See the file scripts/kernel-doc for details.
   See the files Documentation/kernel-doc-nano-HOWTO.txt and scripts/kernel-doc
   for details.
| +
|  
|   Chapter 8: You've made a mess of it
|  
| -


---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Add kerneldoc reference to CodingStyle

2005-07-11 Thread randy_dunlap
On Mon, 11 Jul 2005 09:32:00 +0300 (EEST) Pekka J Enberg wrote:

| Signed-off-by: Pekka Enberg [EMAIL PROTECTED]
| ---
| 
|  CodingStyle |3 +++
|  1 files changed, 3 insertions(+)
| 
| Index: 2.6/Documentation/CodingStyle
| ===
| --- 2.6.orig/Documentation/CodingStyle
| +++ 2.6/Documentation/CodingStyle
| @@ -236,6 +236,9 @@ ugly), but try to avoid excess.  Instead
|  of the function, telling people what it does, and possibly WHY it does
|  it.
|  
| +When commenting the kernel API functions, please use the kerneldoc format.
| +See the file scripts/kernel-doc for details.
   See the files Documentation/kernel-doc-nano-HOWTO.txt and scripts/kernel-doc
   for details.
| +
|  
|   Chapter 8: You've made a mess of it
|  
| -


---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: CDs which hang kernel

2005-07-11 Thread randy_dunlap
On Tue, 12 Jul 2005 04:11:03 +0300 Nerijus Baliunas wrote:

| On Mon, 11 Jul 2005 23:10:37 +0300 Nerijus Baliunas [EMAIL PROTECTED] wrote:
| 
|  I have 2 cdroms which hang PC - one when trying to mount, another when
|  inserted. Kernel 2.6.12-1.1390_FC4, Lite-On SOHW-1673S,
|  hdc: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
|  I can send them by mail if anyone wants.
| 
| Actually it hangs with first one, when trying to mount, with second I get 
oops.

Hi,
Can you post the oops for the second one?

---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] kernel/cpuset.c: add kerneldoc, fix typos

2005-07-10 Thread randy_dunlap
From: Randy Dunlap <[EMAIL PROTECTED]>

Add kerneldoc to kernel/cpuset.c
Fix cpuset typos in init/Kconfig

Paul (someone), please check cpuset_zone_allowed() especially.

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---

 init/Kconfig|2 +-
 kernel/cpuset.c |   26 +++---
 2 files changed, 20 insertions(+), 8 deletions(-)

diff -Naurp linux-2613-rc2/init/Kconfig~kdoc_kernel_cpuset 
linux-2613-rc2/init/Kconfig
--- linux-2613-rc2/init/Kconfig~kdoc_kernel_cpuset  2005-07-09 
13:55:03.0 -0700
+++ linux-2613-rc2/init/Kconfig 2005-07-10 16:42:42.0 -0700
@@ -231,7 +231,7 @@ config CPUSETS
bool "Cpuset support"
depends on SMP
help
- This options will let you create and manage CPUSET's which
+ This option will let you create and manage CPUSETs which
  allow dynamically partitioning a system into sets of CPUs and
  Memory Nodes and assigning tasks to run only within those sets.
  This is primarily useful on large SMP or NUMA systems.
diff -Naurp linux-2613-rc2/kernel/cpuset.c~kdoc_kernel_cpuset 
linux-2613-rc2/kernel/cpuset.c
--- linux-2613-rc2/kernel/cpuset.c~kdoc_kernel_cpuset   2005-07-09 
13:55:03.0 -0700
+++ linux-2613-rc2/kernel/cpuset.c  2005-07-10 17:25:16.0 -0700
@@ -1440,10 +1440,10 @@ void __init cpuset_init_smp(void)
 
 /**
  * cpuset_fork - attach newly forked task to its parents cpuset.
- * @p: pointer to task_struct of forking parent process.
+ * @tsk: pointer to task_struct of forking parent process.
  *
  * Description: By default, on fork, a task inherits its
- * parents cpuset.  The pointer to the shared cpuset is
+ * parent's cpuset.  The pointer to the shared cpuset is
  * automatically copied in fork.c by dup_task_struct().
  * This cpuset_fork() routine need only increment the usage
  * counter in that cpuset.
@@ -1471,7 +1471,6 @@ void cpuset_fork(struct task_struct *tsk
  * by the cpuset_sem semaphore.  If you don't hold cpuset_sem,
  * then a zero cpuset use count is a license to any other task to
  * nuke the cpuset immediately.
- *
  **/
 
 void cpuset_exit(struct task_struct *tsk)
@@ -1521,7 +1520,9 @@ void cpuset_init_current_mems_allowed(vo
current->mems_allowed = NODE_MASK_ALL;
 }
 
-/*
+/**
+ * cpuset_update_current_mems_allowed - update mems parameters to new values
+ *
  * If the current tasks cpusets mems_allowed changed behind our backs,
  * update current->mems_allowed and mems_generation to the new value.
  * Do not call this routine if in_interrupt().
@@ -1540,13 +1541,20 @@ void cpuset_update_current_mems_allowed(
}
 }
 
+/**
+ * cpuset_restrict_to_mems_allowed - limit nodes to current mems_allowed
+ * @nodes: pointer to a node bitmap that is and-ed with mems_allowed
+ */
 void cpuset_restrict_to_mems_allowed(unsigned long *nodes)
 {
bitmap_and(nodes, nodes, nodes_addr(current->mems_allowed),
MAX_NUMNODES);
 }
 
-/*
+/**
+ * cpuset_zonelist_valid_mems_allowed - check zonelist vs. curremt mems_allowed
+ * @zl: the zonelist to be checked
+ *
  * Are any of the nodes on zonelist zl allowed in current->mems_allowed?
  */
 int cpuset_zonelist_valid_mems_allowed(struct zonelist *zl)
@@ -1562,8 +1570,12 @@ int cpuset_zonelist_valid_mems_allowed(s
return 0;
 }
 
-/*
- * Is 'current' valid, and is zone z allowed in current->mems_allowed?
+/**
+ * cpuset_zone_allowed - is zone z allowed in current->mems_allowed
+ * @z: zone in question
+ *
+ * Is zone z allowed in current->mems_allowed, or is
+ * the CPU in interrupt context? (zone is always allowed in this case)
  */
 int cpuset_zone_allowed(struct zone *z)
 {


---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] kernel/crash_dump.c: add kerneldoc

2005-07-10 Thread randy_dunlap
From: Randy Dunlap <[EMAIL PROTECTED]>

Add kerneldoc to kernel/crash_dump.c

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---

 kernel/crash_dump.c |   11 ++-
 1 files changed, 10 insertions(+), 1 deletion(-)

diff -Naurp linux-2613-rc2/kernel/crash_dump.c~kdoc_kernel_crashdump 
linux-2613-rc2/kernel/crash_dump.c
--- linux-2613-rc2/kernel/crash_dump.c~kdoc_kernel_crashdump2005-07-09 
13:55:03.0 -0700
+++ linux-2613-rc2/kernel/crash_dump.c  2005-07-10 16:34:12.0 -0700
@@ -18,7 +18,16 @@
 /* Stores the physical address of elf header of crash image. */
 unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
 
-/*
+/**
+ * copy_oldmem_page - copy one page from "oldmem"
+ * @pfn: page frame number to be copied
+ * @buf: target memory address for the copy; this can be in kernel address
+ * space or user address space (see @userbuf)
+ * @csize: number of bytes to copy
+ * @offset: offset in bytes into the page (based on pfn) to begin the copy
+ * @userbuf: if set, @buf is in user address space, use copy_to_user(),
+ * otherwise @buf is in kernel address space, use memcpy().
+ *
  * Copy a page from "oldmem". For this page, there is no pte mapped
  * in the current kernel. We stitch up a pte, similar to kmap_atomic.
  */


---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] kernel/capability.c: add kerneldoc

2005-07-10 Thread randy_dunlap
From: Randy Dunlap <[EMAIL PROTECTED]>

Add kerneldoc to kernel/capability.c

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---

 kernel/capability.c |   20 +---
 1 files changed, 17 insertions(+), 3 deletions(-)

diff -Naurp linux-2613-rc2/kernel/capability.c~kdoc_kernel_caps 
linux-2613-rc2/kernel/capability.c
--- linux-2613-rc2/kernel/capability.c~kdoc_kernel_caps 2005-06-17 
12:48:29.0 -0700
+++ linux-2613-rc2/kernel/capability.c  2005-07-09 23:04:20.0 -0700
@@ -31,8 +31,14 @@ static DEFINE_SPINLOCK(task_capability_l
  * uninteresting and/or not to be changed.
  */
 
-/*
+/**
  * sys_capget - get the capabilities of a given process.
+ * @header: pointer to struct that contains capability version and
+ * target pid data
+ * @dataptr: pointer to struct that contains the effective, permitted,
+ * and inheritable capabilities that are returned
+ *
+ * Returns 0 on success and < 0 on error.
  */
 asmlinkage long sys_capget(cap_user_header_t header, cap_user_data_t dataptr)
 {
@@ -141,8 +147,14 @@ static inline int cap_set_all(kernel_cap
  return ret;
 }
 
-/*
- * sys_capset - set capabilities for a given process, all processes, or all
+/**
+ * sys_capset - set capabilities for a process or a group of processes
+ * @header: pointer to struct that contains capability version and
+ * target pid data
+ * @data: pointer to struct that contains the effective, permitted,
+ * and inheritable capabilities
+ *
+ * Set capabilities for a given process, all processes, or all
  * processes in a given process group.
  *
  * The restrictions on setting capabilities are specified as:
@@ -152,6 +164,8 @@ static inline int cap_set_all(kernel_cap
  * I: any raised capabilities must be a subset of the (old current) permitted
  * P: any raised capabilities must be a subset of the (old current) permitted
  * E: must be set to a subset of (new target) permitted
+ *
+ * Returns 0 on success and < 0 on error.
  */
 asmlinkage long sys_capset(cap_user_header_t header, const cap_user_data_t 
data)
 {


---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] hardirq uses preempt

2005-07-10 Thread randy_dunlap
From: Randy Dunlap <[EMAIL PROTECTED]>

hardirq.h uses preempt_count() from preempt.h

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---

 include/linux/hardirq.h |1 +
 1 files changed, 1 insertion(+)

diff -Naurp linux-2613-rc2/include/linux/hardirq.h~hardirq-uses-preempt 
linux-2613-rc2/include/linux/hardirq.h
--- linux-2613-rc2/include/linux/hardirq.h~hardirq-uses-preempt 2005-06-17 
12:48:29.0 -0700
+++ linux-2613-rc2/include/linux/hardirq.h  2005-07-10 16:18:39.0 
-0700
@@ -2,6 +2,7 @@
 #define LINUX_HARDIRQ_H
 
 #include 
+#include 
 #include 
 #include 
 #include 


---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: share/private/slave a subtree - define vs enum

2005-07-10 Thread randy_dunlap
On Sun, 10 Jul 2005 21:21:42 +0300 Pekka Enberg wrote:

| Hi Roman,
| 
| At some point in time, I wrote:
| > > Roman, it is not as if I get to decide for the patch submitters. I
| > > comment on any issues _I_ have with the patch and the authors fix
| > > whatever they want (or what the maintainers ask for).
| 
| On Fri, 2005-07-08 at 21:59 +0200, Roman Zippel wrote:
| > The point of a review is to comment on things that _need_ fixing. Less 
| > experienced hackers take this a requirement for their drivers to be 
| > included.
| 
| Hmm. So we disagree on that issue as well. I think the point of review
| is to improve code and help others conform with the existing coding
| style which is why I find it strange that you're suggesting me to limit
| my comments to a subset you agree with.
| 
| Would you please be so kind to define your criteria for things that
| "need fixing" so we could see if can reach some sort of an agreement on
| this. My list is roughly as follows:
| 
|   - Erroneous use of kernel API
|   - Bad coding style
|   - Layering violations
|   - Duplicate code
|   - Hard to read code

Those are all good points IMO, but there is little (or no)
concensus on "bad coding style" or "hard to read code".

Maybe it would make more sense to make some suggested changes to
Documentation/CodingStyle (in the form of a patch) and see what
kinds of reactions (support) it gets.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: I confused about diff(simple question)

2005-07-10 Thread randy_dunlap
On Sun, 10 Jul 2005 13:41:40 +0800 guorke wrote:

| like:
| 
|  /*
| @@ -220,9 +232,8(HERE: why not -220,9 +220,8) @@ fastcall notrace void
| do_page_fault(stru
|struct vm_area_struct * vma;
|unsigned long address;
|unsigned long page;
| -   int write;
| -   siginfo_t info;
| -
| +   int write, si_code;
| +
|/* get the address */
|__asm__("movl %%cr2,%0":"=r" (address));
|trace_special(regs->eip, error_code, address);
| @@ -236,7 +247,7 (HERE: why not -236,7,+236,7) @@ fastcall notrace
| void do_page_fault(stru
| 
|tsk = current;
| 
| -   info.si_code = SEGV_MAPERR;
| +   si_code = SEGV_MAPERR;
| 
|/*
| * We fault-in kernel-space virtual memory on-demand. The
| @@ -316,7 +327,7 (HERE -316,7, +316,7) @@ fastcall notrace void
| do_page_fault(stru
|  * we can handle it..
|  */
|  good_area:
| -   info.si_code = SEGV_ACCERR;
| +   si_code = SEGV_ACCERR;
|write = 0;
|switch (error_code & 3) {
|default:/* 3: write, present */
| @@ -390,11 +401,7 (HERE:why not -390,11,+390,11) @@ bad_area_nosemaphore:
|/* Kernel addresses are always protection faults */
|tsk->thread.error_code = error_code | (address >= TASK_SIZE);
|tsk->thread.trap_no = 14;
| -   info.si_signo = SIGSEGV;
| -   info.si_errno = 0;
| -   /* info.si_code has been set above */
| -   info.si_addr = (void __user *)address;
| -   force_sig_info(SIGSEGV, , tsk);
| +   force_sig_info_fault(SIGSEGV, si_code, address, tsk);
|return;
|}
| 
| @@ -500,11 +507,7(HERE: why not -500,11,+500,7) @@ do_sigbus:
|tsk->thread.cr2 = address;
|tsk->thread.error_code = error_code;
|tsk->thread.trap_no = 14;
| -   info.si_signo = SIGBUS;
| -   info.si_errno = 0;
| -   info.si_code = BUS_ADRERR;
| -   info.si_addr = (void __user *)address;
| -   force_sig_info(SIGBUS, , tsk);
| +   force_sig_info_fault(SIGBUS, BUS_ADRERR, address, tsk);
|return;
| 
| ...
| 
| in :-220,9 +232,8
|  I think the old file from the line 220,and have 9 lines,then the
| newfile have 8 lines
| so must delete one line. but why +232,it from the line 232 ?

That patch segment begins at line 232 in the new file because the
previous patch segments added 12 lines (232 - 220).

Now, were there some previous patch segments (that you omitted) or
not?  If not, it is confusing...

| like this..
| 
| maybe it's very very simple.but i really confused it.wishes helps,



---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: I confused about diff(simple question)

2005-07-10 Thread randy_dunlap
On Sun, 10 Jul 2005 13:41:40 +0800 guorke wrote:

| like:
| 
|  /*
| @@ -220,9 +232,8(HERE: why not -220,9 +220,8) @@ fastcall notrace void
| do_page_fault(stru
|struct vm_area_struct * vma;
|unsigned long address;
|unsigned long page;
| -   int write;
| -   siginfo_t info;
| -
| +   int write, si_code;
| +
|/* get the address */
|__asm__(movl %%cr2,%0:=r (address));
|trace_special(regs-eip, error_code, address);
| @@ -236,7 +247,7 (HERE: why not -236,7,+236,7) @@ fastcall notrace
| void do_page_fault(stru
| 
|tsk = current;
| 
| -   info.si_code = SEGV_MAPERR;
| +   si_code = SEGV_MAPERR;
| 
|/*
| * We fault-in kernel-space virtual memory on-demand. The
| @@ -316,7 +327,7 (HERE -316,7, +316,7) @@ fastcall notrace void
| do_page_fault(stru
|  * we can handle it..
|  */
|  good_area:
| -   info.si_code = SEGV_ACCERR;
| +   si_code = SEGV_ACCERR;
|write = 0;
|switch (error_code  3) {
|default:/* 3: write, present */
| @@ -390,11 +401,7 (HERE:why not -390,11,+390,11) @@ bad_area_nosemaphore:
|/* Kernel addresses are always protection faults */
|tsk-thread.error_code = error_code | (address = TASK_SIZE);
|tsk-thread.trap_no = 14;
| -   info.si_signo = SIGSEGV;
| -   info.si_errno = 0;
| -   /* info.si_code has been set above */
| -   info.si_addr = (void __user *)address;
| -   force_sig_info(SIGSEGV, info, tsk);
| +   force_sig_info_fault(SIGSEGV, si_code, address, tsk);
|return;
|}
| 
| @@ -500,11 +507,7(HERE: why not -500,11,+500,7) @@ do_sigbus:
|tsk-thread.cr2 = address;
|tsk-thread.error_code = error_code;
|tsk-thread.trap_no = 14;
| -   info.si_signo = SIGBUS;
| -   info.si_errno = 0;
| -   info.si_code = BUS_ADRERR;
| -   info.si_addr = (void __user *)address;
| -   force_sig_info(SIGBUS, info, tsk);
| +   force_sig_info_fault(SIGBUS, BUS_ADRERR, address, tsk);
|return;
| 
| ...
| 
| in :-220,9 +232,8
|  I think the old file from the line 220,and have 9 lines,then the
| newfile have 8 lines
| so must delete one line. but why +232,it from the line 232 ?

That patch segment begins at line 232 in the new file because the
previous patch segments added 12 lines (232 - 220).

Now, were there some previous patch segments (that you omitted) or
not?  If not, it is confusing...

| like this..
| 
| maybe it's very very simple.but i really confused it.wishes helps,



---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: share/private/slave a subtree - define vs enum

2005-07-10 Thread randy_dunlap
On Sun, 10 Jul 2005 21:21:42 +0300 Pekka Enberg wrote:

| Hi Roman,
| 
| At some point in time, I wrote:
|   Roman, it is not as if I get to decide for the patch submitters. I
|   comment on any issues _I_ have with the patch and the authors fix
|   whatever they want (or what the maintainers ask for).
| 
| On Fri, 2005-07-08 at 21:59 +0200, Roman Zippel wrote:
|  The point of a review is to comment on things that _need_ fixing. Less 
|  experienced hackers take this a requirement for their drivers to be 
|  included.
| 
| Hmm. So we disagree on that issue as well. I think the point of review
| is to improve code and help others conform with the existing coding
| style which is why I find it strange that you're suggesting me to limit
| my comments to a subset you agree with.
| 
| Would you please be so kind to define your criteria for things that
| need fixing so we could see if can reach some sort of an agreement on
| this. My list is roughly as follows:
| 
|   - Erroneous use of kernel API
|   - Bad coding style
|   - Layering violations
|   - Duplicate code
|   - Hard to read code

Those are all good points IMO, but there is little (or no)
concensus on bad coding style or hard to read code.

Maybe it would make more sense to make some suggested changes to
Documentation/CodingStyle (in the form of a patch) and see what
kinds of reactions (support) it gets.

---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] hardirq uses preempt

2005-07-10 Thread randy_dunlap
From: Randy Dunlap [EMAIL PROTECTED]

hardirq.h uses preempt_count() from preempt.h

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---

 include/linux/hardirq.h |1 +
 1 files changed, 1 insertion(+)

diff -Naurp linux-2613-rc2/include/linux/hardirq.h~hardirq-uses-preempt 
linux-2613-rc2/include/linux/hardirq.h
--- linux-2613-rc2/include/linux/hardirq.h~hardirq-uses-preempt 2005-06-17 
12:48:29.0 -0700
+++ linux-2613-rc2/include/linux/hardirq.h  2005-07-10 16:18:39.0 
-0700
@@ -2,6 +2,7 @@
 #define LINUX_HARDIRQ_H
 
 #include linux/config.h
+#include linux/preempt.h
 #include linux/smp_lock.h
 #include asm/hardirq.h
 #include asm/system.h


---
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] kernel/capability.c: add kerneldoc

2005-07-10 Thread randy_dunlap
From: Randy Dunlap [EMAIL PROTECTED]

Add kerneldoc to kernel/capability.c

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---

 kernel/capability.c |   20 +---
 1 files changed, 17 insertions(+), 3 deletions(-)

diff -Naurp linux-2613-rc2/kernel/capability.c~kdoc_kernel_caps 
linux-2613-rc2/kernel/capability.c
--- linux-2613-rc2/kernel/capability.c~kdoc_kernel_caps 2005-06-17 
12:48:29.0 -0700
+++ linux-2613-rc2/kernel/capability.c  2005-07-09 23:04:20.0 -0700
@@ -31,8 +31,14 @@ static DEFINE_SPINLOCK(task_capability_l
  * uninteresting and/or not to be changed.
  */
 
-/*
+/**
  * sys_capget - get the capabilities of a given process.
+ * @header: pointer to struct that contains capability version and
+ * target pid data
+ * @dataptr: pointer to struct that contains the effective, permitted,
+ * and inheritable capabilities that are returned
+ *
+ * Returns 0 on success and  0 on error.
  */
 asmlinkage long sys_capget(cap_user_header_t header, cap_user_data_t dataptr)
 {
@@ -141,8 +147,14 @@ static inline int cap_set_all(kernel_cap
  return ret;
 }
 
-/*
- * sys_capset - set capabilities for a given process, all processes, or all
+/**
+ * sys_capset - set capabilities for a process or a group of processes
+ * @header: pointer to struct that contains capability version and
+ * target pid data
+ * @data: pointer to struct that contains the effective, permitted,
+ * and inheritable capabilities
+ *
+ * Set capabilities for a given process, all processes, or all
  * processes in a given process group.
  *
  * The restrictions on setting capabilities are specified as:
@@ -152,6 +164,8 @@ static inline int cap_set_all(kernel_cap
  * I: any raised capabilities must be a subset of the (old current) permitted
  * P: any raised capabilities must be a subset of the (old current) permitted
  * E: must be set to a subset of (new target) permitted
+ *
+ * Returns 0 on success and  0 on error.
  */
 asmlinkage long sys_capset(cap_user_header_t header, const cap_user_data_t 
data)
 {


---
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] kernel/crash_dump.c: add kerneldoc

2005-07-10 Thread randy_dunlap
From: Randy Dunlap [EMAIL PROTECTED]

Add kerneldoc to kernel/crash_dump.c

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---

 kernel/crash_dump.c |   11 ++-
 1 files changed, 10 insertions(+), 1 deletion(-)

diff -Naurp linux-2613-rc2/kernel/crash_dump.c~kdoc_kernel_crashdump 
linux-2613-rc2/kernel/crash_dump.c
--- linux-2613-rc2/kernel/crash_dump.c~kdoc_kernel_crashdump2005-07-09 
13:55:03.0 -0700
+++ linux-2613-rc2/kernel/crash_dump.c  2005-07-10 16:34:12.0 -0700
@@ -18,7 +18,16 @@
 /* Stores the physical address of elf header of crash image. */
 unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
 
-/*
+/**
+ * copy_oldmem_page - copy one page from oldmem
+ * @pfn: page frame number to be copied
+ * @buf: target memory address for the copy; this can be in kernel address
+ * space or user address space (see @userbuf)
+ * @csize: number of bytes to copy
+ * @offset: offset in bytes into the page (based on pfn) to begin the copy
+ * @userbuf: if set, @buf is in user address space, use copy_to_user(),
+ * otherwise @buf is in kernel address space, use memcpy().
+ *
  * Copy a page from oldmem. For this page, there is no pte mapped
  * in the current kernel. We stitch up a pte, similar to kmap_atomic.
  */


---
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] kernel/cpuset.c: add kerneldoc, fix typos

2005-07-10 Thread randy_dunlap
From: Randy Dunlap [EMAIL PROTECTED]

Add kerneldoc to kernel/cpuset.c
Fix cpuset typos in init/Kconfig

Paul (someone), please check cpuset_zone_allowed() especially.

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---

 init/Kconfig|2 +-
 kernel/cpuset.c |   26 +++---
 2 files changed, 20 insertions(+), 8 deletions(-)

diff -Naurp linux-2613-rc2/init/Kconfig~kdoc_kernel_cpuset 
linux-2613-rc2/init/Kconfig
--- linux-2613-rc2/init/Kconfig~kdoc_kernel_cpuset  2005-07-09 
13:55:03.0 -0700
+++ linux-2613-rc2/init/Kconfig 2005-07-10 16:42:42.0 -0700
@@ -231,7 +231,7 @@ config CPUSETS
bool Cpuset support
depends on SMP
help
- This options will let you create and manage CPUSET's which
+ This option will let you create and manage CPUSETs which
  allow dynamically partitioning a system into sets of CPUs and
  Memory Nodes and assigning tasks to run only within those sets.
  This is primarily useful on large SMP or NUMA systems.
diff -Naurp linux-2613-rc2/kernel/cpuset.c~kdoc_kernel_cpuset 
linux-2613-rc2/kernel/cpuset.c
--- linux-2613-rc2/kernel/cpuset.c~kdoc_kernel_cpuset   2005-07-09 
13:55:03.0 -0700
+++ linux-2613-rc2/kernel/cpuset.c  2005-07-10 17:25:16.0 -0700
@@ -1440,10 +1440,10 @@ void __init cpuset_init_smp(void)
 
 /**
  * cpuset_fork - attach newly forked task to its parents cpuset.
- * @p: pointer to task_struct of forking parent process.
+ * @tsk: pointer to task_struct of forking parent process.
  *
  * Description: By default, on fork, a task inherits its
- * parents cpuset.  The pointer to the shared cpuset is
+ * parent's cpuset.  The pointer to the shared cpuset is
  * automatically copied in fork.c by dup_task_struct().
  * This cpuset_fork() routine need only increment the usage
  * counter in that cpuset.
@@ -1471,7 +1471,6 @@ void cpuset_fork(struct task_struct *tsk
  * by the cpuset_sem semaphore.  If you don't hold cpuset_sem,
  * then a zero cpuset use count is a license to any other task to
  * nuke the cpuset immediately.
- *
  **/
 
 void cpuset_exit(struct task_struct *tsk)
@@ -1521,7 +1520,9 @@ void cpuset_init_current_mems_allowed(vo
current-mems_allowed = NODE_MASK_ALL;
 }
 
-/*
+/**
+ * cpuset_update_current_mems_allowed - update mems parameters to new values
+ *
  * If the current tasks cpusets mems_allowed changed behind our backs,
  * update current-mems_allowed and mems_generation to the new value.
  * Do not call this routine if in_interrupt().
@@ -1540,13 +1541,20 @@ void cpuset_update_current_mems_allowed(
}
 }
 
+/**
+ * cpuset_restrict_to_mems_allowed - limit nodes to current mems_allowed
+ * @nodes: pointer to a node bitmap that is and-ed with mems_allowed
+ */
 void cpuset_restrict_to_mems_allowed(unsigned long *nodes)
 {
bitmap_and(nodes, nodes, nodes_addr(current-mems_allowed),
MAX_NUMNODES);
 }
 
-/*
+/**
+ * cpuset_zonelist_valid_mems_allowed - check zonelist vs. curremt mems_allowed
+ * @zl: the zonelist to be checked
+ *
  * Are any of the nodes on zonelist zl allowed in current-mems_allowed?
  */
 int cpuset_zonelist_valid_mems_allowed(struct zonelist *zl)
@@ -1562,8 +1570,12 @@ int cpuset_zonelist_valid_mems_allowed(s
return 0;
 }
 
-/*
- * Is 'current' valid, and is zone z allowed in current-mems_allowed?
+/**
+ * cpuset_zone_allowed - is zone z allowed in current-mems_allowed
+ * @z: zone in question
+ *
+ * Is zone z allowed in current-mems_allowed, or is
+ * the CPU in interrupt context? (zone is always allowed in this case)
  */
 int cpuset_zone_allowed(struct zone *z)
 {


---
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt

2005-07-09 Thread randy_dunlap
On Sat, 09 Jul 2005 15:16:01 -0400 Lee Revell wrote:

| On Sat, 2005-07-09 at 12:12 -0700, Andrew Morton wrote:
| > Lee Revell <[EMAIL PROTECTED]> wrote:
| > >
| > >  > This is not a userspace visible thing really with few exceptions, and
| > >  > well people can select the one they want, right?
| > > 
| > >  Then why not leave the default at 1000?
| > 
| > Because some machines exhibit appreciable latency in entering low power
| > state via ACPI, and 1000Hz reduces their battery life.  By about half,
| > iirc.
| > 
| 
| Then the owners of such machines can use HZ=250 and leave the default
| alone.  Why should everyone have to bear the cost?

indeed, why should everyone have to have 1000 timer interrupts per second?

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt

2005-07-09 Thread randy_dunlap
On Sat, 09 Jul 2005 15:16:01 -0400 Lee Revell wrote:

| On Sat, 2005-07-09 at 12:12 -0700, Andrew Morton wrote:
|  Lee Revell [EMAIL PROTECTED] wrote:
|  
| This is not a userspace visible thing really with few exceptions, and
| well people can select the one they want, right?
|   
|Then why not leave the default at 1000?
|  
|  Because some machines exhibit appreciable latency in entering low power
|  state via ACPI, and 1000Hz reduces their battery life.  By about half,
|  iirc.
|  
| 
| Then the owners of such machines can use HZ=250 and leave the default
| alone.  Why should everyone have to bear the cost?

indeed, why should everyone have to have 1000 timer interrupts per second?

---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch 2.6.12-rc3] modified firmware_class.c to add a new function request_firmware_nowait_nohotplug

2005-07-08 Thread randy_dunlap
On Fri, 8 Jul 2005 19:16:57 -0500 Abhay Salunke wrote:

| This is the patch to add dell_rbu driver. This patch requires the 
| firmware_class.c patch sent earlier which adds 
request_firmware_nowait_nohotplug 
| function. 
| Andrew , 
| Could you add this patch to the -mm tree. This patch was submitted about a
| week ago for review.
| 
| Signed-off-by: Abhay Salunke <[EMAIL PROTECTED]>
| 
| Thanks
| Abhay

General comment:

The patches have lots of trailing whitespace.  Please remove all of that.

| diff -uprN linux-2.6.11.11.orig/drivers/firmware/dell_rbu.c 
linux-2.6.11.11.new/drivers/firmware/dell_rbu.c
| --- linux-2.6.11.11.orig/drivers/firmware/dell_rbu.c  1969-12-31 
18:00:00.0 -0600
| +++ linux-2.6.11.11.new/drivers/firmware/dell_rbu.c   2005-06-30 
15:37:27.0 -0500
| @@ -0,0 +1,627 @@
| +/*
| + * dell_rbu.c
| + * Bios Update driver for Dell systems
| + * Author: Dell Inc
| + * Abhay Salunke <[EMAIL PROTECTED]>
| + *
| + * Copyright (C) 2005 Dell Inc.
| + *
| + * Remote BIOS Update (rbu) driver is used for updating DELL BIOS by 
| + * creating entries in the /sys file systems on Linux 2.6 and higher 
| + * kernels. The driver supports two mechanism to update the BIOS namely 
   mechanisms  BIOS,
| + * contiguous and packetized. Both these methods still require having some
| + * application to set the CMOS bit indicating the BIOS to update itself 
| + * after a reboot.
| + *
| + * Contiguous method:
| + * This driver writes the incoming data in a monolithic image by allocating 
| + * contiguous physical pages large enough to accommodate the incoming BIOS 
| + * image size.  
| + *
| + * Packetized method:
| + * The driver writes the incoming packet image by allocating a new packet 
| + * on every time the packet data is written. This driver requires an 
  each time that the
| + * application to break the BIOS image in to fixed sized packet chunks.
  into
| + *
| + * See Documentation/dell_rbu.txt for more info.
| + *
| + */
| +#include 
| +#include 
| +#include 
| +#include 
| +#include 
| +#include 
| +#include 
| +#include 
| +#include 
| +#include 
| +#include 
| +#include 
| +
| +MODULE_AUTHOR("Abhay Salunke <[EMAIL PROTECTED]>");
| +MODULE_DESCRIPTION("Driver for updating BIOS image on DELL systems");
| +MODULE_LICENSE("GPL");
| +MODULE_VERSION("1.0");
| +
| +#define BIOS_SCAN_LIMIT 0x

Please remove this, it's not used.

| +#define MAX_IMAGE_LENGTH 16
| +static struct _rbu_data {
| + void *image_update_buffer;
| + unsigned long image_update_buffer_size;
| + unsigned long bios_image_size;
| + spinlock_t lock;
| + unsigned long packet_read_count;
| + unsigned long packet_write_count;
| + unsigned long num_packets;
| + unsigned long packetsize;
| +} rbu_data;
| +
| +static char image_type[MAX_IMAGE_LENGTH] = "mono";
| +module_param_string(image_type, image_type, sizeof (image_type), 0);

Why is permission 0?  0 means not visible in sysfs.
But you tested this, so ?

| +MODULE_PARM_DESC(image_type, "BIOS image type. choose- mono or packet");
| +
| +struct packet_data {
| + struct list_head list;
| + size_t length;
| + void *data;
| + int ordernum;
| +};
| +
| +static struct packet_data packet_data_head;
| +
| +struct platform_device *rbu_device;
| +int context;
| +static dma_addr_t dell_rbu_dmaaddr;
| +
| +static int
| +fill_last_packet(void *data, size_t length)
| +{
| + struct list_head *ptemp_list;
| + struct packet_data *packet = NULL;
| + int packet_count = 0;
| +
| + pr_debug("fill_last_packet: entry \n");
entry\n  (other places also)
| +
| + if (!rbu_data.num_packets) {
| + pr_debug("fill_last_packet: num_packets=0\n");
| + return -ENOMEM;
| + }
| +
| + packet_count = rbu_data.num_packets;
| +
| + ptemp_list = (_data_head.list)->prev;
| +
| + packet = list_entry(ptemp_list, struct packet_data, list);
| +
| + if ((rbu_data.packet_write_count + length) > rbu_data.packetsize) {
| + pr_debug("dell_rbu:%s: packet size data "
| + "overrun\n", __FUNCTION__);
| + return -EINVAL;
| + }
| +
| + pr_debug("fill_last_packet : buffer = %p\n", packet->data);
| +
| + memcpy((packet->data + rbu_data.packet_write_count), data, length);
| +
| + if ((rbu_data.packet_write_count + length) == rbu_data.packetsize) {
| + /*
| +  * this was the last data chunk in the packet
| +  * so reinitialize the packet data counter to zero
| +  */
| + rbu_data.packet_write_count = 0;
| + } else
| + rbu_data.packet_write_count += length;
| +
| + pr_debug("fill_last_packet: exit \n");
exit\n (other places too)
| + return 0;
| +}
| +
| +static int
| 

Re: [patch 2.6.12-rc3] modified firmware_class.c to add a new function request_firmware_nowait_nohotplug

2005-07-08 Thread randy_dunlap
On Fri, 8 Jul 2005 19:16:57 -0500 Abhay Salunke wrote:

| This is the patch to add dell_rbu driver. This patch requires the 
| firmware_class.c patch sent earlier which adds 
request_firmware_nowait_nohotplug 
| function. 
| Andrew , 
| Could you add this patch to the -mm tree. This patch was submitted about a
| week ago for review.
| 
| Signed-off-by: Abhay Salunke <[EMAIL PROTECTED]>
| 
| Thanks
| Abhay
| diff -uprN linux-2.6.11.11.orig/Documentation/dell_rbu.txt 
linux-2.6.11.11.new/Documentation/dell_rbu.txt
| --- linux-2.6.11.11.orig/Documentation/dell_rbu.txt   1969-12-31 
18:00:00.0 -0600
| +++ linux-2.6.11.11.new/Documentation/dell_rbu.txt2005-06-30 
15:41:28.0 -0500
| @@ -0,0 +1,72 @@
| +Purpose:
| +Demonstrate the usage of the new open sourced rbu (Remote BIOS Update) driver
| +for updating BIOS images on Dell servers and desktops.
| +
| +Scope:
| +This document discusses the functionality of the rbu driver only.
| +It does not cover the support needed from aplications to enable the BIOS to
| +update itself with the image downloaded in to the memory.
| +
| +Overview:
| +This driver enables userspace applications to update the BIOS on Dell servers
| +(starting from servers sold since 1999), desktops and notebooks (starting
   (beginning with servers sold in 1999)  (beginning
| +from those sold in 2005).
   with those sold in 2005)
| +
| +The driver supports BIOS update using the monilothic image and packetized
 monolithic
| +image methods. In case of moniolithic the driver allocates a contiguous chunk
  In the monolithic case,
| +of physical pages having the BIOS image. In case of packetized the app
In the packetized case,
| +using the driver breaks the image in to packets of fixed sizes and the driver
| +would place each packet in contiguous physical memory. The driver also
 places   into
| +maintains a link list of packets for reading them back.
   linked
| +If the dell_rbu driver is unloaded all the allocated memory is freed.
| +
| +The rbu driver needs to have an application which will inform the BIOS to
| +enable the update in the next system reboot.
| +
| +The user should not unload the rbu driver after downloading the BIOS image
| +or updating.
| +
| +The driver load creates the following directories under the /sys file system.
| +/sys/class/firmware/dell_rbu/loading 
| +/sys/class/firmware/dell_rbu/data
| +/sys/devices/platform/dell_rbu/image_type
| +/sys/devices/platform/dell_rbu/data
| +
| +The driver supports two types of update mechanism; monolithic and packetized.
   mechanisms;
| +These update mechanism depends upon the BIOS currently running on the system.
| +Most of the Dell systems support a monolithic update where the BIOS image is 
| +copied to a single contiguous block of physical memory. 
| +In case of packet mechanism the single memory can be broken in smaller chuks
   In the packetized mode, into smaller 
chunks
| +of contiguous memory and the BIOS image is scattered in these packets.
| +
| +By default the driver uses monolithic memory for the update type. This can be
| +changed to contiguous during the driver load time by specifying the load
 packetized mode
| +parameter image_type=packet.  This can also be changed later as below
by using:
| +echo "packet" > /sys/devices/platform/dell_rbu/image_type 
| +
| +Do the steps below to download the BIOS image.
| +1) echo 1 > /sys/class/firmware/dell_rbu/loading
| +2) cp bios_image.hdr /sys/class/firmware/dell_rbu/data
| +3) echo 0 > /sys/class/firmware/dell_rbu/loading
| +
| +The /sys/class/firmware/dell_rbu/ entries will remain till the following is
until
| +done. 
   done:
| +echo -1 > /sys/class/firmware/dell_rbu/loading
| +
| +Until this step is completed the drivr cannot be unloaded.
driver
| +
| +Also the driver provides /sys/devices/platform/dell_rbu/data readonly file to
| +read back the image downloaded. This is useful in case of packet update 
   This is useful in the packetized update
| +mechanism where the above steps 1,2,3 will repeated for every packet. 
| +By reading the /sys/devices/platform/dell_rbu/data file all packet data 
| +downloaded can be verified in a single file. 
| +The packets are arranged in this file one after the other in a FIFO order.
| +
| +NOTE:
| +This driver requires a patch for firmware_class.c which has the addition
| +of request_firmware_nowait_nohotplug function to wortk
 ^insert "the"  work.
| +Also after updating the BIOS image an user mdoe application neeeds to execute
  a 

Re: [patch 2.6.12-rc3] modified firmware_class.c to add a new function request_firmware_nowait_nohotplug

2005-07-08 Thread randy_dunlap
On Fri, 8 Jul 2005 19:16:57 -0500 Abhay Salunke wrote:

| This is the patch to add dell_rbu driver. This patch requires the 
| firmware_class.c patch sent earlier which adds 
request_firmware_nowait_nohotplug 
| function. 
| Andrew , 
| Could you add this patch to the -mm tree. This patch was submitted about a
| week ago for review.
| 
| Signed-off-by: Abhay Salunke [EMAIL PROTECTED]
| 
| Thanks
| Abhay
| diff -uprN linux-2.6.11.11.orig/Documentation/dell_rbu.txt 
linux-2.6.11.11.new/Documentation/dell_rbu.txt
| --- linux-2.6.11.11.orig/Documentation/dell_rbu.txt   1969-12-31 
18:00:00.0 -0600
| +++ linux-2.6.11.11.new/Documentation/dell_rbu.txt2005-06-30 
15:41:28.0 -0500
| @@ -0,0 +1,72 @@
| +Purpose:
| +Demonstrate the usage of the new open sourced rbu (Remote BIOS Update) driver
| +for updating BIOS images on Dell servers and desktops.
| +
| +Scope:
| +This document discusses the functionality of the rbu driver only.
| +It does not cover the support needed from aplications to enable the BIOS to
| +update itself with the image downloaded in to the memory.
| +
| +Overview:
| +This driver enables userspace applications to update the BIOS on Dell servers
| +(starting from servers sold since 1999), desktops and notebooks (starting
   (beginning with servers sold in 1999)  (beginning
| +from those sold in 2005).
   with those sold in 2005)
| +
| +The driver supports BIOS update using the monilothic image and packetized
 monolithic
| +image methods. In case of moniolithic the driver allocates a contiguous chunk
  In the monolithic case,
| +of physical pages having the BIOS image. In case of packetized the app
In the packetized case,
| +using the driver breaks the image in to packets of fixed sizes and the driver
| +would place each packet in contiguous physical memory. The driver also
 places   into
| +maintains a link list of packets for reading them back.
   linked
| +If the dell_rbu driver is unloaded all the allocated memory is freed.
| +
| +The rbu driver needs to have an application which will inform the BIOS to
| +enable the update in the next system reboot.
| +
| +The user should not unload the rbu driver after downloading the BIOS image
| +or updating.
| +
| +The driver load creates the following directories under the /sys file system.
| +/sys/class/firmware/dell_rbu/loading 
| +/sys/class/firmware/dell_rbu/data
| +/sys/devices/platform/dell_rbu/image_type
| +/sys/devices/platform/dell_rbu/data
| +
| +The driver supports two types of update mechanism; monolithic and packetized.
   mechanisms;
| +These update mechanism depends upon the BIOS currently running on the system.
| +Most of the Dell systems support a monolithic update where the BIOS image is 
| +copied to a single contiguous block of physical memory. 
| +In case of packet mechanism the single memory can be broken in smaller chuks
   In the packetized mode, into smaller 
chunks
| +of contiguous memory and the BIOS image is scattered in these packets.
| +
| +By default the driver uses monolithic memory for the update type. This can be
| +changed to contiguous during the driver load time by specifying the load
 packetized mode
| +parameter image_type=packet.  This can also be changed later as below
by using:
| +echo packet  /sys/devices/platform/dell_rbu/image_type 
| +
| +Do the steps below to download the BIOS image.
| +1) echo 1  /sys/class/firmware/dell_rbu/loading
| +2) cp bios_image.hdr /sys/class/firmware/dell_rbu/data
| +3) echo 0  /sys/class/firmware/dell_rbu/loading
| +
| +The /sys/class/firmware/dell_rbu/ entries will remain till the following is
until
| +done. 
   done:
| +echo -1  /sys/class/firmware/dell_rbu/loading
| +
| +Until this step is completed the drivr cannot be unloaded.
driver
| +
| +Also the driver provides /sys/devices/platform/dell_rbu/data readonly file to
| +read back the image downloaded. This is useful in case of packet update 
   This is useful in the packetized update
| +mechanism where the above steps 1,2,3 will repeated for every packet. 
| +By reading the /sys/devices/platform/dell_rbu/data file all packet data 
| +downloaded can be verified in a single file. 
| +The packets are arranged in this file one after the other in a FIFO order.
| +
| +NOTE:
| +This driver requires a patch for firmware_class.c which has the addition
| +of request_firmware_nowait_nohotplug function to wortk
 ^insert the  work.
| +Also after updating the BIOS image an user mdoe application neeeds to execute
  a user mode

Re: [patch 2.6.12-rc3] modified firmware_class.c to add a new function request_firmware_nowait_nohotplug

2005-07-08 Thread randy_dunlap
On Fri, 8 Jul 2005 19:16:57 -0500 Abhay Salunke wrote:

| This is the patch to add dell_rbu driver. This patch requires the 
| firmware_class.c patch sent earlier which adds 
request_firmware_nowait_nohotplug 
| function. 
| Andrew , 
| Could you add this patch to the -mm tree. This patch was submitted about a
| week ago for review.
| 
| Signed-off-by: Abhay Salunke [EMAIL PROTECTED]
| 
| Thanks
| Abhay

General comment:

The patches have lots of trailing whitespace.  Please remove all of that.

| diff -uprN linux-2.6.11.11.orig/drivers/firmware/dell_rbu.c 
linux-2.6.11.11.new/drivers/firmware/dell_rbu.c
| --- linux-2.6.11.11.orig/drivers/firmware/dell_rbu.c  1969-12-31 
18:00:00.0 -0600
| +++ linux-2.6.11.11.new/drivers/firmware/dell_rbu.c   2005-06-30 
15:37:27.0 -0500
| @@ -0,0 +1,627 @@
| +/*
| + * dell_rbu.c
| + * Bios Update driver for Dell systems
| + * Author: Dell Inc
| + * Abhay Salunke [EMAIL PROTECTED]
| + *
| + * Copyright (C) 2005 Dell Inc.
| + *
| + * Remote BIOS Update (rbu) driver is used for updating DELL BIOS by 
| + * creating entries in the /sys file systems on Linux 2.6 and higher 
| + * kernels. The driver supports two mechanism to update the BIOS namely 
   mechanisms  BIOS,
| + * contiguous and packetized. Both these methods still require having some
| + * application to set the CMOS bit indicating the BIOS to update itself 
| + * after a reboot.
| + *
| + * Contiguous method:
| + * This driver writes the incoming data in a monolithic image by allocating 
| + * contiguous physical pages large enough to accommodate the incoming BIOS 
| + * image size.  
| + *
| + * Packetized method:
| + * The driver writes the incoming packet image by allocating a new packet 
| + * on every time the packet data is written. This driver requires an 
  each time that the
| + * application to break the BIOS image in to fixed sized packet chunks.
  into
| + *
| + * See Documentation/dell_rbu.txt for more info.
| + *
| + */
| +#include linux/version.h
| +#include linux/config.h
| +#include linux/init.h
| +#include linux/module.h
| +#include linux/string.h
| +#include linux/errno.h
| +#include linux/blkdev.h
| +#include linux/device.h
| +#include linux/spinlock.h
| +#include linux/moduleparam.h
| +#include linux/firmware.h
| +#include linux/dma-mapping.h
| +
| +MODULE_AUTHOR(Abhay Salunke [EMAIL PROTECTED]);
| +MODULE_DESCRIPTION(Driver for updating BIOS image on DELL systems);
| +MODULE_LICENSE(GPL);
| +MODULE_VERSION(1.0);
| +
| +#define BIOS_SCAN_LIMIT 0x

Please remove this, it's not used.

| +#define MAX_IMAGE_LENGTH 16
| +static struct _rbu_data {
| + void *image_update_buffer;
| + unsigned long image_update_buffer_size;
| + unsigned long bios_image_size;
| + spinlock_t lock;
| + unsigned long packet_read_count;
| + unsigned long packet_write_count;
| + unsigned long num_packets;
| + unsigned long packetsize;
| +} rbu_data;
| +
| +static char image_type[MAX_IMAGE_LENGTH] = mono;
| +module_param_string(image_type, image_type, sizeof (image_type), 0);

Why is permission 0?  0 means not visible in sysfs.
But you tested this, so ?

| +MODULE_PARM_DESC(image_type, BIOS image type. choose- mono or packet);
| +
| +struct packet_data {
| + struct list_head list;
| + size_t length;
| + void *data;
| + int ordernum;
| +};
| +
| +static struct packet_data packet_data_head;
| +
| +struct platform_device *rbu_device;
| +int context;
| +static dma_addr_t dell_rbu_dmaaddr;
| +
| +static int
| +fill_last_packet(void *data, size_t length)
| +{
| + struct list_head *ptemp_list;
| + struct packet_data *packet = NULL;
| + int packet_count = 0;
| +
| + pr_debug(fill_last_packet: entry \n);
entry\n  (other places also)
| +
| + if (!rbu_data.num_packets) {
| + pr_debug(fill_last_packet: num_packets=0\n);
| + return -ENOMEM;
| + }
| +
| + packet_count = rbu_data.num_packets;
| +
| + ptemp_list = (packet_data_head.list)-prev;
| +
| + packet = list_entry(ptemp_list, struct packet_data, list);
| +
| + if ((rbu_data.packet_write_count + length)  rbu_data.packetsize) {
| + pr_debug(dell_rbu:%s: packet size data 
| + overrun\n, __FUNCTION__);
| + return -EINVAL;
| + }
| +
| + pr_debug(fill_last_packet : buffer = %p\n, packet-data);
| +
| + memcpy((packet-data + rbu_data.packet_write_count), data, length);
| +
| + if ((rbu_data.packet_write_count + length) == rbu_data.packetsize) {
| + /*
| +  * this was the last data chunk in the packet
| +  * so reinitialize the packet data counter to zero
| +  */
| + rbu_data.packet_write_count = 0;
| + } else
| + rbu_data.packet_write_count += length;
| +
| + 

[PATCH] feature-removal-schedule corrections

2005-07-07 Thread randy_dunlap

From: Randy Dunlap <[EMAIL PROTECTED]>

Correct email address and a small typo.

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>

diffstat:=
 Documentation/feature-removal-schedule.txt |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff -Naurp linux-2613-rc2/Documentation/feature-removal-schedule.txt~doc-fixes 
linux-2613-rc2/Documentation/feature-removal-schedule.txt
--- linux-2613-rc2/Documentation/feature-removal-schedule.txt~doc-fixes 
2005-07-07 14:46:18.0 -0700
+++ linux-2613-rc2/Documentation/feature-removal-schedule.txt   2005-07-07 
15:05:06.0 -0700
@@ -39,7 +39,7 @@ When: September 2005
 Why:   Replaced by io_remap_pfn_range() which allows more memory space
addressabilty (by using a pfn) and supports sparc & sparc64
iospace as part of the pfn.
-Who:   Randy Dunlap <[EMAIL PROTECTED]>
+Who:   Randy Dunlap <[EMAIL PROTECTED]>
 
 ---
 
@@ -54,7 +54,7 @@ Who:  Adrian Bunk <[EMAIL PROTECTED]>
 What:  register_ioctl32_conversion() / unregister_ioctl32_conversion()
 When:  April 2005
 Why:   Replaced by ->compat_ioctl in file_operations and other method
-   vecors.
+   vectors.
 Who:   Andi Kleen <[EMAIL PROTECTED]>, Christoph Hellwig <[EMAIL PROTECTED]>
 
 ---

---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] scripts/kernel-doc: don't use uninitialized SRCTREE

2005-07-07 Thread randy_dunlap

From: Randy Dunlap <[EMAIL PROTECTED]>

Current kernel-doc (perl) script generates this warning:
Use of uninitialized value in concatenation (.) or string at scripts/kernel-doc 
line 1668.

so explicitly check for SRCTREE in the ENV before using it,
and then if it is set, append a '/' to the end of it, otherwise
the SRCTREE + filename can (will) be missing the intermediate '/'.

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>

diffstat:=
 scripts/kernel-doc |8 +++-
 1 files changed, 7 insertions(+), 1 deletion(-)

diff -Naurp linux-2613-rc2/scripts/kernel-doc~kernel-doc-srctree 
linux-2613-rc2/scripts/kernel-doc
--- linux-2613-rc2/scripts/kernel-doc~kernel-doc-srctree2005-06-17 
12:48:29.0 -0700
+++ linux-2613-rc2/scripts/kernel-doc   2005-07-07 14:33:01.0 -0700
@@ -1665,11 +1665,17 @@ sub xml_escape($) {
 }
 
 sub process_file($) {
-my ($file) = "$ENV{'SRCTREE'[EMAIL PROTECTED]";
+my $file;
 my $identifier;
 my $func;
 my $initial_section_counter = $section_counter;
 
+if (defined($ENV{'SRCTREE'})) {
+   $file = "$ENV{'SRCTREE'}" . "/" . "@_";
+}
+else {
+   $file = "@_";
+}
 if (defined($source_map{$file})) {
$file = $source_map{$file};
 }

---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] kernel/acct: add kerneldoc

2005-07-07 Thread randy_dunlap

From: Randy Dunlap <[EMAIL PROTECTED]>

for kernel/acct.c:
- fix typos
- add kerneldoc for non-static functions

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>

diffstat:=
 kernel/acct.c |   43 +++
 1 files changed, 27 insertions(+), 16 deletions(-)

diff -Naurp linux-2613-rc1-git5/kernel/acct.c~kdoc_kernel_acct 
linux-2613-rc1-git5/kernel/acct.c
--- linux-2613-rc1-git5/kernel/acct.c~kdoc_kernel_acct  2005-06-17 
12:48:29.0 -0700
+++ linux-2613-rc1-git5/kernel/acct.c   2005-07-06 12:01:40.0 -0700
@@ -165,7 +165,7 @@ out:
 }
 
 /*
- * Close the old accouting file (if currently open) and then replace
+ * Close the old accounting file (if currently open) and then replace
  * it with file (if non-NULL).
  *
  * NOTE: acct_globals.lock MUST be held on entry and exit.
@@ -199,11 +199,16 @@ static void acct_file_reopen(struct file
}
 }
 
-/*
- *  sys_acct() is the only system call needed to implement process
- *  accounting. It takes the name of the file where accounting records
- *  should be written. If the filename is NULL, accounting will be
- *  shutdown.
+/**
+ * sys_acct - enable/disable process accounting
+ * @name: file name for accounting records or NULL to shutdown accounting
+ *
+ * Returns 0 for success or negative errno values for failure.
+ *
+ * sys_acct() is the only system call needed to implement process
+ * accounting. It takes the name of the file where accounting records
+ * should be written. If the filename is NULL, accounting will be
+ * shutdown.
  */
 asmlinkage long sys_acct(const char __user *name)
 {
@@ -250,9 +255,12 @@ asmlinkage long sys_acct(const char __us
return (0);
 }
 
-/*
- * If the accouting is turned on for a file in the filesystem pointed
- * to by sb, turn accouting off.
+/**
+ * acct_auto_close - turn off a filesystem's accounting if it is on
+ * @sb: super block for the filesystem
+ *
+ * If the accounting is turned on for a file in the filesystem pointed
+ * to by sb, turn accounting off.
  */
 void acct_auto_close(struct super_block *sb)
 {
@@ -503,8 +511,11 @@ static void do_acct_process(long exitcod
set_fs(fs);
 }
 
-/*
+/**
  * acct_process - now just a wrapper around do_acct_process
+ * @exitcode: task exit code
+ *
+ * handles process accounting for an exiting task
  */
 void acct_process(long exitcode)
 {
@@ -530,9 +541,9 @@ void acct_process(long exitcode)
 }
 
 
-/*
- * acct_update_integrals
- *-  update mm integral fields in task_struct
+/**
+ * acct_update_integrals - update mm integral fields in task_struct
+ * @tsk: task_struct for accounting
  */
 void acct_update_integrals(struct task_struct *tsk)
 {
@@ -547,9 +558,9 @@ void acct_update_integrals(struct task_s
}
 }
 
-/*
- * acct_clear_integrals
- *- clear the mm integral fields in task_struct
+/**
+ * acct_clear_integrals - clear the mm integral fields in task_struct
+ * @tsk: task_struct whose accounting fields are cleared
  */
 void acct_clear_integrals(struct task_struct *tsk)
 {

---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: PPP/PPPoE/PPPoX

2005-07-07 Thread randy_dunlap
On Thu, 07 Jul 2005 11:35:33 -0500 Neal Schilling wrote:

| I've been digging around for quite a while and finally hoped that 
| someone here may be able to help me out. In the 2.6.12 kernel, 
| if_pppox.h changed a few items. I wanted to know if there is someone in 
| particular who maintains that particular area of the kernel, and an 
| email address for them.
| 
| Thanks,
| 
| Neal Schilling
| 
| PS:
| I'm not subscribed to this list. Please be sure to CC me with any replies.

The linux/MAINTAINERS file says:

PPP PROTOCOL DRIVERS AND COMPRESSORS
P:  Paul Mackerras
M:  [EMAIL PROTECTED]
L:  linux-ppp@vger.kernel.org
S:  Maintained

PPP OVER ATM (RFC 2364)
P:  Mitchell Blank Jr
M:  [EMAIL PROTECTED]
S:  Maintained

PPP OVER ETHERNET
P:  Michal Ostrowski
M:  [EMAIL PROTECTED]
S:  Maintained

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] joydev.c: Digital joysticks on analog ports

2005-07-07 Thread randy_dunlap
On Thu, 7 Jul 2005 14:06:07 +0200 Vojtech Pavlik wrote:

| On Thu, Jul 07, 2005 at 01:14:58PM +0200, Thomas Richter wrote:
| > 
| > Hi folks, hi Vojtech,
| > 
| > the following is a patch to drivers/input/joydev.c and
| > include/linux/joystick.h that allows you to connect the "traditional"
| > digital joysticks for C64, Atari, Amiga... on analog input ports by
| > means of a minimalistic self- made adapter board ("ElCheapo",
| > schematics below). The patch converts the digital inputs to suitable
| > "analog" versions that are interpreted fine. The patch "as is" applies
| > to kernel 2.4.31, but it should work for other kernel versions as
| > well.
| > 
| > New kernel parameters for joydev: "digital = 1" sets all default input
| > modes to "digital" instead of analog.
| > 
| > The new ioctl JSIOCSDIGITAL for joydev allows to adjusts this
| > on the running driver.
| 
| Sorry, I have to reject this patch. 
| 
| First, you added support for the adapter to the wrong file - if
| anywhere, the logic should be either inside analog.c, or in a separate
| driver, which would be probably better.
| 
| Second, the 2.4 input layer is in bugfix-only mode now. Any new features
| can go only into 2.6.
| 
| Third - the ElCheapo interface is totally ugly. With just a few more
| component a real convertor, working as a real joystick is possible.
| 
| Fourth - we already have three drivers for these joystick (db9, gamecon
| and turbografx), all connected via trivial circuits to the parallel
| port.

5.  Fix indentation.

6.  Don't init static data to 0.


| > Greetings,
| > Thomas Richter
| > 
| > Patch for drivers/input/joydev.c:
| > 
| > /* snip */
| > 
| > --- ../linux-2.4.31/drivers/input/joydev.c  2003-06-13 16:51:34.0 
+0200
| > +++ drivers/input/joydev.c  2005-07-06 22:37:21.0 +0200
| > @@ -65,6 +65,7 @@
| > struct JS_DATA_SAVE_TYPE glue;
| > int nabs;
| > int nkey;
| > +int digital;
| > __u16 keymap[KEY_MAX - BTN_MISC];
| > __u16 keypam[KEY_MAX - BTN_MISC];
| > __u8 absmap[ABS_MAX];
| > @@ -84,6 +85,11 @@
| >  
| >  static struct joydev *joydev_table[JOYDEV_MINORS];
| >  
| > +static int digital = 0;
| > +
| > +MODULE_PARM(digital,"i");
| > +MODULE_PARM_DESC(digital,"if 1, handle digital joysticks via the 
'ElCheapo' interface");
| > +
| >  MODULE_AUTHOR("Vojtech Pavlik <[EMAIL PROTECTED]>");
| >  MODULE_DESCRIPTION("Joystick device driver");
| >  MODULE_LICENSE("GPL");
| > @@ -109,13 +115,68 @@
| > return value;
| >  }
| >  
| > +static int joydev_digital_event(struct js_event *ev,struct input_handle 
*handle,unsigned int type,
| > +   unsigned int code, int value)
| > +{
| > +  struct joydev *joydev = handle->private;
| > +
| > +  switch(type) {
| > +  case EV_KEY:
| > +if (code < BTN_MISC || value == 2) return 0;
| > +code = joydev->keymap[code - BTN_MISC];
| > +switch(code) {
| > +case 0:
| > +  ev->type   = JS_EVENT_AXIS;
| > +  ev->number = 1;
| > +  ev->value  = (value)?+32767:0;
| > +  break;
| > +case 1:
| > +  ev->type   = JS_EVENT_AXIS;
| > +  ev->number = 0;
| > +  ev->value  = (value)?+32767:0;
| > +  break;
| > +case 2:
| > +  ev->type   = JS_EVENT_AXIS;
| > +  ev->number = 1;
| > +  ev->value  = (value)?-32767:0;
| > +  break;
| > +case 3:
| > +  ev->type   = JS_EVENT_AXIS;
| > +  ev->number = 0;
| > +  ev->value  = (value)?-32767:0;
| > +  break;
| > +default:
| > +  ev->type   = JS_EVENT_BUTTON;
| > +  ev->number = code;
| > +  ev->value  = value;
| > +}
| > +break;
| > +  case EV_ABS:
| > +if (joydev->absmap[code] == 0) {
| > +  ev->type   = JS_EVENT_BUTTON;
| > +  ev->number = 0;
| > +  if (joydev_correct(value, joydev->corr) >= 16384)
| > +   ev->value = 1;
| > +  else
| > +   ev->value = 0;
| > +} else return 0;
| > +break;
| > +  default:
| > +return 0;
| > +  }
| > +  return 1;
| > +}
| > +
| >  static void joydev_event(struct input_handle *handle, unsigned int type, 
unsigned int code, int value)
| >  {
| > struct joydev *joydev = handle->private;
| > struct joydev_list *list = joydev->list;
| > struct js_event event;
| >  
| > -   switch (type) {
| > +   if (joydev->digital) {
| > + if (joydev_digital_event(,handle,type,code,value) == 0)
| > +   return;
| > +   } else switch (type) {
| >  
| > case EV_KEY:
| > if (code < BTN_MISC || value == 2) return;
| > @@ -382,6 +443,8 @@
| > joydev->absmap[joydev->abspam[i]] = i;
| > }
| > return 0;
| > +   case JSIOCSDIGITAL:
| > +   return get_user(joydev->digital, (__u8 *)arg);
| > case JSIOCGAXMAP:
| > return copy_to_user((__u8 *) arg, joydev->abspam,
| > sizeof(__u8) * ABS_MAX) ? 
-EFAULT : 0;
| > @@ -450,6 

Re: [PATCH] joydev.c: Digital joysticks on analog ports

2005-07-07 Thread randy_dunlap
On Thu, 7 Jul 2005 14:06:07 +0200 Vojtech Pavlik wrote:

| On Thu, Jul 07, 2005 at 01:14:58PM +0200, Thomas Richter wrote:
|  
|  Hi folks, hi Vojtech,
|  
|  the following is a patch to drivers/input/joydev.c and
|  include/linux/joystick.h that allows you to connect the traditional
|  digital joysticks for C64, Atari, Amiga... on analog input ports by
|  means of a minimalistic self- made adapter board (ElCheapo,
|  schematics below). The patch converts the digital inputs to suitable
|  analog versions that are interpreted fine. The patch as is applies
|  to kernel 2.4.31, but it should work for other kernel versions as
|  well.
|  
|  New kernel parameters for joydev: digital = 1 sets all default input
|  modes to digital instead of analog.
|  
|  The new ioctl JSIOCSDIGITAL for joydev allows to adjusts this
|  on the running driver.
| 
| Sorry, I have to reject this patch. 
| 
| First, you added support for the adapter to the wrong file - if
| anywhere, the logic should be either inside analog.c, or in a separate
| driver, which would be probably better.
| 
| Second, the 2.4 input layer is in bugfix-only mode now. Any new features
| can go only into 2.6.
| 
| Third - the ElCheapo interface is totally ugly. With just a few more
| component a real convertor, working as a real joystick is possible.
| 
| Fourth - we already have three drivers for these joystick (db9, gamecon
| and turbografx), all connected via trivial circuits to the parallel
| port.

5.  Fix indentation.

6.  Don't init static data to 0.


|  Greetings,
|  Thomas Richter
|  
|  Patch for drivers/input/joydev.c:
|  
|  /* snip */
|  
|  --- ../linux-2.4.31/drivers/input/joydev.c  2003-06-13 16:51:34.0 
+0200
|  +++ drivers/input/joydev.c  2005-07-06 22:37:21.0 +0200
|  @@ -65,6 +65,7 @@
|  struct JS_DATA_SAVE_TYPE glue;
|  int nabs;
|  int nkey;
|  +int digital;
|  __u16 keymap[KEY_MAX - BTN_MISC];
|  __u16 keypam[KEY_MAX - BTN_MISC];
|  __u8 absmap[ABS_MAX];
|  @@ -84,6 +85,11 @@
|   
|   static struct joydev *joydev_table[JOYDEV_MINORS];
|   
|  +static int digital = 0;
|  +
|  +MODULE_PARM(digital,i);
|  +MODULE_PARM_DESC(digital,if 1, handle digital joysticks via the 
'ElCheapo' interface);
|  +
|   MODULE_AUTHOR(Vojtech Pavlik [EMAIL PROTECTED]);
|   MODULE_DESCRIPTION(Joystick device driver);
|   MODULE_LICENSE(GPL);
|  @@ -109,13 +115,68 @@
|  return value;
|   }
|   
|  +static int joydev_digital_event(struct js_event *ev,struct input_handle 
*handle,unsigned int type,
|  +   unsigned int code, int value)
|  +{
|  +  struct joydev *joydev = handle-private;
|  +
|  +  switch(type) {
|  +  case EV_KEY:
|  +if (code  BTN_MISC || value == 2) return 0;
|  +code = joydev-keymap[code - BTN_MISC];
|  +switch(code) {
|  +case 0:
|  +  ev-type   = JS_EVENT_AXIS;
|  +  ev-number = 1;
|  +  ev-value  = (value)?+32767:0;
|  +  break;
|  +case 1:
|  +  ev-type   = JS_EVENT_AXIS;
|  +  ev-number = 0;
|  +  ev-value  = (value)?+32767:0;
|  +  break;
|  +case 2:
|  +  ev-type   = JS_EVENT_AXIS;
|  +  ev-number = 1;
|  +  ev-value  = (value)?-32767:0;
|  +  break;
|  +case 3:
|  +  ev-type   = JS_EVENT_AXIS;
|  +  ev-number = 0;
|  +  ev-value  = (value)?-32767:0;
|  +  break;
|  +default:
|  +  ev-type   = JS_EVENT_BUTTON;
|  +  ev-number = code;
|  +  ev-value  = value;
|  +}
|  +break;
|  +  case EV_ABS:
|  +if (joydev-absmap[code] == 0) {
|  +  ev-type   = JS_EVENT_BUTTON;
|  +  ev-number = 0;
|  +  if (joydev_correct(value, joydev-corr) = 16384)
|  +   ev-value = 1;
|  +  else
|  +   ev-value = 0;
|  +} else return 0;
|  +break;
|  +  default:
|  +return 0;
|  +  }
|  +  return 1;
|  +}
|  +
|   static void joydev_event(struct input_handle *handle, unsigned int type, 
unsigned int code, int value)
|   {
|  struct joydev *joydev = handle-private;
|  struct joydev_list *list = joydev-list;
|  struct js_event event;
|   
|  -   switch (type) {
|  +   if (joydev-digital) {
|  + if (joydev_digital_event(event,handle,type,code,value) == 0)
|  +   return;
|  +   } else switch (type) {
|   
|  case EV_KEY:
|  if (code  BTN_MISC || value == 2) return;
|  @@ -382,6 +443,8 @@
|  joydev-absmap[joydev-abspam[i]] = i;
|  }
|  return 0;
|  +   case JSIOCSDIGITAL:
|  +   return get_user(joydev-digital, (__u8 *)arg);
|  case JSIOCGAXMAP:
|  return copy_to_user((__u8 *) arg, joydev-abspam,
|  sizeof(__u8) * ABS_MAX) ? 
-EFAULT : 0;
|  @@ -450,6 +513,7 @@
|  joydev-handle.private = joydev;
|   
|  joydev-exist = 1;
|  +   joydev-digital = digital;
|   
|  for (i = 0; i  ABS_MAX; i++)
|  if 

Re: PPP/PPPoE/PPPoX

2005-07-07 Thread randy_dunlap
On Thu, 07 Jul 2005 11:35:33 -0500 Neal Schilling wrote:

| I've been digging around for quite a while and finally hoped that 
| someone here may be able to help me out. In the 2.6.12 kernel, 
| if_pppox.h changed a few items. I wanted to know if there is someone in 
| particular who maintains that particular area of the kernel, and an 
| email address for them.
| 
| Thanks,
| 
| Neal Schilling
| 
| PS:
| I'm not subscribed to this list. Please be sure to CC me with any replies.

The linux/MAINTAINERS file says:

PPP PROTOCOL DRIVERS AND COMPRESSORS
P:  Paul Mackerras
M:  [EMAIL PROTECTED]
L:  linux-ppp@vger.kernel.org
S:  Maintained

PPP OVER ATM (RFC 2364)
P:  Mitchell Blank Jr
M:  [EMAIL PROTECTED]
S:  Maintained

PPP OVER ETHERNET
P:  Michal Ostrowski
M:  [EMAIL PROTECTED]
S:  Maintained

---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] kernel/acct: add kerneldoc

2005-07-07 Thread randy_dunlap

From: Randy Dunlap [EMAIL PROTECTED]

for kernel/acct.c:
- fix typos
- add kerneldoc for non-static functions

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]

diffstat:=
 kernel/acct.c |   43 +++
 1 files changed, 27 insertions(+), 16 deletions(-)

diff -Naurp linux-2613-rc1-git5/kernel/acct.c~kdoc_kernel_acct 
linux-2613-rc1-git5/kernel/acct.c
--- linux-2613-rc1-git5/kernel/acct.c~kdoc_kernel_acct  2005-06-17 
12:48:29.0 -0700
+++ linux-2613-rc1-git5/kernel/acct.c   2005-07-06 12:01:40.0 -0700
@@ -165,7 +165,7 @@ out:
 }
 
 /*
- * Close the old accouting file (if currently open) and then replace
+ * Close the old accounting file (if currently open) and then replace
  * it with file (if non-NULL).
  *
  * NOTE: acct_globals.lock MUST be held on entry and exit.
@@ -199,11 +199,16 @@ static void acct_file_reopen(struct file
}
 }
 
-/*
- *  sys_acct() is the only system call needed to implement process
- *  accounting. It takes the name of the file where accounting records
- *  should be written. If the filename is NULL, accounting will be
- *  shutdown.
+/**
+ * sys_acct - enable/disable process accounting
+ * @name: file name for accounting records or NULL to shutdown accounting
+ *
+ * Returns 0 for success or negative errno values for failure.
+ *
+ * sys_acct() is the only system call needed to implement process
+ * accounting. It takes the name of the file where accounting records
+ * should be written. If the filename is NULL, accounting will be
+ * shutdown.
  */
 asmlinkage long sys_acct(const char __user *name)
 {
@@ -250,9 +255,12 @@ asmlinkage long sys_acct(const char __us
return (0);
 }
 
-/*
- * If the accouting is turned on for a file in the filesystem pointed
- * to by sb, turn accouting off.
+/**
+ * acct_auto_close - turn off a filesystem's accounting if it is on
+ * @sb: super block for the filesystem
+ *
+ * If the accounting is turned on for a file in the filesystem pointed
+ * to by sb, turn accounting off.
  */
 void acct_auto_close(struct super_block *sb)
 {
@@ -503,8 +511,11 @@ static void do_acct_process(long exitcod
set_fs(fs);
 }
 
-/*
+/**
  * acct_process - now just a wrapper around do_acct_process
+ * @exitcode: task exit code
+ *
+ * handles process accounting for an exiting task
  */
 void acct_process(long exitcode)
 {
@@ -530,9 +541,9 @@ void acct_process(long exitcode)
 }
 
 
-/*
- * acct_update_integrals
- *-  update mm integral fields in task_struct
+/**
+ * acct_update_integrals - update mm integral fields in task_struct
+ * @tsk: task_struct for accounting
  */
 void acct_update_integrals(struct task_struct *tsk)
 {
@@ -547,9 +558,9 @@ void acct_update_integrals(struct task_s
}
 }
 
-/*
- * acct_clear_integrals
- *- clear the mm integral fields in task_struct
+/**
+ * acct_clear_integrals - clear the mm integral fields in task_struct
+ * @tsk: task_struct whose accounting fields are cleared
  */
 void acct_clear_integrals(struct task_struct *tsk)
 {

---
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] scripts/kernel-doc: don't use uninitialized SRCTREE

2005-07-07 Thread randy_dunlap

From: Randy Dunlap [EMAIL PROTECTED]

Current kernel-doc (perl) script generates this warning:
Use of uninitialized value in concatenation (.) or string at scripts/kernel-doc 
line 1668.

so explicitly check for SRCTREE in the ENV before using it,
and then if it is set, append a '/' to the end of it, otherwise
the SRCTREE + filename can (will) be missing the intermediate '/'.

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]

diffstat:=
 scripts/kernel-doc |8 +++-
 1 files changed, 7 insertions(+), 1 deletion(-)

diff -Naurp linux-2613-rc2/scripts/kernel-doc~kernel-doc-srctree 
linux-2613-rc2/scripts/kernel-doc
--- linux-2613-rc2/scripts/kernel-doc~kernel-doc-srctree2005-06-17 
12:48:29.0 -0700
+++ linux-2613-rc2/scripts/kernel-doc   2005-07-07 14:33:01.0 -0700
@@ -1665,11 +1665,17 @@ sub xml_escape($) {
 }
 
 sub process_file($) {
-my ($file) = $ENV{'SRCTREE'[EMAIL PROTECTED];
+my $file;
 my $identifier;
 my $func;
 my $initial_section_counter = $section_counter;
 
+if (defined($ENV{'SRCTREE'})) {
+   $file = $ENV{'SRCTREE'} . / . @_;
+}
+else {
+   $file = @_;
+}
 if (defined($source_map{$file})) {
$file = $source_map{$file};
 }

---
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] feature-removal-schedule corrections

2005-07-07 Thread randy_dunlap

From: Randy Dunlap [EMAIL PROTECTED]

Correct email address and a small typo.

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]

diffstat:=
 Documentation/feature-removal-schedule.txt |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff -Naurp linux-2613-rc2/Documentation/feature-removal-schedule.txt~doc-fixes 
linux-2613-rc2/Documentation/feature-removal-schedule.txt
--- linux-2613-rc2/Documentation/feature-removal-schedule.txt~doc-fixes 
2005-07-07 14:46:18.0 -0700
+++ linux-2613-rc2/Documentation/feature-removal-schedule.txt   2005-07-07 
15:05:06.0 -0700
@@ -39,7 +39,7 @@ When: September 2005
 Why:   Replaced by io_remap_pfn_range() which allows more memory space
addressabilty (by using a pfn) and supports sparc  sparc64
iospace as part of the pfn.
-Who:   Randy Dunlap [EMAIL PROTECTED]
+Who:   Randy Dunlap [EMAIL PROTECTED]
 
 ---
 
@@ -54,7 +54,7 @@ Who:  Adrian Bunk [EMAIL PROTECTED]
 What:  register_ioctl32_conversion() / unregister_ioctl32_conversion()
 When:  April 2005
 Why:   Replaced by -compat_ioctl in file_operations and other method
-   vecors.
+   vectors.
 Who:   Andi Kleen [EMAIL PROTECTED], Christoph Hellwig [EMAIL PROTECTED]
 
 ---

---
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: bios interaction with linux kernel after uncompression.

2005-07-06 Thread randy_dunlap
On Wed, 6 Jul 2005 12:02:26 +0530 Bhagyashri Bijwe wrote:

| Hi,
|  During bootstrapping,  bios provides services like video ,hard
| drive services, memory sizing, PCI table to linux kernel.
|  After uncompression of kernel , Does linux kernel have any
| interaction with bios?
| I know that most of work is done by linux device driver. 
| What is dependency of running linux on bios ?
|   Thanks in advance,

As little as possible after boot/init.

That means that BIOS is used for APM mode selections
if APM is being used and for ACPI state-switching.
Oh, I guess we have to acknowledge that hidden SMI code
also, but Linux doesn't use it AFAIK, it's just there
and being executed.

Those are all that I know of before being fully awake.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Fix posix_bump_timer args

2005-07-06 Thread randy_dunlap
On Wed, 06 Jul 2005 11:26:31 -0700 Geoff Levand wrote:

| This patch makes posix_bump_timer() consistent with common convention 
| by expecting a pointer to the structure be passed.
| 
| Please apply.

Does it matter other than for consistency?

E.g., in a large system with thousands of timers, it seems that it
could (at least theoretically) have a negative impact by using a
pointer dereference instead of a known fixed address.
or am I just imagining that?

Thanks,
~Randy

| Signed-off-by: Geoff Levand <[EMAIL PROTECTED]> for CELF
| 
| --
| --- linux-2.6.12.1.orig/include/linux/posix-timers.h  2005-06-17 
12:48:29.0 -0700
| +++ linux-2.6.12.1/include/linux/posix-timers.h.bump  2005-07-06 
10:58:52.0 -0700
| @@ -108,7 +108,7 @@
|  #define posix_bump_timer(timr, now)  \
|   do {
\
|long delta, orun;  
\
| -   delta = now.jiffies - (timr)->it.real.timer.expires;  \
| +   delta = (now)->jiffies - (timr)->it.real.timer.expires;   \
|if (delta >= 0) {  
\
|  orun = 1 + (delta / (timr)->it.real.incr);   \
| (timr)->it.real.timer.expires +=  \
| 
| --- linux-2.6.12.1.orig/kernel/posix-timers.c 2005-06-17 12:48:29.0 
-0700
| +++ linux-2.6.12.1/kernel/posix-timers.c.bump 2005-07-06 10:54:48.0 
-0700
| @@ -384,11 +384,11 @@
|   spin_lock(_list.lock);
|   add_clockset_delta(timr, _wall_to);
|  
| - posix_bump_timer(timr, now);
| + posix_bump_timer(timr, );
|  
|   spin_unlock(_list.lock);
|   } else {
| - posix_bump_timer(timr, now);
| + posix_bump_timer(timr, );
|   }
|   timr->it_overrun_last = timr->it_overrun;
|   timr->it_overrun = -1;
| @@ -810,7 +810,7 @@
|   if (expires) {
|   if (timr->it_requeue_pending & REQUEUE_PENDING ||
|   (timr->it_sigev_notify & ~SIGEV_THREAD_ID) == SIGEV_NONE) {
| - posix_bump_timer(timr, now);
| + posix_bump_timer(timr, );
|   expires = timr->it.real.timer.expires;
|   }
|   else
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Documentation fixes

2005-07-06 Thread randy_dunlap
On Wed, 06 Jul 2005 16:12:11 -0700 Daniel Walker wrote:

| 
| I noticed some typo's or mis-thoughts .. Here are my corrections. I
| tried to CC all the authors.

Yes, mostly good corrections.  Here are more on top of yours.

Thanks,
~Randy


| Index: linux-2.6.12/Documentation/watchdog/watchdog.txt
| ===
| --- linux-2.6.12.orig/Documentation/watchdog/watchdog.txt 2005-06-17 
19:48:29.0 +
| +++ linux-2.6.12/Documentation/watchdog/watchdog.txt  2005-07-03 
18:12:40.0 +
| @@ -18,12 +18,12 @@ The following watchdog drivers are curre
|  All six interfaces provide /dev/watchdog, which when open must be written
|  to within a timeout or the machine will reboot. Each write delays the reboot
|  time another timeout. In the case of the software watchdog the ability to 
| -reboot will depend on the state of the machines and interrupts. The hardware
| +reboot will depend on the state of the machine and interrupts. The hardware
|  boards physically pull the machine down off their own onboard timers and
|  will reboot from almost anything.
|  
|  A second temperature monitoring interface is available on the WDT501P cards
| -and some Berkshire cards. This provides /dev/temperature. This is the 
machine 
| +and some Berkshire cards. This provides /dev/temperature. This is the 
machines 
 
machine's
  (and kill the trailing space)

|  internal temperature in degrees Fahrenheit. Each read returns a single byte 
|  giving the temperature.
|  
| @@ -37,16 +37,16 @@ The wdt card cannot be safely probed for
|  wdt=ioaddr,irq as a boot parameter - eg "wdt=0x240,11".
|  
|  The SA1100 watchdog module can be configured with the "sa1100_margin"
| -commandline argument which specifies timeout value in seconds.
| +commandline argument which specifies the timeout value in seconds.
|  
|  The i810 TCO watchdog modules can be configured with the "i810_margin"
| -commandline argument which specifies the counter initial value. The counter
| -is decremented every 0.6 seconds and default to 50 (30 seconds). Values can
| +commandline argument which specifies the counters initial value. The counter
counter's
| +is decremented every 0.6 seconds and defaults to 50 (30 seconds). Values can
|  range between 3 and 63.
|  
|  The i810 TCO watchdog driver also implements the WDIOC_GETSTATUS and
|  WDIOC_GETBOOTSTATUS ioctl()s. WDIOC_GETSTATUS returns the actual counter 
value
| -and WDIOC_GETBOOTSTATUS returns the value of TCO2 Status Register (see 
Intel's
| +and WDIOC_GETBOOTSTATUS returns the value of the TCO2 Status Register (see 
Intel's

Please wrap lines at < 80 characters per line.

|  documentation for the 82801AA and 82801AB datasheet). 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: audit function doc. question

2005-07-06 Thread randy_dunlap
On Wed, 6 Jul 2005 15:21:15 -0700 Chris Wright wrote:

| * randy_dunlap ([EMAIL PROTECTED]) wrote:
| > kernel/audit.c (2.6.13-rc1-git5) audit_log_start() says:
| > 
| > /* Obtain an audit buffer.  This routine does locking to obtain the
| >  * audit buffer, but then no locking is required for calls to
| >  * audit_log_*format.  If the tsk is a task that is currently in a
| >  * syscall, then the syscall is marked as auditable and an audit record
| >  * will be written at syscall exit.  If there is no associated task, tsk
| >  * should be NULL. */
| > struct audit_buffer *audit_log_start(struct audit_context *ctx, int type)
| > {
| > 
| > What does  refer to in the function description?
| > There is no  in this function.
| 
| It refers to tsk, tsk, stale comment.  It's task->audit_context (which is
| ctx there).  Interested in preparing a patch, could even move to proper
| kerneldoc format ;-)

Yes, that's why I asked, I'm adding kerneldoc format comments
to audit*.c (2 files).  You'll see it soon.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Patch of a new driver for kernel 2.4.x that need review

2005-07-06 Thread randy_dunlap
On Wed, 6 Jul 2005 14:14:44 -0700 Mark Gross wrote:

| On Wednesday 22 June 2005 08:12, Bouchard, Sebastien wrote:
| > Hi,
| >
| > Here is a driver (only for 2.4.x) I've done to provide support of a
| > hardware module (available on some ATCA board) used with telecom expension
| > card on the new ATCA platform. This module provide redundant reference
| > clock for telecom hardware with alarm handling when there is a new event
| > (ex.: one of the ref clock is gone).
| > This char driver provide IOCTL for configuration of this module and
| > interrupt handler for processing alarm events.
| >
| > I send this driver so people in this mailing list can do a review of the
| > code.
| >
| > Please reply me directly to my email, i'm not subscribed to the mailing
| > list.
| >
| > Thanks
| > Sebastien Bouchard
| > Software designer
| > Kontron Canada Inc.
| > 
| > 
| 
| I'm helping out a bit with the maintaining of this driver for Sebastien.  
| The following is a 2.6.12 port of Sebastien's 2.4 driver.  

I'd be surprised if Marcelo was taking new drivers for 2.4.x.

2.6.x driver comments below.

| diff -urN -X dontdiff_osdl vanilla/linux-2.6.12/drivers/char/Kconfig 
linux-2.6.12/drivers/char/Kconfig
| --- vanilla/linux-2.6.12/drivers/char/Kconfig 2005-06-17 12:48:29.0 
-0700
| +++ linux-2.6.12/drivers/char/Kconfig 2005-07-06 13:25:18.585951744 -0700
| @@ -998,5 +998,16 @@
|  
|  source "drivers/char/tpm/Kconfig"
|  
| +config TELCLOCK
| + tristate "Telecom clock driver for ATCA"
| + depends on EXPERIMENTAL
| + default n
| + help
| +   The telecom clock device allows direct userspace access to the
| +   configuration of the telecom clock configuration settings.
| +   This device is used for hardware synchronization across the ATCA
| +   back plane fabric.

usually:  backplane

| +
| +

Just 1 blank line, please.

|  endmenu
|  

| diff -urN -X dontdiff_osdl vanilla/linux-2.6.12/drivers/char/tlclk.c 
linux-2.6.12/drivers/char/tlclk.c
| --- vanilla/linux-2.6.12/drivers/char/tlclk.c 1969-12-31 16:00:00.0 
-0800
| +++ linux-2.6.12/drivers/char/tlclk.c 2005-07-06 13:25:18.600949464 -0700
| @@ -0,0 +1,447 @@
| +/*
| + * Telecom Clock driver for Wainwright board
| + *
| + * Copyright (C) 2005 Kontron Canada
| + *
| + * All rights reserved.
| + *
| + * This program is free software; you can redistribute it and/or modify
| + * it under the terms of the GNU General Public License as published by
| + * the Free Software Foundation; either version 2 of the License, or (at
| + * your option) any later version.
| + *
| + * This program is distributed in the hope that it will be useful, but
| + * WITHOUT ANY WARRANTY; without even the implied warranty of
| + * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
| + * NON INFRINGEMENT.  See the GNU General Public License for more
| + * details.
| + *
| + * You should have received a copy of the GNU General Public License
| + * along with this program; if not, write to the Free Software
| + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
| + *
| + * Send feedback to <[EMAIL PROTECTED]>
| + *
| + * Description : This is the TELECOM CLOCK module driver for the ATCA 
platform.
| + */
| +#ifndef __KERNEL__
| +#  define __KERNEL__
| +#endif

Not needed.

| +
| +#include 
| +#include 
| +#include 
| +#include 
| +#include /* printk() */
| +#include /* everything... */
| +#include  /* error codes */
| +#include  /* udelay */
| +#include 

Try to put all  includes after the  includes
unless it's not possible for some reason.

| +#include 
| +#include 
| +#include/* Devfs support */

Devfs is being removed this month...

| +#include 
| +#include 
| +#include 
| +#include   /* inb/outb */
| +
| +#include "tlclk.h"   /* TELECOM IOCTL DEFINE */
| +
| +MODULE_AUTHOR("Sebastien Bouchard <[EMAIL PROTECTED]>");
| +MODULE_LICENSE("GPL");
| +
| +/* Telecom clock I/O register definition */
| +#define TLCLK_BASE 0xa08
| +#define TLCLK_REG0 TLCLK_BASE
| +#define TLCLK_REG1 (TLCLK_BASE+1)
| +#define TLCLK_REG2 (TLCLK_BASE+2)
| +#define TLCLK_REG3 (TLCLK_BASE+3)
| +#define TLCLK_REG4 (TLCLK_BASE+4)
| +#define TLCLK_REG5 (TLCLK_BASE+5)
| +#define TLCLK_REG6 (TLCLK_BASE+6)
| +#define TLCLK_REG7 (TLCLK_BASE+7)
| +
| +#define SET_PORT_BITS(port, mask, val) outb(((inb(port) & mask) | val), port)
| +
| +/* 0 = Dynamic allocation of the major device number */
| +#define TLCLK_MAJOR 252
| +
| +/* Contain the interrupt used for telecom clock */

eh?  contains?  this is self-evident, drop it.

| +static unsigned int telclk_interrupt;
| +
| +static int int_events;   /* Event that generate a interrupt */
| +static int got_event;/* if events processing have been done 
*/
| +
| +static struct timer_list switchover_timer;
| +
| +struct tlclk_alarms *alarm_events;
| +
| +spinlock_t event_lock = SPIN_LOCK_UNLOCKED;


audit function doc. question

2005-07-06 Thread randy_dunlap
kernel/audit.c (2.6.13-rc1-git5) audit_log_start() says:

/* Obtain an audit buffer.  This routine does locking to obtain the
 * audit buffer, but then no locking is required for calls to
 * audit_log_*format.  If the tsk is a task that is currently in a
 * syscall, then the syscall is marked as auditable and an audit record
 * will be written at syscall exit.  If there is no associated task, tsk
 * should be NULL. */
struct audit_buffer *audit_log_start(struct audit_context *ctx, int type)
{


What does  refer to in the function description?
There is no  in this function.

Thanks,
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.13-rc2 white spaces patch

2005-07-06 Thread randy_dunlap
On Wed, 06 Jul 2005 15:41:01 +0200 Micha__ Piotrowski wrote:

| Hi,
| 
| This patch is against 2.6.13-rc2. It cleans whitespaces in init/* and 
| crypto/*.

General comment:  needs a Signed-off-by: line (see
Documenation/SubmittingPatches ).

Howver, I am having trouble seeing changes in lots of the
-/+ lines.  Did thunderbird perhaps mangle your patch?

After that is fixed, we can see if it's worthwhile to do this
kind of patch  (some doubt here)


| Regards,
| Micha__ Piotrowski
| 
| ---
| 
| diff -uprN -X linux-2.6.13-rc2/Documentation/dontdiff 
| linux-2.6.13-rc2/crypto/aes.c linux-2.6.13-rc2-ws/crypto/aes.c
| --- linux-2.6.13-rc2/crypto/aes.c2005-06-17 21:48:29.0 +0200
| +++ linux-2.6.13-rc2-ws/crypto/aes.c2005-07-06 15:14:45.0 +0200
| @@ -1,4 +1,4 @@
| -/*
| +/*
|   * Cryptographic API.
|   *
|   * AES Cipher Algorithm.
| @@ -65,7 +65,7 @@
|  #define AES_BLOCK_SIZE16
|  
|  /*
| - * #define byte(x, nr) ((unsigned char)((x) >> (nr*8)))
| + * #define byte(x, nr) ((unsigned char)((x) >> (nr*8)))
|   */
|  inline static u8
|  byte(const u32 x, const unsigned n)
| diff -uprN -X linux-2.6.13-rc2/Documentation/dontdiff 
| linux-2.6.13-rc2/crypto/api.c linux-2.6.13-rc2-ws/crypto/api.c
| --- linux-2.6.13-rc2/crypto/api.c2005-06-17 21:48:29.0 +0200
| +++ linux-2.6.13-rc2-ws/crypto/api.c2005-07-06 15:14:57.0 +0200
| @@ -9,7 +9,7 @@
|   *
|   * This program is free software; you can redistribute it and/or modify it
|   * under the terms of the GNU General Public License as published by 
| the Free
| - * Software Foundation; either version 2 of the License, or (at your 
| option)
| + * Software Foundation; either version 2 of the License, or (at your 
| option)
|   * any later version.
|   *
|   */
| diff -uprN -X linux-2.6.13-rc2/Documentation/dontdiff 
| linux-2.6.13-rc2/crypto/arc4.c linux-2.6.13-rc2-ws/crypto/arc4.c
| --- linux-2.6.13-rc2/crypto/arc4.c2005-06-17 21:48:29.0 +0200
| +++ linux-2.6.13-rc2-ws/crypto/arc4.c2005-07-06 15:15:09.0 +0200
| @@ -1,4 +1,4 @@
| -/*
| +/*
|   * Cryptographic API
|   *
|   * ARC4 Cipher Algorithm
| diff -uprN -X linux-2.6.13-rc2/Documentation/dontdiff 
| linux-2.6.13-rc2/crypto/blowfish.c linux-2.6.13-rc2-ws/crypto/blowfish.c
| --- linux-2.6.13-rc2/crypto/blowfish.c2005-06-17 21:48:29.0 
| +0200
| +++ linux-2.6.13-rc2-ws/crypto/blowfish.c2005-07-06 
| 15:16:07.0 +0200
| @@ -1,4 +1,4 @@
| -/*
| +/*
|   * Cryptographic API.
|   *
|   * Blowfish Cipher Algorithm, by Bruce Schneier.
| @@ -298,7 +298,7 @@ static const u32 bf_sbox[256 * 4] = {
|  0xb74e6132, 0xce77e25b, 0x578fdfe3, 0x3ac372e6,
|  };
|  
| -/*
| +/*
|   * Round loop unrolling macros, S is a pointer to a S-Box array
|   * organized in 4 unsigned longs at a row.
|   */
| @@ -314,7 +314,7 @@ static const u32 bf_sbox[256 * 4] = {
|  
|  /*
|   * The blowfish encipher, processes 64-bit blocks.
| - * NOTE: This function MUSTN'T respect endianess
| + * NOTE: This function MUSTN'T respect endianess
|   */
|  static void encrypt_block(struct bf_ctx *bctx, u32 *dst, u32 *src)
|  {
| @@ -393,7 +393,7 @@ static void bf_decrypt(void *ctx, u8 *ds
|  out_blk[1] = cpu_to_be32(yl);
|  }
|  
| -/*
| +/*
|   * Calculates the blowfish S and P boxes for encryption and decryption.
|   */
|  static int bf_setkey(void *ctx, const u8 *key, unsigned int keylen, u32 
| *flags)
| diff -uprN -X linux-2.6.13-rc2/Documentation/dontdiff 
| linux-2.6.13-rc2/crypto/cast6.c linux-2.6.13-rc2-ws/crypto/cast6.c
| --- linux-2.6.13-rc2/crypto/cast6.c2005-06-17 21:48:29.0 +0200
| +++ linux-2.6.13-rc2-ws/crypto/cast6.c2005-07-06 15:16:53.0 
| +0200
| @@ -11,7 +11,7 @@
|   * under the terms of GNU General Public License as published by the Free
|   * Software Foundation; either version 2 of the License, or (at your 
| option)
|   * any later version.
| - *
| + *
|   * You should have received a copy of the GNU General Public License
|   * along with this program; if not, write to the Free Software
|   * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 
| 02111-1307, USA
| @@ -310,7 +310,7 @@ static const u32 s4[256] = {
|  
|  static const u32 Tm[24][8] = {
|  { 0x5a827999, 0xc95c653a, 0x383650db, 0xa7103c7c, 0x15ea281d,
| -0x84c413be, 0xf39dff5f, 0x6277eb00 } ,
| +0x84c413be, 0xf39dff5f, 0x6277eb00 } ,
|  { 0xd151d6a1, 0x402bc242, 0xaf05ade3, 0x1ddf9984, 0x8cb98525,
|  0xfb9370c6, 0x6a6d5c67, 0xd9474808 } ,
|  { 0x482133a9, 0xb6fb1f4a, 0x25d50aeb, 0x94aef68c, 0x0388e22d,
| @@ -445,7 +445,7 @@ static inline void QBAR (u32 * block, u8
|  static void cast6_encrypt (void * ctx, u8 * outbuf, const u8 * inbuf) {
|  struct cast6_ctx * c = (struct cast6_ctx *)ctx;
|  u32 block[4];
| -u32 * Km;
| +u32 * Km;
|  u8 * Kr;
|  
|  block[0] = inbuf[0] << 24 | inbuf[1] << 16 | inbuf[2] << 8 | inbuf[3];
| @@ -487,7 +487,7 @@ static void cast6_encrypt (void * ctx, u
| 

Re: 2.6.13-rc2 white spaces patch

2005-07-06 Thread randy_dunlap
On Wed, 06 Jul 2005 21:28:02 +0200 Micha__ Piotrowski wrote:

| Hi Randy,
| 
| randy_dunlap napisa__(a):
| 
| >On Wed, 06 Jul 2005 15:41:01 +0200 Micha__ Piotrowski wrote:
| >
| >| Hi,
| >| 
| >| This patch is against 2.6.13-rc2. It cleans whitespaces in init/* and 
| >| crypto/*.
| >
| >General comment:  needs a Signed-off-by: line (see
| >Documenation/SubmittingPatches ).
| >
| >Howver, I am having trouble seeing changes in lots of the
| >-/+ lines.  Did thunderbird perhaps mangle your patch?
| >
| >After that is fixed, we can see if it's worthwhile to do this
| >kind of patch  (some doubt here)
| >
| >

| >---
| >~Randy
| >
| >  
| >
| Ups,
| 
| I resend the patrch, because iso-8859-2 coding in thunderbird is f%##**%%#.
| Patch is in atachment ;) (bz'iped).

OK, I can see the whitespace changes now, but please don't send patches
in any kind of zip format, it makes them impossible for someone to review
and comment on them.  Attachments are allowed (or tolerated) if they
are of type text/plain so that an email client can display them
inline with the rest of the mail message.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.13-rc2 white spaces patch

2005-07-06 Thread randy_dunlap
On Wed, 06 Jul 2005 21:28:02 +0200 Micha__ Piotrowski wrote:

| Hi Randy,
| 
| randy_dunlap napisa__(a):
| 
| On Wed, 06 Jul 2005 15:41:01 +0200 Micha__ Piotrowski wrote:
| 
| | Hi,
| | 
| | This patch is against 2.6.13-rc2. It cleans whitespaces in init/* and 
| | crypto/*.
| 
| General comment:  needs a Signed-off-by: line (see
| Documenation/SubmittingPatches ).
| 
| Howver, I am having trouble seeing changes in lots of the
| -/+ lines.  Did thunderbird perhaps mangle your patch?
| 
| After that is fixed, we can see if it's worthwhile to do this
| kind of patch  (some doubt here)
| 
| 

| ---
| ~Randy
| 
|   
| 
| Ups,
| 
| I resend the patrch, because iso-8859-2 coding in thunderbird is f%##**%%#.
| Patch is in atachment ;) (bz'iped).

OK, I can see the whitespace changes now, but please don't send patches
in any kind of zip format, it makes them impossible for someone to review
and comment on them.  Attachments are allowed (or tolerated) if they
are of type text/plain so that an email client can display them
inline with the rest of the mail message.

---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.13-rc2 white spaces patch

2005-07-06 Thread randy_dunlap
On Wed, 06 Jul 2005 15:41:01 +0200 Micha__ Piotrowski wrote:

| Hi,
| 
| This patch is against 2.6.13-rc2. It cleans whitespaces in init/* and 
| crypto/*.

General comment:  needs a Signed-off-by: line (see
Documenation/SubmittingPatches ).

Howver, I am having trouble seeing changes in lots of the
-/+ lines.  Did thunderbird perhaps mangle your patch?

After that is fixed, we can see if it's worthwhile to do this
kind of patch  (some doubt here)


| Regards,
| Micha__ Piotrowski
| 
| ---
| 
| diff -uprN -X linux-2.6.13-rc2/Documentation/dontdiff 
| linux-2.6.13-rc2/crypto/aes.c linux-2.6.13-rc2-ws/crypto/aes.c
| --- linux-2.6.13-rc2/crypto/aes.c2005-06-17 21:48:29.0 +0200
| +++ linux-2.6.13-rc2-ws/crypto/aes.c2005-07-06 15:14:45.0 +0200
| @@ -1,4 +1,4 @@
| -/*
| +/*
|   * Cryptographic API.
|   *
|   * AES Cipher Algorithm.
| @@ -65,7 +65,7 @@
|  #define AES_BLOCK_SIZE16
|  
|  /*
| - * #define byte(x, nr) ((unsigned char)((x)  (nr*8)))
| + * #define byte(x, nr) ((unsigned char)((x)  (nr*8)))
|   */
|  inline static u8
|  byte(const u32 x, const unsigned n)
| diff -uprN -X linux-2.6.13-rc2/Documentation/dontdiff 
| linux-2.6.13-rc2/crypto/api.c linux-2.6.13-rc2-ws/crypto/api.c
| --- linux-2.6.13-rc2/crypto/api.c2005-06-17 21:48:29.0 +0200
| +++ linux-2.6.13-rc2-ws/crypto/api.c2005-07-06 15:14:57.0 +0200
| @@ -9,7 +9,7 @@
|   *
|   * This program is free software; you can redistribute it and/or modify it
|   * under the terms of the GNU General Public License as published by 
| the Free
| - * Software Foundation; either version 2 of the License, or (at your 
| option)
| + * Software Foundation; either version 2 of the License, or (at your 
| option)
|   * any later version.
|   *
|   */
| diff -uprN -X linux-2.6.13-rc2/Documentation/dontdiff 
| linux-2.6.13-rc2/crypto/arc4.c linux-2.6.13-rc2-ws/crypto/arc4.c
| --- linux-2.6.13-rc2/crypto/arc4.c2005-06-17 21:48:29.0 +0200
| +++ linux-2.6.13-rc2-ws/crypto/arc4.c2005-07-06 15:15:09.0 +0200
| @@ -1,4 +1,4 @@
| -/*
| +/*
|   * Cryptographic API
|   *
|   * ARC4 Cipher Algorithm
| diff -uprN -X linux-2.6.13-rc2/Documentation/dontdiff 
| linux-2.6.13-rc2/crypto/blowfish.c linux-2.6.13-rc2-ws/crypto/blowfish.c
| --- linux-2.6.13-rc2/crypto/blowfish.c2005-06-17 21:48:29.0 
| +0200
| +++ linux-2.6.13-rc2-ws/crypto/blowfish.c2005-07-06 
| 15:16:07.0 +0200
| @@ -1,4 +1,4 @@
| -/*
| +/*
|   * Cryptographic API.
|   *
|   * Blowfish Cipher Algorithm, by Bruce Schneier.
| @@ -298,7 +298,7 @@ static const u32 bf_sbox[256 * 4] = {
|  0xb74e6132, 0xce77e25b, 0x578fdfe3, 0x3ac372e6,
|  };
|  
| -/*
| +/*
|   * Round loop unrolling macros, S is a pointer to a S-Box array
|   * organized in 4 unsigned longs at a row.
|   */
| @@ -314,7 +314,7 @@ static const u32 bf_sbox[256 * 4] = {
|  
|  /*
|   * The blowfish encipher, processes 64-bit blocks.
| - * NOTE: This function MUSTN'T respect endianess
| + * NOTE: This function MUSTN'T respect endianess
|   */
|  static void encrypt_block(struct bf_ctx *bctx, u32 *dst, u32 *src)
|  {
| @@ -393,7 +393,7 @@ static void bf_decrypt(void *ctx, u8 *ds
|  out_blk[1] = cpu_to_be32(yl);
|  }
|  
| -/*
| +/*
|   * Calculates the blowfish S and P boxes for encryption and decryption.
|   */
|  static int bf_setkey(void *ctx, const u8 *key, unsigned int keylen, u32 
| *flags)
| diff -uprN -X linux-2.6.13-rc2/Documentation/dontdiff 
| linux-2.6.13-rc2/crypto/cast6.c linux-2.6.13-rc2-ws/crypto/cast6.c
| --- linux-2.6.13-rc2/crypto/cast6.c2005-06-17 21:48:29.0 +0200
| +++ linux-2.6.13-rc2-ws/crypto/cast6.c2005-07-06 15:16:53.0 
| +0200
| @@ -11,7 +11,7 @@
|   * under the terms of GNU General Public License as published by the Free
|   * Software Foundation; either version 2 of the License, or (at your 
| option)
|   * any later version.
| - *
| + *
|   * You should have received a copy of the GNU General Public License
|   * along with this program; if not, write to the Free Software
|   * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 
| 02111-1307, USA
| @@ -310,7 +310,7 @@ static const u32 s4[256] = {
|  
|  static const u32 Tm[24][8] = {
|  { 0x5a827999, 0xc95c653a, 0x383650db, 0xa7103c7c, 0x15ea281d,
| -0x84c413be, 0xf39dff5f, 0x6277eb00 } ,
| +0x84c413be, 0xf39dff5f, 0x6277eb00 } ,
|  { 0xd151d6a1, 0x402bc242, 0xaf05ade3, 0x1ddf9984, 0x8cb98525,
|  0xfb9370c6, 0x6a6d5c67, 0xd9474808 } ,
|  { 0x482133a9, 0xb6fb1f4a, 0x25d50aeb, 0x94aef68c, 0x0388e22d,
| @@ -445,7 +445,7 @@ static inline void QBAR (u32 * block, u8
|  static void cast6_encrypt (void * ctx, u8 * outbuf, const u8 * inbuf) {
|  struct cast6_ctx * c = (struct cast6_ctx *)ctx;
|  u32 block[4];
| -u32 * Km;
| +u32 * Km;
|  u8 * Kr;
|  
|  block[0] = inbuf[0]  24 | inbuf[1]  16 | inbuf[2]  8 | inbuf[3];
| @@ -487,7 +487,7 @@ static void cast6_encrypt (void * ctx, u
|  static 

audit function doc. question

2005-07-06 Thread randy_dunlap
kernel/audit.c (2.6.13-rc1-git5) audit_log_start() says:

/* Obtain an audit buffer.  This routine does locking to obtain the
 * audit buffer, but then no locking is required for calls to
 * audit_log_*format.  If the tsk is a task that is currently in a
 * syscall, then the syscall is marked as auditable and an audit record
 * will be written at syscall exit.  If there is no associated task, tsk
 * should be NULL. */
struct audit_buffer *audit_log_start(struct audit_context *ctx, int type)
{


What does tsk refer to in the function description?
There is no tsk in this function.

Thanks,
---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Patch of a new driver for kernel 2.4.x that need review

2005-07-06 Thread randy_dunlap
On Wed, 6 Jul 2005 14:14:44 -0700 Mark Gross wrote:

| On Wednesday 22 June 2005 08:12, Bouchard, Sebastien wrote:
|  Hi,
| 
|  Here is a driver (only for 2.4.x) I've done to provide support of a
|  hardware module (available on some ATCA board) used with telecom expension
|  card on the new ATCA platform. This module provide redundant reference
|  clock for telecom hardware with alarm handling when there is a new event
|  (ex.: one of the ref clock is gone).
|  This char driver provide IOCTL for configuration of this module and
|  interrupt handler for processing alarm events.
| 
|  I send this driver so people in this mailing list can do a review of the
|  code.
| 
|  Please reply me directly to my email, i'm not subscribed to the mailing
|  list.
| 
|  Thanks
|  Sebastien Bouchard
|  Software designer
|  Kontron Canada Inc.
|  mailto:[EMAIL PROTECTED]
|  http://www.kontron.com/
| 
| I'm helping out a bit with the maintaining of this driver for Sebastien.  
| The following is a 2.6.12 port of Sebastien's 2.4 driver.  

I'd be surprised if Marcelo was taking new drivers for 2.4.x.

2.6.x driver comments below.

| diff -urN -X dontdiff_osdl vanilla/linux-2.6.12/drivers/char/Kconfig 
linux-2.6.12/drivers/char/Kconfig
| --- vanilla/linux-2.6.12/drivers/char/Kconfig 2005-06-17 12:48:29.0 
-0700
| +++ linux-2.6.12/drivers/char/Kconfig 2005-07-06 13:25:18.585951744 -0700
| @@ -998,5 +998,16 @@
|  
|  source drivers/char/tpm/Kconfig
|  
| +config TELCLOCK
| + tristate Telecom clock driver for ATCA
| + depends on EXPERIMENTAL
| + default n
| + help
| +   The telecom clock device allows direct userspace access to the
| +   configuration of the telecom clock configuration settings.
| +   This device is used for hardware synchronization across the ATCA
| +   back plane fabric.

usually:  backplane

| +
| +

Just 1 blank line, please.

|  endmenu
|  

| diff -urN -X dontdiff_osdl vanilla/linux-2.6.12/drivers/char/tlclk.c 
linux-2.6.12/drivers/char/tlclk.c
| --- vanilla/linux-2.6.12/drivers/char/tlclk.c 1969-12-31 16:00:00.0 
-0800
| +++ linux-2.6.12/drivers/char/tlclk.c 2005-07-06 13:25:18.600949464 -0700
| @@ -0,0 +1,447 @@
| +/*
| + * Telecom Clock driver for Wainwright board
| + *
| + * Copyright (C) 2005 Kontron Canada
| + *
| + * All rights reserved.
| + *
| + * This program is free software; you can redistribute it and/or modify
| + * it under the terms of the GNU General Public License as published by
| + * the Free Software Foundation; either version 2 of the License, or (at
| + * your option) any later version.
| + *
| + * This program is distributed in the hope that it will be useful, but
| + * WITHOUT ANY WARRANTY; without even the implied warranty of
| + * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
| + * NON INFRINGEMENT.  See the GNU General Public License for more
| + * details.
| + *
| + * You should have received a copy of the GNU General Public License
| + * along with this program; if not, write to the Free Software
| + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
| + *
| + * Send feedback to [EMAIL PROTECTED]
| + *
| + * Description : This is the TELECOM CLOCK module driver for the ATCA 
platform.
| + */
| +#ifndef __KERNEL__
| +#  define __KERNEL__
| +#endif

Not needed.

| +
| +#include linux/config.h
| +#include linux/module.h
| +#include linux/init.h
| +#include linux/sched.h
| +#include linux/kernel.h/* printk() */
| +#include linux/fs.h/* everything... */
| +#include linux/errno.h /* error codes */
| +#include linux/delay.h /* udelay */
| +#include asm/uaccess.h

Try to put all asm includes after the linux includes
unless it's not possible for some reason.

| +#include linux/slab.h
| +#include linux/ioport.h
| +#include linux/devfs_fs_kernel.h   /* Devfs support */

Devfs is being removed this month...

| +#include linux/interrupt.h
| +#include linux/spinlock.h
| +#include linux/timer.h
| +#include asm/io.h  /* inb/outb */
| +
| +#include tlclk.h   /* TELECOM IOCTL DEFINE */
| +
| +MODULE_AUTHOR(Sebastien Bouchard [EMAIL PROTECTED]);
| +MODULE_LICENSE(GPL);
| +
| +/* Telecom clock I/O register definition */
| +#define TLCLK_BASE 0xa08
| +#define TLCLK_REG0 TLCLK_BASE
| +#define TLCLK_REG1 (TLCLK_BASE+1)
| +#define TLCLK_REG2 (TLCLK_BASE+2)
| +#define TLCLK_REG3 (TLCLK_BASE+3)
| +#define TLCLK_REG4 (TLCLK_BASE+4)
| +#define TLCLK_REG5 (TLCLK_BASE+5)
| +#define TLCLK_REG6 (TLCLK_BASE+6)
| +#define TLCLK_REG7 (TLCLK_BASE+7)
| +
| +#define SET_PORT_BITS(port, mask, val) outb(((inb(port)  mask) | val), port)
| +
| +/* 0 = Dynamic allocation of the major device number */
| +#define TLCLK_MAJOR 252
| +
| +/* Contain the interrupt used for telecom clock */

eh?  contains?  this is self-evident, drop it.

| +static unsigned int telclk_interrupt;
| +
| +static int int_events;   /* Event that generate a interrupt */
| +static int got_event;/* 

Re: audit function doc. question

2005-07-06 Thread randy_dunlap
On Wed, 6 Jul 2005 15:21:15 -0700 Chris Wright wrote:

| * randy_dunlap ([EMAIL PROTECTED]) wrote:
|  kernel/audit.c (2.6.13-rc1-git5) audit_log_start() says:
|  
|  /* Obtain an audit buffer.  This routine does locking to obtain the
|   * audit buffer, but then no locking is required for calls to
|   * audit_log_*format.  If the tsk is a task that is currently in a
|   * syscall, then the syscall is marked as auditable and an audit record
|   * will be written at syscall exit.  If there is no associated task, tsk
|   * should be NULL. */
|  struct audit_buffer *audit_log_start(struct audit_context *ctx, int type)
|  {
|  
|  What does tsk refer to in the function description?
|  There is no tsk in this function.
| 
| It refers to tsk, tsk, stale comment.  It's task-audit_context (which is
| ctx there).  Interested in preparing a patch, could even move to proper
| kerneldoc format ;-)

Yes, that's why I asked, I'm adding kerneldoc format comments
to audit*.c (2 files).  You'll see it soon.

---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Documentation fixes

2005-07-06 Thread randy_dunlap
On Wed, 06 Jul 2005 16:12:11 -0700 Daniel Walker wrote:

| 
| I noticed some typo's or mis-thoughts .. Here are my corrections. I
| tried to CC all the authors.

Yes, mostly good corrections.  Here are more on top of yours.

Thanks,
~Randy


| Index: linux-2.6.12/Documentation/watchdog/watchdog.txt
| ===
| --- linux-2.6.12.orig/Documentation/watchdog/watchdog.txt 2005-06-17 
19:48:29.0 +
| +++ linux-2.6.12/Documentation/watchdog/watchdog.txt  2005-07-03 
18:12:40.0 +
| @@ -18,12 +18,12 @@ The following watchdog drivers are curre
|  All six interfaces provide /dev/watchdog, which when open must be written
|  to within a timeout or the machine will reboot. Each write delays the reboot
|  time another timeout. In the case of the software watchdog the ability to 
| -reboot will depend on the state of the machines and interrupts. The hardware
| +reboot will depend on the state of the machine and interrupts. The hardware
|  boards physically pull the machine down off their own onboard timers and
|  will reboot from almost anything.
|  
|  A second temperature monitoring interface is available on the WDT501P cards
| -and some Berkshire cards. This provides /dev/temperature. This is the 
machine 
| +and some Berkshire cards. This provides /dev/temperature. This is the 
machines 
 
machine's
  (and kill the trailing space)

|  internal temperature in degrees Fahrenheit. Each read returns a single byte 
|  giving the temperature.
|  
| @@ -37,16 +37,16 @@ The wdt card cannot be safely probed for
|  wdt=ioaddr,irq as a boot parameter - eg wdt=0x240,11.
|  
|  The SA1100 watchdog module can be configured with the sa1100_margin
| -commandline argument which specifies timeout value in seconds.
| +commandline argument which specifies the timeout value in seconds.
|  
|  The i810 TCO watchdog modules can be configured with the i810_margin
| -commandline argument which specifies the counter initial value. The counter
| -is decremented every 0.6 seconds and default to 50 (30 seconds). Values can
| +commandline argument which specifies the counters initial value. The counter
counter's
| +is decremented every 0.6 seconds and defaults to 50 (30 seconds). Values can
|  range between 3 and 63.
|  
|  The i810 TCO watchdog driver also implements the WDIOC_GETSTATUS and
|  WDIOC_GETBOOTSTATUS ioctl()s. WDIOC_GETSTATUS returns the actual counter 
value
| -and WDIOC_GETBOOTSTATUS returns the value of TCO2 Status Register (see 
Intel's
| +and WDIOC_GETBOOTSTATUS returns the value of the TCO2 Status Register (see 
Intel's

Please wrap lines at  80 characters per line.

|  documentation for the 82801AA and 82801AB datasheet). 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Fix posix_bump_timer args

2005-07-06 Thread randy_dunlap
On Wed, 06 Jul 2005 11:26:31 -0700 Geoff Levand wrote:

| This patch makes posix_bump_timer() consistent with common convention 
| by expecting a pointer to the structure be passed.
| 
| Please apply.

Does it matter other than for consistency?

E.g., in a large system with thousands of timers, it seems that it
could (at least theoretically) have a negative impact by using a
pointer dereference instead of a known fixed address.
or am I just imagining that?

Thanks,
~Randy

| Signed-off-by: Geoff Levand [EMAIL PROTECTED] for CELF
| 
| --
| --- linux-2.6.12.1.orig/include/linux/posix-timers.h  2005-06-17 
12:48:29.0 -0700
| +++ linux-2.6.12.1/include/linux/posix-timers.h.bump  2005-07-06 
10:58:52.0 -0700
| @@ -108,7 +108,7 @@
|  #define posix_bump_timer(timr, now)  \
|   do {
\
|long delta, orun;  
\
| -   delta = now.jiffies - (timr)-it.real.timer.expires;  \
| +   delta = (now)-jiffies - (timr)-it.real.timer.expires;   \
|if (delta = 0) {  
\
|  orun = 1 + (delta / (timr)-it.real.incr);   \
| (timr)-it.real.timer.expires +=  \
| 
| --- linux-2.6.12.1.orig/kernel/posix-timers.c 2005-06-17 12:48:29.0 
-0700
| +++ linux-2.6.12.1/kernel/posix-timers.c.bump 2005-07-06 10:54:48.0 
-0700
| @@ -384,11 +384,11 @@
|   spin_lock(abs_list.lock);
|   add_clockset_delta(timr, new_wall_to);
|  
| - posix_bump_timer(timr, now);
| + posix_bump_timer(timr, now);
|  
|   spin_unlock(abs_list.lock);
|   } else {
| - posix_bump_timer(timr, now);
| + posix_bump_timer(timr, now);
|   }
|   timr-it_overrun_last = timr-it_overrun;
|   timr-it_overrun = -1;
| @@ -810,7 +810,7 @@
|   if (expires) {
|   if (timr-it_requeue_pending  REQUEUE_PENDING ||
|   (timr-it_sigev_notify  ~SIGEV_THREAD_ID) == SIGEV_NONE) {
| - posix_bump_timer(timr, now);
| + posix_bump_timer(timr, now);
|   expires = timr-it.real.timer.expires;
|   }
|   else
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: bios interaction with linux kernel after uncompression.

2005-07-06 Thread randy_dunlap
On Wed, 6 Jul 2005 12:02:26 +0530 Bhagyashri Bijwe wrote:

| Hi,
|  During bootstrapping,  bios provides services like video ,hard
| drive services, memory sizing, PCI table to linux kernel.
|  After uncompression of kernel , Does linux kernel have any
| interaction with bios?
| I know that most of work is done by linux device driver. 
| What is dependency of running linux on bios ?
|   Thanks in advance,

As little as possible after boot/init.

That means that BIOS is used for APM mode selections
if APM is being used and for ACPI state-switching.
Oh, I guess we have to acknowledge that hidden SMI code
also, but Linux doesn't use it AFAIK, it's just there
and being executed.

Those are all that I know of before being fully awake.

---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] char: Add Dell Systems Management Base driver

2005-07-05 Thread randy_dunlap
On Tue, 5 Jul 2005 19:13:34 -0500 Doug Warzecha wrote:

| This patch adds the Dell Systems Management Base driver.
| 
| The Dell Systems Management Base driver is a character driver that
| implements ioctls for Dell systems management software to use to
| communicate with the driver.  The driver provides support for Dell
| systems management software to manage the following Dell PowerEdge
| systems: 300, 1300, 1400, 400SC, 500SC, 1500SC, 1550, 600SC, 1600SC,
| 650, 1655MC, 700, and 750.
| 
| By making a contribution to this project, I certify that:
| The contribution was created in whole or in part by me and
| I have the right to submit it under the open source license
| indicated in the file.

Could you possibly reply to some earlier comments that have been posted
from Chris Wedgwood and me (and possibly others) instead of
ignoring them?

e.g.,
http://marc.theaimsgroup.com/?l=linux-kernel=111984209416906=2
http://marc.theaimsgroup.com/?l=linux-kernel=111966319714417=2
http://marc.theaimsgroup.com/?l=linux-kernel=111895964717480=2
and others.

Thanks,
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: page allocation/attributes question (i386/x86_64 specific)

2005-07-05 Thread randy_dunlap
On Tue, 5 Jul 2005 16:35:51 -0500 [EMAIL PROTECTED] wrote:

| randy_dunlap wrote:
| > On Tue, 5 Jul 2005 15:02:26 -0500 [EMAIL PROTECTED] wrote:
| > 
| >> Andi--
| >> 
| >> I made another pass at this.  This does roughly the same thing, but
| >> it doesn't create the new "change_page_attr_perm()" functions.  With
| >> this patch, the change to init.c (cleanup_nx_in_kerneltext()) is
| >> optional. I changed __change_page_attr() so that, if the page to be
| >> changed is part of a large executable page, it splits the page up
| >> *keeping the executability of the extra 511 pages*, and then marks
| >> the new PTE page as reserved so that it won't be reverted.
| >> 
| >> So, basically, without the changes to init.c, the NX bits for data in
| >> the first two big pages won't get fixed until someone calls
| >> change_page_attr() on them.  If NX is disabled, these patches have
| >> no functional effect at all. 
| >> 
| >> How does this look?
| > 
| > Look?  It has lots of bad line breaks and other style issues.
| > 
| > But I'll let Andi comment on the technical issues.
| > 
| >> -
| >> 
| >> diff -purN linux-2.6.12grep/arch/i386/mm/init.c
| >> linux-2.6.12/arch/i386/mm/init.c
| >> --- linux-2.6.12grep/arch/i386/mm/init.c   2005-07-01
| >> 15:09:27.0 -0500 +++
| >> linux-2.6.12/arch/i386/mm/init.c   2005-07-05 14:32:57.0
| -0500
| >>  @@ -666,6 +666,28 @@ static int noinline do_test_wp_bit(void) 
| >> return flag; } 
| >> 
| >> +/*
| >> + * In kernel_physical_mapping_init(), any big pages that contained
| >> kernel text area were + * set up as big executable pages.  This
| >> function should be called + when the initmem
| >> + * is freed, to correctly set up the executable & non-executable +
| >> pages in this area.
| >> + */
| >> +static void cleanup_nx_in_kerneltext(void) {
| >> +  unsigned long from, to;
| >> +
| >> +  if (!nx_enabled) return;
| > 
| > return; on separate line.
| > 
| >> +  from = PAGE_OFFSET;
| >> +  to = (unsigned long)_text & PAGE_MASK;
| >> +  for (; fromfrom < to
| > 
| > (i.e., use the spacebar)
| > 
| >> +  change_page_attr(virt_to_page(from), 1, PAGE_KERNEL); +
| >> +  from = ((unsigned long)_etext + PAGE_SIZE - 1) & PAGE_MASK;
| >> +  to = ((unsigned long)__init_end + LARGE_PAGE_SIZE) &
| >> LARGE_PAGE_MASK; + for (; from 
| > add spaces:from < to
| > 
| >> +  change_page_attr(virt_to_page(from), 1, PAGE_KERNEL); }
| +
| >>  void free_initmem(void)
| >>  {
| >>unsigned long addr;
| > 
| > 
| > ---
| > ~Randy
| 
| Thanks for the feedback.  I know it looks like crap with the line
| wrapping, but I have no way of sending non-automatically-line-broken
| email right now, which is why I attached the file in addition to the
| inline text.  I apologize for that.

My apologies also, I completely missed seeing the attachment.

| I'll correct those cosmetic issues, thanks.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: page allocation/attributes question (i386/x86_64 specific)

2005-07-05 Thread randy_dunlap
On Tue, 5 Jul 2005 15:02:26 -0500 [EMAIL PROTECTED] wrote:

| Hayes, Stuart wrote:
| >> So, if I understand correctly what's going on in x86_64, your fix
| >> wouldn't be applicable to i386.  In x86_64, every large page has a
| >> correct "ref_prot" that is the normal setting for that page... but in
| >> i386, the kernel text area does not--it should ideally be split into
| >> small pages all the time if there are both kernel code & free pages
| >> residing in the same 2M area. 
| >> 
| >> Stuart
| > 
| > (This isn't a submission--I'm just posting this for comments.)
| > 
| > Right now, any large page that touches anywhere from PAGE_OFFSET to
| > __init_end is initially set up as a large, executable page... but
| > some of this area contains data & free pages.  The patch below adds a
| > "cleanup_nx_in_kerneltext()" function, called at the end of
| > free_initmem(), which changes these pages--except for the range from
| > "_text" to "_etext"--to PAGE_KERNEL (i.e., non-executable). 
| > 
| > This does result in two large pages being split up into small PTEs
| > permanently, but all the non-code regions will be non-executable, and
| > change_page_attr() will work correctly.  
| > 
| > What do you think of this?  I have tested this on 2.6.12.
| > 
| > (I've attached the patch as a file, too, since my mail server can't
| > be convinced to not wrap text.) 
| > 
| > Stuart
| > 
| 
| Andi--
| 
| I made another pass at this.  This does roughly the same thing, but it
| doesn't create the new "change_page_attr_perm()" functions.  With this
| patch, the change to init.c (cleanup_nx_in_kerneltext()) is optional.  I
| changed __change_page_attr() so that, if the page to be changed is part
| of a large executable page, it splits the page up *keeping the
| executability of the extra 511 pages*, and then marks the new PTE page
| as reserved so that it won't be reverted.
| 
| So, basically, without the changes to init.c, the NX bits for data in
| the first two big pages won't get fixed until someone calls
| change_page_attr() on them.  If NX is disabled, these patches have no
| functional effect at all.
| 
| How does this look?

Look?  It has lots of bad line breaks and other style issues.

But I'll let Andi comment on the technical issues.

| -
| 
| diff -purN linux-2.6.12grep/arch/i386/mm/init.c
| linux-2.6.12/arch/i386/mm/init.c
| --- linux-2.6.12grep/arch/i386/mm/init.c  2005-07-01
| 15:09:27.0 -0500
| +++ linux-2.6.12/arch/i386/mm/init.c  2005-07-05 14:32:57.0
| -0500
| @@ -666,6 +666,28 @@ static int noinline do_test_wp_bit(void)
|   return flag;
|  }
|  
| +/*
| + * In kernel_physical_mapping_init(), any big pages that contained
| kernel text area were
| + * set up as big executable pages.  This function should be called when
| the initmem
| + * is freed, to correctly set up the executable & non-executable pages
| in this area.
| + */
| +static void cleanup_nx_in_kerneltext(void)
| +{
| + unsigned long from, to;
| +
| + if (!nx_enabled) return;

return; on separate line.

| + from = PAGE_OFFSET;
| + to = (unsigned long)_text & PAGE_MASK;
| + for (; fromhttp://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Why cannot I do "insmod nfsd.ko" directly?

2005-07-05 Thread randy_dunlap
On Tue, 5 Jul 2005 14:23:39 -0400 Xin Zhao wrote:

| I tried to do "insmod nfsd.ko", but always got the error message
| "insmod: error inserting 'nfsd.ko': -1 Unknown symbol in module"

The kernel message log would at least tell you what symbol
is missing and then you/we can determnine why and where that
symbol is located.  Maybe there's just another module that needs
to be loaded before nfsd.ko.  And try using modprobe instead
of insmod since modprobe will look for module dependencies.


| Why?
| 
| The kernel is 2.6.11.10
| The command I used is:
| 1. insmod lockd.ko  ---succeed
| 2. exportfs -r   ---succeed
| 3. insmod nfsd.ko --- failed 
| 
| 
| Moreover, I noticed that if I do the following commands, nfsd.ko can
| be inserted:
| 
| 1. rpc.mountd
| 2. exportfs -r
| 3. rpc.nfsd 1
| 
| Can someone explain what trick rpc.mountd and rpc.nfsd do to make
| nfsd.ko insertable?
| 
| Thanks in advance for your kind help!


---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Why cannot I do insmod nfsd.ko directly?

2005-07-05 Thread randy_dunlap
On Tue, 5 Jul 2005 14:23:39 -0400 Xin Zhao wrote:

| I tried to do insmod nfsd.ko, but always got the error message
| insmod: error inserting 'nfsd.ko': -1 Unknown symbol in module

The kernel message log would at least tell you what symbol
is missing and then you/we can determnine why and where that
symbol is located.  Maybe there's just another module that needs
to be loaded before nfsd.ko.  And try using modprobe instead
of insmod since modprobe will look for module dependencies.


| Why?
| 
| The kernel is 2.6.11.10
| The command I used is:
| 1. insmod lockd.ko  ---succeed
| 2. exportfs -r   ---succeed
| 3. insmod nfsd.ko --- failed 
| 
| 
| Moreover, I noticed that if I do the following commands, nfsd.ko can
| be inserted:
| 
| 1. rpc.mountd
| 2. exportfs -r
| 3. rpc.nfsd 1
| 
| Can someone explain what trick rpc.mountd and rpc.nfsd do to make
| nfsd.ko insertable?
| 
| Thanks in advance for your kind help!


---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: page allocation/attributes question (i386/x86_64 specific)

2005-07-05 Thread randy_dunlap
On Tue, 5 Jul 2005 15:02:26 -0500 [EMAIL PROTECTED] wrote:

| Hayes, Stuart wrote:
|  So, if I understand correctly what's going on in x86_64, your fix
|  wouldn't be applicable to i386.  In x86_64, every large page has a
|  correct ref_prot that is the normal setting for that page... but in
|  i386, the kernel text area does not--it should ideally be split into
|  small pages all the time if there are both kernel code  free pages
|  residing in the same 2M area. 
|  
|  Stuart
|  
|  (This isn't a submission--I'm just posting this for comments.)
|  
|  Right now, any large page that touches anywhere from PAGE_OFFSET to
|  __init_end is initially set up as a large, executable page... but
|  some of this area contains data  free pages.  The patch below adds a
|  cleanup_nx_in_kerneltext() function, called at the end of
|  free_initmem(), which changes these pages--except for the range from
|  _text to _etext--to PAGE_KERNEL (i.e., non-executable). 
|  
|  This does result in two large pages being split up into small PTEs
|  permanently, but all the non-code regions will be non-executable, and
|  change_page_attr() will work correctly.  
|  
|  What do you think of this?  I have tested this on 2.6.12.
|  
|  (I've attached the patch as a file, too, since my mail server can't
|  be convinced to not wrap text.) 
|  
|  Stuart
|  
| 
| Andi--
| 
| I made another pass at this.  This does roughly the same thing, but it
| doesn't create the new change_page_attr_perm() functions.  With this
| patch, the change to init.c (cleanup_nx_in_kerneltext()) is optional.  I
| changed __change_page_attr() so that, if the page to be changed is part
| of a large executable page, it splits the page up *keeping the
| executability of the extra 511 pages*, and then marks the new PTE page
| as reserved so that it won't be reverted.
| 
| So, basically, without the changes to init.c, the NX bits for data in
| the first two big pages won't get fixed until someone calls
| change_page_attr() on them.  If NX is disabled, these patches have no
| functional effect at all.
| 
| How does this look?

Look?  It has lots of bad line breaks and other style issues.

But I'll let Andi comment on the technical issues.

| -
| 
| diff -purN linux-2.6.12grep/arch/i386/mm/init.c
| linux-2.6.12/arch/i386/mm/init.c
| --- linux-2.6.12grep/arch/i386/mm/init.c  2005-07-01
| 15:09:27.0 -0500
| +++ linux-2.6.12/arch/i386/mm/init.c  2005-07-05 14:32:57.0
| -0500
| @@ -666,6 +666,28 @@ static int noinline do_test_wp_bit(void)
|   return flag;
|  }
|  
| +/*
| + * In kernel_physical_mapping_init(), any big pages that contained
| kernel text area were
| + * set up as big executable pages.  This function should be called when
| the initmem
| + * is freed, to correctly set up the executable  non-executable pages
| in this area.
| + */
| +static void cleanup_nx_in_kerneltext(void)
| +{
| + unsigned long from, to;
| +
| + if (!nx_enabled) return;

return; on separate line.

| + from = PAGE_OFFSET;
| + to = (unsigned long)_text  PAGE_MASK;
| + for (; fromto; from += PAGE_SIZE)
   from  to

(i.e., use the spacebar)

| + change_page_attr(virt_to_page(from), 1, PAGE_KERNEL); 
| + 
| + from = ((unsigned long)_etext + PAGE_SIZE - 1)  PAGE_MASK;
| + to = ((unsigned long)__init_end + LARGE_PAGE_SIZE) 
| LARGE_PAGE_MASK;
| + for (; fromto; from += PAGE_SIZE)

add spaces:from  to

| + change_page_attr(virt_to_page(from), 1, PAGE_KERNEL); 
| +}
| +
|  void free_initmem(void)
|  {
|   unsigned long addr;


---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: page allocation/attributes question (i386/x86_64 specific)

2005-07-05 Thread randy_dunlap
On Tue, 5 Jul 2005 16:35:51 -0500 [EMAIL PROTECTED] wrote:

| randy_dunlap wrote:
|  On Tue, 5 Jul 2005 15:02:26 -0500 [EMAIL PROTECTED] wrote:
|  
|  Andi--
|  
|  I made another pass at this.  This does roughly the same thing, but
|  it doesn't create the new change_page_attr_perm() functions.  With
|  this patch, the change to init.c (cleanup_nx_in_kerneltext()) is
|  optional. I changed __change_page_attr() so that, if the page to be
|  changed is part of a large executable page, it splits the page up
|  *keeping the executability of the extra 511 pages*, and then marks
|  the new PTE page as reserved so that it won't be reverted.
|  
|  So, basically, without the changes to init.c, the NX bits for data in
|  the first two big pages won't get fixed until someone calls
|  change_page_attr() on them.  If NX is disabled, these patches have
|  no functional effect at all. 
|  
|  How does this look?
|  
|  Look?  It has lots of bad line breaks and other style issues.
|  
|  But I'll let Andi comment on the technical issues.
|  
|  -
|  
|  diff -purN linux-2.6.12grep/arch/i386/mm/init.c
|  linux-2.6.12/arch/i386/mm/init.c
|  --- linux-2.6.12grep/arch/i386/mm/init.c   2005-07-01
|  15:09:27.0 -0500 +++
|  linux-2.6.12/arch/i386/mm/init.c   2005-07-05 14:32:57.0
| -0500
|   @@ -666,6 +666,28 @@ static int noinline do_test_wp_bit(void) 
|  return flag; } 
|  
|  +/*
|  + * In kernel_physical_mapping_init(), any big pages that contained
|  kernel text area were + * set up as big executable pages.  This
|  function should be called + when the initmem
|  + * is freed, to correctly set up the executable  non-executable +
|  pages in this area.
|  + */
|  +static void cleanup_nx_in_kerneltext(void) {
|  +  unsigned long from, to;
|  +
|  +  if (!nx_enabled) return;
|  
|  return; on separate line.
|  
|  +  from = PAGE_OFFSET;
|  +  to = (unsigned long)_text  PAGE_MASK;
|  +  for (; fromto; from += PAGE_SIZE)
| from  to
|  
|  (i.e., use the spacebar)
|  
|  +  change_page_attr(virt_to_page(from), 1, PAGE_KERNEL); +
|  +  from = ((unsigned long)_etext + PAGE_SIZE - 1)  PAGE_MASK;
|  +  to = ((unsigned long)__init_end + LARGE_PAGE_SIZE) 
|  LARGE_PAGE_MASK; + for (; fromto; from += PAGE_SIZE)
|  
|  add spaces:from  to
|  
|  +  change_page_attr(virt_to_page(from), 1, PAGE_KERNEL); }
| +
|   void free_initmem(void)
|   {
| unsigned long addr;
|  
|  
|  ---
|  ~Randy
| 
| Thanks for the feedback.  I know it looks like crap with the line
| wrapping, but I have no way of sending non-automatically-line-broken
| email right now, which is why I attached the file in addition to the
| inline text.  I apologize for that.

My apologies also, I completely missed seeing the attachment.

| I'll correct those cosmetic issues, thanks.

---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] char: Add Dell Systems Management Base driver

2005-07-05 Thread randy_dunlap
On Tue, 5 Jul 2005 19:13:34 -0500 Doug Warzecha wrote:

| This patch adds the Dell Systems Management Base driver.
| 
| The Dell Systems Management Base driver is a character driver that
| implements ioctls for Dell systems management software to use to
| communicate with the driver.  The driver provides support for Dell
| systems management software to manage the following Dell PowerEdge
| systems: 300, 1300, 1400, 400SC, 500SC, 1500SC, 1550, 600SC, 1600SC,
| 650, 1655MC, 700, and 750.
| 
| By making a contribution to this project, I certify that:
| The contribution was created in whole or in part by me and
| I have the right to submit it under the open source license
| indicated in the file.

Could you possibly reply to some earlier comments that have been posted
from Chris Wedgwood and me (and possibly others) instead of
ignoring them?

e.g.,
http://marc.theaimsgroup.com/?l=linux-kernelm=111984209416906w=2
http://marc.theaimsgroup.com/?l=linux-kernelm=111966319714417w=2
http://marc.theaimsgroup.com/?l=linux-kernelm=111895964717480w=2
and others.

Thanks,
---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/