Re: OpenCL / handling of hardware-specific packages
On 01.07.19 23:59, Rebecca N. Palmer wrote: Hi, >> So, installing an opencl-based package pulls in *all* cl driver stacks ? > > If we do the above, yes by default, but the user can prevent this by > explicitly installing any one. Ok, that's fine, as long as it doesn't cause the already mentioned problems. >> Please don't do that. This IMHO clearly belongs into the operator's >> hands > > Do you mean "not as long as it would cause the above bugs" or "not > ever"? If the latter, is it because of wasted storage/bandwidth or > something else? Bandwidth and install time is one issue, another is storage (yes, some folks actually care about storage, eg. w/ containers :p), another is reducing code and therefore potential bugs and attack surface. In general, I'd like to keep my systems as minimal as possible. > Do you also believe that the existing hardware-related -all packages > (printer-driver-all(-enforce), va-driver-all, vdpau-driver-all, > xserver-xorg-input-all, xserver-xorg-video-all) should not exist / > should not be installed by default? I don't have a problem with those packages, but there shouldn't be dependencies on them, so that suddenly hundreds of packages come in when just one is needed. Maybe there should be some selection mechanism (not sure how that could be implemented, yet). >> (or possibly some installer magic). > > Do we have such a mechanism? I agree this would be better if it existed. Honestly, I don't know. Perhaps that deserves a more detailed discussion. At that point it would also be nice if we could configure things like which editor or mailer to install. Maybe this could be done w/ some virtual package + equivs magic. I'll have to think about this ... > The AppStream metadata format includes a field for "hardware this works > with", and beignet-opencl-icd has one, but I don't know if any existing > tools use this field. I don't like the idea of making driver packages depending on some desktop stuff :o IMHO, it should be handled on dpkg/apt level. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: OpenCL / handling of hardware-specific packages
On Tue, 2019-07-02 at 16:40:14 +0200, Petter Reinholdtsen wrote: > [Guillem Jover] > > The closest thing I'm aware of is isenkram, but re-checking it now, it > > looks it's now tailored for hot-plugged hardware? Its README contains > > interesting information on alternatives and similar solutions. CCed > > Petter for further input. > > Not quite sure why you believe it is tailored for hot-plugged hardware. > What should be updated to avoid such impression? It can definitely > handle any package with hardware mapping in AppStream. I've to confess, I just skimmed over it, but precisely the few first things I checked, were what might have mislead me: ,--- $ apt show isenkram … Description: Suggest packages to install when inserting new hardware (GUI popup) Try to figure out which packages to suggest for use with a freshly inserted hardware device. `--- .--- README --- The Isenkram project This is a simple system to propose to the logged in user any Debian packages that would be useful to support a given given piece of inserted hardware. … `--- ,--- NOTES --- Make it easier to get pluggable hardware working in Debian == … `--- Thanks, Guillem
Re: OpenCL / handling of hardware-specific packages
Thank you for the heads up, I am not following debian-devel@ these days. Please keep me on Cc. [Guillem Jover] > The closest thing I'm aware of is isenkram, but re-checking it now, it > looks it's now tailored for hot-plugged hardware? Its README contains > interesting information on alternatives and similar solutions. CCed > Petter for further input. Not quite sure why you believe it is tailored for hot-plugged hardware. What should be updated to avoid such impression? It can definitely handle any package with hardware mapping in AppStream. Isenkram provide a background daemon 'isenkramd' for handling hot-plugged hardware, and various scripts for one off runs related to more fixed hardware. You can run 'isenkram-lookup' to get a list of packages suited for the currently identified hardware, 'isenkram-pkginstall' to get a interactive list of packages with the option to install them, 'isenkram-autoinstall-firmware' to automatically install the firmware relevant for the current machine, and even 'tasksel' after installing the isenkram-cli package to get a tasksel option to install all the packages listed by isenkram-lookup. -- Happy hacking Petter Reinholdtsen
Re: OpenCL / handling of hardware-specific packages
On Tue, 2019-07-02 at 14:29 +0200, Guillem Jover wrote: [...] > The closest thing I'm aware of is isenkram, but re-checking it now, it > looks it's now tailored for hot-plugged hardware? Its README contains > interesting information on alternatives and similar solutions. CCed > Petter for further input. Linux doesn't distinguish between devices found in an initial enumeration or hot-plugged later, so I doubt that isenkram is limited in that way. Ben. -- Ben Hutchings Any sufficiently advanced bug is indistinguishable from a feature. signature.asc Description: This is a digitally signed message part
Re: OpenCL / handling of hardware-specific packages
Hi! On Mon, 2019-07-01 at 22:59:51 +0100, Rebecca N. Palmer wrote: > On 01/07/2019 18:10, Enrico Weigelt, metux IT consult wrote: > > Please don't do that. This IMHO clearly belongs into the operator's > > hands > > Do you mean "not as long as it would cause the above bugs" or "not ever"? > If the latter, is it because of wasted storage/bandwidth or something else? > > Do you also believe that the existing hardware-related -all packages > (printer-driver-all(-enforce), va-driver-all, vdpau-driver-all, > xserver-xorg-input-all, xserver-xorg-video-all) should not exist / should > not be installed by default? As long as we do not have an out-of-the-box way to automatically propose/install hardware-specific packages to match the current system, the «-all» package pattern is the best we've got, which gives a good default, but makes it possible to removed unnecessary packages. > > (or possibly some installer magic). > > Do we have such a mechanism? I agree this would be better if it existed. > > The AppStream metadata format includes a field for "hardware this works > with", and beignet-opencl-icd has one, but I don't know if any existing > tools use this field. The closest thing I'm aware of is isenkram, but re-checking it now, it looks it's now tailored for hot-plugged hardware? Its README contains interesting information on alternatives and similar solutions. CCed Petter for further input. Thanks, Guillem
Re: OpenCL / handling of hardware-specific packages
On 01/07/2019 18:10, Enrico Weigelt, metux IT consult wrote: On 19.06.19 09:09, Rebecca N. Palmer wrote: I proposed [0] fixing this by creating a metapackage for "all OpenCL drivers" (similar to the ones for graphics). However, having unusable OpenCL drivers installed can trigger bugs: [1] in llvm, and some applications that treat "no hardware for this driver" as "fatal error" instead of "try the next driver". So, installing an opencl-based package pulls in *all* cl driver stacks ? If we do the above, yes by default, but the user can prevent this by explicitly installing any one. Please don't do that. This IMHO clearly belongs into the operator's hands Do you mean "not as long as it would cause the above bugs" or "not ever"? If the latter, is it because of wasted storage/bandwidth or something else? Do you also believe that the existing hardware-related -all packages (printer-driver-all(-enforce), va-driver-all, vdpau-driver-all, xserver-xorg-input-all, xserver-xorg-video-all) should not exist / should not be installed by default? (or possibly some installer magic). Do we have such a mechanism? I agree this would be better if it existed. The AppStream metadata format includes a field for "hardware this works with", and beignet-opencl-icd has one, but I don't know if any existing tools use this field.
