/sys/firmware/acpi (Re: [ACPI] [PATCH/RFC 4/4]An experimentalimplementation for IDE bus)

From: Len Brown
Date: Tue Nov 09 2004 - 01:03:05 EST

On Mon, 2004-11-08 at 10:24, Matthew Wilcox wrote:
> ... Are we ever going to do anything
> with /sys/firmware/acpi/namespace/ or will it just stay around
> consuming inodes and dentries for no good reason?

When I suggested deleting /sys/firmware/acpi, Patrick replied that his
intention was that real devices would have symbolic links into that

I think this is not the best way to go. Two simple reasons come to

The ACPI device hierarchy reflects the actual layout of the system
devices better than the current /sys/devices/ tree, linking into it from
/sys/devices doesn't fix /sys/devices. Instead we need to consult ACPI
during the actual construction of /sys/devices/.

While the layout reflects reality, the device names in
/sys/firmware/acpi are arbitrary internal BIOS names, and so there will
never be any consistency between systems such that a human or a program
could have an easy time navigating the tree structure.

The argument in favor of exposing the tree has been for things like Alex
Williamson's patch to invoke ACPI methods by reading /sysfs. But this
is a really neat solution looking for a problem. if and when such a
problem is found, the same technique can always be made available under
the real /sys/devices tree.


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