On Mon, Apr 10, 2006 at 06:20:52PM +0900, KAMEZAWA Hiroyuki wrote:
> This patch changes memoryX/phys_device to symbolic link.
>
> This phys_device always contains 0 now, and of no use.
>
> This patch changes it to symbolic link. acpi memohotplug is changed to support
> this.
>
> When this is applied, phys_device becomes meaningful.
> ==
> [kamezawa@casares ~]$ readlink /sys/devices/system/memory/memory10/phys_device
> ../../../../firmware/acpi/namespace/ACPI/_SB/LSB1/MEM2
>
> ==
> I posted previous version in Feb/2006.
> Several changes to acpi_memhotplug.c in these days simplified acpi part of
> this patch :) This patch is against 2.6.17-rc1-mm2.
>
> Note:
> There looks no code to make symbolic link to acpi namespace now. But this patch
> will not bother Patrick-san's acpi refactoring work now goes on.
> (I asked him , he answerd if enough simple.)
>
> [1/2] includes sysfs changes.
> [2/2] includes acpi memhoplug changes.
>
> Thanks,
> -Kame
>
> Now, memory device 's sysfs entry (/sys/devices/system/memory/memoryX)
> has phys_device file. Now, it contains just an integer.
> But it is always 0.
>
> The purpose of phys_device is to show relationship between memory section
> and physical ram device. But to show relationship, we have to maintain
> a table phys_device number <-> device.
>
> This patch changes phys_device file to symbolic link to the device.
> By this, phys_device directly points to a physical device to which it
> belongs to.
>
>
> Signed-Off-By: KAMEZAWA Hiroyuki <[email protected]>
>
> Index: linux-2.6.17-rc1-mm2/drivers/base/memory.c
> ===================================================================
> --- linux-2.6.17-rc1-mm2.orig/drivers/base/memory.c 2006-04-10 15:48:17.000000000 +0900
> +++ linux-2.6.17-rc1-mm2/drivers/base/memory.c 2006-04-10 15:50:19.000000000 +0900
> @@ -252,31 +252,33 @@
> return count;
> }
>
> -/*
> - * phys_device is a bad name for this. What I really want
> - * is a way to differentiate between memory ranges that
> - * are part of physical devices that constitute
> - * a complete removable unit or fru.
> - * i.e. do these ranges belong to the same physical device,
> - * s.t. if I offline all of these sections I can then
> - * remove the physical device?
> - */
> -static ssize_t show_phys_device(struct sys_device *dev, char *buf)
> -{
> - struct memory_block *mem =
> - container_of(dev, struct memory_block, sysdev);
> - return sprintf(buf, "%d\n", mem->phys_device);
> -}
>
> static SYSDEV_ATTR(phys_index, 0444, show_mem_phys_index, NULL);
> static SYSDEV_ATTR(state, 0644, show_mem_state, store_mem_state);
> -static SYSDEV_ATTR(phys_device, 0444, show_phys_device, NULL);
>
> #define mem_create_simple_file(mem, attr_name) \
> sysdev_create_file(&mem->sysdev, &attr_##attr_name)
> #define mem_remove_simple_file(mem, attr_name) \
> sysdev_remove_file(&mem->sysdev, &attr_##attr_name)
>
> +static int attach_phys_device(struct memory_block *mem, struct kobject *kobj)
> +{
> + int ret;
> + ret = sysfs_create_link(&mem->sysdev.kobj, kobj, "phys_device");
> + if (ret)
> + return ret;
> + mem->phys_device = kobj;
mem->phys_device = kobject_get(kobj);
is probably better, as you are storing a pointer to a kobject, so you
need to increment its reference count.
> +static void remove_phys_device(struct memory_block *mem)
> +{
> + if (mem->phys_device) {
> + sysfs_remove_link(&mem->sysdev.kobj, "phys_device");
> + mem->phys_device = NULL;
kobject_put(mem->phys_device);
mem->phys_device = NULL;
is a better way to do this.
And yes, the sysfs_create_link() function does increment the reference
count of the kobject, but it's better to be safe :)
thanks,
greg k-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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
