Re: RFC: DKMS - Dynamic Kernel Module Support
On Thu, 11 Sep 2008 10:00:38 +0200, David Paleino wrote: Hello *, some time ago I filed a RFS [1] for DKMS [2] So, what's the final status of this thread? Should I continue working on the package? Should I drop it? I wouldn't want to drop it -- if there's no consensus or, at least, someone wanting it -- and wanting to *sponsor* it, or someone that will actually *use* it, I believe I'll put that on my private repository. Should I continue working on DKMS for Debian, or is that all wasted time? David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFC: DKMS - Dynamic Kernel Module Support
On Wed, 2008-09-17 at 22:33 +0200, David Paleino wrote: On Thu, 11 Sep 2008 10:00:38 +0200, David Paleino wrote: Hello *, some time ago I filed a RFS [1] for DKMS [2] So, what's the final status of this thread? Should I continue working on the package? Should I drop it? I wouldn't want to drop it -- if there's no consensus or, at least, someone wanting it -- and wanting to *sponsor* it, or someone that will actually *use* it, I believe I'll put that on my private repository. I'm willing to review it and sponsor it when it's ready. Should I continue working on DKMS for Debian, or is that all wasted time? I think it's worthwhile, though I personally won't need to use it. Ben. signature.asc Description: This is a digitally signed message part
Re: Re: RFC: DKMS - Dynamic Kernel Module Support
So, what's the final status of this thread? Should I continue working on the package? Should I drop it? I wouldn't want to drop it -- if there's no consensus or, at least, someone wanting it -- and wanting to *sponsor* it, or someone that will actually *use* it, I believe I'll put that on my private repository. Should I continue working on DKMS for Debian, or is that all wasted time? From the 6 advantages you mentioned, I believe after the discussion 5 and 6 survived. These aren't advantages that would convince easily everyone used to module-assistant to switch, but converts from distributions using DKMS could want it instead of module-assistant. I guess I'd personally give DKMS a try. So it shouldn't be all wasted time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: DKMS - Dynamic Kernel Module Support
On mer, 2008-09-17 at 22:33 +0200, David Paleino wrote: Should I continue working on DKMS for Debian, or is that all wasted time? Go ahead, it *will* be useful, and isn't intended to replace module-assistant anyway. It may have some problems, but they will be identified, reported and fixed. Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: RFC: DKMS - Dynamic Kernel Module Support
Le lundi 15 septembre 2008 à 07:54 +0200, Yves-Alexis Perez a écrit : On dim, 2008-09-14 at 22:36 +0100, Ben Hutchings wrote: (DKMS actually moves the old version out of the way and moves the new version into its place. I think we might want to modify that behaviour in Debian, perhaps using dpkg-divert.) That may not be as easy as it seems. The moving is done as part of the postinst script, where dkms is run with “install” argument. So before that, the .ko file is not there. Just another issue that’s easily solved if we make dkms to install modules in another directory. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFC: DKMS - Dynamic Kernel Module Support
Le samedi 13 septembre 2008 à 07:08 +, Tzafrir Cohen a écrit : And as I mentioned before, the problem with those generated debs is that you can not install two of them on your system if you have two different kernel variants. Then it is a bug in the Debian dkms package, and one that should be quite easy to fix. Certainly not something that should prevent us from embracing it. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFC: DKMS - Dynamic Kernel Module Support
On dim, 2008-09-14 at 09:15 +0200, Josselin Mouette wrote: Le samedi 13 septembre 2008 à 07:08 +, Tzafrir Cohen a écrit : And as I mentioned before, the problem with those generated debs is that you can not install two of them on your system if you have two different kernel variants. Then it is a bug in the Debian dkms package, and one that should be quite easy to fix. Certainly not something that should prevent us from embracing it. And I'm sure upstream people would be quite fine with adding such fix. I recently submitted a patch and opened a discussion about presence of _ in generated packages name. This was fixed really fastly, so they are really open for discussion. Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: RFC: DKMS - Dynamic Kernel Module Support
On Fri, 2008-09-12 at 10:02 +, Tzafrir Cohen wrote: snip That may be true for an out-of-tree modules. However, let's recall that Fedora ships with Latest kernel and Debian (Stable) doesn't. Hence Debian should be more concerened with backporting. Right now Debian does have the latest stable kernel. I think Fedora is trying to set high standards for what it includes (out-of-tree drivers are mostly crap) but at the expense of providing what its users actually need. (I suppose people make the same criticism of Debian over the strict application of DFSG - and yet we are pragmatic about that as well; we still have a non-free section in the archive.) (Discalimer: I work for a company that ships hardware using a badly out-of-tree module. I work for a company that ships hardware using a module that was out-of-tree for several years. While we try to fix that, there is little we can do. I very much doubt that. One of the arguments used by those opposing getting that code into the kernel is the longer release cycle that would mean it takes some monthes from the time we're done with internal QA till customers start using the code) Some of our customers and prospective customers, which are mostly OEMs, demanded that we work to get our driver in-tree. This is presumably because that gets it into distributions and reduces their installation and support burden in the long-term. It also ensures a certain amount of code review, further reducing their support burden. We also benefit from that review and from having the in-tree driver updated in the future together with kernel APIs. At the same time, we - and you - will still need to support an out-of-tree driver on older kernels and to cover new hardware. If you install a new version of the module in /lib/modules/$version/updates then that takes precedence over the old version. (This is hard-coded into depmod.) (DKMS actually moves the old version out of the way and moves the new version into its place. I think we might want to modify that behaviour in Debian, perhaps using dpkg-divert.) Ben. signature.asc Description: This is a digitally signed message part
Re: RFC: DKMS - Dynamic Kernel Module Support
On Sat, Sep 13, 2008 at 01:54:43AM +0200, Josselin Mouette wrote: Le samedi 13 septembre 2008 à 00:44 +0200, José Luis Tallón a écrit : - Having files *vital* to the system not tracked by dpkg is counter-productive. At the very least it thwarts the most basic and obvious way of integrity protection. Dpkg is not tripwire. If you think you can rely on dpkg for checking data integrity, you are fooling yourself. Many of those modules distributed by dkms are ones that the user is also likely to try installing on his own from source. debsums helps answering the question: oh here's a little module, I wonder where it came from? Do not assume everybody maintaining the system know of dkms (or of m-a or such). Knowledge of debsums or equivalent should be assumed from anybody maintaining a Debian system. It does provide a fantastic opportunity to leave cruft behind when uninstalling, too These are things that we already know how to deal with. - Where, for security reasons, the full build is unavailable (i.e. removed from production servers), source-only DKMS would be completely unusable. However, in a farm of identical servers (quite normal nowadays), a sysadmin would only need to have one particular machine equipped with the build system plus full DKMS. Modules would then be distributed to the other servers via a private repository. Having a way to automatically install modules doesn’t prevent from building .debs containing them, as it was already explained multiple times. Furthermore, the target of DKMS is not server-grade material, for which use of out-of-tree modules is exceptional; it is for desktops and laptops with non-free graphics and wifi. In most cases you don’t care of having distributable packages. Dell developed dkms for Linux servers it ships. Many servers ship with disk controllers, network controllers and such that are not yet supported in the kernel of current RHEL or Debian Stable. In a perfect world all the code would reach mainline kernel soon enough and we wouldn't need to maintain packages like lirc and zd1211 on our own. In the real world, there is also some free software whose maintainers refuse to include it in the mainline kernel for technical reasons. And as I mentioned before, the problem with those generated debs is that you can not install two of them on your system if you have two different kernel variants. -- Tzafrir Cohen | [EMAIL PROTECTED] | VIM is http://tzafrir.org.il || a Mutt's [EMAIL PROTECTED] || best ICQ# 16849754 || friend -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: DKMS - Dynamic Kernel Module Support
On sam, 2008-09-13 at 00:21 +0200, José Luis Tallón wrote: No. You only need dkms. Hmm... How does dkms build the modules for a build kernel, then? Surely a compiler and linker must be needed, right? You build the module on the build host, then put it on a .deb package. You install this .deb package on the target host. Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: RFC: DKMS - Dynamic Kernel Module Support
On sam, 2008-09-13 at 06:21 +, Tzafrir Cohen wrote: Can you do that if you generate modules for both 2.6.26-1-686 and 2.6.26-1-vserver-686 ? Will tell you on monday. -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: RFC: DKMS - Dynamic Kernel Module Support
OoO En cette matinée ensoleillée du samedi 13 septembre 2008, vers 09:08, Tzafrir Cohen [EMAIL PROTECTED] disait : Do not assume everybody maintaining the system know of dkms (or of m-a or such). Knowledge of debsums or equivalent should be assumed from anybody maintaining a Debian system. It is the very first time I heard of debsums. -- BOFH excuse #54: Evil dogs hypnotized the night shift pgpfhOYgPwlf4.pgp Description: PGP signature
Re: RFC: DKMS - Dynamic Kernel Module Support
Tzafrir Cohen dijo [Sat, Sep 13, 2008 at 07:08:05AM +]: - Having files *vital* to the system not tracked by dpkg is counter-productive. At the very least it thwarts the most basic and obvious way of integrity protection. Dpkg is not tripwire. If you think you can rely on dpkg for checking data integrity, you are fooling yourself. Many of those modules distributed by dkms are ones that the user is also likely to try installing on his own from source. debsums helps answering the question: oh here's a little module, I wonder where it came from? Do not assume everybody maintaining the system know of dkms (or of m-a or such). Knowledge of debsums or equivalent should be assumed from anybody maintaining a Debian system. What does maintain mean to you? Do you think that everybody who bought a Nokia 810 tablet or similar uses it on a daily basis? They _are_ maintained a Debian-based system. Do regular Ubuntu desktop users know (or care) about it? Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: RFC: DKMS - Dynamic Kernel Module Support
So, DKMS is being run after the installation of a kernel. Am I right? Yes. Btw, is all this documented anywhere? I guess it isn't. Kindly, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: DKMS - Dynamic Kernel Module Support
On Sat, Sep 13, 2008 at 09:32:41PM -0500, Gunnar Wolf wrote: Tzafrir Cohen dijo [Sat, Sep 13, 2008 at 07:08:05AM +]: - Having files *vital* to the system not tracked by dpkg is counter-productive. At the very least it thwarts the most basic and obvious way of integrity protection. Dpkg is not tripwire. If you think you can rely on dpkg for checking data integrity, you are fooling yourself. Many of those modules distributed by dkms are ones that the user is also likely to try installing on his own from source. debsums helps answering the question: oh here's a little module, I wonder where it came from? Do not assume everybody maintaining the system know of dkms (or of m-a or such). Knowledge of debsums or equivalent should be assumed from anybody maintaining a Debian system. Correction: that question is naturally answered by dpkg -S . debsums helps confirm this. What does maintain mean to you? Do you think that everybody who bought a Nokia 810 tablet or similar uses it on a daily basis? They _are_ maintained a Debian-based system. Do regular Ubuntu desktop users know (or care) about it? Do you want to have a build system on your Nokia 810? Or put the relevant modules in a repository? An Ubuntu Desktop user who was tempted to install Nvidia drivers from source (yes, I saw such suggestions over the 'net) would be in a better position when asking support in a forum. You see, when you have multiple modules of the same name in the modules directory (/lib/modules/kernel-version) , the output of modinfo can be misleading: the module listed by modinfo is not necesserily the one that will get loaded by modprobe. I've had all sort of such spooky situations. In such a cases I can normally guess by the time and version field where thtat module comes from, and likewise, by the subdirectory. But I see no reason every user will need my experience. I see no reason some random Joe at the forrum answering the suer's questions should need to do more guesswork. -- Tzafrir Cohen | [EMAIL PROTECTED] | VIM is http://tzafrir.org.il || a Mutt's [EMAIL PROTECTED] || best ICQ# 16849754 || friend -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: DKMS - Dynamic Kernel Module Support
On jeu, 2008-09-11 at 18:02 +, Tzafrir Cohen wrote: Do you actually have a working build system? Must you have a build system on every host? I have one on a testbed yes. I have a box which has dkms, build-essential and headers installed. I import the driver source tarball, run dkms mkdeb, then I end with a .deb containing a “dkms archive”. When I install the package on another box (where I only need dkms), it will run dkms import on the archive, then install the binary module. Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: RFC: DKMS - Dynamic Kernel Module Support
On jeu, 2008-09-11 at 10:00 +0200, David Paleino wrote: This mail is being sent to see what Debian developers (and users) think about this framework: it's useless if no package uses it :) I currently use DKMS at work on some servers which run Debian. All other run RHEL, and have fully updated drivers for raid cards and stuff like that. But those drivers are not up to date even in 2.6.24 so I had to update them, so I tested DKMS. I don't think it's completely the same thing as module-assistant. Some hardware provider already provide dkms-ized sources, so one can install them easily on dkms-enabled box. -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: RFC: DKMS - Dynamic Kernel Module Support
On Thu, 11 Sep 2008, David Paleino wrote: On Thu, 11 Sep 2008 19:50:35 +0200, David Paleino wrote: On Thu, 11 Sep 2008 19:43:39 +0200, Josselin Mouette wrote: You’d run into the same issue as module-assistant has: a package being installed cannot launch installation of other packages. Uhm, right. I believe there could be a margin of improvement here for apt-get: 1) apt-get install linux-image-2.6-blabla 2) ...installation goes... 3) the postinst hook sets an APT flag (something like: please rerun because you still have things to do) with some action (i.e. mark package FOO for installation) 4) apt-get checks if there are any flags set, and if so, acts consequently. Re-reading my mail: isn't that what dpkg triggers do (i.e. setting flags and postponing actions...)? Can't apt-get just spawn another instance of itself? No. Triggers are postponed but that doesn't mean that they are executed outside of dpkg's lock. We should rather invent some mechanism to register suggestion of package to install. It should integrate with the desktop (notifications) and offer the possibility to always install by default. It could also be used by discover to suggest firmware-* or *-source when it detects hardware that need it. installing -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: DKMS - Dynamic Kernel Module Support
On Thu, Sep 11, 2008 at 4:00 PM, David Paleino [EMAIL PROTECTED] wrote: some time ago I filed a RFS [1] for DKMS [2], and Daniel Baumann daniel asked me what advantages it had over module-assistant. After some talking with upstream, here I have the answer. Only down side I worry about is that having such a solution encourages out-of-tree drivers. Personally, I'd prefer if Debian were to adopt some variation of Fedora's policy: http://fedoraproject.org/wiki/Packaging/KernelModules http://fedoraproject.org/wiki/DavidWoodhouse/KmodProposal -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: DKMS - Dynamic Kernel Module Support
On Thu, Sep 11, 2008 at 12:24:08PM -0500, Mario Limonciello wrote: As I understand, the dpkg maintainer (Michael Vogt) Do you mean apt maintainer? TTBOMK, Michael has never been involved with dpkg maintenance; so is this implementation going to be in dpkg, or apt? Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: DKMS - Dynamic Kernel Module Support
On Fri, Sep 12, 2008 at 02:51:00PM +0800, Paul Wise wrote: On Thu, Sep 11, 2008 at 4:00 PM, David Paleino [EMAIL PROTECTED] wrote: some time ago I filed a RFS [1] for DKMS [2], and Daniel Baumann daniel asked me what advantages it had over module-assistant. After some talking with upstream, here I have the answer. Only down side I worry about is that having such a solution encourages out-of-tree drivers. Personally, I'd prefer if Debian were to adopt some variation of Fedora's policy: http://fedoraproject.org/wiki/Packaging/KernelModules http://fedoraproject.org/wiki/DavidWoodhouse/KmodProposal From what I rapidly read there, I understand that Fedora doesn't want to *ship* drivers using dkms stuff, but doesn't care about users doing what they want with it. And that's what it is about, imho. Having dkms in Debian means users can install dkms drivers (provided by hardware vendor for example) and have dell management stuff happy, it doesn't mean *debian* has to ship drivers in dkms format. Cheers, -- Yves-Alexis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: DKMS - Dynamic Kernel Module Support
On Fri, 12 Sep 2008 14:51:00 +0800, Paul Wise wrote: On Thu, Sep 11, 2008 at 4:00 PM, David Paleino [EMAIL PROTECTED] wrote: some time ago I filed a RFS [1] for DKMS [2], and Daniel Baumann daniel asked me what advantages it had over module-assistant. After some talking with upstream, here I have the answer. Only down side I worry about is that having such a solution encourages out-of-tree drivers. Not really: DKMS tarballs are meant to be included in-tree, as Mario himself stated. I'd not say that m-a encourages out-of-tree drivers... Personally, I'd prefer if Debian were to adopt some variation of Fedora's policy: http://fedoraproject.org/wiki/Packaging/KernelModules This page says: Fedora prefers in-tree modules, out-of-tree modules are not permitted and should be merged instead. We all agree here, no? But, what the case of non-free drivers, for example? http://fedoraproject.org/wiki/DavidWoodhouse/KmodProposal The main point: There is no justification for shipping kernel modules as separate packages within Fedora, in either source (dkms payload) or binary (kmod/kmdl) form. If code is good enough to ship, it should be shipped in the kernel package. If it's not, then it should not be shipped at all with the 'Fedora' name on it. Totally agree with this. But we, as Debian, being the Universal Operating System, should, IMVHO, try to support most types of technologies: as stated by other people (corsac, for example), most hardware vendors provide DKMS tarballs, why not supporting it? Why negate the users the ability to download a tarball from the vendor's website and install it flawlessly? Kindly, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFC: DKMS - Dynamic Kernel Module Support
On Fri, Sep 12, 2008 at 02:51:00PM +0800, Paul Wise wrote: On Thu, Sep 11, 2008 at 4:00 PM, David Paleino [EMAIL PROTECTED] wrote: some time ago I filed a RFS [1] for DKMS [2], and Daniel Baumann daniel asked me what advantages it had over module-assistant. After some talking with upstream, here I have the answer. Only down side I worry about is that having such a solution encourages out-of-tree drivers. Personally, I'd prefer if Debian were to adopt some variation of Fedora's policy: http://fedoraproject.org/wiki/Packaging/KernelModules http://fedoraproject.org/wiki/DavidWoodhouse/KmodProposal That may be true for an out-of-tree modules. However, let's recall that Fedora ships with Latest kernel and Debian (Stable) doesn't. Hence Debian should be more concerened with backporting. (Discalimer: I work for a company that ships hardware using a badly out-of-tree module. While we try to fix that, there is little we can do. One of the arguments used by those opposing getting that code into the kernel is the longer release cycle that would mean it takes some monthes from the time we're done with internal QA till customers start using the code) -- Tzafrir Cohen | [EMAIL PROTECTED] | VIM is http://tzafrir.org.il || a Mutt's [EMAIL PROTECTED] || best ICQ# 16849754 || friend -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: DKMS - Dynamic Kernel Module Support
Le vendredi 12 septembre 2008 à 10:00 +0200, Raphael Hertzog a écrit : IMO a solution that install modules manually (i.e. without dpkg) is not acceptable. Why? I think this is the only sane way to go for drivers that we won’t ship binary packages for. As long as the .ko files are correctly removed when you remove the kernel image – which is feasible with a trigger – there is nothing wrong with it. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFC: DKMS - Dynamic Kernel Module Support
On Thu, Sep 11, 2008 at 10:00:38AM +0200, David Paleino wrote: *Usability Maintainability* 3) You don't need to know much about what you are doing in order to install a package that uses DKMS. If you look at the kqemu-source package in Ubuntu, the moment you install it, it builds modules for your running kernel. As soon as you install a new kernel, it will build modules for that kernel too. Any old kernels that you have, modules will be built as soon as you boot into the kernel. Compare this to module-assistant. You have to install kqemu-source, and then manually run module assistant for every single kernel you need modules for. No on has answered that point. You didn't seem to read about the options '-l' and '-k' of m-a. Furthermore, m-a is part of the package management system, which is a good thing. If my repository contains -modules packages, they will bo automatically upgraded upon a new version of the module. Building packages should be the norm. Having many files under /lib that cannot be tracked by debsums is not something I like. m-a handles building in a way I like (besides its defaulting to full-screen mode). Another issue: with rpm it is OK to have several packages of the same name installed on the system. dpkg does not like this. Hence kernel modules deb packages have the name $BASE-$KVERS (e.g: lirc-modules-2.6.26-1-686), whereas rpm packages of kernel modules tend to encode $KVERS in the Version field alone. Upon initial inspection of the dkms script, it seems to generate deb packages whose name does not not include $KVERS . But I didn't test it. -- Tzafrir Cohen | [EMAIL PROTECTED] | VIM is http://tzafrir.org.il || a Mutt's [EMAIL PROTECTED] || best ICQ# 16849754 || friend -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: DKMS - Dynamic Kernel Module Support
On Fri, 12 Sep 2008 11:12:59 +, Tzafrir Cohen wrote: Furthermore, m-a is part of the package management system, which is a good thing. If my repository contains -modules packages, they will bo automatically upgraded upon a new version of the module. Building packages should be the norm. Having many files under /lib that cannot be tracked by debsums is not something I like. [..] Another issue: with rpm it is OK to have several packages of the same name installed on the system. dpkg does not like this. Hence kernel modules deb packages have the name $BASE-$KVERS (e.g: lirc-modules-2.6.26-1-686), whereas rpm packages of kernel modules tend to encode $KVERS in the Version field alone. The modules are meant to be handled by dkms, not dpkg. If you need a .deb, it might be a problem, then. -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFC: DKMS - Dynamic Kernel Module Support
On Fri, 12 Sep 2008 11:13:59 +0200, Josselin Mouette wrote: Le vendredi 12 septembre 2008 à 10:00 +0200, Raphael Hertzog a écrit : IMO a solution that install modules manually (i.e. without dpkg) is not acceptable. Why? I think this is the only sane way to go for drivers that we won’t ship binary packages for. That's why I originally proposed the DKMS way, i.e.: dkms add [..] dkms remove [..] dkms status [..] ... As long as the .ko files are correctly removed when you remove the kernel image – which is feasible with a trigger – there is nothing wrong with it. I believe that most people feel comfortable only with .deb's (this is not Raphael's case, I hope!)... but, well, if that manual way is accepted, it might become the standard way to do it in Debian one day. M2C, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFC: DKMS - Dynamic Kernel Module Support
On Fri, Sep 12, 2008 at 01:18:04PM +0200, David Paleino wrote: On Fri, 12 Sep 2008 11:12:59 +, Tzafrir Cohen wrote: Another issue: with rpm it is OK to have several packages of the same name installed on the system. dpkg does not like this. Hence kernel modules deb packages have the name $BASE-$KVERS (e.g: lirc-modules-2.6.26-1-686), whereas rpm packages of kernel modules tend to encode $KVERS in the Version field alone. The modules are meant to be handled by dkms, not dpkg. If you need a .deb, it might be a problem, then. This is a major bug IMHO. It means that at least for i386 dkms-generated debs cannot be put in repositories. Thus you require a build environment on the target host. -- Tzafrir Cohen | [EMAIL PROTECTED] | VIM is http://tzafrir.org.il || a Mutt's [EMAIL PROTECTED] || best ICQ# 16849754 || friend -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: DKMS - Dynamic Kernel Module Support
On Fri, 12 Sep 2008 11:32:07 +, Tzafrir Cohen wrote: On Fri, Sep 12, 2008 at 01:18:04PM +0200, David Paleino wrote: On Fri, 12 Sep 2008 11:12:59 +, Tzafrir Cohen wrote: Another issue: with rpm it is OK to have several packages of the same name installed on the system. dpkg does not like this. Hence kernel modules deb packages have the name $BASE-$KVERS (e.g: lirc-modules-2.6.26-1-686), whereas rpm packages of kernel modules tend to encode $KVERS in the Version field alone. The modules are meant to be handled by dkms, not dpkg. If you need a .deb, it might be a problem, then. This is a major bug IMHO. It means that at least for i386 dkms-generated debs cannot be put in repositories. Thus you require a build environment on the target host. We're not talking about *distributing* dkms-generated debs. We're talking about letting users download a tarball from $vendor and use it happily within Debian, like he would do in Ubuntu/Mandriva/Fedora/... -- i.e. integrate the DKMS framework inside Debian. Regards, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFC: DKMS - Dynamic Kernel Module Support
On Fri, 12 Sep 2008, Josselin Mouette wrote: Le vendredi 12 septembre 2008 à 10:00 +0200, Raphael Hertzog a écrit : IMO a solution that install modules manually (i.e. without dpkg) is not acceptable. Why? I think this is the only sane way to go for drivers that we won’t ship binary packages for. Why? What's wrong with dynamically generating .deb of those modules and installing them? There are technical challenges but it would be good to overcome them as it's not the first time that we could have used some functionality to trigger some supplementary package installation. As long as the .ko files are correctly removed when you remove the kernel image – which is feasible with a trigger – there is nothing wrong with it. If you remove dkms, and remove kernel afterwards, you will keep cruft for the eternity. Handling the modules with dpkg is always better for accountability/auditability. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: DKMS - Dynamic Kernel Module Support
Le vendredi 12 septembre 2008 à 13:55 +0200, Raphael Hertzog a écrit :
Why? What's wrong with dynamically generating .deb of those modules and
installing them?
I think this is going out of the scope of dpkg to be able to recursively
install packages that it was not even asked to install.
There are technical challenges but it would be good to overcome them as
it's not the first time that we could have used some functionality to
trigger some supplementary package installation.
As a dpkg maintainer you are certainly in a better situation to tell us
whether it is possible to achieve that and how much perverted it would
be, but I really don’t think this is the good way to go.
As long as the .ko files are correctly removed when you remove the
kernel image – which is feasible with a trigger – there is nothing wrong
with it.
If you remove dkms, and remove kernel afterwards, you will keep cruft for
the eternity. Handling the modules with dpkg is always better for
accountability/auditability.
No, if you remove dkms it should remove the modules it has installed as
well.
This will not, by far, be the first package to install manage that are
not contained within the package. You should see it just like the
byte-compilation of elisp or python modules: when a new
kernel/interpreter version is available, you need to compile/bytecompile
the drivers/modules that are handled by dkms/python-{central,support}.
The only thing that is different is that you need to ensure that the
headers are installed for each of the kernel images.
I would also much agree to install these files in a separate directory
tree from /lib/modules/2.6.xx-y-zzz, so that no confusion arises. /var
is not possible because it may not be mounted, but
think /lib/modules.dkms for example. This requires simple changes to
module-init-tools and initramfs-tools, but I think we can get something
working simply and correctly.
Cheers,
--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`-our own. Resistance is futile.
signature.asc
Description: Ceci est une partie de message numériquement signée
Re: RFC: DKMS - Dynamic Kernel Module Support
Tzafrir Cohen wrote:
Upon initial inspection of the dkms script, it seems to generate
deb packages whose name does not not include $KVERS . But I didn't test
it.
This is correct, because you don't want to have multiple DKMS packages
installed to support many versions of the kernel module. The idea is
that if you were to ship a binary kernel module in the package, you
would be shipping the source with it. When the user were to install
another kernel version, the source would be used to build a new binary
kernel module.
This will not, by far, be the first package to install manage that are
not contained within the package. You should see it just like the
byte-compilation of elisp or python modules: when a new
kernel/interpreter version is available, you need to compile/bytecompile
the drivers/modules that are handled by dkms/python-{central,support}.
The only thing that is different is that you need to ensure that the
headers are installed for each of the kernel images.
I would also much agree to install these files in a separate directory
tree from /lib/modules/2.6.xx-y-zzz, so that no confusion arises. /var
is not possible because it may not be mounted, but
think /lib/modules.dkms for example. This requires simple changes to
module-init-tools and initramfs-tools, but I think we can get something
working simply and correctly.
Earlier in this thread it was mentioned that since these compiled files
are not managed by dpkg, that perhaps they should be stored in /var.
This is already the case, /var/lib/dkms is where everything is stored
at. It's copied over to /lib/modules/... If there is a worry about
storing files in /lib/modules when they are copied, perhaps instead
making this action a symlink would be better?
--
Mario Limonciello
*Dell | Linux Engineering*
[EMAIL PROTECTED]
signature.asc
Description: OpenPGP digital signature
Re: RFC: DKMS - Dynamic Kernel Module Support
On ven, 2008-09-12 at 13:55 +0200, Raphael Hertzog wrote: Why? I think this is the only sane way to go for drivers that we won’t ship binary packages for. Why? What's wrong with dynamically generating .deb of those modules and installing them? That's exactly what “dkms mkdeb” does. Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: RFC: DKMS - Dynamic Kernel Module Support
On ven, 2008-09-12 at 11:32 +, Tzafrir Cohen wrote: This is a major bug IMHO. It means that at least for i386 dkms-generated debs cannot be put in repositories. Thus you require a build environment on the target host. No. You only need dkms. -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: RFC: DKMS - Dynamic Kernel Module Support
Yves-Alexis Perez wrote: On ven, 2008-09-12 at 11:32 +, Tzafrir Cohen wrote: This is a major bug IMHO. It means that at least for i386 dkms-generated debs cannot be put in repositories. Thus you require a build environment on the target host. No. You only need dkms. Hmm... How does dkms build the modules for a build kernel, then? Surely a compiler and linker must be needed, right? J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: DKMS - Dynamic Kernel Module Support
David Paleino wrote:
On Fri, 12 Sep 2008 11:12:59 +, Tzafrir Cohen wrote:
Furthermore, m-a is part of the package management system, which is a
good thing.
Indeed, as reasoned below
[...]
Building packages should be the norm. Having many files under /lib that
cannot be tracked by debsums is not something I like.
[...]
The modules are meant to be handled by dkms, not dpkg. If you need a .deb, it
might be a problem, then.
There are a couple reasons against this IMHO:
- Having files *vital* to the system not tracked by dpkg is
counter-productive. At the very least it thwarts the most basic and
obvious way of integrity protection. It does provide a fantastic
opportunity to leave cruft behind when uninstalling, too
- Where, for security reasons, the full build is unavailable (i.e.
removed from production servers), source-only DKMS would be completely
unusable. However, in a farm of identical servers (quite normal
nowadays), a sysadmin would only need to have one particular machine
equipped with the build system plus full DKMS. Modules would then be
distributed to the other servers via a private repository.
The second item above brings the same issue again. My vote goes for
using an approach similar to module-assistant here, and generate
versioned modules which can co-exist within a system. Moreover, the
generated modules would be installed normally, under
/lib/modules/${KVERS} and tracked by dpkg.
One idea which comes to mind (without further thinking) is to merge both
approaches: dkms could become a subsystem of module-assistant in Debian:
As presented above, installing kernel-headers and/or booting a kernel
for which modules are unavailable would trigger building the necessary
modules with DKMS, and module-assistant would be used to generate the
policy-conforming .deb. This package would then be installed
automatically, so that boot can continue.
When the rebuild is triggered by booting with a new kernel, dpkg is not
active and can be invoked to *register* the new modules, hence realizing
the accountability objective.
When triggered by dpkg installing a -headers package well, we'll
have to devise a solution for this. As said before in this thread, and
knowing nary a thing about dpkg's internals, it might just not be
possible to do this. However, solving this problem might, as hinted
before, provide us with a more elegant solution to other issues.
In any case, since updating -headers can never happen without human
intervention (save, maybe, for apt-cron), it is not unreasonable to
require the admin to manually install the packages immediately after.
Moreover, some script might be provided to automate this process: e.g.
drop a file in some /etc/dkms/pending.d/module file which said script
would use in order to install the just-generated modules.
AFAICS, the aforementioned solution covers all three use cases:
- Updating -headers, wanting to have modules installed immediately (so
as not to lengthen the boot period --- think the VoIP case pointed out
before). Just run the provided script (à la update-grub)
- Updating -headers in the master machine, then being able to
replicate just the binary packages to other machines so that they are
available upon next boot, without the need for a working build
environment in those machines
- When the modules don't get installed before reboot, the built
packages can be looked for in some predetermined location. If
unavailable, the modules could be built and installed on the spot
(again, out of any dpkg loop)
I may perfectly well be leaving some use case out, but this could be a
starting point. My two cents.
J.L.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: DKMS - Dynamic Kernel Module Support
Le samedi 13 septembre 2008 à 00:44 +0200, José Luis Tallón a écrit : - Having files *vital* to the system not tracked by dpkg is counter-productive. At the very least it thwarts the most basic and obvious way of integrity protection. Dpkg is not tripwire. If you think you can rely on dpkg for checking data integrity, you are fooling yourself. It does provide a fantastic opportunity to leave cruft behind when uninstalling, too These are things that we already know how to deal with. - Where, for security reasons, the full build is unavailable (i.e. removed from production servers), source-only DKMS would be completely unusable. However, in a farm of identical servers (quite normal nowadays), a sysadmin would only need to have one particular machine equipped with the build system plus full DKMS. Modules would then be distributed to the other servers via a private repository. Having a way to automatically install modules doesn’t prevent from building .debs containing them, as it was already explained multiple times. Furthermore, the target of DKMS is not server-grade material, for which use of out-of-tree modules is exceptional; it is for desktops and laptops with non-free graphics and wifi. In most cases you don’t care of having distributable packages. When the rebuild is triggered by booting with a new kernel, dpkg is not active and can be invoked to *register* the new modules, hence realizing the accountability objective. When triggered by dpkg installing a -headers package well, we'll have to devise a solution for this. As said before in this thread, and knowing nary a thing about dpkg's internals, it might just not be possible to do this. However, solving this problem might, as hinted before, provide us with a more elegant solution to other issues. Elegant? You are advising to intertwin the boot process and the package manager, and you invoke elegance? Please, stop this bullshit. Unless dpkg’s architecture is revamped to allow such things (and I’m not sure it is wise to do so), you are just blowing hot air. We probably have all we need today to get things like DKMS to work, and you are just arguing for delaying such critical desktop features for no good reason. In any case, since updating -headers can never happen without human intervention (save, maybe, for apt-cron), it is not unreasonable to require the admin to manually install the packages immediately after. If we aren’t able to bring an improvement, let’s just stick with module-assistant, then. The point of dkms is that we might finally be able to provide a way to simply “install a driver” and be done with it, having something to automatically care of all upgrades. Please don’t use this as a pretext to introduce changes we don’t need to the most fundamental piece of software in Debian. Thanks, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFC: DKMS - Dynamic Kernel Module Support
Hi, I have experince mostly with the out-of-tree module Zaptel. I'm personally happy with m-a. It works resonably well for me. Though I appreciate the goal of cross-vendor compatibility. Some comments: On Thu, Sep 11, 2008 at 10:00:38AM +0200, David Paleino wrote: 1) It includes a kernel postinstall hook. This means that, the moment kernel headers get installed, your modules are automatically rebuilt. Seems just as easy (or diffiuclt) to implement with module-assistant, right? Is it possible to generate a package at a package post-install hook? 2) It includes a boot time service to add modules for a running kernel provided headers are available. Boot time service or install time reload? At install time it is not always possible to reload modules silently. Reboot is the easy way to get modules reloaded. *Usability Maintainability* 3) You don't need to know much about what you are doing in order to install a package that uses DKMS. If you look at the kqemu-source package in Ubuntu, the moment you install it, it builds modules for your running kernel. As soon as you install a new kernel, it will build modules for that kernel too. Any old kernels that you have, modules will be built as soon as you boot into the kernel. Compare this to module-assistant. You have to install kqemu-source, and then manually run module assistant for every single kernel you need modules for. I wonder how this can be done with zaptel. If you try to be user-friendly and run '/etc/init.d/zaptel/unload' when installing zaptel-modules-current-kernel' it'll eventually fail normally, because Asterisk holds /dev/zap/pseudo open, and hence zaptel cannot be unloaded. (And this assumes that the application using it is 'asterisk') 5) Interoperability with different distributions. DKMS tarballs can be used on RHEL, SuSE, Ubuntu, or Debian. If there are different kernels, patches can be included in the DKMS tarball to enable support on different kernel releases. OK. As a test case, please provide a DKMS for zaptel. I know one was made for Mandriva. I looked into it a while ago because I thought DKMS is such a grand idea. And I recall I bumped into many practical issues I had to overcome myself. I think that this was mainly to do with the fact that Zaptel is both userspace and kernek. 6) Acceptance in enterprise solutions. Both Redhat Novell support DKMS as a solution for OEMs to provide kernel modules that won't be maintained in the upstream tree for the foreseeable future. IIRC Fedora has a policy for Kernel packages which is *not* DKMS. But I don't follow Fedora/RH closely. -- Tzafrir Cohen | [EMAIL PROTECTED] | VIM is http://tzafrir.org.il || a Mutt's [EMAIL PROTECTED] || best ICQ# 16849754 || friend -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: DKMS - Dynamic Kernel Module Support
Hi, please keep also the upstream author CCed :) On Thu, 11 Sep 2008 15:00:14 +, Tzafrir Cohen wrote: I have experince mostly with the out-of-tree module Zaptel. I'm personally happy with m-a. It works resonably well for me. Though I appreciate the goal of cross-vendor compatibility. That's why I'm trying to introduce DKMS! Some comments: On Thu, Sep 11, 2008 at 10:00:38AM +0200, David Paleino wrote: 1) It includes a kernel postinstall hook. This means that, the moment kernel headers get installed, your modules are automatically rebuilt. Seems just as easy (or diffiuclt) to implement with module-assistant, right? Is it possible to generate a package at a package post-install hook? The short answer: probably not, but DKMS is not following this way. The long answer: here's the problem -- currently m-a just generates .deb packages, which are handled by apt-get, dpkg and the such. DKMS would instead handle all that by itself -- and to remove a module, you'd need to do something like: # dkms remove -m module [-v version] [...lots of other options...] This is, obviously, to guarantee cross-vendor compatibility. It can't generate a vendor-specific package (be it .deb, .rpm or any other else), it just has to do that by itself. (even if there's the mkdeb command to dkms [i.e. dkms mkdeb] which... well... generates a .deb.) 2) It includes a boot time service to add modules for a running kernel provided headers are available. Boot time service or install time reload? At install time it is not always possible to reload modules silently. Reboot is the easy way to get modules reloaded. Sure, but I believe Mario intended trasparently adding modules -- i.e. modules you forgot to updateinstall would automatically be handled by DKMS on boot. Mario, am I wrong? *Usability Maintainability* 3) You don't need to know much about what you are doing in order to install a package that uses DKMS. If you look at the kqemu-source package in Ubuntu, the moment you install it, it builds modules for your running kernel. As soon as you install a new kernel, it will build modules for that kernel too. Any old kernels that you have, modules will be built as soon as you boot into the kernel. Compare this to module-assistant. You have to install kqemu-source, and then manually run module assistant for every single kernel you need modules for. I wonder how this can be done with zaptel. If you try to be user-friendly and run '/etc/init.d/zaptel/unload' when installing zaptel-modules-current-kernel' it'll eventually fail normally, because Asterisk holds /dev/zap/pseudo open, and hence zaptel cannot be unloaded. (And this assumes that the application using it is 'asterisk') I believe this is a bug in the zaptel init scripts... shouldn't they check whether they can be unloaded? Is there a --force option? But this is another story :) 5) Interoperability with different distributions. DKMS tarballs can be used on RHEL, SuSE, Ubuntu, or Debian. If there are different kernels, patches can be included in the DKMS tarball to enable support on different kernel releases. OK. As a test case, please provide a DKMS for zaptel. Googling for dkms zaptel gives some results, but most for Mandriva. I believe some effort should be made to make a central repository (like for autopackage, and for other similar cross-vendor projects) where to store vanilla tarballs. Mario, do you know of any central source currently available? I know one was made for Mandriva. I looked into it a while ago because I thought DKMS is such a grand idea. And I recall I bumped into many practical issues I had to overcome myself. I think that this was mainly to do with the fact that Zaptel is both userspace and kernek. I'm sorry I haven't all that experience with DKMS to clearly confirm this. Mario, can you confirm? 6) Acceptance in enterprise solutions. Both Redhat Novell support DKMS as a solution for OEMs to provide kernel modules that won't be maintained in the upstream tree for the foreseeable future. IIRC Fedora has a policy for Kernel packages which is *not* DKMS. But I don't follow Fedora/RH closely. Me neither -- oh well, I'm not into the enterprise world at all! Kindly, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFC: DKMS - Dynamic Kernel Module Support
On Thu, Sep 11, 2008 at 05:29:44PM +0200, David Paleino wrote: I wonder how this can be done with zaptel. If you try to be user-friendly and run '/etc/init.d/zaptel/unload' when installing zaptel-modules-current-kernel' it'll eventually fail normally, because Asterisk holds /dev/zap/pseudo open, and hence zaptel cannot be unloaded. (And this assumes that the application using it is 'asterisk') I believe this is a bug in the zaptel init scripts... shouldn't they check whether they can be unloaded? Is there a --force option? But this is another story :) Maybe it's possible (I'm not exactly sure. I think it's possible, at least in most cases). But do I want this? Do I want to shut down my PBX because of the Ubuntu kernel upgrade of the month? Which is why I never tried to add such an option to the init script, and why noone has asked for it. -- Tzafrir Cohen | [EMAIL PROTECTED] | VIM is http://tzafrir.org.il || a Mutt's [EMAIL PROTECTED] || best ICQ# 16849754 || friend -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: DKMS - Dynamic Kernel Module Support
On Thu, 11 Sep 2008 15:58:22 +, Tzafrir Cohen wrote: On Thu, Sep 11, 2008 at 05:29:44PM +0200, David Paleino wrote: I wonder how this can be done with zaptel. If you try to be user-friendly and run '/etc/init.d/zaptel/unload' when installing zaptel-modules-current-kernel' it'll eventually fail normally, because Asterisk holds /dev/zap/pseudo open, and hence zaptel cannot be unloaded. (And this assumes that the application using it is 'asterisk') I believe this is a bug in the zaptel init scripts... shouldn't they check whether they can be unloaded? Is there a --force option? But this is another story :) Maybe it's possible (I'm not exactly sure. I think it's possible, at least in most cases). But do I want this? Do I want to shut down my PBX because of the Ubuntu kernel upgrade of the month? So, you'll never upgrade kernel... because upgrading would mean losing zaptel -- and your PBX. Am I right? :) -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFC: DKMS - Dynamic Kernel Module Support
On Thu, 11 Sep 2008 10:00:38 +0200, David Paleino wrote: If you have AUTOINSTALL set to yes in a DKMS control file: 1) It includes a kernel postinstall hook. This means that, the moment kernel headers get installed, your modules are automatically rebuilt. This is achieved through the installation of a script in: /etc/kernel/header_postinst.d/ /etc/kernel/postinst.d/ /etc/kernel/prerm.d/ A quick search with apt-file didn't return any result. Is this approach supported by Debian? I remember grub updating itself when a new kernel is installed: is that a postinst by the kernel package itself? Kindly, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFC: DKMS - Dynamic Kernel Module Support
David Paleino wrote: Sure, but I believe Mario intended trasparently adding modules -- i.e. modules you forgot to updateinstall would automatically be handled by DKMS on boot. Mario, am I wrong? Correct, the service will simply compile the modules for you. rmmod/modprobe/udev control of the modules is outside the scope of what it handles. I believe this is a bug in the zaptel init scripts... shouldn't they check whether they can be unloaded? Is there a --force option? But this is another story :) For the case that was mentioned for asterisk holding zaptel devices open, that's not what DKMS is here to solve. DKMS is one step up the chain producing the modules that are needed for Zaptel. Googling for dkms zaptel gives some results, but most for Mandriva. I believe some effort should be made to make a central repository (like for autopackage, and for other similar cross-vendor projects) where to store vanilla tarballs. Mario, do you know of any central source currently available? The original plan for DKMS built modules was not to provide a central repository for these modules. They *should* all end up in the kernel in the long term. In cases that a vendor is providing a driver to be used on a variety of distributions, they should be hosting it on their own webspace generally. Another usecase is putting it directly into distributions that are most interesting to the vendor, but this is significantly more work. This is how a few drivers in Ubuntu are handled at this point. I'm sorry I haven't all that experience with DKMS to clearly confirm this. Mario, can you confirm? So if there were issues between the interaction of the Zaptel userspace init script and DKMS producing the modules to be used, an upstart style script will be needed so that Zaptel's userspace script doesn't get launched unless DKMS is finished. -- Mario Limonciello *Dell | Linux Engineering* [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: RFC: DKMS - Dynamic Kernel Module Support
Hi Cohen: Keep in mind, if there is a new kernel that gets installed, this will build the driver for that kernel, but nothing will be activated until you reboot. That choice is your own. Due to the kernel postinstall service, you won't even need to build the modules during the next boot prior to the zaptel service starting. Regards Tzafrir Cohen wrote: On Thu, Sep 11, 2008 at 05:29:44PM +0200, David Paleino wrote: Maybe it's possible (I'm not exactly sure. I think it's possible, at least in most cases). But do I want this? Do I want to shut down my PBX because of the Ubuntu kernel upgrade of the month? Which is why I never tried to add such an option to the init script, and why noone has asked for it. -- Mario Limonciello *Dell | Linux Engineering* [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: RFC: DKMS - Dynamic Kernel Module Support
Hi David: I'll add on the Ubuntu kernel team here to get some comments on this postinstall hook functionality and it's origins. Regards David Paleino wrote: On Thu, 11 Sep 2008 10:00:38 +0200, David Paleino wrote: If you have AUTOINSTALL set to yes in a DKMS control file: 1) It includes a kernel postinstall hook. This means that, the moment kernel headers get installed, your modules are automatically rebuilt. This is achieved through the installation of a script in: /etc/kernel/header_postinst.d/ /etc/kernel/postinst.d/ /etc/kernel/prerm.d/ A quick search with apt-file didn't return any result. Is this approach supported by Debian? I remember grub updating itself when a new kernel is installed: is that a postinst by the kernel package itself? Kindly, David -- Mario Limonciello *Dell | Linux Engineering* [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: RFC: DKMS - Dynamic Kernel Module Support
On Thu, 11 Sep 2008 19:17:17 +0200, Josselin Mouette wrote: Le jeudi 11 septembre 2008 à 17:29 +0200, David Paleino a écrit : 1) It includes a kernel postinstall hook. This means that, the moment kernel headers get installed, your modules are automatically rebuilt. Seems just as easy (or diffiuclt) to implement with module-assistant, right? Is it possible to generate a package at a package post-install hook? The short answer: probably not, but DKMS is not following this way. The long answer: here's the problem -- currently m-a just generates .deb packages, which are handled by apt-get, dpkg and the such. DKMS would instead handle all that by itself -- and to remove a module, you'd need to do something like: # dkms remove -m module [-v version] [...lots of other options...] This is definitely the correct way to build extra modules. This could mean: * The end of the nightmare for users who need to rebuild their modules by hand every time the kernel ABI changes. Correct. * More smoothness for testing migration of non-free modules, which could simply be shipped as source. Right. Effectively, DKMS tarballs are just source tarballs of modules plus some scripts for DKMS to use. One of the issues I’m wondering about is: how do you ensure you always have the kernel headers for the installed kernels? Some kind of check inside DKMS? In the end, that's a Bash script, and the Debian maintainer (i.e. me, in this case) could just maintain a patch for this (or just issue a warning at the kernel post-inst hook looking like Hey, if you do not install linux-headers-foo, you won't be able to use these modules: foo bar baz buz). Or, better, DKMS as an autoinstall option in its configuration file: we could use a kernel postinst hook to check this value, and if it's set to yes (or true, or 1, or whatever), auto-download and install kernel-headers. Would this be acceptable? Regards, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFC: DKMS - Dynamic Kernel Module Support
Hi Josselin: As I understand, the dpkg maintainer (Michael Vogt) is implementing the idea of package groups that have sticky dependencies. This should mean that when a package gets installed, it will need to register with the package group. When a kernel with a new ABI is available, it won't be offered as an upgrade until all of the items in the package group are available for the upgrade. I've added him on to try to comment on this some more. Josselin Mouette wrote: Le jeudi 11 septembre 2008 à 17:29 +0200, David Paleino a écrit : This is definitely the correct way to build extra modules. This could mean: * The end of the nightmare for users who need to rebuild their modules by hand every time the kernel ABI changes. * More smoothness for testing migration of non-free modules, which could simply be shipped as source. Please go ahead in this direction. One of the issues I’m wondering about is: how do you ensure you always have the kernel headers for the installed kernels? Cheers, -- Mario Limonciello *Dell | Linux Engineering* [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: RFC: DKMS - Dynamic Kernel Module Support
Le jeudi 11 septembre 2008 à 19:23 +0200, David Paleino a écrit : One of the issues I’m wondering about is: how do you ensure you always have the kernel headers for the installed kernels? Some kind of check inside DKMS? In the end, that's a Bash script, and the Debian maintainer (i.e. me, in this case) could just maintain a patch for this (or just issue a warning at the kernel post-inst hook looking like Hey, if you do not install linux-headers-foo, you won't be able to use these modules: foo bar baz buz). Yes, and if dkps depends on linux-headers-2.6-$subarch, that will do the trick at least for the default kernel. (Depending on just linux-headers-2.6 is not enough, since linux-headers-2.6.xx-y-$subarch provides it). Or, better, DKMS as an autoinstall option in its configuration file: we could use a kernel postinst hook to check this value, and if it's set to yes (or true, or 1, or whatever), auto-download and install kernel-headers. Would this be acceptable? You’d run into the same issue as module-assistant has: a package being installed cannot launch installation of other packages. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFC: DKMS - Dynamic Kernel Module Support
On Thu, 11 Sep 2008 19:43:39 +0200, Josselin Mouette wrote: Le jeudi 11 septembre 2008 à 19:23 +0200, David Paleino a écrit : One of the issues I’m wondering about is: how do you ensure you always have the kernel headers for the installed kernels? Some kind of check inside DKMS? In the end, that's a Bash script, and the Debian maintainer (i.e. me, in this case) could just maintain a patch for this (or just issue a warning at the kernel post-inst hook looking like Hey, if you do not install linux-headers-foo, you won't be able to use these modules: foo bar baz buz). Yes, and if dkps depends on linux-headers-2.6-$subarch, that will do the trick at least for the default kernel. (Depending on just linux-headers-2.6 is not enough, since linux-headers-2.6.xx-y-$subarch provides it). With -foo I meant -x.x-y-$arch ;) Sorry for abbreviating! Or, better, DKMS as an autoinstall option in its configuration file: we could use a kernel postinst hook to check this value, and if it's set to yes (or true, or 1, or whatever), auto-download and install kernel-headers. Would this be acceptable? You’d run into the same issue as module-assistant has: a package being installed cannot launch installation of other packages. Uhm, right. I believe there could be a margin of improvement here for apt-get: 1) apt-get install linux-image-2.6-blabla 2) ...installation goes... 3) the postinst hook sets an APT flag (something like: please rerun because you still have things to do) with some action (i.e. mark package FOO for installation) 4) apt-get checks if there are any flags set, and if so, acts consequently. Would this be an acceptable solution? (but that would imply improving apt-get itself) Kindly, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFC: DKMS - Dynamic Kernel Module Support
On Thu, Sep 11, 2008 at 07:43:39PM +0200, Josselin Mouette wrote: Le jeudi 11 septembre 2008 à 19:23 +0200, David Paleino a écrit : One of the issues I’m wondering about is: how do you ensure you always have the kernel headers for the installed kernels? Some kind of check inside DKMS? In the end, that's a Bash script, and the Debian maintainer (i.e. me, in this case) could just maintain a patch for this (or just issue a warning at the kernel post-inst hook looking like Hey, if you do not install linux-headers-foo, you won't be able to use these modules: foo bar baz buz). Yes, and if dkps depends on linux-headers-2.6-$subarch, that will do the trick at least for the default kernel. (Depending on just linux-headers-2.6 is not enough, since linux-headers-2.6.xx-y-$subarch provides it). I think you meant: depend on linux-headers-2.6.26-1-all There is no linux-headers-2.6-all-latest And even that means tying a nice and little package to a specific kernel version, which is probably not such a nice idea. Especially not for those who build their own kernel. For i386 the situation is particualrily bad, as the -all will pull a hosts of other packages. -- Tzafrir Cohen | [EMAIL PROTECTED] | VIM is http://tzafrir.org.il || a Mutt's [EMAIL PROTECTED] || best ICQ# 16849754 || friend -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: DKMS - Dynamic Kernel Module Support
Le jeudi 11 septembre 2008 à 17:29 +0200, David Paleino a écrit : 1) It includes a kernel postinstall hook. This means that, the moment kernel headers get installed, your modules are automatically rebuilt. Seems just as easy (or diffiuclt) to implement with module-assistant, right? Is it possible to generate a package at a package post-install hook? The short answer: probably not, but DKMS is not following this way. The long answer: here's the problem -- currently m-a just generates .deb packages, which are handled by apt-get, dpkg and the such. DKMS would instead handle all that by itself -- and to remove a module, you'd need to do something like: # dkms remove -m module [-v version] [...lots of other options...] This is definitely the correct way to build extra modules. This could mean: * The end of the nightmare for users who need to rebuild their modules by hand every time the kernel ABI changes. * More smoothness for testing migration of non-free modules, which could simply be shipped as source. Please go ahead in this direction. One of the issues I’m wondering about is: how do you ensure you always have the kernel headers for the installed kernels? Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFC: DKMS - Dynamic Kernel Module Support
On Thu, 11 Sep 2008 19:50:35 +0200, David Paleino wrote: On Thu, 11 Sep 2008 19:43:39 +0200, Josselin Mouette wrote: You’d run into the same issue as module-assistant has: a package being installed cannot launch installation of other packages. Uhm, right. I believe there could be a margin of improvement here for apt-get: 1) apt-get install linux-image-2.6-blabla 2) ...installation goes... 3) the postinst hook sets an APT flag (something like: please rerun because you still have things to do) with some action (i.e. mark package FOO for installation) 4) apt-get checks if there are any flags set, and if so, acts consequently. Re-reading my mail: isn't that what dpkg triggers do (i.e. setting flags and postponing actions...)? Can't apt-get just spawn another instance of itself? Regards, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFC: DKMS - Dynamic Kernel Module Support
On Thu, 11 Sep 2008 17:52:39 +, Tzafrir Cohen wrote: On Thu, Sep 11, 2008 at 07:43:39PM +0200, Josselin Mouette wrote: Le jeudi 11 septembre 2008 à 19:23 +0200, David Paleino a écrit : One of the issues I’m wondering about is: how do you ensure you always have the kernel headers for the installed kernels? Some kind of check inside DKMS? In the end, that's a Bash script, and the Debian maintainer (i.e. me, in this case) could just maintain a patch for this (or just issue a warning at the kernel post-inst hook looking like Hey, if you do not install linux-headers-foo, you won't be able to use these modules: foo bar baz buz). Yes, and if dkps depends on linux-headers-2.6-$subarch, that will do the trick at least for the default kernel. (Depending on just linux-headers-2.6 is not enough, since linux-headers-2.6.xx-y-$subarch provides it). I think you meant: depend on linux-headers-2.6.26-1-all There is no linux-headers-2.6-all-latest Well, that could always be added as a package... And even that means tying a nice and little package to a specific kernel version, which is probably not such a nice idea. You do that with m-a, and you have to rebuild modules manually at every kernel change. Especially not for those who build their own kernel. Could you please elaborate on this? Why would that be different? For i386 the situation is particualrily bad, as the -all will pull a hosts of other packages. Sure, but who said to get -all? apt-get is able to determine the architecture he's running on, right? Anyways, dkms is a shells script, it could use dpkg-architecture to get the right string to append to the package name. And, with the idea I exposed before, of those triggers, that should be feasible (i.e. mark the package linux-headers-$version-`dpkg-architecture | grep blabla` as to be installed). Am I just saying non-sense things? :( Regards, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFC: DKMS - Dynamic Kernel Module Support
On Thu, Sep 11, 2008 at 07:50:35PM +0200, David Paleino wrote: On Thu, 11 Sep 2008 19:43:39 +0200, Josselin Mouette wrote: Le jeudi 11 septembre 2008 à 19:23 +0200, David Paleino a écrit : One of the issues I’m wondering about is: how do you ensure you always have the kernel headers for the installed kernels? Some kind of check inside DKMS? In the end, that's a Bash script, and the Debian maintainer (i.e. me, in this case) could just maintain a patch for this (or just issue a warning at the kernel post-inst hook looking like Hey, if you do not install linux-headers-foo, you won't be able to use these modules: foo bar baz buz). Yes, and if dkps depends on linux-headers-2.6-$subarch, that will do the trick at least for the default kernel. (Depending on just linux-headers-2.6 is not enough, since linux-headers-2.6.xx-y-$subarch provides it). With -foo I meant -x.x-y-$arch ;) Sorry for abbreviating! Or, better, DKMS as an autoinstall option in its configuration file: we could use a kernel postinst hook to check this value, and if it's set to yes (or true, or 1, or whatever), auto-download and install kernel-headers. Would this be acceptable? You’d run into the same issue as module-assistant has: a package being installed cannot launch installation of other packages. Uhm, right. I believe there could be a margin of improvement here for apt-get: 1) apt-get install linux-image-2.6-blabla 2) ...installation goes... 3) the postinst hook sets an APT flag (something like: please rerun because you still have things to do) with some action (i.e. mark package FOO for installation) 4) apt-get checks if there are any flags set, and if so, acts consequently. Do you actually have a working build system? Must you have a build system on every host? What is the name of the generated deb package? Can two packages of different kernel architectures liv in the same system? 2.6.26-1-486 and 2.6.26-1-686 . -- Tzafrir Cohen | [EMAIL PROTECTED] | VIM is http://tzafrir.org.il || a Mutt's [EMAIL PROTECTED] || best ICQ# 16849754 || friend -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: DKMS - Dynamic Kernel Module Support
On Thu, 11 Sep 2008 18:02:41 +, Tzafrir Cohen wrote: On Thu, Sep 11, 2008 at 07:50:35PM +0200, David Paleino wrote: I believe there could be a margin of improvement here for apt-get: 1) apt-get install linux-image-2.6-blabla 2) ...installation goes... 3) the postinst hook sets an APT flag (something like: please rerun because you still have things to do) with some action (i.e. mark package FOO for installation) 4) apt-get checks if there are any flags set, and if so, acts consequently. Do you actually have a working build system? Must you have a build system on every host? I can't understand what your question means here. M-a also installs a build system, when you choose Prepare... why would that be different for dkms? Just install build-essential (and what else is needed) alongside with the proper linux-headers-* package. What is the name of the generated deb package? Can two packages of different kernel architectures liv in the same system? 2.6.26-1-486 and 2.6.26-1-686 . DKMS *does* *not* generate .deb packages (although it can): the modules are handled by itself, and not via dpkg (thus, the generated modules are not .debs, but stay in /lib/modules/.../) David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFC: DKMS - Dynamic Kernel Module Support
On Thu, Sep 11, 2008 at 08:02:53PM +0200, David Paleino wrote: On Thu, 11 Sep 2008 17:52:39 +, Tzafrir Cohen wrote: On Thu, Sep 11, 2008 at 07:43:39PM +0200, Josselin Mouette wrote: Le jeudi 11 septembre 2008 à 19:23 +0200, David Paleino a écrit : One of the issues I’m wondering about is: how do you ensure you always have the kernel headers for the installed kernels? Some kind of check inside DKMS? In the end, that's a Bash script, and the Debian maintainer (i.e. me, in this case) could just maintain a patch for this (or just issue a warning at the kernel post-inst hook looking like Hey, if you do not install linux-headers-foo, you won't be able to use these modules: foo bar baz buz). Yes, and if dkps depends on linux-headers-2.6-$subarch, that will do the trick at least for the default kernel. (Depending on just linux-headers-2.6 is not enough, since linux-headers-2.6.xx-y-$subarch provides it). I think you meant: depend on linux-headers-2.6.26-1-all There is no linux-headers-2.6-all-latest Well, that could always be added as a package... And even that means tying a nice and little package to a specific kernel version, which is probably not such a nice idea. You do that with m-a, and you have to rebuild modules manually at every kernel change. Especially not for those who build their own kernel. Could you please elaborate on this? Why would that be different? For i386 the situation is particualrily bad, as the -all will pull a hosts of other packages. Sure, but who said to get -all? apt-get is able to determine the architecture he's running on, right? Anyways, dkms is a shells script, it could use dpkg-architecture to get the right string to append to the package name. And, with the idea I exposed before, of those triggers, that should be feasible (i.e. mark the package linux-headers-$version-`dpkg-architecture | grep blabla` as to be installed). linux-headers-`uname -r` is correct if you run it before the upgrade. [EMAIL PROTECTED]:~$ dpkg-architecture DEB_BUILD_ARCH=i386 DEB_BUILD_ARCH_OS=linux DEB_BUILD_ARCH_CPU=i386 DEB_BUILD_GNU_CPU=i486 DEB_BUILD_GNU_SYSTEM=linux-gnu DEB_BUILD_GNU_TYPE=i486-linux-gnu DEB_HOST_ARCH=i386 DEB_HOST_ARCH_OS=linux DEB_HOST_ARCH_CPU=i386 DEB_HOST_GNU_CPU=i486 DEB_HOST_GNU_SYSTEM=linux-gnu DEB_HOST_GNU_TYPE=i486-linux-gnu [EMAIL PROTECTED]:~$ uname -r 2.6.18-6-vserver-686 OK. I must have missed something obvious. -- Tzafrir Cohen | [EMAIL PROTECTED] | VIM is http://tzafrir.org.il || a Mutt's [EMAIL PROTECTED] || best ICQ# 16849754 || friend -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: DKMS - Dynamic Kernel Module Support
Le jeudi 11 septembre 2008 à 20:02 +0200, David Paleino a écrit : On Thu, 11 Sep 2008 17:52:39 +, Tzafrir Cohen wrote: On Thu, Sep 11, 2008 at 07:43:39PM +0200, Josselin Mouette wrote: Yes, and if dkps depends on linux-headers-2.6-$subarch, that will do the trick at least for the default kernel. (Depending on just linux-headers-2.6 is not enough, since linux-headers-2.6.xx-y-$subarch provides it). I think you meant: depend on linux-headers-2.6.26-1-all There is no linux-headers-2.6-all-latest No, I meant what I wrote. If you depend on a specific version of the kernel, the whole point of this package is moot. For i386 the situation is particualrily bad, as the -all will pull a hosts of other packages. You need a OR dependency, not to bring all of them. For example, for i386 this becomes: Depends: linux-headers-2.6-686 | linux-headers-2.6-486 | linux-headers-2.6-amd64 | ... All of this is very bad. We need a way to express “I need the headers installed for all installed kernel packages”. The idea of package groups only partially solves this; it guarantees the headers are upgraded with the image, but it does not provide a good way to install the *good* headers. For example, let’s say d-i installed the linux-image-2.6-amd64 image, because you have a 64bit CPU. If you install a package using dkms, and it pulls the headers. But which headers? APT is not clever enough to install the ones corresponding to an existing kernel image; it will just install the first one in the list. Sure, but who said to get -all? At least getting -all guarantees that you have the correct one, so this is by far not the worst idea that has been thrown. Having a linux-headers-2.6-all package depending on the default version of -all would do the trick for most situations, I think. apt-get is able to determine the architecture he's running on, right? Anyways, dkms is a shells script, it could use dpkg-architecture to get the right string to append to the package name. And, with the idea I exposed before, of those triggers, that should be feasible (i.e. mark the package linux-headers-$version-`dpkg-architecture | grep blabla` as to be installed). Am I just saying non-sense things? :( Yes. You cannot install packages in a triggered script, or in whatever way that will be determined from within a package itself. You need to get *all* the requirements through package dependencies so that it can go in a single APT run. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFC: DKMS - Dynamic Kernel Module Support
hi, On Thu, Sep 11, 2008 at 07:50:35PM +0200, David Paleino wrote: You’d run into the same issue as module-assistant has: a package being installed cannot launch installation of other packages. Uhm, right. I believe there could be a margin of improvement here for apt-get: snip 3) the postinst hook sets an APT flag (something like: please rerun because you still have things to do) with some action (i.e. mark package FOO for installation) 4) apt-get checks if there are any flags set, and if so, acts consequently. Would this be an acceptable solution? (but that would imply improving apt-get itself) no, i don't think it would be acceptable (though of course i'm not an apt maintainer). personally i wouldn't see it as an improvement, only an ugly workaround. also keep in mind that there are a number of package managers and frontends out there, and regardless, dpkg itself would then no longer work in such situations. as an alternative, i'd suggest: - building the modules as part of the upgrade process using dpkg triggers or some other clever mechanism to determine when it needs to be done - storing the modules in a nested subdirectory of /var/lib, like maybe /var/lib/dkms-or-ma/modules/uname -r/foo. - writing an initramfs hook that includes looking for modules from these directories when building the initramfs - making any necessary modifications to module-init-tools so that these directories were included in the search path for modprobe. note that this is non-conflicting with rolling the modules into a .deb package too, but i think is the only clean way to build/install kernel modules if you are already within the package installation process. sean signature.asc Description: Digital signature
Re: RFC: DKMS - Dynamic Kernel Module Support
On Thu, 11 Sep 2008 20:24:53 +0200, Josselin Mouette wrote: Le jeudi 11 septembre 2008 à 20:02 +0200, David Paleino a écrit : apt-get is able to determine the architecture he's running on, right? Anyways, dkms is a shells script, it could use dpkg-architecture to get the right string to append to the package name. And, with the idea I exposed before, of those triggers, that should be feasible (i.e. mark the package linux-headers-$version-`dpkg-architecture | grep blabla` as to be installed). Am I just saying non-sense things? :( Yes. You cannot install packages in a triggered script, or in whatever way that will be determined from within a package itself. Is there any particular reason for this? I've seen aptitude doing something similar (i.e. running multiple times with a single launch)... am I wrong? You need to get *all* the requirements through package dependencies so that it can go in a single APT run. Yes, the run is single, i.e. you just launch apt-get install linux-image-2.6.26-1-686 and stop. What I meant is apt-get starting kind of a sub-process... Let me clarify the idea: isn't it possible to make a dkms trigger, that runs on installation of linux-image-*? It should do the following: a) checks if autoinstall is set in dkms configuration; b) if set to yes: 1) start the install of the corresponding linux-headers-* package (a way to programmatically determine the package name of this?); 2) start the compilation of in-tree modules; (i.e. modules handled by dkms) c) if set to no: 1) print a message suggesting the installation of the above package; 2) print a message suggesting what to do next From your reply, I understand that b1) wouldn't be possible to achieve. Why? Can't triggers start external programs? Thanks for your help in trying to solve this, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFC: DKMS - Dynamic Kernel Module Support
On Thu, 11 Sep 2008 20:13:40 +0200, sean finney wrote: hi, Hello Sean, On Thu, Sep 11, 2008 at 07:50:35PM +0200, David Paleino wrote: You’d run into the same issue as module-assistant has: a package being installed cannot launch installation of other packages. Uhm, right. I believe there could be a margin of improvement here for apt-get: snip 3) the postinst hook sets an APT flag (something like: please rerun because you still have things to do) with some action (i.e. mark package FOO for installation) 4) apt-get checks if there are any flags set, and if so, acts consequently. Would this be an acceptable solution? (but that would imply improving apt-get itself) no, i don't think it would be acceptable (though of course i'm not an apt maintainer). personally i wouldn't see it as an improvement, only an ugly workaround. Probably I badly exposed my idea: in recent replies I'm thinking to a dkms trigger... also keep in mind that there are a number of package managers and frontends out there, and regardless, dpkg itself would then no longer work in such situations. Uhm, right. But, with the trigger idea, that would be handled by dpkg itself -- AFAIK that's the lowest program that handles packages. as an alternative, i'd suggest: - building the modules as part of the upgrade process using dpkg triggers or some other clever mechanism to determine when it needs to be done Ok, this is what I was trying to suggest :) - storing the modules in a nested subdirectory of /var/lib, like maybe /var/lib/dkms-or-ma/modules/uname -r/foo. How would those modules work with the kernel? AFAIK, modules should be put into /lib/modules/`uname -r`/kernel/. - writing an initramfs hook that includes looking for modules from these directories when building the initramfs Uhm, and if the machine boots without initramfs? - making any necessary modifications to module-init-tools so that these directories were included in the search path for modprobe. Probably this might be a good solution. note that this is non-conflicting with rolling the modules into a .deb package too, but i think is the only clean way to build/install kernel modules if you are already within the package installation process. I'd like to stick with the triggers idea -- it looks cleaner (and nicer) to me, but I'm no dpkg expert... Thanks for your contribution, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFC: DKMS - Dynamic Kernel Module Support
Le jeudi 11 septembre 2008 à 21:44 +0200, David Paleino a écrit : On Thu, 11 Sep 2008 20:24:53 +0200, Josselin Mouette wrote: You cannot install packages in a triggered script, or in whatever way that will be determined from within a package itself. Is there any particular reason for this? Yes, launching dpkg requires locking the database, and the database is already locked within a dpkg run. I've seen aptitude doing something similar (i.e. running multiple times with a single launch)... am I wrong? Aptitude may launch dpkg several times, but the order of the runs is determined before. Let me clarify the idea: isn't it possible to make a dkms trigger, that runs on installation of linux-image-*? It should do the following: a) checks if autoinstall is set in dkms configuration; b) if set to yes: 1) start the install of the corresponding linux-headers-* package (a way to programmatically determine the package name of this?); 2) start the compilation of in-tree modules; (i.e. modules handled by dkms) c) if set to no: 1) print a message suggesting the installation of the above package; 2) print a message suggesting what to do next From your reply, I understand that b1) wouldn't be possible to achieve. Why? Can't triggers start external programs? Triggers are run from within dpkg, and cannot launch new APT/dpkg processes. And in all cases, it is fundamentally wrong to assume that APT can be invoked. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFC: DKMS - Dynamic Kernel Module Support
On Thu, 11 Sep 2008 21:55:16 +0200, Josselin Mouette wrote: Le jeudi 11 septembre 2008 à 21:44 +0200, David Paleino a écrit : On Thu, 11 Sep 2008 20:24:53 +0200, Josselin Mouette wrote: You cannot install packages in a triggered script, or in whatever way that will be determined from within a package itself. Is there any particular reason for this? Yes, launching dpkg requires locking the database, and the database is already locked within a dpkg run. Uhm, right. Didn't think to that, sorry. I've seen aptitude doing something similar (i.e. running multiple times with a single launch)... am I wrong? Aptitude may launch dpkg several times, but the order of the runs is determined before. ACK. Let me clarify the idea: isn't it possible to make a dkms trigger, that runs on installation of linux-image-*? It should do the following: a) checks if autoinstall is set in dkms configuration; b) if set to yes: 1) start the install of the corresponding linux-headers-* package (a way to programmatically determine the package name of this?); 2) start the compilation of in-tree modules; (i.e. modules handled by dkms) c) if set to no: 1) print a message suggesting the installation of the above package; 2) print a message suggesting what to do next From your reply, I understand that b1) wouldn't be possible to achieve. Why? Can't triggers start external programs? Triggers are run from within dpkg, and cannot launch new APT/dpkg processes. And in all cases, it is fundamentally wrong to assume that APT can be invoked. Ok, understood. Ok, let's change approach. I'm CCing the Ubuntu kernel team list: could you please explain how the kernel postinst hook works? (i.e. /etc/kernel/postinst.d/ and the like) Kindly, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFC: DKMS - Dynamic Kernel Module Support
On Thu, 2008-09-11 at 10:00 +0200, David Paleino wrote: *Other* 5) Interoperability with different distributions. DKMS tarballs can be used on RHEL, SuSE, Ubuntu, or Debian. If there are different kernels, patches can be included in the DKMS tarball to enable support on different kernel releases. 6) Acceptance in enterprise solutions. Both Redhat Novell support DKMS as a solution for OEMs to provide kernel modules that won't be maintained in the upstream tree for the foreseeable future. A certain major OEM requires its server component vendors to provide any required out-of-tree modules as DKMS packages. If Debian were to include DKMS that would make it easier for users to set up their $OEM systems if they include components that aren't supported by a stable release. Note, we would also need to ensure that alien does a good job with DKMS RPMs. Ben. signature.asc Description: This is a digitally signed message part
Re: Re: RFC: DKMS - Dynamic Kernel Module Support
This is achieved through the installation of a script in: /etc/kernel/header_postinst.d/ /etc/kernel/postinst.d/ /etc/kernel/prerm.d/ A quick search with apt-file didn't return any result. Is this approach supported by Debian? /etc/kernel/header_postinst.d/ isn't supported. I remember grub updating itself when a new kernel is installed: is that a postinst by the kernel package itself? Yes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: DKMS - Dynamic Kernel Module Support
On jeu, 2008-09-11 at 21:32 +0100, Ben Hutchings wrote: Note, we would also need to ensure that alien does a good job with DKMS RPMs. dkms can build deb packages. They need dkms to be installed too (so you need it installed on all your servers, not just on the build machine), but it works fine. -- Yves-Alexis signature.asc Description: This is a digitally signed message part
