(adding virtualization mailing list) On Thursday 19 May 2011, Chris Metcalf wrote: > On 5/19/2011 9:41 AM, Arnd Bergmann wrote: > >> /proc/tile/hvconfig > >> Detailed configuration description of the hypervisor config > > I'm concerned about moving this one out of /proc, since it's just (copious) > free text. An "hvconfig" (hypervisor config) file describes hypervisor > driver "dedicated tiles" that run things like network packet or PCIe > ingress/egress processing, etc. In addition it lists hypervisor driver > options, boot flags for the kernel, etc, all kinds of things -- and you > can't really guarantee that it will fit on a 4KB page, though in practice > it usually does. The hypervisor reads this file from the boot stream when > it boots, and then makes it available to Linux not for Linux's use, or even > for programmatic userspace use, but just for end users to be able to review > and verify that the configuration they think they booted is really what > they got, for customer remote debugging, etc. The "remote debugging" > aspect makes truncation to page size a particularly worrisome idea. Since it's not the kernel that is imposing the format here, you could make it a binary sysfs attribute, which works in the same way as a proc file and does not have the size limitations. > >> /proc/tile/board > >> Information on part numbers, serial numbers, etc., of the > >> hardware that the kernel is executing on > >> > >> /proc/tile/switch > >> The type of control path for the onboard network switch, if any. > > These two report information about the hardware, not the hypervisor. For > example: > > # cat /proc/tile/board > board_part: 402-00002-05 > board_serial: NBS-5002-00012 > chip_serial: P62338.01.110 > chip_revision: A0 > board_revision: 2.2 > board_description: Tilera TILExpressPro-64, TILEPro64 processor (866 MHz-capable), 1 10GbE, 6 1GbE > # cat /proc/tile/switch > control: mdio gbe/0 I think it's ok to have it below /sys/hypervisor, because the information is provided through a hypervisor ABI, even though it describes something else. This is more like /sys/firmware, but the boundaries between that and /sys/hypervisor are not clearly defined when running virtualized anyway. > The chip_serial and chip_revision can certainly hang off > /sys/devices/system/cpu along with chip_height and chip_width (I've made > this change now) but I don't know where the remaining "board" level > description could go. Note that (as you can see in the source) certain > boards will also include four lines of output with the "mezzanine board" > part number, serial number, revision, and description; this particular > example doesn't have a mezzanine board. The "switch" info is broken out > into a separate file just to make it easier to script some /etc/rc code > that launches a configurator for the Marvell switch on some of our boards, > but is conceptually part of the board info. > > >> /proc/tile/hardwall > >> Information on the set of currently active hardwalls (note that > >> the implementation is already present in arch/tile/kernel/hardwall.c; > >> this change just enables it) > > This one is not a hypervisor-related file. It just lists information about > the set of Linux hardwalls currently active. Again, it's not primarily > intended for programmatic use, but as a diagnostic tool. same here, I'd still put it into the hypervisor structure. Arnd _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
