[arch-dev-public] External Kernel Modules - DKMS
There was a short discussion not long ago on the TUR mailing list regarding external kernel modules. It was suggested that they be setup using dkms, which will easily allow one package, for multiple kernels. Having looked at the dkms setup suggested, and the few example modules in the AUR (search dkms), this might be a good idea, and make it much simpler to support a range of different kernels. Contrary to what andyrtr said, the DKMS system looks quite good, and would fit well. James
Am Dienstag, 31. Juli 2007 13:39:29 schrieb James Rayner:
There was a short discussion not long ago on the TUR mailing list regarding external kernel modules. It was suggested that they be setup using dkms, which will easily allow one package, for multiple kernels.
Having looked at the dkms setup suggested, and the few example modules in the AUR (search dkms), this might be a good idea, and make it much simpler to support a range of different kernels. Contrary to what andyrtr said, the DKMS system looks quite good, and would fit well.
James
It might be a good idea for those kernels in aur/community. But I don not see any reason why we should provide more than one kernel within the official repositories ([current]/[extra]). Pierre -- archlinux.de
2007/7/31, Pierre Schmitz <pierre@archlinux.de>:
Am Dienstag, 31. Juli 2007 13:39:29 schrieb James Rayner:
There was a short discussion not long ago on the TUR mailing list regarding external kernel modules. It was suggested that they be setup using dkms, which will easily allow one package, for multiple kernels.
Having looked at the dkms setup suggested, and the few example modules in the AUR (search dkms), this might be a good idea, and make it much simpler to support a range of different kernels. Contrary to what andyrtr said, the DKMS system looks quite good, and would fit well.
James
It might be a good idea for those kernels in aur/community.
But I don not see any reason why we should provide more than one kernel within the official repositories ([current]/[extra]).
That's exactly what I thought too. -- Roman Kyrylych (Роман Кирилич)
Tuesday 31 July 2007, Pierre Schmitz wrote: | But I don not see any reason why we should provide more than one | kernel within the official repositories ([current]/[extra]). one reason would be to have a high-resolution (1000Hz instead of 250Hz time resolution) kernel in the repos for computers that depend on it (heavy usage of real time multimedia recording). i'm not saying that i have time to upload every since and then a whole kernel to the servers (at least now without having a broad internet connection), but because our official one is 250Hz i run my own. - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
2007/7/31, Damir Perisa <damir.perisa@solnet.ch>:
Tuesday 31 July 2007, Pierre Schmitz wrote: | But I don not see any reason why we should provide more than one | kernel within the official repositories ([current]/[extra]).
one reason would be to have a high-resolution (1000Hz instead of 250Hz time resolution) kernel in the repos for computers that depend on it (heavy usage of real time multimedia recording).
i'm not saying that i have time to upload every since and then a whole kernel to the servers (at least now without having a broad internet connection), but because our official one is 250Hz i run my own.
300Hz now. -- Roman Kyrylych (Роман Кирилич)
Roman Kyrylych schrieb:
i'm not saying that i have time to upload every since and then a whole kernel to the servers (at least now without having a broad internet connection), but because our official one is 250Hz i run my own.
300Hz now.
That only improves NTSC video playback/av-sync, but applications that depend on a high timer frequency (like 1000Hz) still don't work. BTW: What is DKMS
Thomas Bächler wrote:
Roman Kyrylych schrieb:
i'm not saying that i have time to upload every since and then a whole kernel to the servers (at least now without having a broad internet connection), but because our official one is 250Hz i run my own. 300Hz now.
That only improves NTSC video playback/av-sync, but applications that depend on a high timer frequency (like 1000Hz) still don't work.
BTW: What is DKMS
http://linux.dell.com/projects.shtml I also had a brief look at this back when it was orginally proposed, and I think it's worth considering. Re the off-topic part of this thread: I don't understand this "one kernel only" idea myself. If one of us commits to maintaining an alternative kernel package, what good reason is there not to provide it? T.
On Tue, 2007-07-31 at 16:32 +0100, Tom K wrote:
http://linux.dell.com/projects.shtml
I also had a brief look at this back when it was orginally proposed, and I think it's worth considering.
Re the off-topic part of this thread: I don't understand this "one kernel only" idea myself. If one of us commits to maintaining an alternative kernel package, what good reason is there not to provide it?
The reason is because the repos get flooded by duplicate modules and maintenance is a pain with all these different kernels (amd64 guys need to rebuild all modules for all kernels, not fun). With DKMS this would become a nonsense issue, IMHO we should switch. It's easy to integrate into a package using postinstall commands and users are not tied to our specific kernels anymore.
On 31/07/07, Tom K <tom@archlinux.org> wrote:
http://linux.dell.com/projects.shtml
I also had a brief look at this back when it was orginally proposed, and I think it's worth considering.
+1 - I think this is pretty exciting. Ziggy has also recently built a kernel with various patches that provides only an updated vmlinuz and otherwise runs against the stock kernel modules. If this approach is as stable as Ziggy believes then it opens up a whole world of tweaking possibilities. Tom, I'd also like to revisit the custom kernel PKGBUILDs and wiki, would you be interested in working on that with me?
Am Dienstag, 31. Juli 2007 15:54:06 schrieb Damir Perisa:
one reason would be to have a high-resolution (1000Hz instead of 250Hz time resolution) kernel in the repos for computers that depend on it (heavy usage of real time multimedia recording).
i'm not saying that i have time to upload every since and then a whole kernel to the servers (at least now without having a broad internet connection), but because our official one is 250Hz i run my own.
Of course only one kernel cannot fit any use cases you might imagine. But we can only provide package which are usable for most of our users. The others should just use makepkg and build their own kernel package. -- archlinux.de
it seems to be an agreement for having only one official kernel very soon. what for would we need dkms? 1) automated module compiling on major kernel updates - see how often the most important modules are broken and need patching or new versions. dkms won't help there. 2) build kernel modules for custom kernels - why should we support that in core? dkms would be just another possible broken pkg. i suggest to keep it simple how we do it now with only one kernel and prebuild modules. dkms could be a playground in the community repo or maybe even in extra if you like to support it. but first of all we should make important decisions: will we keep the repos or do we want to switch to core + something else? any discussion about the content of our still not defined repos won't make much sense for me now. Andy
On 7/31/07, Andreas Radke <a.radke@arcor.de> wrote:
2) build kernel modules for custom kernels - why should we support that in core? dkms would be just another possible broken pkg.
I've seen a lot of this attitude recently, and I really want to say that I find it decidedly un-Arch-like. "Why support the users when we can just do it our way?" I've always been a fan of arch because it becomes what _I_ want, not what some packager decided I wanted. I'm pretty sure this is true of a lot of people.
but first of all we should make important decisions: will we keep the repos or do we want to switch to core + something else? any discussion about the content of our still not defined repos won't make much sense for me now.
Hrm, I'd recommend making a new thread for this topic here. Let's not hijack James' topic.
participants (10)
-
Aaron Griffin
-
Andreas Radke
-
Damir Perisa
-
James Rayner
-
Jan de Groot
-
Phil Dillon-Thiselton
-
Pierre Schmitz
-
Roman Kyrylych
-
Thomas Bächler
-
Tom K