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 ... 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) 2) acl acl is in core, and I'd guess can be just enabled for those that need it 3) keymaps no other dependencies or issues (if i haven't missed anything), would make a few laptop users more happy 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) 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. - in context of lvm/dm/md/udev - do we really need static builds (and random patches making that still possible) ?
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
On 11-06-05 19:54, Juergen Daubert wrote:
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 ;)
Certainly :) Though in coming times it will probably be harder and harder to keep stuff clean off /usr ... whenever one considers Lennart a madman or a visionary (or anything in between or not), he has a point: http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken (this is not really related to systemd, but got lot attention in this context; when i read it for the first time a while ago my initial reaction was "blasphemy!" too, but after cooling down a bit - the issues raised are nonetheless valid) In barebone setup, 78-sound-card.rules (so alsa) sets some udev environment vars based on ids, though how important that really is (purely descriptive, or actually functional at some point) - hard for me to say. OTOH, I was wondering - simple global re-trigger after all the fscks & mounts are done would likely fix most (all ?) potential problems (even if it's arguably ugly approach). That means, initial coldplug limited to certain subsystems (block, net), then fsck+mount, then full coldplug guaranteeing needed stuff is (or should be) in place. That could be good idea actually.
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).
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.
I didn't really mean #3 as real option. #4 sounds indeed pretty good (and pretty trivial along the way). Regardless of 2-pass coldplug mentioned above.
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.
Ah got it. I use syslinux exclusively these days for everything - so kinda missed that detail.
At all I'm maintaining lvm in opt only because someone has to do it. Patches or better a voluneer are more than welcome ...
Well, I could maintain few things. In context of 2.8 there're few other changes I have roughly in mind: - mtab symlink - /run - in core: syslinux, dracut, gdisk (eventually parted), pam, socat (eventually netcat) - a few changes to rc scripts Nothing revolutionary or complex, but pushing standard install a little bit forward.
- 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.
Tough to say, though it certainly simplifies life when going quick DIY way. Anyway, I'll prep some patches - small things for 2.7, some bigger ones for 2.8 - easier to discuss when changes are actually visible.
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
participants (3)
-
Danny Rawlins -
Juergen Daubert -
Michal Soltys