[arch-dev-public] dropping mkinitcpio-nfs-utils

Gerardo Exequiel Pozzi vmlinuz386 at gmail.com
Thu Jul 7 00:05:22 UTC 2016


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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20160706/6ea18053/attachment.asc>


More information about the arch-dev-public mailing list