[arch-dev-public] dropping mkinitcpio-nfs-utils
Hi all, I'd like to drop mkinitcpio-nfs-utils from the repos. I suspect (but would be happy to be proven wrong) that nobody uses this package. It's based on code extracted from klibc which, while still a somewhat active project, is lacking sorely in features in the network stack and NFS itself (supporting only nfs3). If someone were interested in reviving this in the future, I'd suspect that it would be best to start from the ground up with a systemd-based initramfs, using nfs-utils and systemd-networkd. The best part of this deal would be that someone who actually uses this setup would then be maintaining the code! Any objections? d
Dave Reisner <d@falconindy.com> on Mon, 2016/07/04 13:16:
Hi all,
I'd like to drop mkinitcpio-nfs-utils from the repos. I suspect (but would be happy to be proven wrong) that nobody uses this package. It's based on code extracted from klibc which, while still a somewhat active project, is lacking sorely in features in the network stack and NFS itself (supporting only nfs3).
If someone were interested in reviving this in the future, I'd suspect that it would be best to start from the ground up with a systemd-based initramfs, using nfs-utils and systemd-networkd. The best part of this deal would be that someone who actually uses this setup would then be maintaining the code!
Any objections?
Yes... :-p We use ipconfig for network configuration in initramfs, which is needed for PXE boot - even for non-nfs setups. -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
On 07/04/16 14:16, Dave Reisner wrote:
Hi all,
I'd like to drop mkinitcpio-nfs-utils from the repos. I suspect (but would be happy to be proven wrong) that nobody uses this package. It's based on code extracted from klibc which, while still a somewhat active project, is lacking sorely in features in the network stack and NFS itself (supporting only nfs3).
If someone were interested in reviving this in the future, I'd suspect that it would be best to start from the ground up with a systemd-based initramfs, using nfs-utils and systemd-networkd. The best part of this deal would be that someone who actually uses this setup would then be maintaining the code!
Any objections?
d
Yes, used in archiso. Will be great if posible to migrate to pure systemd, but it does not provide such functionality and flexibility (cmdline params). Three years ago, I proposed a feature request in systemd, for some related things, but nobody was interested [#1]. [#1] https://lists.freedesktop.org/archives/systemd-devel/2013-July/012397.html
On Mon, Jul 04, 2016 at 08:12:42PM -0300, Gerardo Exequiel Pozzi via arch-dev-public wrote:
On 07/04/16 14:16, Dave Reisner wrote:
Hi all,
I'd like to drop mkinitcpio-nfs-utils from the repos. I suspect (but would be happy to be proven wrong) that nobody uses this package. It's based on code extracted from klibc which, while still a somewhat active project, is lacking sorely in features in the network stack and NFS itself (supporting only nfs3).
If someone were interested in reviving this in the future, I'd suspect that it would be best to start from the ground up with a systemd-based initramfs, using nfs-utils and systemd-networkd. The best part of this deal would be that someone who actually uses this setup would then be maintaining the code!
Any objections?
d
Yes, used in archiso.
Will be great if posible to migrate to pure systemd, but it does not provide such functionality and flexibility (cmdline params). Three years ago, I proposed a feature request in systemd, for some related things, but nobody was interested [#1].
[#1] https://lists.freedesktop.org/archives/systemd-devel/2013-July/012397.html
Well, it seems rather unfair that we attempt to treat the kernel command line as environment. Any resemblance to shell environment variables is merely a coincidence, IMO, as it's much closer to command line arguments to an ordinary userspace program (hence the proc filename 'cmdline'). With that in mind, it doesn't really seem suitable to push this upstream to systemd as it would need to make arbitrary decisions about what to do with data in cmdline which isn't exportable through the shell. Should it sanitize these (and would it do this by replacement or just dropping the invalid data)? Assign arbitrary values to bare words? Drop them entirely? I think it's rather app-specific as to how this is handled, since the data which is invalid to the shell may very well not be invalid elsewhere. With that in mind, would it be useful if I were to refactor the cmdline parsing logic in mkinitcpio to make it reusable? I went ahead and wrote some unit tests against the existing parser (findings a number of bugs) and then rewrote it to do exactly this: http://code.falconindy.com/cgit/mkinitcpio.git/commit/?id=a3829b600 Now you can do something like: cmdline_item_callback() { local key=$1 value=$2 case $key in ...) ... ;; esac } . ./init_functions process_cmdline 'cmdline_item_callback' Perhaps you could use this to write out something suitable as an EnvironmentFile which ArchISO could source and use in its units. Let me know what you think, d
On 07/06/16 08:58, Dave Reisner wrote:
On Mon, Jul 04, 2016 at 08:12:42PM -0300, Gerardo Exequiel Pozzi via arch-dev-public wrote:
On 07/04/16 14:16, Dave Reisner wrote:
Hi all,
I'd like to drop mkinitcpio-nfs-utils from the repos. I suspect (but would be happy to be proven wrong) that nobody uses this package. It's based on code extracted from klibc which, while still a somewhat active project, is lacking sorely in features in the network stack and NFS itself (supporting only nfs3).
If someone were interested in reviving this in the future, I'd suspect that it would be best to start from the ground up with a systemd-based initramfs, using nfs-utils and systemd-networkd. The best part of this deal would be that someone who actually uses this setup would then be maintaining the code!
Any objections?
d
Yes, used in archiso.
Will be great if posible to migrate to pure systemd, but it does not provide such functionality and flexibility (cmdline params). Three years ago, I proposed a feature request in systemd, for some related things, but nobody was interested [#1].
[#1] https://lists.freedesktop.org/archives/systemd-devel/2013-July/012397.html
Well, it seems rather unfair that we attempt to treat the kernel command line as environment. Any resemblance to shell environment variables is merely a coincidence, IMO, as it's much closer to command line arguments to an ordinary userspace program (hence the proc filename 'cmdline').
With that in mind, it doesn't really seem suitable to push this upstream to systemd as it would need to make arbitrary decisions about what to do with data in cmdline which isn't exportable through the shell. Should it sanitize these (and would it do this by replacement or just dropping the invalid data)? Assign arbitrary values to bare words? Drop them entirely? I think it's rather app-specific as to how this is handled, since the data which is invalid to the shell may very well not be invalid elsewhere.
With that in mind, would it be useful if I were to refactor the cmdline parsing logic in mkinitcpio to make it reusable? I went ahead and wrote some unit tests against the existing parser (findings a number of bugs) and then rewrote it to do exactly this:
http://code.falconindy.com/cgit/mkinitcpio.git/commit/?id=a3829b600
Now you can do something like:
cmdline_item_callback() { local key=$1 value=$2
case $key in ...) ... ;; esac }
. ./init_functions process_cmdline 'cmdline_item_callback'
Perhaps you could use this to write out something suitable as an EnvironmentFile which ArchISO could source and use in its units.
Let me know what you think, d
Looks good, it should help to parse ip= and BOOTIF=, to make a generator to dynamically create static or dhcp network units in case of systemd usage. Thanks.
participants (3)
-
Christian Hesse
-
Dave Reisner
-
Gerardo Exequiel Pozzi