> > > Consider the lives of people administering large server farms or
^^^^^^^^^^^^^^^^^^^^
> > > clusters. Their hardware is not necessarily homogenous, and the
> > > ability to query the DMI tables on the fly could be useful both
> > > for administration and automatic process migration.
> > Given that 'dmidecode' works fine in those circumstances, that's still
> > not a convincing argument imo.
> But only for people and programs with root privileges.
^^^^^^
Someone building a new kernel for a box (ie administrator) will have
root priveledges. Though running 'make guessconfig' or whatever as
root would suck.
What Alan suggests (ripping the necessary bits out of dmidecode
and making a setuid program) sounds better, as long as someone
audits it afterwards.
> then, on whether we want to insist that all software doing hardware
> probing must have root privileges to function.
probing isa isn't pretty. which is why we don't have anything
as nice as /proc/bus/pci. The pnpbios support goes a little towards
this, but only detects PNP cards obviously. Ye olde ISA is all but
invisible to /proc
As we get the devicefs in 2.5 fleshed out, hopefully such things will
come in time for the older busses like PNPISA & EISA
> There is already stuff in /proc that seems to be there for precisely this
> reason. So /proc/dmi would hardly be a violation of norms.
Just because its a shitbucket, doesn't mean we should keep adding to it.
It's become the dumping ground for so much crap that just doesn't need to
be there.
-- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/