| 1 |
On Fri, Mar 31, 2017 at 2:58 AM, Robin H. Johnson <robbat2@g.o> wrote: |
| 2 |
> On Thu, Mar 30, 2017 at 08:39:55PM -0400, Rich Freeman wrote: |
| 3 |
>> > As the genkernel author, there have been debates about replacing the |
| 4 |
>> > initramfs-generation portion with Dracut (which requires porting of some |
| 5 |
>> > of the existing initramfs functionality to Dracut) [this is probably a |
| 6 |
>> > GSOC project candidate as well, but it'll be a lot of work]. |
| 7 |
>> I'm not sure what genkernel functionality dracut is actually missing, |
| 8 |
>> but you could certainly use dracut even without porting any additional |
| 9 |
>> functionality to it. Since dracut is highly modular it is probably a |
| 10 |
>> good starting point. |
| 11 |
>> |
| 12 |
>> If anybody does port genkernel functionality to dracut I suggest doing |
| 13 |
>> it in coordination with upstream so that this isn't some kind of |
| 14 |
>> Gentoo-specific patch (or more likely a set of modules). |
| 15 |
> The objective here would be trying for 1:1 compatibility layer with |
| 16 |
> genkernel initramfs arguments & behavior, such that the upgrade can |
| 17 |
> detect "are all kernel options presently used supported by the new |
| 18 |
> version, or would the user have to modify their kernel boot params to |
| 19 |
> boot safely" |
| 20 |
|
| 21 |
Is there really any value in having argument/behavior-level |
| 22 |
compatibility vs simply feature-level compatibility? How many Gentoo |
| 23 |
tools are actually integrated with genkernel today? It seems like it |
| 24 |
would make far more sense to just port those to dracut. |
| 25 |
|
| 26 |
> |
| 27 |
> Some of the behavior might just be thin wrapping or reuse of dracut |
| 28 |
> behavior, eg: |
| 29 |
> - btrfs |
| 30 |
> - dmcrypt |
| 31 |
> - iscsi |
| 32 |
> - lvm |
| 33 |
> - mdadm |
| 34 |
> - multipath |
| 35 |
> - ssh (dropbear) |
| 36 |
> - zfs |
| 37 |
> - dmcrypt |
| 38 |
> - luks |
| 39 |
> - dmraid |
| 40 |
> - ataraid |
| 41 |
> |
| 42 |
|
| 43 |
If this stuff already works, why bother wrapping it? Do we really |
| 44 |
need alternative syntax on a popular cross-distro tool? |
| 45 |
|
| 46 |
> Other parts might be unique and need to be ported still, eg: |
| 47 |
> - gentoo livedvd |
| 48 |
> - docache |
| 49 |
> - aufs |
| 50 |
> - do/no$HW |
| 51 |
> - swsusp |
| 52 |
> - tuxonice |
| 53 |
> - unionfs |
| 54 |
> - overlayfs |
| 55 |
> - fbsplash (I think there are two different implementations even) |
| 56 |
|
| 57 |
There is nothing wrong with creating dracut modules for these things, |
| 58 |
and I'm sure that upstream would accept some of them. However, I |
| 59 |
don't really see any of this as a pre-req for Gentoo Atom. |
| 60 |
|
| 61 |
> |
| 62 |
> As a GSOC project, this would probably start by making sure there is a |
| 63 |
> comprehensive list of genkernel initramfs functionality, and matching |
| 64 |
> parts to existing dracut functionality, and then prioritizing the |
| 65 |
> remaining pieces for those that need wrappers vs from-scratch vs |
| 66 |
> obsolete code. |
| 67 |
> |
| 68 |
|
| 69 |
This might make sense as a GSOC project, but it seems more like a |
| 70 |
dracut/Redhat/Fedora project than a Gentoo one. |
| 71 |
|
| 72 |
-- |
| 73 |
Rich |
Archives