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)
- vgchange would be better to use --sysinit
- 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 ...
- 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 -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux