Arnd Bergmann
2011-May-19 15:22 UTC
[PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute
(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/0I 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
Chris Metcalf
2011-May-20 14:26 UTC
[PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute
On 5/19/2011 11:22 AM, Arnd Bergmann wrote:> On Thursday 19 May 2011, Chris Metcalf wrote: >>>> /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.I'll create a /sys/hypervisor/board/ and report the attributes there.>>>> /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.Since /proc/tile/hardwall has no connection to the hypervisor whatsoever, I'm reluctant to put it under /sys/hypervisor. Perhaps in this case it would be reasonable to just have the hardwall subsystem put the file in /proc/driver/hardwall, or even /proc/hardwall? Or I could make the /dev/hardwall char device dump out the ASCII text that we currently get from /proc/hardwall if you read from it, which is a little weird but not inconceivable. For example it currently shows things like this: # cat /proc/tile/hardwall 2x2 1,1 pids: 484 at 2,1 479 at 1,1 2x2 0,3 pids: In this example "2x2 1,1" is a 2x2 grid of cpus starting at grid (x,y) position (1,1), with task 484 bound to the cpu at (x,y) position (2,1). -- Chris Metcalf, Tilera Corp. http://www.tilera.com
Arnd Bergmann
2011-May-24 15:38 UTC
[PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute
On Thursday 19 May 2011, Arnd Bergmann wrote:> > > > # 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.A minor point that I meant to bring up but had not gotten to: When you do a /sys/hypervisor/ interface, put everything into a subdirectory under /sys/hypervisor with the name of your hypervisor, to avoid naming conflicts, e.g. /sys/hypervisor/tilera-hv/board/board_serial Arnd
Apparently Analagous Threads
- [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute
- Windows Tile Vertically from Windows 7
- [LLVMdev] About commit TILE-Gx backend to community repository and default disabled
- [RFC PATCH v2 21/25] smp, tile: kill SMP single function call interrupt
- [RFC PATCH v2 21/25] smp, tile: kill SMP single function call interrupt