Re: [PATCH][RFC] disable built-in modules V2
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 do_initcalls(void)
{
initcall_t *call;
@@ -547,6 +558,9 @@ static void __init do_initcalls(void)
for (call = __initcall_start; call < __initcall_end; call++) {
char *msg;
+ if (!*call)
+ continue;
+
if (initcall_debug) {
printk(KERN_DEBUG "Calling initcall 0x%p", *call);
print_fn_descriptor_symbol(": %s()", (unsigned
long) *call);
Yes, that looks more sensible. It hides the fact that the initcall ever
existed, rather than explicitly telling you that it's been skipped, but I
don't imagine that that's ever going to cause a problem in practice (i.e., I
don't think anyone would ever enable "force_ohci1394=off" by mistake and
also without noticing).
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 great deal about this area.
An IA64 descriptor is of the form { , _context }, and a function
pointer is a pointer to such a descriptor. Presumably, setting a function
pointer to NULL will either end up setting the pointer-to-descriptor to NULL
or the code pointer to NULL, but either way, I would expect the 'if
(!*call)' comparison to work as intended.
Best thing would be to get someone on IA64 and/or PPC64 to check this for
you. Also might be worth checking that the patch works as intended with
CONFIG_MODULES=n (assuming you haven't already).
Regards,
Malcolm
-
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][RFC] disable built-in modules V2
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;
+ }
+}
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)
Regards,
Malcolm
-
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][RFC] disable built-in modules V2
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 do_initcalls(void)
{
initcall_t *call;
@@ -547,6 +558,9 @@ static void __init do_initcalls(void)
for (call = __initcall_start; call __initcall_end; call++) {
char *msg;
+ if (!*call)
+ continue;
+
if (initcall_debug) {
printk(KERN_DEBUG Calling initcall 0x%p, *call);
print_fn_descriptor_symbol(: %s(), (unsigned
long) *call);
Yes, that looks more sensible. It hides the fact that the initcall ever
existed, rather than explicitly telling you that it's been skipped, but I
don't imagine that that's ever going to cause a problem in practice (i.e., I
don't think anyone would ever enable force_ohci1394=off by mistake and
also without noticing).
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 great deal about this area.
An IA64 descriptor is of the form { code, data_context }, and a function
pointer is a pointer to such a descriptor. Presumably, setting a function
pointer to NULL will either end up setting the pointer-to-descriptor to NULL
or the code pointer to NULL, but either way, I would expect the 'if
(!*call)' comparison to work as intended.
Best thing would be to get someone on IA64 and/or PPC64 to check this for
you. Also might be worth checking that the patch works as intended with
CONFIG_MODULES=n (assuming you haven't already).
Regards,
Malcolm
-
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] Symlink /sys/class/block to /sys/block (fwd)
Greg KH writes: Following the discussion in [1], the attached patch creates /sys/class/block as a symlink to /sys/block. The patch applies to 2.6.11-rc4-bk7. Please cc: me on any replies - I'm not subscribed to the mailing list. Hm, your patch is linewrapped, and can't be applied :( Bah, and I did send it to myself first, but I guess my mailer un-flowed it for me :-(. I'll try to find a better mailer. But more importantly: static void disk_release(struct kobject * kobj) Did you try to remove a disk (like a usb device) and see what happens here? Hint, this isn't the proper place to remove the symlink... Er, yeah. Oops. *Is* there a sensible place to remove the symlink from, though? Nobody seems to call subsystem_unregister(_subsys), which is the place I'd expect to add a call to, and I can't see anything that's otherwise obvious... Regards, Malcolm [resent using the right address for linux-kernel. Sorry for the duplicate, Greg] - 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] Symlink /sys/class/block to /sys/block (fwd)
Greg KH writes: Following the discussion in [1], the attached patch creates /sys/class/block as a symlink to /sys/block. The patch applies to 2.6.11-rc4-bk7. Please cc: me on any replies - I'm not subscribed to the mailing list. Hm, your patch is linewrapped, and can't be applied :( Bah, and I did send it to myself first, but I guess my mailer un-flowed it for me :-(. I'll try to find a better mailer. But more importantly: static void disk_release(struct kobject * kobj) Did you try to remove a disk (like a usb device) and see what happens here? Hint, this isn't the proper place to remove the symlink... Er, yeah. Oops. *Is* there a sensible place to remove the symlink from, though? Nobody seems to call subsystem_unregister(block_subsys), which is the place I'd expect to add a call to, and I can't see anything that's otherwise obvious... Regards, Malcolm [resent using the right address for linux-kernel. Sorry for the duplicate, Greg] - 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] Symlink /sys/class/block to /sys/block
Greg,
Following the discussion in [1], the attached patch creates /sys/class/block
as a symlink to /sys/block. The patch applies to 2.6.11-rc4-bk7.
Please cc: me on any replies - I'm not subscribed to the mailing list.
[1] http://marc.theaimsgroup.com/?m=110506536315986
Regards,
Malcolm
Signed-off-by: Malcolm Rowe <[EMAIL PROTECTED]>
diff -ur linux-2.6.11-rc4-bk7/drivers/base/class.c
linux-2.6.11-rc4-bk7-diff/drivers/base/class.c
--- linux-2.6.11-rc4-bk7/drivers/base/class.c 2005-02-19 21:34:31.0
+
+++ linux-2.6.11-rc4-bk7-diff/drivers/base/class.c 2005-02-19
21:38:31.0 +
@@ -69,7 +69,7 @@
};
/* Hotplug events for classes go to the class_obj subsys */
-static decl_subsys(class, _class, NULL);
+decl_subsys(class, _class, NULL);
int class_create_file(struct class * cls, const struct class_attribute *
attr)
diff -ur linux-2.6.11-rc4-bk7/drivers/block/genhd.c
linux-2.6.11-rc4-bk7-diff/drivers/block/genhd.c
--- linux-2.6.11-rc4-bk7/drivers/block/genhd.c 2005-02-19 21:34:31.0
+
+++ linux-2.6.11-rc4-bk7-diff/drivers/block/genhd.c 2005-02-19
22:01:56.0 +
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#define MAX_PROBE_HASH 255 /* random */
@@ -300,11 +301,24 @@
return NULL;
}
+extern struct subsystem class_subsys;
+
static int __init genhd_device_init(void)
{
bdev_map = kobj_map_init(base_probe, _subsys);
blk_dev_init();
- subsystem_register(_subsys);
+ if (!subsystem_register(_subsys)) {
+ /*
+ * /sys/block should really live under /sys/class, but for
+ * the moment, we can only have class devices, not
+ * sub-classes-devices. Until we can move /sys/block into
+ * the right place, create a symlink from /sys/class/block to
+ * /sys/block, so that userspace doesn't need to know about
+ * the difference.
+ */
+ sysfs_create_link(_subsys.kset.kobj,
+ _subsys.kset.kobj, "block");
+ }
return 0;
}
@@ -406,6 +420,7 @@
static void disk_release(struct kobject * kobj)
{
struct gendisk *disk = to_disk(kobj);
+ sysfs_remove_link(_subsys.kset.kobj, "block");
kfree(disk->random);
kfree(disk->part);
free_disk_stats(disk);
-
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] Symlink /sys/class/block to /sys/block
Greg,
Following the discussion in [1], the attached patch creates /sys/class/block
as a symlink to /sys/block. The patch applies to 2.6.11-rc4-bk7.
Please cc: me on any replies - I'm not subscribed to the mailing list.
[1] http://marc.theaimsgroup.com/?m=110506536315986
Regards,
Malcolm
Signed-off-by: Malcolm Rowe [EMAIL PROTECTED]
diff -ur linux-2.6.11-rc4-bk7/drivers/base/class.c
linux-2.6.11-rc4-bk7-diff/drivers/base/class.c
--- linux-2.6.11-rc4-bk7/drivers/base/class.c 2005-02-19 21:34:31.0
+
+++ linux-2.6.11-rc4-bk7-diff/drivers/base/class.c 2005-02-19
21:38:31.0 +
@@ -69,7 +69,7 @@
};
/* Hotplug events for classes go to the class_obj subsys */
-static decl_subsys(class, ktype_class, NULL);
+decl_subsys(class, ktype_class, NULL);
int class_create_file(struct class * cls, const struct class_attribute *
attr)
diff -ur linux-2.6.11-rc4-bk7/drivers/block/genhd.c
linux-2.6.11-rc4-bk7-diff/drivers/block/genhd.c
--- linux-2.6.11-rc4-bk7/drivers/block/genhd.c 2005-02-19 21:34:31.0
+
+++ linux-2.6.11-rc4-bk7-diff/drivers/block/genhd.c 2005-02-19
22:01:56.0 +
@@ -14,6 +14,7 @@
#include linux/slab.h
#include linux/kmod.h
#include linux/kobj_map.h
+#include linux/sysfs.h
#define MAX_PROBE_HASH 255 /* random */
@@ -300,11 +301,24 @@
return NULL;
}
+extern struct subsystem class_subsys;
+
static int __init genhd_device_init(void)
{
bdev_map = kobj_map_init(base_probe, block_subsys);
blk_dev_init();
- subsystem_register(block_subsys);
+ if (!subsystem_register(block_subsys)) {
+ /*
+ * /sys/block should really live under /sys/class, but for
+ * the moment, we can only have class devices, not
+ * sub-classes-devices. Until we can move /sys/block into
+ * the right place, create a symlink from /sys/class/block to
+ * /sys/block, so that userspace doesn't need to know about
+ * the difference.
+ */
+ sysfs_create_link(class_subsys.kset.kobj,
+ block_subsys.kset.kobj, block);
+ }
return 0;
}
@@ -406,6 +420,7 @@
static void disk_release(struct kobject * kobj)
{
struct gendisk *disk = to_disk(kobj);
+ sysfs_remove_link(class_subsys.kset.kobj, block);
kfree(disk-random);
kfree(disk-part);
free_disk_stats(disk);
-
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/
