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
