Re: [Lse-tech] topology design notes

Pat Mochel wrote:
> Pardon my ignorance, but I'm not quite sure what you mean by
> 'instrumentation'.
>
> Are you looking for usage boundaries, and the implementation requirements
> of each bus/device/node?
>
> If you mean something different, could you please articulate exactly what
> you're talking about?
Hi Pat,
Actually, I would have thought that the last few day's debate would
explain what I mean, but I don't mind elaborating. What I mean is
the instrumentation that allows a kernel component, a tracer, a user
application -- any piece of code -- to monitor or sample the activity
of the system and the components it is built of. In your case a bus,
driver, processor node, memory bank or whatever.
An instrumentation that provides a mechanism for exploration of what
system components exist at any point in time and the instrumentation
available for those components in the form of current parameters,
usage and performance metrics etc. It should be used for all types of
data extraction and, preferably, manipulation of the instrumented entity.
For example, the mechanism that allows me to find an Ethernet card
should also allow me to see the card in the global topology, to extract
whatever data is available (in the same manner I use to ectract data for
a memory module or power supply) and should allow me to modify the
status if the device, bus, or whatever -- all using the same interface.
That would require all devices to follow a non-negotiable set of ground
rules for attaching itself in the topologi tree (or network) and for
announcing and allowing access to its attributes and methods.
Just for the heck of it, please tell me why procfs is an abomination
(which I tend to agree with) but driverfs is not? Why this fixation
on making everything a file system?
Niels