Re: [PATCH 0/5][RFC] Physical PCI slot objects

[Alex Chiang]

* 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-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/