Hello Marek, Marek Libra [2017-10-19 11:44 +0200]: > I would like to renew the effort on Host Devices for Cockpit [1].
Indeed, sorry that this got dragged for so long. > To move forward, let's implement it step by step while opening brand new PR > picking just a subset of the already implemented functionality [1] while > adjusted to generally acceptable form. Agreed. Garrett did some initial design mockups [1] and a feature page [2] recently. The per-bus table details seem a bit questionable to me still, but we can discuss/iterate on that. [1] http://garrettlesage.com/cockpit-mockweb/hardware/ [2] https://github.com/cockpit-project/cockpit/wiki/Feature:-Hardware-View > Initial implementation would meet: > - PCI support only > - initially read-only: just the List of devices by their Class (according > to [2]) > - example: by Audio device, Ethernet Controller, etc > > - data source: sysfs > - make use of backward-compatible lspci for data preprocessing (especially > manipulation with HW database) What do you mean by this? I. e. why should we call lspci instead of reading this from udev's database? udevadm info's output is more machine readable, contains other device classes as well, and hwdb uses the same ID databases than lspci/lsusb. But I might be missing something? > - monitor for changes by listening kernel uevents That sounds good to me as a first milestone, and then this can hit some user testing and feedback. As a finger exercise I did some code cleanup/generalization [3] and put up an initial WIP for showing the system-global data (Machine type/name, BIOS, CPU type) [4]. [3] https://github.com/cockpit-project/cockpit/pull/8491 [4] https://github.com/cockpit-project/cockpit/pull/8501 Thanks, Martin _______________________________________________ cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-le...@lists.fedorahosted.org