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

Reply via email to