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" <stefw(a)redhat.com>
> To: "Development discussion for the Cockpit Project"
<cockpit-devel(a)lists.fedorahosted.org>
> 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
> cockpit-devel(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/admin/lists/cockpit-devel@lists.fedorahost...
>