* Re: [KJ] [PATCH] Changed all calls to pci_module_init to
2006-10-28 20:10 [KJ] [PATCH] Changed all calls to pci_module_init to be Ethan A Burns
@ 2006-10-30 4:16 ` Richard Knutsson
2006-10-30 16:25 ` Ethan A Burns
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Richard Knutsson @ 2006-10-30 4:16 UTC (permalink / raw)
To: kernel-janitors
Ethan A Burns wrote:
> From: Ethan A. Burns <burns.ethan@gmail.com>
>
> This change was necessary because pci_module_init is obsolete.
>
> Signed-off-by: Ethan A. Burns <eaburns@unh.edu>
> ---
> drivers/ata/ata_generic.c | 2 +-
> drivers/ata/pata_pdc2027x.c | 2 +-
> drivers/char/ipmi/ipmi_si_intf.c | 2 +-
> drivers/net/hp100.c | 2 +-
> drivers/net/tokenring/olympic.c | 2 +-
> drivers/scsi/megaraid.c | 2 +-
> drivers/scsi/tmscsim.c | 2 +-
> include/linux/pci.h | 6 ------
> 8 files changed, 7 insertions(+), 13 deletions(-)
>
<snip>
> diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
> index e5cfb1f..fbfab65 100644
> --- a/drivers/char/ipmi/ipmi_si_intf.c
> +++ b/drivers/char/ipmi/ipmi_si_intf.c
> @@ -2483,7 +2483,7 @@ #ifdef CONFIG_ACPI
> #endif
>
> #ifdef CONFIG_PCI
> - pci_module_init(&ipmi_pci_driver);
> + pci_register_driver(&ipmi_pci_driver);
> #endif
>
Think you should remove #ifdef since pci_register_driver() returns 0 if
undefined.
> if (si_trydefaults) {
> diff --git a/drivers/net/hp100.c b/drivers/net/hp100.c
> index 844c136..7dc5185 100644
> --- a/drivers/net/hp100.c
> +++ b/drivers/net/hp100.c
> @@ -3034,7 +3034,7 @@ #ifdef CONFIG_EISA
> goto out2;
> #endif
> #ifdef CONFIG_PCI
> - err = pci_module_init(&hp100_pci_driver);
> + err = pci_register_driver(&hp100_pci_driver);
> if (err && err != -ENODEV)
> goto out3;
> #endif
>
<snip>
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 09be0f8..70278cc 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -389,12 +389,6 @@ #define PCI_DEVICE_CLASS(dev_class,dev_c
> .vendor = PCI_ANY_ID, .device = PCI_ANY_ID, \
> .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID
>
> -/*
> - * pci_module_init is obsolete, this stays here till we fix up all usages of it
> - * in the tree.
> - */
> -#define pci_module_init pci_register_driver
> -
> /* these external functions are only available when PCI support is enabled */
> #ifdef CONFIG_PCI
>
> --
>
Is scheduled in Documentation/feature-removal-schedule.txt for January
2007 ;).
Other then those, I liked it.
cu
Richard Knutsson
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [KJ] [PATCH] Changed all calls to pci_module_init to
2006-10-28 20:10 [KJ] [PATCH] Changed all calls to pci_module_init to be Ethan A Burns
2006-10-30 4:16 ` [KJ] [PATCH] Changed all calls to pci_module_init to Richard Knutsson
@ 2006-10-30 16:25 ` Ethan A Burns
2006-10-30 17:15 ` Richard Knutsson
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Ethan A Burns @ 2006-10-30 16:25 UTC (permalink / raw)
To: kernel-janitors
Richard,
New patch is at the bottom. I was unaware of
Documentation/feature-removal-schedule.txt. Since this is already schedueled
for removal, does this mean that this is an unneeded patch? This item was on
the TODO list, which is why I decided to take a stab at it.
--Ethan
> Ethan A Burns wrote:
> >From: Ethan A. Burns <burns.ethan@gmail.com>
> >
> >This change was necessary because pci_module_init is obsolete.
> >
> >Signed-off-by: Ethan A. Burns <eaburns@unh.edu>
> >---
> > drivers/ata/ata_generic.c | 2 +-
> > drivers/ata/pata_pdc2027x.c | 2 +-
> > drivers/char/ipmi/ipmi_si_intf.c | 2 +-
> > drivers/net/hp100.c | 2 +-
> > drivers/net/tokenring/olympic.c | 2 +-
> > drivers/scsi/megaraid.c | 2 +-
> > drivers/scsi/tmscsim.c | 2 +-
> > include/linux/pci.h | 6 ------
> > 8 files changed, 7 insertions(+), 13 deletions(-)
> >
> <snip>
> >diff --git a/drivers/char/ipmi/ipmi_si_intf.c
> >b/drivers/char/ipmi/ipmi_si_intf.c
> >index e5cfb1f..fbfab65 100644
> >--- a/drivers/char/ipmi/ipmi_si_intf.c
> >+++ b/drivers/char/ipmi/ipmi_si_intf.c
> >@@ -2483,7 +2483,7 @@ #ifdef CONFIG_ACPI
> > #endif
> >
> > #ifdef CONFIG_PCI
> >- pci_module_init(&ipmi_pci_driver);
> >+ pci_register_driver(&ipmi_pci_driver);
> > #endif
> >
> Think you should remove #ifdef since pci_register_driver() returns 0 if
> undefined.
> > if (si_trydefaults) {
> >diff --git a/drivers/net/hp100.c b/drivers/net/hp100.c
> >index 844c136..7dc5185 100644
> >--- a/drivers/net/hp100.c
> >+++ b/drivers/net/hp100.c
> >@@ -3034,7 +3034,7 @@ #ifdef CONFIG_EISA
> > goto out2;
> > #endif
> > #ifdef CONFIG_PCI
> >- err = pci_module_init(&hp100_pci_driver);
> >+ err = pci_register_driver(&hp100_pci_driver);
> > if (err && err != -ENODEV)
> > goto out3;
> > #endif
> >
> <snip>
> >diff --git a/include/linux/pci.h b/include/linux/pci.h
> >index 09be0f8..70278cc 100644
> >--- a/include/linux/pci.h
> >+++ b/include/linux/pci.h
> >@@ -389,12 +389,6 @@ #define PCI_DEVICE_CLASS(dev_class,dev_c
> > .vendor = PCI_ANY_ID, .device = PCI_ANY_ID, \
> > .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID
> >
> >-/*
> >- * pci_module_init is obsolete, this stays here till we fix up all usages
> >of it
> >- * in the tree.
> >- */
> >-#define pci_module_init pci_register_driver
> >-
> > /* these external functions are only available when PCI support is
> > enabled */
> > #ifdef CONFIG_PCI
> >
> >--
> >
> Is scheduled in Documentation/feature-removal-schedule.txt for January
> 2007 ;).
>
> Other then those, I liked it.
>
> cu
> Richard Knutsson
Subject: [PATCH] Changed all calls to pci_module_init to be pci_register_device.
This change was necessary because pci_module_init is obsolete.
Signed-off-by: Ethan A. Burns <burns.ethan@gmail.com>
---
drivers/ata/ata_generic.c | 2 +-
drivers/ata/pata_pdc2027x.c | 2 +-
drivers/char/ipmi/ipmi_si_intf.c | 4 +---
drivers/net/hp100.c | 4 +---
drivers/scsi/megaraid.c | 2 +-
drivers/scsi/tmscsim.c | 2 +-
include/linux/pci.h | 6 ------
7 files changed, 6 insertions(+), 16 deletions(-)
diff --git a/drivers/ata/ata_generic.c b/drivers/ata/ata_generic.c
index 377425e..f4625ec 100644
--- a/drivers/ata/ata_generic.c
+++ b/drivers/ata/ata_generic.c
@@ -230,7 +230,7 @@ static struct pci_driver ata_generic_pci
static int __init ata_generic_init(void)
{
- return pci_module_init(&ata_generic_pci_driver);
+ return pci_register_driver(&ata_generic_pci_driver);
}
diff --git a/drivers/ata/pata_pdc2027x.c b/drivers/ata/pata_pdc2027x.c
index d894d99..56e0287 100644
--- a/drivers/ata/pata_pdc2027x.c
+++ b/drivers/ata/pata_pdc2027x.c
@@ -853,7 +853,7 @@ static void __devexit pdc2027x_remove_on
*/
static int __init pdc2027x_init(void)
{
- return pci_module_init(&pdc2027x_pci_driver);
+ return pci_register_driver(&pdc2027x_pci_driver);
}
/**
diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index e5cfb1f..e5df1dc 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -2482,9 +2482,7 @@ #ifdef CONFIG_ACPI
acpi_find_bmc();
#endif
-#ifdef CONFIG_PCI
- pci_module_init(&ipmi_pci_driver);
-#endif
+ pci_register_driver(&ipmi_pci_driver);
if (si_trydefaults) {
mutex_lock(&smi_infos_lock);
diff --git a/drivers/net/hp100.c b/drivers/net/hp100.c
index 844c136..259ba83 100644
--- a/drivers/net/hp100.c
+++ b/drivers/net/hp100.c
@@ -3033,11 +3033,9 @@ #ifdef CONFIG_EISA
if (err && err != -ENODEV)
goto out2;
#endif
-#ifdef CONFIG_PCI
- err = pci_module_init(&hp100_pci_driver);
+ err = pci_register_driver(&hp100_pci_driver);
if (err && err != -ENODEV)
goto out3;
-#endif
out:
return err;
out3:
diff --git a/drivers/scsi/megaraid.c b/drivers/scsi/megaraid.c
index 86099fd..df5329d 100644
--- a/drivers/scsi/megaraid.c
+++ b/drivers/scsi/megaraid.c
@@ -5069,7 +5069,7 @@ #ifdef CONFIG_PROC_FS
"megaraid: failed to create megaraid root\n");
}
#endif
- error = pci_module_init(&megaraid_pci_driver);
+ error = pci_register_driver(&megaraid_pci_driver);
if (error) {
#ifdef CONFIG_PROC_FS
remove_proc_entry("megaraid", &proc_root);
diff --git a/drivers/scsi/tmscsim.c b/drivers/scsi/tmscsim.c
index fa5382e..ce8845e 100644
--- a/drivers/scsi/tmscsim.c
+++ b/drivers/scsi/tmscsim.c
@@ -2681,7 +2681,7 @@ static int __init dc390_module_init(void
printk (KERN_INFO "DC390: Using safe settings.\n");
}
- return pci_module_init(&dc390_driver);
+ return pci_register_driver(&dc390_driver);
}
static void __exit dc390_module_exit(void)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 09be0f8..70278cc 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -389,12 +389,6 @@ #define PCI_DEVICE_CLASS(dev_class,dev_c
.vendor = PCI_ANY_ID, .device = PCI_ANY_ID, \
.subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID
-/*
- * pci_module_init is obsolete, this stays here till we fix up all usages of it
- * in the tree.
- */
-#define pci_module_init pci_register_driver
-
/* these external functions are only available when PCI support is enabled */
#ifdef CONFIG_PCI
--
1.4.2.4
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply related [flat|nested] 12+ messages in thread* Re: [KJ] [PATCH] Changed all calls to pci_module_init to
2006-10-28 20:10 [KJ] [PATCH] Changed all calls to pci_module_init to be Ethan A Burns
2006-10-30 4:16 ` [KJ] [PATCH] Changed all calls to pci_module_init to Richard Knutsson
2006-10-30 16:25 ` Ethan A Burns
@ 2006-10-30 17:15 ` Richard Knutsson
2006-10-30 17:40 ` Ethan A Burns
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Richard Knutsson @ 2006-10-30 17:15 UTC (permalink / raw)
To: kernel-janitors
Ethan A Burns wrote:
> Richard,
> New patch is at the bottom. I was unaware of
> Documentation/feature-removal-schedule.txt. Since this is already schedueled
> for removal, does this mean that this is an unneeded patch? This item was on
> the TODO list, which is why I decided to take a stab at it.
>
> --Ethan
>
>
(please don't top-post ;) )
The cleaning up of the drivers is needed, it is just the removal of
pci_module_init() that needs to be left out (just to minimize the risk
of people complaining it was removed ahead of time). And if you don't
find anything more to do, I would appreciate any help to replace the
#define FALSE/TRUE-mess we currently have in the tree with the newly (in
linus-tree just before 2.6.19-rc1) added false/true (is defined in
include/linux/stddef.h).
> Subject: [PATCH] Changed all calls to pci_module_init to be pci_register_device.
>
> This change was necessary because pci_module_init is obsolete.
>
> Signed-off-by: Ethan A. Burns <burns.ethan@gmail.com>
> ---
> drivers/ata/ata_generic.c | 2 +-
> drivers/ata/pata_pdc2027x.c | 2 +-
> drivers/char/ipmi/ipmi_si_intf.c | 4 +---
> drivers/net/hp100.c | 4 +---
> drivers/scsi/megaraid.c | 2 +-
> drivers/scsi/tmscsim.c | 2 +-
> include/linux/pci.h | 6 ------
> 7 files changed, 6 insertions(+), 16 deletions(-)
>
<snip>
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 09be0f8..70278cc 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -389,12 +389,6 @@ #define PCI_DEVICE_CLASS(dev_class,dev_c
> .vendor = PCI_ANY_ID, .device = PCI_ANY_ID, \
> .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID
>
> -/*
> - * pci_module_init is obsolete, this stays here till we fix up all usages of it
> - * in the tree.
> - */
> -#define pci_module_init pci_register_driver
> -
> /* these external functions are only available when PCI support is enabled */
> #ifdef CONFIG_PCI
>
>
Except for the above, I 'ack' it.
cu around
Richard Knutsson
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [KJ] [PATCH] Changed all calls to pci_module_init to
2006-10-28 20:10 [KJ] [PATCH] Changed all calls to pci_module_init to be Ethan A Burns
` (2 preceding siblings ...)
2006-10-30 17:15 ` Richard Knutsson
@ 2006-10-30 17:40 ` Ethan A Burns
2006-10-31 3:54 ` Richard Knutsson
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Ethan A Burns @ 2006-10-30 17:40 UTC (permalink / raw)
To: kernel-janitors
> Ethan A Burns wrote:
> >Richard,
> > New patch is at the bottom. I was unaware of
> >Documentation/feature-removal-schedule.txt. Since this is already
> >schedueled
> >for removal, does this mean that this is an unneeded patch? This item was
> >on
> >the TODO list, which is why I decided to take a stab at it.
> >
> > --Ethan
> >
> >
> (please don't top-post ;) )
Sorry, I didn't know about top-posting, and probably other mailing
list etiquitte that we will findout as I go.
>
> The cleaning up of the drivers is needed, it is just the removal of
> pci_module_init() that needs to be left out (just to minimize the risk
> of people complaining it was removed ahead of time). And if you don't
> find anything more to do, I would appreciate any help to replace the
> #define FALSE/TRUE-mess we currently have in the tree with the newly (in
> linus-tree just before 2.6.19-rc1) added false/true (is defined in
> include/linux/stddef.h).
I wouldn't mind doing that. Just a simple find/replace of 'FALSE' with 'false'
and 'TRUE' with 'true'? Even these simple (tedious) things are a good
learning experience for me, if nothing else than to just get use to sending
patches, etc.
--Ethan
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [KJ] [PATCH] Changed all calls to pci_module_init to
2006-10-28 20:10 [KJ] [PATCH] Changed all calls to pci_module_init to be Ethan A Burns
` (3 preceding siblings ...)
2006-10-30 17:40 ` Ethan A Burns
@ 2006-10-31 3:54 ` Richard Knutsson
2006-10-31 8:46 ` [KJ] [PATCH] Changed all calls to pci_module_init to be Suren Naidu
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Richard Knutsson @ 2006-10-31 3:54 UTC (permalink / raw)
To: kernel-janitors
Ethan A Burns wrote:
>> The cleaning up of the drivers is needed, it is just the removal of
>> pci_module_init() that needs to be left out (just to minimize the risk
>> of people complaining it was removed ahead of time). And if you don't
>> find anything more to do, I would appreciate any help to replace the
>> #define FALSE/TRUE-mess we currently have in the tree with the newly (in
>> linus-tree just before 2.6.19-rc1) added false/true (is defined in
>> include/linux/stddef.h).
>>
>
> I wouldn't mind doing that. Just a simple find/replace of 'FALSE' with 'false'
> and 'TRUE' with 'true'?
Both yes and no. Of course you can do a simple replace (like just using
sed with "s/FALSE/false/") but I think it is a good idea to check the
paths for the variables to see they are real booleans (only gets 'false'
and 'true', also only used in logical operations) and also clean up
things like "if (b = TRUE)". If you make such a patch, can you cc: me
too, please?
> Even these simple (tedious) things are a good
> learning experience for me, if nothing else than to just get use to sending
> patches, etc.
>
You got the diffstat right and there where no errors in the patch (no
line-wrapping or etc. that I could see), so good work. :)
cu around
Richard Knutsson
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [KJ] [PATCH] Changed all calls to pci_module_init to be
2006-10-28 20:10 [KJ] [PATCH] Changed all calls to pci_module_init to be Ethan A Burns
` (4 preceding siblings ...)
2006-10-31 3:54 ` Richard Knutsson
@ 2006-10-31 8:46 ` Suren Naidu
2006-11-01 1:41 ` Richard Knutsson
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Suren Naidu @ 2006-10-31 8:46 UTC (permalink / raw)
To: kernel-janitors
> >
> > I wouldn't mind doing that. Just a simple find/replace of 'FALSE' with 'false'
> > and 'TRUE' with 'true'?
> Both yes and no. Of course you can do a simple replace (like just using
> sed with "s/FALSE/false/") but I think it is a good idea to check the
> paths for the variables to see they are real booleans (only gets 'false'
> and 'true', also only used in logical operations) and also clean up
> things like "if (b = TRUE)". If you make such a patch, can you cc: me
> too, please?
Is this a janitor project ? Is anyone working on it ?
Suren
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [KJ] [PATCH] Changed all calls to pci_module_init to be
2006-10-28 20:10 [KJ] [PATCH] Changed all calls to pci_module_init to be Ethan A Burns
` (5 preceding siblings ...)
2006-10-31 8:46 ` [KJ] [PATCH] Changed all calls to pci_module_init to be Suren Naidu
@ 2006-11-01 1:41 ` Richard Knutsson
2006-11-01 1:46 ` eaburns
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Richard Knutsson @ 2006-11-01 1:41 UTC (permalink / raw)
To: kernel-janitors
Suren Naidu wrote:
>> >
>> > I wouldn't mind doing that. Just a simple find/replace of 'FALSE'
>> with 'false'
>> > and 'TRUE' with 'true'?
>> Both yes and no. Of course you can do a simple replace (like just using
>> sed with "s/FALSE/false/") but I think it is a good idea to check the
>> paths for the variables to see they are real booleans (only gets 'false'
>> and 'true', also only used in logical operations) and also clean up
>> things like "if (b = TRUE)". If you make such a patch, can you cc: me
>> too, please?
>
> Is this a janitor project ? Is anyone working on it ?
Not really, have not thought about it actually. Just thought, since
there is a generic boolean in the kernel now, it would be a good
janitorial task, don't you think? I have yet to get around and start
seriously produce patches and if it should be a "project", who should I
see about that?
cu
Richard Knutsson
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [KJ] [PATCH] Changed all calls to pci_module_init to be
2006-10-28 20:10 [KJ] [PATCH] Changed all calls to pci_module_init to be Ethan A Burns
` (6 preceding siblings ...)
2006-11-01 1:41 ` Richard Knutsson
@ 2006-11-01 1:46 ` eaburns
2006-11-01 2:28 ` Richard Knutsson
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: eaburns @ 2006-11-01 1:46 UTC (permalink / raw)
To: kernel-janitors
> >> >
> >> > I wouldn't mind doing that. Just a simple find/replace of 'FALSE'
> >> with 'false'
> >> > and 'TRUE' with 'true'?
> >> Both yes and no. Of course you can do a simple replace (like just using
> >> sed with "s/FALSE/false/") but I think it is a good idea to check the
> >> paths for the variables to see they are real booleans (only gets 'false'
> >> and 'true', also only used in logical operations) and also clean up
> >> things like "if (b = TRUE)". If you make such a patch, can you cc: me
> >> too, please?
> >
> > Is this a janitor project ? Is anyone working on it ?
> Not really, have not thought about it actually. Just thought, since
> there is a generic boolean in the kernel now, it would be a good
> janitorial task, don't you think? I have yet to get around and start
> seriously produce patches and if it should be a "project", who should I
> see about that?
Maybe this is more of a newbie question than a janitorial question:
I was going to try to fix a few of these, however, I was not sure how to get
certain files to compile. For example, I found a few arch/ppc files that I
tried to make this change to, but I do not have a ppc I have an x86_64 and an
i386. Is there at way that I can at least try to compile these files? I
realize that I wouldn't be able to test it, but in a case like this I feel
like a successfull compile would be a good start.
If there is no easy (I could probably do a complete cross compile, but that's
a lot more work than I am willing to do for this little change I made) way to
compile this, what's the usual procedure for somthing like this? Don't do the
change if you can't compile it, or make a patch and see if someone else will
try it for you?
--Ethan
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [KJ] [PATCH] Changed all calls to pci_module_init to be
2006-10-28 20:10 [KJ] [PATCH] Changed all calls to pci_module_init to be Ethan A Burns
` (7 preceding siblings ...)
2006-11-01 1:46 ` eaburns
@ 2006-11-01 2:28 ` Richard Knutsson
2006-11-01 2:31 ` Richard Knutsson
2006-11-01 4:03 ` Randy Dunlap
10 siblings, 0 replies; 12+ messages in thread
From: Richard Knutsson @ 2006-11-01 2:28 UTC (permalink / raw)
To: kernel-janitors
eaburns@bender.eaburns.mooo.com wrote:
>>>>> I wouldn't mind doing that. Just a simple find/replace of 'FALSE'
>>>>>
>>>> with 'false'
>>>>
>>>>> and 'TRUE' with 'true'?
>>>>>
>>>> Both yes and no. Of course you can do a simple replace (like just using
>>>> sed with "s/FALSE/false/") but I think it is a good idea to check the
>>>> paths for the variables to see they are real booleans (only gets 'false'
>>>> and 'true', also only used in logical operations) and also clean up
>>>> things like "if (b = TRUE)". If you make such a patch, can you cc: me
>>>> too, please?
>>>>
>>> Is this a janitor project ? Is anyone working on it ?
>>>
>> Not really, have not thought about it actually. Just thought, since
>> there is a generic boolean in the kernel now, it would be a good
>> janitorial task, don't you think? I have yet to get around and start
>> seriously produce patches and if it should be a "project", who should I
>> see about that?
>>
>
> Maybe this is more of a newbie question than a janitorial question:
> I was going to try to fix a few of these, however, I was not sure how to get
> certain files to compile. For example, I found a few arch/ppc files that I
> tried to make this change to, but I do not have a ppc I have an x86_64 and an
> i386. Is there at way that I can at least try to compile these files? I
> realize that I wouldn't be able to test it, but in a case like this I feel
> like a successfull compile would be a good start.
>
> If there is no easy (I could probably do a complete cross compile, but that's
> a lot more work than I am willing to do for this little change I made) way to
> compile this, what's the usual procedure for somthing like this? Don't do the
> change if you can't compile it, or make a patch and see if someone else will
> try it for you?
>
> --Ethan
>
I believe a cross-compiler is the only way to compile it in your case,
so I would think a good re-reading, and yet another, would be sufficient
to then send it to the mailing-list with a note that you have not
compiled it (and why). Hopefully someone with the ability will do it for
you.
After all, if you find something suspicious but you can't fix it, you
still can mail the list with the problem, because we are all here to
make a damn good kernel, aren't we ;)
Just my opinion...
Richard Knutsson
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [KJ] [PATCH] Changed all calls to pci_module_init to be
2006-10-28 20:10 [KJ] [PATCH] Changed all calls to pci_module_init to be Ethan A Burns
` (8 preceding siblings ...)
2006-11-01 2:28 ` Richard Knutsson
@ 2006-11-01 2:31 ` Richard Knutsson
2006-11-01 4:03 ` Randy Dunlap
10 siblings, 0 replies; 12+ messages in thread
From: Richard Knutsson @ 2006-11-01 2:31 UTC (permalink / raw)
To: kernel-janitors
eaburns@bender.eaburns.mooo.com wrote:
>>>>> I wouldn't mind doing that. Just a simple find/replace of 'FALSE'
>>>>>
>>>> with 'false'
>>>>
>>>>> and 'TRUE' with 'true'?
>>>>>
>>>> Both yes and no. Of course you can do a simple replace (like just using
>>>> sed with "s/FALSE/false/") but I think it is a good idea to check the
>>>> paths for the variables to see they are real booleans (only gets 'false'
>>>> and 'true', also only used in logical operations) and also clean up
>>>> things like "if (b = TRUE)". If you make such a patch, can you cc: me
>>>> too, please?
>>>>
>>> Is this a janitor project ? Is anyone working on it ?
>>>
>> Not really, have not thought about it actually. Just thought, since
>> there is a generic boolean in the kernel now, it would be a good
>> janitorial task, don't you think? I have yet to get around and start
>> seriously produce patches and if it should be a "project", who should I
>> see about that?
>>
>
> Maybe this is more of a newbie question than a janitorial question:
> I was going to try to fix a few of these, however, I was not sure how to get
> certain files to compile. For example, I found a few arch/ppc files that I
> tried to make this change to, but I do not have a ppc I have an x86_64 and an
> i386. Is there at way that I can at least try to compile these files? I
> realize that I wouldn't be able to test it, but in a case like this I feel
> like a successfull compile would be a good start.
>
> If there is no easy (I could probably do a complete cross compile, but that's
> a lot more work than I am willing to do for this little change I made) way to
> compile this, what's the usual procedure for somthing like this? Don't do the
> change if you can't compile it, or make a patch and see if someone else will
> try it for you?
>
> --Ethan
>
I believe a cross-compiler is the only way to compile it in your case,
so I would think a good re-reading, and yet another, would be sufficient
to then send it to the mailing-list with a note that you have not
compiled it (and why). Hopefully someone with the ability will do it for
you.
After all, if you find something suspicious but you can't fix it, you
still can mail the list with the problem, because we are all here to
make a damn good kernel, aren't we ;)
Just my opinion...
Richard Knutsson
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [KJ] [PATCH] Changed all calls to pci_module_init to be
2006-10-28 20:10 [KJ] [PATCH] Changed all calls to pci_module_init to be Ethan A Burns
` (9 preceding siblings ...)
2006-11-01 2:31 ` Richard Knutsson
@ 2006-11-01 4:03 ` Randy Dunlap
10 siblings, 0 replies; 12+ messages in thread
From: Randy Dunlap @ 2006-11-01 4:03 UTC (permalink / raw)
To: kernel-janitors
On Tue, 31 Oct 2006 20:46:17 -0500 eaburns@bender.eaburns.mooo.com wrote:
> > >> >
> > >> > I wouldn't mind doing that. Just a simple find/replace of 'FALSE'
> > >> with 'false'
> > >> > and 'TRUE' with 'true'?
> > >> Both yes and no. Of course you can do a simple replace (like just using
> > >> sed with "s/FALSE/false/") but I think it is a good idea to check the
> > >> paths for the variables to see they are real booleans (only gets 'false'
> > >> and 'true', also only used in logical operations) and also clean up
> > >> things like "if (b = TRUE)". If you make such a patch, can you cc: me
> > >> too, please?
> > >
> > > Is this a janitor project ? Is anyone working on it ?
> > Not really, have not thought about it actually. Just thought, since
> > there is a generic boolean in the kernel now, it would be a good
> > janitorial task, don't you think? I have yet to get around and start
> > seriously produce patches and if it should be a "project", who should I
> > see about that?
>
> Maybe this is more of a newbie question than a janitorial question:
> I was going to try to fix a few of these, however, I was not sure how to get
> certain files to compile. For example, I found a few arch/ppc files that I
> tried to make this change to, but I do not have a ppc I have an x86_64 and an
> i386. Is there at way that I can at least try to compile these files? I
> realize that I wouldn't be able to test it, but in a case like this I feel
> like a successfull compile would be a good start.
>
> If there is no easy (I could probably do a complete cross compile, but that's
> a lot more work than I am willing to do for this little change I made) way to
> compile this, what's the usual procedure for somthing like this? Don't do the
> change if you can't compile it, or make a patch and see if someone else will
> try it for you?
cross-compile or submit the patch to a build farm.
OSDL offers pre-built cross-build toolchains at
http://developer.osdl.org/dev/plm/cross_compile/
or a build farm at: http://plm.testing.osdl.org/
(you have to register to use this).
---
~Randy
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 12+ messages in thread