Re: [gentoo-dev] Re: udev - mdev
On Sun, Jul 29, 2012 at 01:38:28PM +0200, Luca Barbato wrote Forking udev and making sure it stays as lean as possible isn't that bad. That describes mdev to a T. No need to re-invent the wheel. Making mdev a bit richer and enjoy the speed advantage of busybox over stand alone shells could be another option. The busybox people would probably not want additional functionality built-in. A better route would be mdev helper programs or shims that we can add to Gentoo as required. Actually, shell scripts launched by /etc/mdev.conf can be quite powerful. E.g. wiki page https://wiki.gentoo.org/wiki/Mdev/Automount_USB has ash scripts to implement auto(un)mounting of USB devices. It works for me, but I'm waiting for feedback from other users before moving it out of beta (Work In Progress) status. Once I'm confident in the scripts, I'll link to them from the main mdev page at https://wiki.gentoo.org/wiki/Mdev In case you're wondering, I'm not a C programmer, so scripting was the only available tool for me. Most of the perceived speed in non-shell init systems is due not having to spawn as many processes. A full busybox wouldn't spawn many processes. It would be an interesting project to make a busybox-based Gentoo fork. But there are differences between busybox utilities and standalone gnu utilities. This is especially important for a source-based distro like Gentoo, where all sorts of gnu utilities get excercised by build scripts each time you do an update. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] Re: udev - mdev
On 07/14/2012 03:21 AM, Olivier Crête wrote:
Seriously, mdev is a just a bad and now useless hack, it does nothing
more than using devtmpfs. You do not need udev for a very simple system.
If you system is a bit more complicated, than udev is what you want. It
works fine on millions of shipping devices.
And on any new embedded platform, one should seriously think about using
systemd too. It is very lean, replaces most of the giant, unmaintainable
shellscripts that you find in many devices with smaller compiled code,
and was designed to be a good fit for embedded devices.
Last time I looked at systemd it was anything that lean.
Obviously you can say that if you already need dbus and glib and ...
${systemd_deplist} it doesn't count.
Likewise if you are already using busybox it comes with a quite rich shell.
Most depends on what you consider embedded.
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] Re: udev - mdev
On 07/14/2012 04:34 AM, Canek Peláez Valdés wrote: On Fri, Jul 13, 2012 at 9:32 PM, Canek Peláez Valdés can...@gmail.com wrote: [snip] A lot of that is optional. The only hard dependencies are: =sys-apps/kmod-5 =sys-apps/util-linux-2.20 dev-util/gperf =dev-util/intltool-0.40.0 virtual/pkgconfig virtual/os-headers Everything else is optional. I repeat: the idea that udev is somewhat bloated or fat is really incorrect. Little correction: inherit autotools brings things like automake and libtool, but then again, almost *every* Gentoo installation has those. build dependencies should not count. =) The bare udev shouldn't be that huge, then you start look at the glib integration and such and it might get a bit more than you'd like. Forking udev and making sure it stays as lean as possible isn't that bad. Making mdev a bit richer and enjoy the speed advantage of busybox over stand alone shells could be another option. Most of the perceived speed in non-shell init systems is due not having to spawn as many processes. A full busybox wouldn't spawn many processes. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
[gentoo-dev] Re: udev - mdev
Michael Mol posted on Sun, 15 Jul 2012 20:57:28 -0400 as excerpted: This is sounding closer and closer to an on-disk liveCD. It is, isn't it? But I'd want to keep it reasonably small, as I guess I'd be rebuilding the squashfs pretty much whenever I updated any package that it contained binaries from. Actually, I guess if I did squashfs, I could even mount it directly, avoiding the initr* entirely, tho in effect it'd be close. I could have the kernel call a shell script as init, then have it exec the real init (and thus openrc) after it did some initial setup and mounts, thus allowing the real init to inherit the same PID 1 it normally gets. (Some of that idea is triggered by Maxim K's post. Thanks to both of you.) Alternatively, I could reconfigure inittab to start my script first, then start openrc (consolidating the openrc sysinit, etc, entries). But that actually sounds more complex than simply running an initial script as init, and having it exec init. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: udev - mdev
Duncan wrote: Alternatively, I could reconfigure inittab to start my script first .. that actually sounds more complex Use init. It would be a sensitive script. If it fails the kernel is sad. //Peter
Re: [gentoo-dev] Re: udev - mdev
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 15/07/12 09:00 PM, Maxim Kammerer wrote: On Mon, Jul 16, 2012 at 3:30 AM, Duncan 1i5t5.dun...@cox.net wrote: Thinking in that direction does stimulate yet another idea, tho. What about a squashfs root? AFAIK squashfs is read-only at use time, thus enforcing actually mounting something else to write anything, eliminating many of the down sides of sticking with the initial ramfs root, but it would allow the same flexibility in terms of sticking whatever into it at create-time, while only taking the memory necessary for what's actually stuck in it at create-time. It is possible, see: https://github.com/mkdesu/liberte/blob/master/src/root/initrd/init https://github.com/mkdesu/liberte/blob/master/src/etc/fstab The setup above is somewhat different from what you have in mind (SquashFS image is located on disk, and contains the complete live filesystem, not just a skeleton), so mounting read-writable branches can be deferred to the regular post-initramfs services (such as localmount) — on the other hand, maybe you want to do the same (mount branches read-only in initramfs, and remount them read-write in an init.d service). ...if going this route, why not simply not bother to pivot_root out of the initramfs at all? or pivot_root but only into a directory structure still sitting in the initramfs? As long as all non-root bits are in separate storage, you can mount 'em all in the appropriate place... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlAEHNAACgkQ2ugaI38ACPCbBgD+MCInpuQXjir37zFTn3ebJe30 dEWqqxihYox1+XrR7JYA/26jjkglGXZzxP0Kq17xuyoDBD8qnymAsziieDsMCMvN =/C5P -END PGP SIGNATURE-
[gentoo-dev] Re: udev - mdev
Ian Stakenvicius posted on Mon, 16 Jul 2012 09:53:20 -0400 as excerpted: ...if going this route, why not simply not bother to pivot_root out of the initramfs at all? or pivot_root but only into a directory structure still sitting in the initramfs? As long as all non-root bits are in separate storage, you can mount 'em all in the appropriate place... I'm not sure whether that was asked of me or Maxim K, but that was beginning to be my conclusion as well. See the earlier comment about not even using an initr* at all, tho this would be close. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: udev - mdev
On Sat, Jul 14, 2012 at 9:02 PM, Duncan 1i5t5.dun...@cox.net wrote: Rich Freeman posted on Sat, 14 Jul 2012 19:57:41 -0400 as excerpted: I doubt anybody has tried it, so you'll have to experiment. Anybody /anybody/, or anybody on gentoo? FWIW, there are people running it in general (IIRC much of the discussion was on Debian, some on Fedora/RH), but I didn't see anything out there written from a gentoo perspective. I'd think that a source vs binary distro wouldn't matter much as far as a tmpfs-based root goes. That is, if you're taking about an empty root that you just mount stuff on top of. I imagine you could do it with a dracut module. There is already a module that will parse a pre-boot fstab (/etc/fstab.sys). The trick is that you need to create the root filesystem and the mountpoints within it first. The trick will be how dracut handles not specifying a root filesystem. While I do know dracut is an initr* helper, you just made me quite aware of just how much research I'd have to do on the topic. =:^\ I wasn't aware dracut even /had/ modules, while you're referring to them with the ease of familiarity... See: http://rich0gentoo.wordpress.com/2012/01/21/a-quick-dracut-module/ Much of dracut's power comes from its modules. Again, I'm not sure how it handles not being given a root at all. You'd have to build a root, or extract it from a tarball/etc. Looking at the docs it seems like you'd need a hook for the cmdline stage that sets rootok (assuming it gets that far without a root, or if you set it to something like root=TMPFS). Then you'd install a hook to mount to mount the tmpfs, and then use the fstab-sys module to mount everything else. You'd need to create mountpoints for everything of course, and not just the boot-critical stuff, since otherwise openrc won't be able to finish mounting mounting everything. The big problem with btrfs subvolumes from my perspective is that they're still all on a single primary filesystem, and if that filesystem develops problems... all your eggs/data are in one big basket, good luck if the bottom drops out of it! Maybe, but does it really buy you much if you only lose /lib, and not /usr? I guess it is less data to restore from backup, but... The beauty of btrfs subvolumes is that it lets you manage all your storage as a single pool, even more flexibly than LVM. Sure, chopping it up does reduce the impact of failure a bit, but I'd hate to have to maintain such a system. Filesystem failure should be a very rare occurance for any decent filesystem (of course, this is why I won't be using btrfs in production for a while). Rich
[gentoo-dev] Re: udev - mdev
Rich Freeman posted on Sun, 15 Jul 2012 08:30:31 -0400 as excerpted: Looking at the docs it seems like you'd need a hook for the cmdline stage that sets rootok (assuming it gets that far without a root, or if you set it to something like root=TMPFS). Then you'd install a hook to mount to mount the tmpfs, and then use the fstab-sys module to mount everything else. You'd need to create mountpoints for everything of course, and not just the boot-critical stuff, since otherwise openrc won't be able to finish mounting mounting everything. The last bit I had already anticipated, as I'm doing something similar with my tmpfs-based /tmp and /var/tmp (symlinked to /tmp). Nothing mounted on top, but I'm creating subdirs inside it, setting permissions, etc. A critical difference is that this is on a full rootfs so I don't have to worry about not having the necessary tools available yet, but I do have the general ideas down. And I'm doing some bind-mounts as well, which require a remount to let all the options take effect, and of course there's mount ordering to worry about, etc. So I have the general idea, but doing it from an initr* with limited tools available will be interesting. As for the tmpfs rootfs itself, I have the vague idea that I'd simply (note the scare-quotes) use what's normally the initial root that's essentially thrown away, only I'd not throw it away, I'd just mount everything on top, keep using it, and /somehow/ ensure that anything running from it directly terminates one way or another, so that I don't have old processes stuck around using the mounted-over points. The big problem with btrfs subvolumes from my perspective is that they're still all on a single primary filesystem, and if that filesystem develops problems... all your eggs/data are in one big basket, good luck if the bottom drops out of it! Maybe, but does it really buy you much if you only lose /lib, and not /usr? I guess it is less data to restore from backup, but... Which is why I keep /usr (and /lib64 and /usr/lib64) on rootfs currently, tho the traditional /usr/src/, /usr/local, and /usr/portage are either pointed elsewhere with the appropriate vars or mountpoints/symlinks to elsewhere. Of course that'd have to change a bit for a tmpfs rootfs, since /lib64, /usr and /etc would obviously be mounted from elsewhere, but they could still be either symlinked or bind-mounted to the appropriate location on the single (read-only) system-filesystem. FWIW I remember being truly fascinated with the power of symlinks when I first switched from MS. Now I consider them normal, but the power and flexibility of bind-mounts still amazes me, especially since, as with symlinks, it's possible to bind-mount individual files, but unlike symlinks (more like hard-links but cross-filesystem), it's possible to have some of the bind-mounts read-write (or dev, exec, etc) while others are read-only (or nodev, noexec...). The beauty of btrfs subvolumes is that it lets you manage all your storage as a single pool, even more flexibly than LVM. Sure, chopping it up does reduce the impact of failure a bit, but I'd hate to have to maintain such a system. Filesystem failure should be a very rare occurance for any decent filesystem (of course, this is why I won't be using btrfs in production for a while). Very rare, yes. Hardware issues happen tho. I remember the a/c failing at one point, thus causing ambient temps (Phoenix summer) to reach 50C or so, and who knows how much in the computer. Head-crash time. But after cooling off, the unmounted-at-the-time filesystems were damaged very little, while a couple of the mounted filesystems surely had physical grooves in the platter. Had that been all one filesystem, the damage would have been far less confined. That's one example. Another one, happened back when I was beta testing IE4 on MS, was due to a system software error on their part. IE started bypassing the filesystem and writing to the cache index directly, but it wasn't set system attribute, so the defragger moved the file and put something else in that physical disk location. I had my temp-inet-files on tmp, which was its own partition and didn't have significant issues, but some of the other betatesters lost valuable data, overwritten by IE, which was still bypassing the filesystem and writing directly to what it thought was its cache index file. So it's not always filesystem failure, itself. But I tried btrfs for a bit just to get an idea what it was all about, and agree totally with you there. I'm off of it entirely now, and won't be touching it again until I'd guess early next year at the earliest. The thing simply isn't ready for the expectations I have of my filesystems, and anybody using it now without backups is simply playing Russian Roulette with their data. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master
Re: [gentoo-dev] Re: udev - mdev
On Sun, Jul 15, 2012 at 2:25 PM, Duncan 1i5t5.dun...@cox.net wrote: So I have the general idea, but doing it from an initr* with limited tools available will be interesting. Dracut modules can specify any tools they need, and they will be loaded into the initramfs. Obviously you'll want to use some discretion here. As for the tmpfs rootfs itself, I have the vague idea that I'd simply (note the scare-quotes) use what's normally the initial root that's essentially thrown away, only I'd not throw it away, I'd just mount everything on top, keep using it, and /somehow/ ensure that anything running from it directly terminates one way or another, so that I don't have old processes stuck around using the mounted-over points. I suspect you could do that, but you'd probably have to change the cleanup code, and you need to keep in mind that the initramfs runs on ramfs and not tmpfs. While similar there are a few important differences. Ramfs does not support size limits, so you can extinguish all of your ram easily enough. Ramfs also does not swap, which means that any actual content in that filesystem will waste ram, whether it is used or not. Anything that writes to it could wipe out all your memory even if you have swap available. The design of ramfs is designed for simplicity rather than robustness (you can support an initramfs on a system that otherwise lacks the drivers for tmpfs. Which is why I keep /usr (and /lib64 and /usr/lib64) on rootfs currently, tho the traditional /usr/src/, /usr/local, and /usr/portage are either pointed elsewhere with the appropriate vars or mountpoints/symlinks to elsewhere. Of course that'd have to change a bit for a tmpfs rootfs, since /lib64, /usr and /etc would obviously be mounted from elsewhere, but they could still be either symlinked or bind-mounted to the appropriate location on the single (read-only) system-filesystem. Giving it a little thought, the simplest tmpfs-based root would be one that defines a tarball as a the root. The system would create a tmpfs, extract the tarball to it, and then use the existing fstab-sys module to mount stuff on top of that. This gives you the option of actually putting some content in the tarball, or just storing an empty directory structure in it. A tarball would let you set permissions/etc and be a bit more generic than writing a custom script. If you wrote a module to do this I wouldn't be suprised if upstream let you merge it. You'd just need to define some kind of sane syntax for it (root=TAR=path...to...tarball - though how a path works with nothing mounted you'd have to define). Maybe you define the tarball at initramfs creation (as is done with fstab.sys and mdadm.conf). FWIW I remember being truly fascinated with the power of symlinks when I first switched from MS. Now I consider them normal, but the power and flexibility of bind-mounts still amazes me, especially since, as with symlinks, it's possible to bind-mount individual files, but unlike symlinks (more like hard-links but cross-filesystem), it's possible to have some of the bind-mounts read-write (or dev, exec, etc) while others are read-only (or nodev, noexec...). Yup, my /usr and /var are bind-mounts - I was following the pre-initramfs raid guide and had my root on a raid1, and wanted to keep it minimal. However, rather than having 47 individual filesystems in lvm I only defined a few and bind-mounted half the tree off of one of them. Fstab.sys seems to handle that just fine (mounting the main mountpoint first, and the bind mounts afterwards). Rich
Re: [gentoo-dev] Re: udev - mdev
On Fri, Jul 13, 2012 at 05:58:25AM +, Duncan wrote They're seriously thinking about (and may be planning on) removing that option from the kernel entirely, to keep people configuring their first kernels from getting themselves in trouble, but of course that's now part of the kernel/userspace interface, so it isn't allowed to just disappear like kernel/kernel interfaces can. A couple of points... 1) Your argument applies to just about anything in the kernel configuration process. If you don't follow instructions, the kernel will encounter anything from partial loss of functionality to possibly failing to boot at all. I'm a big boy. If I foul up, I'll admit that I goofed. 2) Full disclosure; I do have an interest in retaining the hotplug pointer mechanism. I have mdev set up on my machines as per https://wiki.gentoo.org/wiki/Mdev Going one step further, I have auto(un)mount working on my machines as per https://wiki.gentoo.org/wiki/Mdev/Automount_USB and https://wiki.gentoo.org/wiki/Mdev/Automount_USB/automount This has been working OK for me for a few weeks, and I've asked others to test on their machines. I'll still consider it beta (Work In Progress) until other people confirm it works for them. Once that's done, my next project might be custom mdev rules, similar to custom udev rules. -- Walter Dnes waltd...@waltdnes.org
[gentoo-dev] Re: udev - mdev
Rich Freeman posted on Sun, 15 Jul 2012 14:48:55 -0400 as excerpted: Giving it a little thought, the simplest tmpfs-based root would be one that defines a tarball as a the root. The system would create a tmpfs, extract the tarball to it, and then use the existing fstab-sys module to mount stuff on top of that. This gives you the option of actually putting some content in the tarball, or just storing an empty directory structure in it. A tarball would let you set permissions/etc and be a bit more generic than writing a custom script. If you wrote a module to do this I wouldn't be suprised if upstream let you merge it. You'd just need to define some kind of sane syntax for it (root=TAR=path...to...tarball - though how a path works with nothing mounted you'd have to define). Maybe you define the tarball at initramfs creation (as is done with fstab.sys and mdadm.conf). Tarball is an interesting idea I hadn't considered. At first blush I like it. =:^) Thinking in that direction does stimulate yet another idea, tho. What about a squashfs root? AFAIK squashfs is read-only at use time, thus enforcing actually mounting something else to write anything, eliminating many of the down sides of sticking with the initial ramfs root, but it would allow the same flexibility in terms of sticking whatever into it at create-time, while only taking the memory necessary for what's actually stuck in it at create-time. I /think/ it's swappable, too, which would give me some flexibility in terms of letting more stuff be added at create-time without having to worry about it being locked in memory. And I think squashfs is reasonably tested territory for this sort of thing, given its use for live-media, etc. And it's in mainline now, too, which is nice. =:^) I'll have to do some research and think about that a bit more... Definitely thanks for the tarball idea, as otherwise I'd probably have not got out of my box and thought about squashfs. I'm probably missing its downsides ATM, but you still broke my thinking out of the box! -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: udev - mdev
On Sun, Jul 15, 2012 at 8:30 PM, Duncan 1i5t5.dun...@cox.net wrote: Rich Freeman posted on Sun, 15 Jul 2012 14:48:55 -0400 as excerpted: Giving it a little thought, the simplest tmpfs-based root would be one that defines a tarball as a the root. The system would create a tmpfs, extract the tarball to it, and then use the existing fstab-sys module to mount stuff on top of that. This gives you the option of actually putting some content in the tarball, or just storing an empty directory structure in it. A tarball would let you set permissions/etc and be a bit more generic than writing a custom script. If you wrote a module to do this I wouldn't be suprised if upstream let you merge it. You'd just need to define some kind of sane syntax for it (root=TAR=path...to...tarball - though how a path works with nothing mounted you'd have to define). Maybe you define the tarball at initramfs creation (as is done with fstab.sys and mdadm.conf). Tarball is an interesting idea I hadn't considered. At first blush I like it. =:^) Thinking in that direction does stimulate yet another idea, tho. What about a squashfs root? AFAIK squashfs is read-only at use time, thus enforcing actually mounting something else to write anything, eliminating many of the down sides of sticking with the initial ramfs root, but it would allow the same flexibility in terms of sticking whatever into it at create-time, while only taking the memory necessary for what's actually stuck in it at create-time. I /think/ it's swappable, too, which would give me some flexibility in terms of letting more stuff be added at create-time without having to worry about it being locked in memory. And I think squashfs is reasonably tested territory for this sort of thing, given its use for live-media, etc. And it's in mainline now, too, which is nice. =:^) I'll have to do some research and think about that a bit more... Definitely thanks for the tarball idea, as otherwise I'd probably have not got out of my box and thought about squashfs. I'm probably missing its downsides ATM, but you still broke my thinking out of the box! This is sounding closer and closer to an on-disk liveCD. -- :wq
Re: [gentoo-dev] Re: udev - mdev
On Mon, Jul 16, 2012 at 3:30 AM, Duncan 1i5t5.dun...@cox.net wrote: Thinking in that direction does stimulate yet another idea, tho. What about a squashfs root? AFAIK squashfs is read-only at use time, thus enforcing actually mounting something else to write anything, eliminating many of the down sides of sticking with the initial ramfs root, but it would allow the same flexibility in terms of sticking whatever into it at create-time, while only taking the memory necessary for what's actually stuck in it at create-time. It is possible, see: https://github.com/mkdesu/liberte/blob/master/src/root/initrd/init https://github.com/mkdesu/liberte/blob/master/src/etc/fstab The setup above is somewhat different from what you have in mind (SquashFS image is located on disk, and contains the complete live filesystem, not just a skeleton), so mounting read-writable branches can be deferred to the regular post-initramfs services (such as localmount) — on the other hand, maybe you want to do the same (mount branches read-only in initramfs, and remount them read-write in an init.d service). -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] Re: udev - mdev
Walter Dnes waltd...@waltdnes.org writes: On Sat, Jul 14, 2012 at 01:49:32AM +0300, Maxim Kammerer wrote On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao r...@gentoo.org wrote: mdev would need to switch to the netlink hotplug interface. I think that's quite unlikely, since mdev is not a daemon. Perhaps by the time /proc/sys/kernel/hotplug is gone, mdev advocates will have settled on some early udev fork. [1] Do you realize this would effectively kill linux in the embedded device area? Udev, even without the systemd code, is simply to large for embedded devices. But surely most embedded devices do not need hotplug functionality, they have a known, fixed, set of devices. So should static nodes in /dev/ not be sufficient?
Re: [gentoo-dev] Re: udev - mdev
On Sat, Jul 14, 2012 at 12:35 AM, Sylvain Alain d2racing...@gmail.com wrote:
Hi all, about the Mdev stuff, Slashbeast from Funtoo.org started that
project a while ago.
https://github.com/slashbeast/mdev-like-a-boss
I think that it's actually working pretty good on his box.
Some Coredevs from Funtoo are actually running with that stuff.
I don't think anybody has ever suggested that it's not possible to run
mdev instead of udev: as Walter has proved, it is indeed possible.
The question Olivier and William are making is (if I understand
correctly) if you don't need the features of udev, then why not use
only devtmpfs. I think everyone agrees that mdev doesn't have (and
probably never will nor want) all the features that udev has.
Seeing all the trouble some people have taken to make their systems
work with mdev just to avoid having to use an initramfs, I really
wonder how much effort it would have taken the simple task of learning
one step more when updating kernels and switch to use an initramfs.
Then again, everyone is entitled to work in the features (or
anti-features) they want. It is FLOSS after all.
Just the 0.02 ${CURRENCY} of a happy udev/systemd user (I'm really
happy the merged the two project trees).
Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
[gentoo-dev] Re: udev - mdev
Graham Murray posted on Sat, 14 Jul 2012 07:13:56 +0100 as excerpted: Walter Dnes waltd...@waltdnes.org writes: Do you realize this would effectively kill linux in the embedded device area? Udev, even without the systemd code, is simply to large for embedded devices. But surely most embedded devices do not need hotplug functionality, they have a known, fixed, set of devices. So should static nodes in /dev/ not be sufficient? Well, there's (kernel-side) devfs as well, as others have mentioned. Meanwhile, embedded can mean different things to different users of the term. I expect few would argue that onboard boot devices on embedded are likely to change, but there's a lot of (arguably embedded) devices with USB-host support these days, and some form of dynamic device-nodes, even if it's just devfs, can make that much more flexible and easier to deal with. What's interesting is the potential on such devices for USB-based storage, displays, sound, net and HID, blurring the definition of embedded even further, altho one would hope nobody tries to connect all of those up to the same host USB port (via hub) at the same time as I can just imagine the bandwidth management headaches trying to do so, thus implying 2-3 USB host-ports, minimum. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: udev - mdev
Canek Peláez Valdés wrote: Seeing all the trouble some people have taken to make their systems work with mdev just to avoid having to use an initramfs, I really wonder how much effort it would have taken the simple task of learning one step more when updating kernels and switch to use an initramfs. I think udev, systemd, and initramfs are orthogonal concepts. FWIW I've built more or less deeply embedded Linux systems with Gentoo and without, for years. I stopped using init scripts long before I started using Gentoo in 2004. systemd is in most regards a significant improvement over everything that was previously available. The few regards where it isn't are outweighed fairly easily by the value of same process management both on desktop Linux and embedded Linux. On deeply embedded systems with say 2 or 4 Mbyte flash I might choose something other than systemd however. As was pointed out, such a system may also not need to be very dynamic, so losing udev is not neccessarily a problem. If they do need to be dynamic, then will have to make some room for udev as well. Anyone who tries to argue that initramfs would be good for me to have on my systems should brace themselves for a mouthful of foul swedish language coming their way! ;) //Peter
Re: [gentoo-dev] Re: udev - mdev
On Sat, Jul 14, 2012 at 4:02 PM, Peter Stuge pe...@stuge.se wrote: [snip] Anyone who tries to argue that initramfs would be good for me to have on my systems should brace themselves for a mouthful of foul swedish language coming their way! ;) I don't think anyone has argued it's good for anyone. An initramfs it's just now the only supported way (by udev and systemd) to have a separated /usr partition. If your /usr is in the same partition as /, then udev and systemd supports your configuration *without* an initramfs. I have it like that in a couple of servers, and actually I only use an initramfs in my laptop and desktop because I like plymouth. If your /usr is in a separate partition as /, and you don't want to use an initramfs, you're free to do so. Only then udev (and systemd, if you use it) will not support your configuration, and any problem you encounter will be ignored in their mailing lists/bugzillas. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Re: udev - mdev
Canek Peláez Valdés wrote: An initramfs it's just now the only supported way (by udev and systemd) to have a separated /usr partition. Yes sure. I considered separate partitions in the 90s, let's just say that I don't see the problem that many on the internet cry about. Using multiple filesystems in a system allows doing very nice things, but /usr /var /whatever is waay too clumsy, to do the nice things there needs to be more cleverness, which we're not neccessarily ready for just yet. //Peter
[gentoo-dev] Re: udev - mdev
Canek Peláez Valdés posted on Sat, 14 Jul 2012 16:29:19 -0500 as excerpted: If your /usr is in the same partition as /, then udev and systemd supports your configuration *without* an initramfs. I have it like that in a couple of servers, and actually I only use an initramfs in my laptop and desktop because I like plymouth. If your /usr is in a separate partition as /, and you don't want to use an initramfs, you're free to do so. Only then udev (and systemd, if you use it) will not support your configuration, and any problem you encounter will be ignored in their mailing lists/bugzillas. BTW, any gentooish documentation out there on rootfs as tmpfs, with /etc and the like mounted on top of it, operationally ro, rw remounted for updates? That's obviously going to take an initr*, which I've never really understood to the point I'm comfortable with my ability to recover from problems so I've not run one since my Mandrake era, but that's a status that can change, and what with the /usr move and some computer problems I just finished dealing with, I've been thinking about the possibility lately. So if there's some good docs on the topic someone can point me at, I'd be grateful. =:^) I'm aware of the issues with /etc/mtab and have googled a bit on the workarounds, but that looks like a decent amount of work, and if I'm going to do that, I might as well invest the time and do it right, initr*, full tmpfs rootfs with everything non-volatile mounted on top, the whole shebang! -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: udev - mdev
On Sat, Jul 14, 2012 at 7:38 PM, Duncan 1i5t5.dun...@cox.net wrote: BTW, any gentooish documentation out there on rootfs as tmpfs, with /etc and the like mounted on top of it, operationally ro, rw remounted for updates? That's obviously going to take an initr*, which I've never really understood to the point I'm comfortable with my ability to recover from problems so I've not run one since my Mandrake era, but that's a status that can change, and what with the /usr move and some computer problems I just finished dealing with, I've been thinking about the possibility lately. So if there's some good docs on the topic someone can point me at, I'd be grateful. =:^) I doubt anybody has tried it, so you'll have to experiment. I imagine you could do it with a dracut module. There is already a module that will parse a pre-boot fstab (/etc/fstab.sys). The trick is that you need to create the root filesystem and the mountpoints within it first. The trick will be how dracut handles not specifying a root filesystem. However, if anything I think the future trend will be towards having everything back on the root filesystem, since with btrfs you can set quotas on subvolumes and have a lot more flexibility in general, which you start to lose if you chop up your disks. However, I guess you could still have one big btrfs filesystem and mount individual subvolumes out of it onto your root. I'm not really sure what that gets you. Having the root itself be a subvolume does have benefits, since you can then snapshot it and easily boot back off a snapshot if something goes wrong. Rich
[gentoo-dev] Re: udev - mdev
Rich Freeman posted on Sat, 14 Jul 2012 19:57:41 -0400 as excerpted: On Sat, Jul 14, 2012 at 7:38 PM, Duncan 1i5t5.dun...@cox.net wrote: BTW, any gentooish documentation out there on rootfs as tmpfs, with /etc and the like mounted on top of it, operationally ro, rw remounted for updates? That's obviously going to take an initr*, which I've never really understood to the point I'm comfortable with my ability to recover from problems so I've not run one since my Mandrake era, but that's a status that can change, and what with the /usr move and some computer problems I just finished dealing with, I've been thinking about the possibility lately. So if there's some good docs on the topic someone can point me at, I'd be grateful. =:^) I doubt anybody has tried it, so you'll have to experiment. Anybody /anybody/, or anybody on gentoo? FWIW, there are people running it in general (IIRC much of the discussion was on Debian, some on Fedora/RH), but I didn't see anything out there written from a gentoo perspective. Gentoo-based docs/perspective does help, as one isn't constantly having to translate binary-based assumptions into gentooese, but there's enough out there in general that a suitably determined/ motivated person at the usual experienced gentoo user level should be able to do it, without having to be an /extreme/ wizard. But so far I've not been /that/ motivated, and if there was gentoo docs available, it would bring the barriers down far enough that I likely /would/ then have the (now lower) required motivation/determination. Just looking for that shortcut, is all. =:^) I imagine you could do it with a dracut module. There is already a module that will parse a pre-boot fstab (/etc/fstab.sys). The trick is that you need to create the root filesystem and the mountpoints within it first. The trick will be how dracut handles not specifying a root filesystem. While I do know dracut is an initr* helper, you just made me quite aware of just how much research I'd have to do on the topic. =:^\ I wasn't aware dracut even /had/ modules, while you're referring to them with the ease of familiarity... However, if anything I think the future trend will be towards having everything back on the root filesystem, since with btrfs you can set quotas on subvolumes and have a lot more flexibility in general, which you start to lose if you chop up your disks. However, I guess you could still have one big btrfs filesystem and mount individual subvolumes out of it onto your root. I'm not really sure what that gets you. Having the root itself be a subvolume does have benefits, since you can then snapshot it and easily boot back off a snapshot if something goes wrong. The big problem with btrfs subvolumes from my perspective is that they're still all on a single primary filesystem, and if that filesystem develops problems... all your eggs/data are in one big basket, good luck if the bottom drops out of it! One lesson I've had drilled into my head repeatedly over now two decades of computer experience... don't put all your data in one basket! It's a personal policy that's saved my @$$ more than a few times over the years. Even with raid, when I first setup md/raid, I set it up as a nice big (partitioned) raid, with a second (similarly partitioned) raid as a backup. With triple-digits gigs of data (this was pre-terabyte-drive era), a system-crash related re-add and resync would take /hours/. So when I rebuilt the setup, I created over a dozen (including working and backup copies of many of them) individual raids, each in its own set of partitions on the physical devices, some raids of which were further partitioned, some not, but only the media raid (and its backup) were anything like 100 gigs, and with many of even the working raids (plus all backups) not even activated for normal operation unless I was actually working on whatever data was on that raid, and in general even most of the the assembled raids with rw mounting not actively writing at the time of a crash, re-add and resync tended to be seconds or minutes, not hours. So I'm about as strong a partitioning-policy advocate as you'll get, tho I do keep everything that the pm installs, along with the installation database (so /etc, /usr, /var, but not for instance /var/log or /usr/src, which are mountpoints), on the same (currently) rootfs of 8-ish gigs, with a backup root partition (actually two of them now) that I can point the kernel at from grub, if the working rootfs breaks for some reason. So the separate /usr/ thing hasn't affected me at all, because /usr/ is on rootfs. But as I said I had some computer hardware issues recently, and they made me aware of just how nice it'd be to have that rootfs mounted read-only for normal operation -- no fsck/log-replay needed on read-only-at-time-of- crash mounts! =:^) So I'm pondering just how hard it would be... -- Duncan - List replies
Re: [gentoo-dev] Re: udev - mdev
On Fri, Jul 13, 2012 at 05:58:25AM +, Duncan wrote They're seriously thinking about (and may be planning on) removing that option from the kernel entirely, to keep people configuring their first kernels from getting themselves in trouble, but of course that's now part of the kernel/userspace interface, so it isn't allowed to just disappear like kernel/kernel interfaces can. At minimum they'd likely have to have it on the deprecation and removal schedule for awhile. (I've not checked to see if it's there already.) So what happens to people using mdev? Do we have to switch from Linu-x to Lenna-x? -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] Re: udev - mdev
On 07/13/2012 04:04 PM, Walter Dnes wrote: On Fri, Jul 13, 2012 at 05:58:25AM +, Duncan wrote They're seriously thinking about (and may be planning on) removing that option from the kernel entirely, to keep people configuring their first kernels from getting themselves in trouble, but of course that's now part of the kernel/userspace interface, so it isn't allowed to just disappear like kernel/kernel interfaces can. At minimum they'd likely have to have it on the deprecation and removal schedule for awhile. (I've not checked to see if it's there already.) So what happens to people using mdev? Do we have to switch from Linu-x to Lenna-x? mdev would need to switch to the netlink hotplug interface. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: udev - mdev
On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao r...@gentoo.org wrote: mdev would need to switch to the netlink hotplug interface. I think that's quite unlikely, since mdev is not a daemon. Perhaps by the time /proc/sys/kernel/hotplug is gone, mdev advocates will have settled on some early udev fork. [1] [1] http://archives.gentoo.org/gentoo-dev/msg_72b87bf5888d6f6e675429dbfe420db5.xml -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] Re: udev - mdev
On Sat, Jul 14, 2012 at 01:49:32AM +0300, Maxim Kammerer wrote On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao r...@gentoo.org wrote: mdev would need to switch to the netlink hotplug interface. I think that's quite unlikely, since mdev is not a daemon. Perhaps by the time /proc/sys/kernel/hotplug is gone, mdev advocates will have settled on some early udev fork. [1] Do you realize this would effectively kill linux in the embedded device area? Udev, even without the systemd code, is simply to large for embedded devices. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] Re: udev - mdev
On Fri, Jul 13, 2012 at 7:13 PM, Walter Dnes waltd...@waltdnes.org wrote: On Sat, Jul 14, 2012 at 01:49:32AM +0300, Maxim Kammerer wrote On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao r...@gentoo.org wrote: mdev would need to switch to the netlink hotplug interface. I think that's quite unlikely, since mdev is not a daemon. Perhaps by the time /proc/sys/kernel/hotplug is gone, mdev advocates will have settled on some early udev fork. [1] Do you realize this would effectively kill linux in the embedded device area? Udev, even without the systemd code, is simply to large for embedded devices. The guys from ProFUSION would disagree with you: http://profusion.mobi/ It is a a software development company focused on embedded systems, and several of its employees contribute code and ideas for systemd, so they also use udev. For embedded systems. The idea that udev is simply to large is simply incorrect, I believe. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Re: udev - mdev
On Fri, Jul 13, 2012 at 8:13 PM, Walter Dnes waltd...@waltdnes.org wrote: On Sat, Jul 14, 2012 at 01:49:32AM +0300, Maxim Kammerer wrote On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao r...@gentoo.org wrote: mdev would need to switch to the netlink hotplug interface. I think that's quite unlikely, since mdev is not a daemon. Perhaps by the time /proc/sys/kernel/hotplug is gone, mdev advocates will have settled on some early udev fork. [1] Do you realize this would effectively kill linux in the embedded device area? Udev, even without the systemd code, is simply to large for embedded devices. I'll venture a guess the solution will be to create a shim daemon which turns around and launches udev. -- :wq
Re: [gentoo-dev] Re: udev - mdev
On Sat, Jul 14, 2012 at 3:13 AM, Walter Dnes waltd...@waltdnes.org wrote: Do you realize this would effectively kill linux in the embedded device area? Udev, even without the systemd code, is simply to large for embedded devices. What's “too large”? Udev already looks pretty small to me (116k udevd, 50k libudev, 500k resident memory), and I didn't even try compiling it with all extra features switched off. If that's too large for an embedded device, does that device really need (or can handle) anything more than devtmpfs? -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] Re: udev - mdev
On Fri, Jul 13, 2012 at 08:40:20PM -0400, Michael Mol wrote I'll venture a guess the solution will be to create a shim daemon which turns around and launches udev. A quicker-and-dirtier solution would be to create a shim daemon that runs under the the name udev, and passes all calls to /sbin/mdev. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] Re: udev - mdev
On Fri, Jul 13, 2012 at 9:10 PM, Walter Dnes waltd...@waltdnes.org wrote: On Fri, Jul 13, 2012 at 08:40:20PM -0400, Michael Mol wrote I'll venture a guess the solution will be to create a shim daemon which turns around and launches udev. A quicker-and-dirtier solution would be to create a shim daemon that runs under the the name udev, and passes all calls to /sbin/mdev. ... and that's what I thought I'd typed. -.- -- :wq
Re: [gentoo-dev] Re: udev - mdev
On Fri, 2012-07-13 at 21:10 -0400, Walter Dnes wrote: On Fri, Jul 13, 2012 at 08:40:20PM -0400, Michael Mol wrote I'll venture a guess the solution will be to create a shim daemon which turns around and launches udev. A quicker-and-dirtier solution would be to create a shim daemon that runs under the the name udev, and passes all calls to /sbin/mdev. Seriously, mdev is a just a bad and now useless hack, it does nothing more than using devtmpfs. You do not need udev for a very simple system. If you system is a bit more complicated, than udev is what you want. It works fine on millions of shipping devices. And on any new embedded platform, one should seriously think about using systemd too. It is very lean, replaces most of the giant, unmaintainable shellscripts that you find in many devices with smaller compiled code, and was designed to be a good fit for embedded devices. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: udev - mdev
On Sat, Jul 14, 2012 at 03:41:36AM +0300, Maxim Kammerer wrote On Sat, Jul 14, 2012 at 3:13 AM, Walter Dnes waltd...@waltdnes.org wrote: Do you realize this would effectively kill linux in the embedded device area? Udev, even without the systemd code, is simply to large for embedded devices. What's ?too large?? Udev already looks pretty small to me (116k udevd, 50k libudev, 500k resident memory), and I didn't even try compiling it with all extra features switched off. If that's too large for an embedded device, does that device really need (or can handle) anything more than devtmpfs? What does equery depgraph show for udev? Since I don't have udev installed, I can't check it here. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] Re: udev - mdev
On Fri, Jul 13, 2012 at 9:22 PM, Walter Dnes waltd...@waltdnes.org wrote: On Sat, Jul 14, 2012 at 03:41:36AM +0300, Maxim Kammerer wrote On Sat, Jul 14, 2012 at 3:13 AM, Walter Dnes waltd...@waltdnes.org wrote: Do you realize this would effectively kill linux in the embedded device area? Udev, even without the systemd code, is simply to large for embedded devices. What's ?too large?? Udev already looks pretty small to me (116k udevd, 50k libudev, 500k resident memory), and I didn't even try compiling it with all extra features switched off. If that's too large for an embedded device, does that device really need (or can handle) anything more than devtmpfs? What does equery depgraph show for udev? Since I don't have udev installed, I can't check it here. sys-fs/udev-114: [ 0] sys-fs/udev-114 [ 1] sys-libs/libselinux-2.1.9-r1 [ 1] sys-apps/baselayout-2.1-r1 sys-fs/udev-115-r1: [ 0] sys-fs/udev-115-r1 [ 1] sys-libs/libselinux-2.1.9-r1 [ 1] sys-apps/baselayout-2.1-r1 sys-fs/udev-119: [ 0] sys-fs/udev-119 [ 1] sys-libs/libselinux-2.1.9-r1 [ 1] sys-apps/baselayout-2.1-r1 sys-fs/udev-124-r1: [ 0] sys-fs/udev-124-r1 [ 1] sys-libs/libselinux-2.1.9-r1 [ 1] sys-apps/baselayout-2.1-r1 sys-fs/udev-124-r2: [ 0] sys-fs/udev-124-r2 [ 1] sys-libs/libselinux-2.1.9-r1 [ 1] sys-apps/baselayout-2.1-r1 sys-fs/udev-141: [ 0] sys-fs/udev-141 [ 1] sys-libs/libselinux-2.1.9-r1 [ 1] sys-apps/baselayout-2.1-r1 sys-fs/udev-141-r1: [ 0] sys-fs/udev-141-r1 [ 1] sys-libs/libselinux-2.1.9-r1 [ 1] sys-apps/baselayout-2.1-r1 sys-fs/udev-146-r1: [ 0] sys-fs/udev-146-r1 [ 1] sys-libs/libselinux-2.1.9-r1 [ 1] sys-apps/acl-2.2.51 [ 1] sys-apps/usbutils-004 [ 1] virtual/libusb-0 [ 1] sys-apps/pciutils-3.1.9-r1 [ 1] dev-libs/glib-2.30.3 [ 1] sys-apps/util-linux-2.20.1-r2 [ 1] dev-util/gperf-3.0.4 [ 1] sys-apps/baselayout-2.1-r1 sys-fs/udev-149: [ 0] sys-fs/udev-149 [ 1] sys-libs/libselinux-2.1.9-r1 [ 1] sys-apps/acl-2.2.51 [ 1] sys-apps/usbutils-004 [ 1] virtual/libusb-0 [ 1] sys-apps/pciutils-3.1.9-r1 [ 1] dev-libs/glib-2.30.3 [ 1] sys-apps/util-linux-2.20.1-r2 [ 1] dev-util/gperf-3.0.4 [ 1] virtual/pkgconfig-0 [ 1] virtual/os-headers-0 [ 1] app-text/tree-1.6.0-r1 [ 1] sys-apps/baselayout-2.1-r1 sys-fs/udev-151-r4: [ 0] sys-fs/udev-151-r4 [ 1] sys-libs/libselinux-2.1.9-r1 [ 1] sys-apps/acl-2.2.51 [ 1] sys-apps/usbutils-004 [ 1] virtual/libusb-0 [ 1] sys-apps/pciutils-3.1.9-r1 [ 1] dev-libs/glib-2.30.3 [ 1] sys-apps/util-linux-2.20.1-r2 [ 1] dev-util/gperf-3.0.4 [ 1] virtual/pkgconfig-0 [ 1] virtual/os-headers-0 [ 1] app-text/tree-1.6.0-r1 [ 1] sys-apps/baselayout-2.1-r1 sys-fs/udev-164-r2: [ 0] sys-fs/udev-164-r2 [ 1] sys-libs/libselinux-2.1.9-r1 [ 1] sys-apps/acl-2.2.51 [ 1] sys-apps/usbutils-004 [ 1] virtual/libusb-0 [ 1] sys-apps/pciutils-3.1.9-r1 [ 1] dev-libs/glib-2.30.3 [ 1] sys-apps/util-linux-2.20.1-r2 [ 1] dev-util/gperf-3.0.4 [ 1] virtual/pkgconfig-0 [ 1] virtual/os-headers-0 [ 1] app-text/tree-1.6.0-r1 [ 1] sys-apps/baselayout-2.1-r1 sys-fs/udev-171-r5: [ 0] sys-fs/udev-171-r5 [ 1] sys-libs/libselinux-2.1.9-r1 [ 1] sys-apps/acl-2.2.51 [ 1] dev-libs/glib-2.30.3 [ 1] dev-libs/gobject-introspection-1.30.0-r2 [ 1] virtual/libusb-0 [ 1] sys-apps/util-linux-2.20.1-r2 [ 1] dev-util/gperf-3.0.4 [ 1] virtual/pkgconfig-0 [ 1] virtual/os-headers-0 [ 1] app-text/tree-1.6.0-r1 [ 1] sys-apps/usbutils-004 [ 1] sys-apps/hwids- [ 1] sys-apps/pciutils-3.1.9-r2 [ 1] sys-apps/pciutils-3.1.9-r1 [ 1] sys-apps/pciutils-3.1.7 [ 1] sys-apps/baselayout-2.1-r1 sys-fs/udev-171-r6: [ 0] sys-fs/udev-171-r6 [ 1] sys-libs/libselinux-2.1.9-r1 [ 1] dev-libs/glib-2.30.3 [ 1] dev-libs/gobject-introspection-1.30.0-r2 [ 1] virtual/libusb-0 [ 1] sys-apps/util-linux-2.20.1-r2 [ 1] dev-util/gperf-3.0.4 [ 1] virtual/pkgconfig-0 [ 1] virtual/os-headers-0 [ 1] app-text/tree-1.6.0-r1 [ 1] sys-apps/usbutils-004 [ 1] sys-apps/hwids- [ 1] sys-apps/pciutils-3.1.9-r2 [ 1] sys-apps/pciutils-3.1.9-r1 [ 1] sys-apps/pciutils-3.1.7 [ 1] sys-apps/baselayout-2.1-r1 sys-fs/udev-182-r2: [ 0] sys-fs/udev-182-r2 [ 1] sys-libs/libselinux-2.1.9-r1 [ 1] dev-libs/glib-2.30.3 [ 1] dev-libs/gobject-introspection-1.30.0-r2 [ 1] sys-apps/kmod- [ 1] sys-apps/util-linux-2.20.1-r2 [ 1] dev-util/gperf-3.0.4 [ 1] virtual/pkgconfig-0 [ 1] virtual/os-headers-0 [ 1] dev-util/gtk-doc-1.18-r1 [ 1] sys-apps/usbutils-004 [ 1] sys-apps/pciutils-3.1.9-r1 [ 1] sys-apps/pciutils-3.1.7 [ 1] sys-fs/udev-init-scripts- sys-fs/udev-182-r3: [ 0] sys-fs/udev-182-r3 [ 1] sys-libs/libselinux-2.1.9-r1 [ 1] dev-libs/glib-2.30.3 [ 1] dev-libs/gobject-introspection-1.30.0-r2 [ 1] sys-apps/kmod- [ 1]
Re: [gentoo-dev] Re: udev - mdev
On Fri, Jul 13, 2012 at 9:21 PM, Olivier Crête tes...@gentoo.org wrote: And on any new embedded platform, one should seriously think about using systemd too. It is very lean, replaces most of the giant, unmaintainable shellscripts that you find in many devices with smaller compiled code, and was designed to be a good fit for embedded devices. Fair point here - for an embedded device where memory is THAT tight I'd wonder if ditching the shell might be an attainable goal. C has to be more memory-efficient. Rich
Re: [gentoo-dev] Re: udev - mdev
On Fri, Jul 13, 2012 at 8:28 PM, Michael Mol mike...@gmail.com wrote: On Fri, Jul 13, 2012 at 9:22 PM, Walter Dnes waltd...@waltdnes.org wrote: On Sat, Jul 14, 2012 at 03:41:36AM +0300, Maxim Kammerer wrote On Sat, Jul 14, 2012 at 3:13 AM, Walter Dnes waltd...@waltdnes.org wrote: Do you realize this would effectively kill linux in the embedded device area? Udev, even without the systemd code, is simply to large for embedded devices. What's ?too large?? Udev already looks pretty small to me (116k udevd, 50k libudev, 500k resident memory), and I didn't even try compiling it with all extra features switched off. If that's too large for an embedded device, does that device really need (or can handle) anything more than devtmpfs? What does equery depgraph show for udev? Since I don't have udev installed, I can't check it here. [snip] sys-fs/udev-186: [ 0] sys-fs/udev-186 [ 1] dev-libs/glib-2.30.3 [ 1] dev-libs/gobject-introspection-1.30.0-r2 [ 1] sys-libs/libselinux-2.1.9-r1 [ 1] sys-apps/kmod- [ 1] sys-apps/util-linux-2.20.1-r2 [ 1] dev-util/gperf-3.0.4 [ 1] dev-util/intltool-0.50.2 [ 1] virtual/pkgconfig-0 [ 1] virtual/os-headers-0 [ 1] dev-util/gtk-doc-1.18-r1 [ 1] sys-devel/automake-1.11.1 [ 1] sys-devel/automake-1.12.1 [ 1] sys-devel/autoconf-2.68 [ 1] sys-devel/libtool-2.4-r1 [ 1] sys-apps/hwids- [ 1] sys-fs/udev-init-scripts- A lot of that is optional. The only hard dependencies are: =sys-apps/kmod-5 =sys-apps/util-linux-2.20 dev-util/gperf =dev-util/intltool-0.40.0 virtual/pkgconfig virtual/os-headers Everything else is optional. I repeat: the idea that udev is somewhat bloated or fat is really incorrect. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Re: udev - mdev
On Fri, Jul 13, 2012 at 9:32 PM, Canek Peláez Valdés can...@gmail.com wrote: [snip] A lot of that is optional. The only hard dependencies are: =sys-apps/kmod-5 =sys-apps/util-linux-2.20 dev-util/gperf =dev-util/intltool-0.40.0 virtual/pkgconfig virtual/os-headers Everything else is optional. I repeat: the idea that udev is somewhat bloated or fat is really incorrect. Little correction: inherit autotools brings things like automake and libtool, but then again, almost *every* Gentoo installation has those. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Re: udev - mdev
On Fri, Jul 13, 2012 at 08:13:43PM -0400, Walter Dnes wrote: On Sat, Jul 14, 2012 at 01:49:32AM +0300, Maxim Kammerer wrote On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao r...@gentoo.org wrote: mdev would need to switch to the netlink hotplug interface. I think that's quite unlikely, since mdev is not a daemon. Perhaps by the time /proc/sys/kernel/hotplug is gone, mdev advocates will have settled on some early udev fork. [1] Do you realize this would effectively kill linux in the embedded device area? Udev, even without the systemd code, is simply to large for embedded devices. What about using devtmpfs alone? William pgpsZziQMIEqm.pgp Description: PGP signature
Re: [gentoo-dev] Re: udev - mdev
Hi all, about the Mdev stuff, Slashbeast from Funtoo.org started that project a while ago. https://github.com/slashbeast/mdev-like-a-boss I think that it's actually working pretty good on his box. Some Coredevs from Funtoo are actually running with that stuff. Sylvain 2012/7/13 William Hubbs willi...@gentoo.org On Fri, Jul 13, 2012 at 08:13:43PM -0400, Walter Dnes wrote: On Sat, Jul 14, 2012 at 01:49:32AM +0300, Maxim Kammerer wrote On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao r...@gentoo.org wrote: mdev would need to switch to the netlink hotplug interface. I think that's quite unlikely, since mdev is not a daemon. Perhaps by the time /proc/sys/kernel/hotplug is gone, mdev advocates will have settled on some early udev fork. [1] Do you realize this would effectively kill linux in the embedded device area? Udev, even without the systemd code, is simply to large for embedded devices. What about using devtmpfs alone? William -- Salut alp Sylvain
[gentoo-dev] Re: udev - mdev
William Hubbs posted on Thu, 12 Jul 2012 17:29:31 -0500 as excerpted: And make sure that /proc/sys/kernel/hotplug points to udev. If you are using udev, /proc/sys/kernel/hotplug should be empty; do not point this to udev. Yes. I've not changed that setting from whatever the default is, and I guess udev moved its hook out from there quite some time ago so it's pointing at nothing, but having that actually point to something is known in kernel circles to lead to a lot of unnecessary grief. They're seriously thinking about (and may be planning on) removing that option from the kernel entirely, to keep people configuring their first kernels from getting themselves in trouble, but of course that's now part of the kernel/userspace interface, so it isn't allowed to just disappear like kernel/kernel interfaces can. At minimum they'd likely have to have it on the deprecation and removal schedule for awhile. (I've not checked to see if it's there already.) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
