(02:21:09 PM) clumens: in a world where we use systemd for anaconda, how does linuxrc.s390 fit into that?
(02:25:32 PM) david c.: linuxrc.s390 currently does a number of things, most notably firing off a few daemons and enabling hardware devices. like loader, it either uses the provided command line parameters to enable devices or it prompts the user. the catch is that the prompting has to be supported on 3270 consoles, so that's why it's shell and uses 'read'. moving to systemd should help get rid of linuxrc.s390, but what I'd really like to do is:
(02:25:53 PM) david c.: (1) all daemon startups should be handled the same way on all platforms, using whatever init we are currently using in Fedora
(02:27:19 PM) david c.: (2) move the device enabling part of linuxrc.s390 to anaconda in Python. with the single initrd.img now, we gain that ability. there could now be a class that anaconda runs before starting up the normal anaconda interface, we can do the simple user input stuff there and turn on devices. as much as possible should now rely on the s390utils stuff, but that's been slow going.
(02:27:42 PM) david c.: with that, we can also greatly simplify the input gathering and verification since it won't have to be shell
(02:29:57 PM) clumens: yeah, i like that. so it then seems to me that moving to systemd is blocked on getting that stuff done first.
(02:30:33 PM) david c.: yeah
(02:31:19 PM) clumens: you've made some progress there, but not too much right? what with that whole management thing and all.
(02:34:23 PM) david c.: yeah, last year I was working on a complete replacement for linuxrc.s390. it was complicated by the fact that we had loader and then anaconda, which is what led to the script in the first place. I had written preloader, which moved the prompting and device enabling out of shell in to a C program where I could use glib to do things. while it's an improvement on some fronts, I don't really like it
(02:35:33 PM) david c.: moving all of the device enabling for s390 probably isn't possible either. like we still need the ability to bring up the network device early, because that's what will start the installation process. so with a move to systemd, we may need to make a systemd service or whatever it's called to handle just the networking device discovery and bring up for s390. which would then allow loader to start up when the user sshes in
(02:36:02 PM) david c.: the discovery and enabling of the storage devices of s390 can be moved to anaconda to give us more flexibility and allow us to use the storage code directly
(02:36:38 PM) clumens: discovery and enabling doesn't have to be in anaconda itself to make use of the storage code
(02:37:15 PM) david c.: that's also true. but I'm also thinking that I would like to avoid making more side programs to do things that we should just have in the installer directly
(02:38:52 PM) clumens: ack to having a systemd service for a lot of this stuff
(02:39:19 PM) clumens: and yeah while having more side programs kind of sucks, the guts of it would still be anaconda's storage code, so it's not really so bad.