Hi, to follow-up this idea, I've created new Wiki page: https://github.com/cockpit-project/cockpit/wiki/Feature:-Hardware-Devices
POC will follow. Thanks, Marek ----- Original Message ----- > From: "Stef Walter" <[email protected]> > To: "Development discussion for the Cockpit Project" > <[email protected]> > Sent: Thursday, March 24, 2016 1:59:52 PM > Subject: Re: idea/rfc: device screen in cockpit > > On 23.03.2016 18:37, Martin Polednik wrote: > > On 23/03/16 18:03 +0100, Stef Walter wrote: > >> On 23.03.2016 15:34, Martin Polednik wrote: > >>>>> I have an idea for cockpit, but before thinking it further, I'm > >>>>> interested in hearing your opinions. I am oVirt developer mostly > >>>>> dealing with system stuff and this is something that could be useful > >>>>> in virtualization while also providing utility for administrators > >>>>> using cockpit. > >>>>> > >>>>> The idea is about new tab/plugin (not sure of the terminology) called > >>>>> 'devices', that would allow access to (hardware) devices as exposed by > >>>>> sysfs. The interface could be similar to 'Services' tab/plugin, > >>>>> showing a list of device names created from their physical location, > >>>>> similarly to libvirt's nodedev-list. > >>>>> > >>>>> After clicking on the name, new screen would be presented, showing > >>>>> additional information such as > >>>>> > >>>>> * physical address, > >>>>> * driver in use, > >>>>> * special capabilities (SR-IOV numvfs and totalvfs, NPIV max_vports, > >>>>> vports), > >>>>> * iommu group (possibly clickable to reveal all devices in given > >>>>> group), > >>>>> * vendor, vendor id, product, product id. > >>>>> > >>>>> Additionally, it makes sense to allow some basic operations: > >>>>> > >>>>> * unbinding from host driver, binding it to specific one (useful for > >>>>> local vfio-pci testing), > >>>>> * reattaching it back (one use case is that > >>>>> oVirt does not reattach devices automatically due to possible > >>>>> issues, needs user intervention), > >>>>> * setting numvfs, vports, > >>>>> * ... ? > >>>>> > >>>>> Do you find ideas above reasonable for cockpit? It is mostly in idea > >>>>> phase, and builds on development and requirements of oVirt. I > >>>>> personally believe that this could be useful for broader audience. > >> > >> I think this makes a lot of sense. It's the sort of functionality people > >> expect when interacting with a specific server. > >> > >> Is sysfs enough of an API to deliver a decent experience? > > > > Combination of sysfs and udev to be accurate. I haven't dug into > > cockpit internals (yet), but as long as bash access is available it is > > possible to gather all the required information. > > Great. Do these change while running the server much? If so you probably > want to find a way to detect that something has changed, wait a few > seconds, and run things again to update the display. > > > Example (SR-IOV capable Intel 82576 NIC): > > # basic information > > # pwd > > /sys/bus/pci/devices/0000:05:00.0 > > > > # udevadm info $(pwd) > > P: /devices/pci0000:00/0000:00:09.0/0000:05:00.0 > > E: DEVPATH=/devices/pci0000:00/0000:00:09.0/0000:05:00.0 > > E: DRIVER=igb > > E: ID_MODEL_FROM_DATABASE=82576 Gigabit Network Connection (NC362i > > Integrated Dual port Gigabit Server Adapter) > > E: ID_PCI_CLASS_FROM_DATABASE=Network controller > > E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller > > E: ID_VENDOR_FROM_DATABASE=Intel Corporation > > E: MODALIAS=pci:v00008086d000010C9sv0000103Csd0000323Fbc02sc00i00 > > E: PCI_CLASS=20000 > > E: PCI_ID=8086:10C9 > > E: PCI_SLOT_NAME=0000:05:00.0 > > E: PCI_SUBSYS_ID=103C:323F > > E: SUBSYSTEM=pci > > E: USEC_INITIALIZED=994474b > > > > # SR-IOV control > > # ls sriov_* > > sriov_numvfs sriov_totalvfs > > > > # cat sriov_numvfs > > 0 > > > > # cat sriov_totalvfs > > 7 > > > > # echo 5 > sriov_numvfs > > > > # cat sriov_numvfs > > 5 > > > > # IOMMU group > > # readlink iommu_group > > ../../../../kernel/iommu_groups/15 > > > > # cat vendor > > 0x8086 > > > > # cat device > > 0x10c9 > > > > # driver for unbinding, we have all the required information (sorry, > > # I'm using that nic!) > > # readlink driver > > ../../../../bus/pci/drivers/igb > > > > Additionally, the devices are exposed as a tree and can therefore be > > displayed that way (I'm not sure about UI/UX in that case). > > Once you have a proof of concept working, it would be good to work on > the design. Here's how new features land, in case you haven't seen it: > > https://github.com/cockpit-project/cockpit/wiki/New-Features > > Stef > > > This is pretty much what libvirt does when dealing with devices - > > making it more than enough to do anything virtualization and device > > management requires. Similar information can be gathered about SCSI > > and USB devices as far as I know. > > > > > > _______________________________________________ > cockpit-devel mailing list > [email protected] > https://lists.fedorahosted.org/admin/lists/[email protected] > _______________________________________________ cockpit-devel mailing list [email protected] https://lists.fedorahosted.org/admin/lists/[email protected]
