* Andi Kleen <andi@xxxxxxxxxxxxxx>: > On Wed, Nov 14, 2007 at 08:00:25AM -0700, Matthew Wilcox wrote: > > On Wed, Nov 14, 2007 at 03:35:33PM +0100, Andi Kleen wrote: > > > It becomes much more when someone does a find /sys. > > > dentries are expensive. They eventually can get pruned > > > again, but it's still costly to do that. > > > > Again, if this is a big concern for you, there are better > > places to look at for savings. > > Whoever is proposing a feature has the burden to justify that > its usefulness is larger than the overhead/cost it adds. > > Doesn't seem to be the case with this one so far. I'm a bit confused where you're going with this. I thought the main point of contention wasn't around the utility of the patchset, it was around getting the actual information correct. We've already mentioned several uses that this patchset adds: 1. allowing managability folks to determine which physical slot their failing card might be sitting in (independent of hotplug capability). 2. giving installers a method of presenting the physical slot to the user so that the user can choose to, say, do a network install off of the card in slot N, vs having to guess based on MAC address or something else unfriendly 3. performance monitoring tools based on slot addresses/numbers I believe that userspace cares more about those sorts of things compared to consuming extra bytes when creating sysfs entries. > And in general ignoring overhead in new features is a pretty > sad approach. Big bloat does come in small steps with each new > feature. I'm kinda new to the Linux kernel, so I don't really get what you're saying. Are you saying that the approved method of exposing kernel information to the user via sysfs is actually bloat? Even if that information has utility? Feel free to educate me; I'm here to learn. Thanks. /ac - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
