Re: Out-of-tree kernel module udeb
On Thu, 2015-05-21 at 00:12 +0200, maximilian attems wrote: On Sun, May 17, 2015 at 01:36:53PM +0100, Ben Hutchings wrote: On Sun, 2015-05-17 at 13:25 +0200, Cyril Brulebois wrote: At the moment only spl is available in the archive, using dkms, and for zfs it's similar in the way of packaging though not uploaded yet. What we have (code ready to go) is a mechanism that detects/gets definition of a current KVERS and generate a source package with dependencies and binary packages with names corresponding to it. What do you guys think? My personal stance on kernel related things would be “upstream first”. If it ain't going to be merged into mainline, or at least accepted as a patchset (like e.g. aufs3 or rt in wheezy) for src:linux, I'm not sure we want to support that. Cc-ing debian-kernel@ to see what they think. I strongly oppose adding OOT modules this way as a supposed workaround for licence incompatibility. this has been indeed our general conensus. we reject OOT modules or patchsets that have zero or near zero probability of getting merged upstream. I meant as a separate package that goes into the installer, not the kernel package (where I think our policy is well known now!). Ben. -- Ben Hutchings I'm not a reverse psychological virus. Please don't copy me into your sig. signature.asc Description: This is a digitally signed message part
Re: Out-of-tree kernel module udeb
On Sun, May 17, 2015 at 01:36:53PM +0100, Ben Hutchings wrote: On Sun, 2015-05-17 at 13:25 +0200, Cyril Brulebois wrote: At the moment only spl is available in the archive, using dkms, and for zfs it's similar in the way of packaging though not uploaded yet. What we have (code ready to go) is a mechanism that detects/gets definition of a current KVERS and generate a source package with dependencies and binary packages with names corresponding to it. What do you guys think? My personal stance on kernel related things would be “upstream first”. If it ain't going to be merged into mainline, or at least accepted as a patchset (like e.g. aufs3 or rt in wheezy) for src:linux, I'm not sure we want to support that. Cc-ing debian-kernel@ to see what they think. I strongly oppose adding OOT modules this way as a supposed workaround for licence incompatibility. this has been indeed our general conensus. we reject OOT modules or patchsets that have zero or near zero probability of getting merged upstream. -- maks signature.asc Description: Digital signature
Re: Out-of-tree kernel module udeb
On Sun, May 17, 2015 at 9:39 PM, Cyril Brulebois k...@debian.org wrote: Ben Hutchings b...@decadent.org.uk (2015-05-17): On Sun, 2015-05-17 at 13:25 +0200, Cyril Brulebois wrote: My personal stance on kernel related things would be upstream first. If it ain't going to be merged into mainline, or at least accepted as a patchset (like e.g. aufs3 or rt in wheezy) for src:linux, I'm not sure we want to support that. Cc-ing debian-kernel@ to see what they think. I strongly oppose adding OOT modules this way as a supposed workaround for licence incompatibility. Just to clarify: I didn't mean to suggest doing so to work around any license issues. I was just trying to mention an alternate way for stuff that aren't (going to be) in mainline and that might still land in Debian kernels. Build the module in the same source tree of Linux kernel (including patch at build time) is not a feasible option for ZoL because of the potential of licensing incompatibility, that is to say we are risk to combine CDDL work into GPL one. The only safe option is to build the module from another source package and eliminate the possibility of building that module into a monolithic kernel binary. Thanks, Aron -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAMr=8w4h0mv85ao-rxsaznrozdg9zhgpq-3kajss5d3w377...@mail.gmail.com
Re: Out-of-tree kernel module udeb
Hi, Aron Xu a...@debian.org (2015-05-17): [Not on list, please keep me posted.] [done] I'm wondering whether d-i team would like to accept out-of-tree kernel module udeb for certain features, for example ZFS support? And if the answer is yes, what's the best way of doing it? I wasn't actively involved with debian-boot back then but from what I've seen through debian-release at the time, o-o-t modules were a huge pain to handle. I'd rather not have to deal with such things again. Two years ago we had a GSoC project to provide ZFS on Linux integration, and after that licensing problem blocked the code's actual inclusion. As written in one of the recent Bits from the DPL, the issue is in much better shape and I believe it's time to discuss how to move on with the technical part. At the moment only spl is available in the archive, using dkms, and for zfs it's similar in the way of packaging though not uploaded yet. What we have (code ready to go) is a mechanism that detects/gets definition of a current KVERS and generate a source package with dependencies and binary packages with names corresponding to it. What do you guys think? My personal stance on kernel related things would be “upstream first”. If it ain't going to be merged into mainline, or at least accepted as a patchset (like e.g. aufs3 or rt in wheezy) for src:linux, I'm not sure we want to support that. Cc-ing debian-kernel@ to see what they think. Mraw, KiBi. signature.asc Description: Digital signature
Re: Out-of-tree kernel module udeb
On Sun, 2015-05-17 at 13:25 +0200, Cyril Brulebois wrote: Hi, Aron Xu a...@debian.org (2015-05-17): [Not on list, please keep me posted.] [done] I'm wondering whether d-i team would like to accept out-of-tree kernel module udeb for certain features, for example ZFS support? And if the answer is yes, what's the best way of doing it? I wasn't actively involved with debian-boot back then but from what I've seen through debian-release at the time, o-o-t modules were a huge pain to handle. I'd rather not have to deal with such things again. Two years ago we had a GSoC project to provide ZFS on Linux integration, and after that licensing problem blocked the code's actual inclusion. As written in one of the recent Bits from the DPL, the issue is in much better shape and I believe it's time to discuss how to move on with the technical part. This is wishful thinking. At the moment only spl is available in the archive, using dkms, and for zfs it's similar in the way of packaging though not uploaded yet. What we have (code ready to go) is a mechanism that detects/gets definition of a current KVERS and generate a source package with dependencies and binary packages with names corresponding to it. What do you guys think? My personal stance on kernel related things would be “upstream first”. If it ain't going to be merged into mainline, or at least accepted as a patchset (like e.g. aufs3 or rt in wheezy) for src:linux, I'm not sure we want to support that. Cc-ing debian-kernel@ to see what they think. I strongly oppose adding OOT modules this way as a supposed workaround for licence incompatibility. For OOT modules that are under GPLv2 or compatible licence, you would have to decide which images they belong in rather than letting the kernel team do that through kernel-wedge config. Ben. -- Ben Hutchings compatible: Gracefully accepts erroneous data from any source signature.asc Description: This is a digitally signed message part
Re: Out-of-tree kernel module udeb
On May 17, 2015, at 1:25 PM, Cyril Brulebois wrote:
Aron Xu a...@debian.org (2015-05-17):
At the moment only spl is available in the archive, using dkms, and
for zfs it's similar in the way of packaging though not uploaded yet.
What we have (code ready to go) is a mechanism that detects/gets
definition of a current KVERS and generate a source package with
dependencies and binary packages with names corresponding to it.
My personal stance on kernel related things would be “upstream first”.
I'm not exactly sure what you mean by that, but if you mean that upstream
(i.e. ZFS On Linux - ZoL in this case) should have the support to build
binary modules package(s), then they do.
BUT, it's somewhat of a hack. The debs upstream build is from alien the
rpm which it natively have.
And if we're talking about udebs, there is no need for that in upstream.
If we're talking about upstream as the Linux kernel sources, because of
the CDDL license of ZoL, we're _NEVER_ (ever, ever!!) going to be able
to put it in the Linux kernel source tree.
Unless someone that's never seen the ZoL code decides to … reverse engineer
one of the most advanced filesystems ever created (so far). I doubt (do
get I a understatement of the year award for that?? :) that will ever
happen either.
If it ain't going to be merged into mainline, or at least accepted as a
patchset (like e.g. aufs3 or rt in wheezy) for src:linux, I'm not sure
we want to support that.
Currently (just to catch everyone up for those that haven't been paying
attention :), I've been doing debs, udebs etc for both SPL (Solaris Porting
Layer) and ZFS for ZoL for years.
I have also made a modified version of D-I (previous patches have been
sent to relevant parties of Debian GNU/Linux although I've been, over the
year, improving on them) that I supply to the ZoL community. But since
Debian GNU/Linux was in release mode, only a few of them was accepted.
So when the packages are built, it also build the udebs for the kernel
it's running on. Because we need ZoL support in the installer, with its
limited space requirements, we can't obviously (!!) ship a build environment
there as well to build the spl and zfs modules (from the existing dkms
packages).
We need the udebs.
_Inside_ the installed system which is created, the dkms packages are used
as normal. It's only in the partition phase of the install we need udebs.
Building this for the current running system is, I agree, somewhat of a
pain. BUT, since the kernel doesn't really change that much/often, I think
_we_ (the pkg-zfsonlinux-devel) can handle it, to make sure that there's udebs
for the kernel D-I is using.
PS1. Because I personally _hate_, _loath_, _really don't like_ dkms, I created
the option to create a {spl,zfs}-modules-source, much like I'm used to
from the OpenAFS code (and others). But it still needs a build environment
(just not necessarily on the host using ZoL - which I prefer not to have).
PS2. Because I got the impression that binary modules wouldn't be allowed
(still haven't heard anything definitive about that from the DPL etc),
I started experimenting with using zfs-fuse for the installer part, and
real ZoL modules (from dkms) for the 'finished product'. After a couple
of weeks, I had a proof-of-concept that seemed to work.
BUT, it's The hack of all hacks in my opinion, and I just can't recommend
that course with a straight face.
We need the udebs to get this all the way (to allow users to install
a fully enabled ZFS system).
--
Choose a job you love, and you will never have
to work a day in your life.
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: Out-of-tree kernel module udeb
Turbo Fredriksson tu...@bayour.com (2015-05-17):
On May 17, 2015, at 1:25 PM, Cyril Brulebois wrote:
My personal stance on kernel related things would be “upstream first”.
I'm not exactly sure what you mean by that, but if you mean that upstream
(i.e. ZFS On Linux - ZoL in this case) should have the support to build
binary modules package(s), then they do.
BUT, it's somewhat of a hack. The debs upstream build is from alien the
rpm which it natively have.
And if we're talking about udebs, there is no need for that in upstream.
None of this.
If we're talking about upstream as the Linux kernel sources, because of
the CDDL license of ZoL, we're _NEVER_ (ever, ever!!) going to be able
to put it in the Linux kernel source tree.
I'm speaking of that.
If it ain't going to be merged into mainline, or at least accepted as a
patchset (like e.g. aufs3 or rt in wheezy) for src:linux, I'm not sure
we want to support that.
Currently (just to catch everyone up for those that haven't been paying
attention :), I've been doing debs, udebs etc for both SPL (Solaris Porting
Layer) and ZFS for ZoL for years.
I have also made a modified version of D-I (previous patches have been
sent to relevant parties of Debian GNU/Linux although I've been, over the
year, improving on them) that I supply to the ZoL community. But since
Debian GNU/Linux was in release mode, only a few of them was accepted.
So when the packages are built, it also build the udebs for the kernel
it's running on. Because we need ZoL support in the installer, with its
limited space requirements, we can't obviously (!!) ship a build environment
there as well to build the spl and zfs modules (from the existing dkms
packages).
We need the udebs.
_Inside_ the installed system which is created, the dkms packages are used
as normal. It's only in the partition phase of the install we need udebs.
Building this for the current running system is, I agree, somewhat of a
pain. BUT, since the kernel doesn't really change that much/often, I think
_we_ (the pkg-zfsonlinux-devel) can handle it, to make sure that there's udebs
for the kernel D-I is using.
Let me rephrase: I'm pretty sure I don't want to have to deal with the
linux-modules-extra-2.6 du jour.
PS1. Because I personally _hate_, _loath_, _really don't like_ dkms, I created
the option to create a {spl,zfs}-modules-source, much like I'm used to
from the OpenAFS code (and others). But it still needs a build
environment
(just not necessarily on the host using ZoL - which I prefer not to
have).
PS2. Because I got the impression that binary modules wouldn't be allowed
(still haven't heard anything definitive about that from the DPL etc),
I started experimenting with using zfs-fuse for the installer part, and
real ZoL modules (from dkms) for the 'finished product'. After a couple
of weeks, I had a proof-of-concept that seemed to work.
BUT, it's The hack of all hacks in my opinion, and I just can't
recommend
that course with a straight face.
We need the udebs to get this all the way (to allow users to install
a fully enabled ZFS system).
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: Out-of-tree kernel module udeb
Ben Hutchings b...@decadent.org.uk (2015-05-17): On Sun, 2015-05-17 at 13:25 +0200, Cyril Brulebois wrote: My personal stance on kernel related things would be “upstream first”. If it ain't going to be merged into mainline, or at least accepted as a patchset (like e.g. aufs3 or rt in wheezy) for src:linux, I'm not sure we want to support that. Cc-ing debian-kernel@ to see what they think. I strongly oppose adding OOT modules this way as a supposed workaround for licence incompatibility. Just to clarify: I didn't mean to suggest doing so to work around any license issues. I was just trying to mention an alternate way for stuff that aren't (going to be) in mainline and that might still land in Debian kernels. Mraw, KiBi. signature.asc Description: Digital signature
