On Apr 9, 2005 12:07 PM, Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Sat, Apr 09, 2005 at 12:03:45PM +0200, Magnus Damm wrote:
> >
> > > Perhaps they should start using initramfs then.
> >
> > But how does that help me? I still want to be able to pass a list of
> > unwanted modules on the kernel
On Sat, Apr 09, 2005 at 12:03:45PM +0200, Magnus Damm wrote:
>
> > Perhaps they should start using initramfs then.
>
> But how does that help me? I still want to be able to pass a list of
> unwanted modules on the kernel command line. Using initramfs and
> modules is fine, although I would prefer
On Apr 9, 2005 11:48 AM, Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Sat, Apr 09, 2005 at 11:43:59AM +0200, Magnus Damm wrote:
> >
> > > Perhaps your favourite distribution could build that as a module to
> > > start with.
> >
> > Right. Today distributions can boot from external usb-storage
On Sat, Apr 09, 2005 at 11:43:59AM +0200, Magnus Damm wrote:
>
> > Perhaps your favourite distribution could build that as a module to
> > start with.
>
> Right. Today distributions can boot from external usb-storage devices,
> maybe even from firewire hardware as I am sure you know. I guess they
On Apr 9, 2005 3:42 AM, Herbert Xu <[EMAIL PROTECTED]> wrote:
> Magnus Damm <[EMAIL PROTECTED]> wrote:
> >
> > Say a kernel shipped with your favourite distribution crashes your
> > machine during boot-up - wouldn't it be nice to be able to just
> > disable the problematic module from the kernel
On Apr 9, 2005 3:42 AM, Herbert Xu [EMAIL PROTECTED] wrote:
Magnus Damm [EMAIL PROTECTED] wrote:
Say a kernel shipped with your favourite distribution crashes your
machine during boot-up - wouldn't it be nice to be able to just
disable the problematic module from the kernel command line
On Sat, Apr 09, 2005 at 11:43:59AM +0200, Magnus Damm wrote:
Perhaps your favourite distribution could build that as a module to
start with.
Right. Today distributions can boot from external usb-storage devices,
maybe even from firewire hardware as I am sure you know. I guess they
have
On Apr 9, 2005 11:48 AM, Herbert Xu [EMAIL PROTECTED] wrote:
On Sat, Apr 09, 2005 at 11:43:59AM +0200, Magnus Damm wrote:
Perhaps your favourite distribution could build that as a module to
start with.
Right. Today distributions can boot from external usb-storage devices,
maybe even
On Sat, Apr 09, 2005 at 12:03:45PM +0200, Magnus Damm wrote:
Perhaps they should start using initramfs then.
But how does that help me? I still want to be able to pass a list of
unwanted modules on the kernel command line. Using initramfs and
modules is fine, although I would prefer being
On Apr 9, 2005 12:07 PM, Herbert Xu [EMAIL PROTECTED] wrote:
On Sat, Apr 09, 2005 at 12:03:45PM +0200, Magnus Damm wrote:
Perhaps they should start using initramfs then.
But how does that help me? I still want to be able to pass a list of
unwanted modules on the kernel command line.
Magnus Damm <[EMAIL PROTECTED]> wrote:
>
> Say a kernel shipped with your favourite distribution crashes your
> machine during boot-up - wouldn't it be nice to be able to just
> disable the problematic module from the kernel command line instead of
Perhaps your favourite distribution could build
Magnus Damm [EMAIL PROTECTED] wrote:
Say a kernel shipped with your favourite distribution crashes your
machine during boot-up - wouldn't it be nice to be able to just
disable the problematic module from the kernel command line instead of
Perhaps your favourite distribution could build that
On Apr 7, 2005 4:38 AM, Horst von Brand <[EMAIL PROTECTED]> wrote:
> AsterixTheGaul <[EMAIL PROTECTED]> said:
> > > -#define module_init(x) __initcall(x);
> > > +#define module_init(x) __initcall(x); __module_init_disable(x);
> >
> > It would be better if there is brackets around them... like
> >
On Apr 7, 2005 7:29 PM, Randy.Dunlap <[EMAIL PROTECTED]> wrote:
> On Thu, 7 Apr 2005 13:22:57 -0400 (EDT) Richard B. Johnson wrote:
> | Can't you disable module-loading with a module? I think so.
> | You don't need to modify the kernel. Boot-scripts could
> | just load the "final" module and there
On Thu, Apr 07, 2005 at 01:22:57PM -0400, Richard B. Johnson wrote:
> >| Anyway, besides nitpicking, is there any reason not to include this
> >| code? Or is the added feature considered plain bloat? Yes, the kernel
> >| will become a bit larger, but all the data added by this patch will go
>
On Thu, 7 Apr 2005 13:22:57 -0400 (EDT) Richard B. Johnson wrote:
| On Thu, 7 Apr 2005, Randy.Dunlap wrote:
|
| > On Thu, 7 Apr 2005 10:23:32 +0200 Magnus Damm wrote:
| >
| > | On Apr 7, 2005 4:23 AM, Roland Dreier <[EMAIL PROTECTED]> wrote:
| > | > > > -#define module_init(x) __initcall(x);
|
On Thu, 7 Apr 2005, Randy.Dunlap wrote:
On Thu, 7 Apr 2005 10:23:32 +0200 Magnus Damm wrote:
| On Apr 7, 2005 4:23 AM, Roland Dreier <[EMAIL PROTECTED]> wrote:
| > > > -#define module_init(x) __initcall(x);
| > > > +#define module_init(x) __initcall(x); __module_init_disable(x);
| > >
| > > It
On Thu, 7 Apr 2005 10:23:32 +0200 Magnus Damm wrote:
| On Apr 7, 2005 4:23 AM, Roland Dreier <[EMAIL PROTECTED]> wrote:
| > > > -#define module_init(x) __initcall(x);
| > > > +#define module_init(x) __initcall(x); __module_init_disable(x);
| > >
| > > It would be better if there is brackets
AsterixTheGaul <[EMAIL PROTECTED]> said:
> > -#define module_init(x) __initcall(x);
> > +#define module_init(x) __initcall(x); __module_init_disable(x);
>
> It would be better if there is brackets around them... like
>
> #define module_init(x) { __initcall(x); __module_init_disable(x); }
>
>
On Apr 7, 2005 4:23 AM, Roland Dreier <[EMAIL PROTECTED]> wrote:
> > > -#define module_init(x) __initcall(x);
> > > +#define module_init(x) __initcall(x); __module_init_disable(x);
> >
> > It would be better if there is brackets around them... like
> >
> > #define module_init(x) {
On Thu, 7 Apr 2005, Magnus Damm wrote:
> On Apr 6, 2005 4:28 PM, Malcolm Rowe <[EMAIL PROTECTED]> wrote:
> > Magnus Damm writes:
> > > And I guess the idea of replacing the initcall pointer with NULL will
> > > work both with and without function descriptors, right? So we should
> > > be safe on
On Thu, 7 Apr 2005, Magnus Damm wrote:
On Apr 6, 2005 4:28 PM, Malcolm Rowe [EMAIL PROTECTED] wrote:
Magnus Damm writes:
And I guess the idea of replacing the initcall pointer with NULL will
work both with and without function descriptors, right? So we should
be safe on IA64 and
On Apr 7, 2005 4:23 AM, Roland Dreier [EMAIL PROTECTED] wrote:
-#define module_init(x) __initcall(x);
+#define module_init(x) __initcall(x); __module_init_disable(x);
It would be better if there is brackets around them... like
#define module_init(x) { __initcall(x);
AsterixTheGaul [EMAIL PROTECTED] said:
-#define module_init(x) __initcall(x);
+#define module_init(x) __initcall(x); __module_init_disable(x);
It would be better if there is brackets around them... like
#define module_init(x) { __initcall(x); __module_init_disable(x); }
then we know
On Thu, 7 Apr 2005 10:23:32 +0200 Magnus Damm wrote:
| On Apr 7, 2005 4:23 AM, Roland Dreier [EMAIL PROTECTED] wrote:
| -#define module_init(x) __initcall(x);
| +#define module_init(x) __initcall(x); __module_init_disable(x);
|
|It would be better if there is brackets around
On Thu, 7 Apr 2005, Randy.Dunlap wrote:
On Thu, 7 Apr 2005 10:23:32 +0200 Magnus Damm wrote:
| On Apr 7, 2005 4:23 AM, Roland Dreier [EMAIL PROTECTED] wrote:
| -#define module_init(x) __initcall(x);
| +#define module_init(x) __initcall(x); __module_init_disable(x);
|
|It would be
On Thu, 7 Apr 2005 13:22:57 -0400 (EDT) Richard B. Johnson wrote:
| On Thu, 7 Apr 2005, Randy.Dunlap wrote:
|
| On Thu, 7 Apr 2005 10:23:32 +0200 Magnus Damm wrote:
|
| | On Apr 7, 2005 4:23 AM, Roland Dreier [EMAIL PROTECTED] wrote:
| | -#define module_init(x) __initcall(x);
| |
On Thu, Apr 07, 2005 at 01:22:57PM -0400, Richard B. Johnson wrote:
| Anyway, besides nitpicking, is there any reason not to include this
| code? Or is the added feature considered plain bloat? Yes, the kernel
| will become a bit larger, but all the data added by this patch will go
| into
On Apr 7, 2005 7:29 PM, Randy.Dunlap [EMAIL PROTECTED] wrote:
On Thu, 7 Apr 2005 13:22:57 -0400 (EDT) Richard B. Johnson wrote:
| Can't you disable module-loading with a module? I think so.
| You don't need to modify the kernel. Boot-scripts could
| just load the final module and there is
On Apr 7, 2005 4:38 AM, Horst von Brand [EMAIL PROTECTED] wrote:
AsterixTheGaul [EMAIL PROTECTED] said:
-#define module_init(x) __initcall(x);
+#define module_init(x) __initcall(x); __module_init_disable(x);
It would be better if there is brackets around them... like
#define
> > -#define module_init(x) __initcall(x);
> > +#define module_init(x) __initcall(x); __module_init_disable(x);
>
> It would be better if there is brackets around them... like
>
> #define module_init(x) { __initcall(x); __module_init_disable(x); }
>
> then we know it wont break some code
Hi,
> -#define module_init(x) __initcall(x);
> +#define module_init(x) __initcall(x); __module_init_disable(x);
It would be better if there is brackets around them... like
#define module_init(x) { __initcall(x); __module_init_disable(x); }
then we know it wont break some code like
if (..)
On Apr 6, 2005 4:28 PM, Malcolm Rowe <[EMAIL PROTECTED]> wrote:
> Magnus Damm writes:
> > And I guess the idea of replacing the initcall pointer with NULL will
> > work both with and without function descriptors, right? So we should
> > be safe on IA64 and PPC64.
>
> I think so, though I don't
Magnus Damm writes:
Regardless of anything else, won't this break booting with initcall_debug on
PPC64/IA64 machines? (see the definition of print_fn_descriptor_symbol() in
kallsyms.h)
Correct, thanks for pointing that out. The code below is probably better:
static void __init
On Apr 6, 2005 12:32 PM, Malcolm Rowe <[EMAIL PROTECTED]> wrote:
> Magnus Damm writes:
> > Here comes version 2 of the disable built-in patch.
>
> > +void __init disable_initcall(void *fn)
> > +{
> > + initcall_t *call;
> > +
> > + for (call = __initcall_start; call < __initcall_end;
Magnus Damm writes:
Here comes version 2 of the disable built-in patch.
+void __init disable_initcall(void *fn)
+{
+ initcall_t *call;
+
+ for (call = __initcall_start; call < __initcall_end; call++) {
+
+ if (*call == fn)
+ *call = NULL;
+ }
On Apr 6, 2005 12:32 PM, Malcolm Rowe [EMAIL PROTECTED] wrote:
Magnus Damm writes:
Here comes version 2 of the disable built-in patch.
+void __init disable_initcall(void *fn)
+{
+ initcall_t *call;
+
+ for (call = __initcall_start; call __initcall_end; call++) {
+
+
Magnus Damm writes:
Regardless of anything else, won't this break booting with initcall_debug on
PPC64/IA64 machines? (see the definition of print_fn_descriptor_symbol() in
kallsyms.h)
Correct, thanks for pointing that out. The code below is probably better:
static void __init
On Apr 6, 2005 4:28 PM, Malcolm Rowe [EMAIL PROTECTED] wrote:
Magnus Damm writes:
And I guess the idea of replacing the initcall pointer with NULL will
work both with and without function descriptors, right? So we should
be safe on IA64 and PPC64.
I think so, though I don't really know a
Hi,
-#define module_init(x) __initcall(x);
+#define module_init(x) __initcall(x); __module_init_disable(x);
It would be better if there is brackets around them... like
#define module_init(x) { __initcall(x); __module_init_disable(x); }
then we know it wont break some code like
if (..)
-#define module_init(x) __initcall(x);
+#define module_init(x) __initcall(x); __module_init_disable(x);
It would be better if there is brackets around them... like
#define module_init(x) { __initcall(x); __module_init_disable(x); }
then we know it wont break some code like
Here comes version 2 of the disable built-in patch.
This patch makes it possible to disable built-in code from the kernel
command line. The patch is rather simple - it extends the compiled-in case
of module_init() to include __setup() with a name based on KBUILD_MODNAME.
As an example, if you
Here comes version 2 of the disable built-in patch.
This patch makes it possible to disable built-in code from the kernel
command line. The patch is rather simple - it extends the compiled-in case
of module_init() to include __setup() with a name based on KBUILD_MODNAME.
As an example, if you
43 matches
Mail list logo
