Juergen Daubert wrote:
On Sun, Jun 05, 2011 at 05:44:09PM +0200, Michal Soltys wrote:
Hi Michal,
thanks for sharing your ideas, some quick remarks below. Hope others will comment as well. As a general rule we should wait until the next CRUX release with bigger changes.
A few things have piled up, so before any simple patches to get it up to speed (with other related or no stuff), maybe you have some other ideas/plans:
1) hwdb
This is enabled by default, but de-facto depends on usbutils (usb.ids) and pciutils (pci.ids). Which is prefectly fine, apart from /usr mounts. Nothing anywhere close to important here judging from egrep, but there're a few rules that set few things depending on the contents of those files.
There're a few options I can see here:
1) check+mount in initramfs (btw, with few simple alterations to rc, dracut can serve as pretty much perfect initramfs for CRUX)
2) "we don't support separate /usr" - well, it's an option ...
That's a bit overstated, because udev still works even if it cannot find {pci,usb}.ids ;)
3) disable hwdb ...
4) point udev to different places for usb.ids (since 171) and pci.ids, and adjust respective packages to additionally copy *.ids files to some place under / (/lib/hwdb ? etc.). To make it flexible, simple patches to shell scripts used to update those files would be necessary as well (update_pciids, update_usbids.sh).
5) some other options
Either way, if udev is assumed to be able to run cleanly with unmounted and separate /usr, something here would be needed. I'd opt for #4 now (and #1 in a long shot), as the required changes are pretty trivial (even if ugly, see for fun: http://www.spinics.net/linux/lists/hotplug/msg04867.html)
I've no strong optinion yet, but would be fine with 4) or even 3). I didn't disabled it with the latest udev updates because it dosn't hurt anything.
2) acl
acl is in core, and I'd guess can be just enabled for those that need it
depends on glib, see below
3) keymaps
no other dependencies or issues (if i haven't missed anything), would make a few laptop users more happy
depends on opt/gperf at buildtime. Not a big issue to move it to core, but probably a CRUX 2.8 thing.
4) generator rules
Deprecated but still enabled. The stance on network renaming is, that those that need it should provide static rules themselves (which is pretty trivial to do either way). I'd disable it and install some example file in /etc/udev/rules.d
5) edd, floppy, modeswitch
deprecated and disabled by default (modeswitch moved to upstream, edd caused problems, floopy created deprecated names iirc), so not much to mention here
6) gudev
If it's decided to keep that disabled (besides aiming at as minimal build as possible, any other reasons ?), then trickery with moving glib's runtime dirs to / is likely unnecessary as well (gio part in particular)
well, moving glib to core was triggered by the pkg-config dependency and not by udev. But we decided to put the libs into /lib to have the option to use it with udev as well sometimes, or even not ;) Anyhow that's CRUX 2.8 stuff.
9) other things and somewhat related things
- do we really need udevinfo symlink anymore ? (think the switch to udevadm is roughly 2 years old already)
- do we still need exec access in /dev ? (or itow, is there still anything that would want such thing present)
- I'd really move start_udev to rc. It's not even supposed to be run from commandline. And it needs to check a few more things related to handover (generally /dev submounts).
- vgscan should have --mknodes removed, as everything is handled by udev now. It can cause a few warning messages as well, if udev-configured lvm finds nodes manually created (overwritten) by lvm (which --mknodes will promptly do)
Providing it's using udev already.
- vgchange would be better to use --sysinit
Agreed, also --ignorelockingfailure is redundant with --sysinit enabled.
- there's one more thing related to lvm - the udev db must be preserved across pivot, otherwise vgchange would have to be called with --refresh to properly repopulate udev db; overall something to keep in mind depending on what kind of initramfs builder one uses
- in context of lvm/dm - do we really need them as separate packages ? Space savings are at best symbolic, Pkgfiles are practically identical.
as always we try to keep the core collection small. The reason why we moved dm to core was simply lilo, which links against libdevmapper if installed. Without that libdevmapper would still reside in opt.
At all I'm maintaining lvm in opt only because someone has to do it. Patches or better a voluneer are more than welcome ...
I was the previous maintainer of lvm and I use lvm everyday, then (I think it was Jue) took over maintainership and split out libdevmapper for lilo use in core. Having said this you need to bump libdevmapper everytime lvm is bumped so there is no way I'll pick up lvm again even if jue agreed to me to maintain the opt/lvm back in contrib/lvm as it used to be, while libdevmapper is in core where I can not bump it's version. My two cents worth. On a slightly less related note I was the one to get cryptsetup to have a --enable-static-cryptsetup option, to align up better with mdadm and lvm2 for initramfs use.
- in context of lvm/dm/md/udev - do we really need static builds (and random patches making that still possible) ?
the idea behind that is to have static builds of all progs that might be needed for a boot-system via initrd available. Don't know if this is still important for someone, probably not really.
Greetings Juergen
Regards, Danny