On 05/25/2012 06:51 PM, Bruce Dubbs wrote: > Armin K. wrote: >> On 05/25/2012 03:52 PM, Bruce Dubbs wrote: > > I think the reason it finishes so early for you is that the drivers are > modules and have not yet been initialized. > > Is /sbin/init a link to systemd?
Yes and yes. Udev will handle modules later. And /sbin/init is link to systemd, as well as poweroff,runlevel,shutdown,reboot are links to systemctl. I don't have any of sysvinit init programs installed. > We'll need to add dbus to LFS. :( The only requirement I can see is > expat so we'll need that too. > Well, yes. Also, intltool is needed for NLS, which needs XML::Parser which needs expat. I think that dependency can be ommited by using --disable-nls. >> libcap > > I suppose they mean libcap2 which has attr as a dependency. > Yeah. Also, coreutils can benefit from libcap2 and acl (another dep of attr). > So we have to add 3 packages that we don't want to support systemd what > we don't want in order to get udev which we do want. [..] >> * udev: all udev sources are merged into the systemd source tree now. >> All future udev development will happen in the systemd tree. It >> is still fully supported to use the udev daemon and tools without >> systemd running, like in initramfs or other init systems. Building >> udev though, will require the *build* of the systemd tree, but >> udev can be properly *run* without systemd. > > Other than the dependency issue, I can live with that. > >> * udev: the daemon binary is called systemd-udevd now and installed >> in /usr/lib/systemd/. Standalone builds or non-systemd systems need >> to adapt to that, create symlink, or rename the binary after building >> it. > > Naming is not a terribly important issue. We could symlimk some names > though. > [..] >> DBus is really no big problem. You can't avoid dependencies just like >> that. I don't think it would be problematic for anyone using server >> since it does not use nearly anything when it comes to resources. >> >> Also, if you think of a *simple* server, you can ditch udev and create >> static nodes. Again, LFS gives user a choice. It is up to user to decide >> what they need and what they don't need. > > That's true. We don't show the users much about mknod any more. > [..] >> I just want to make clear one thing that will most people say >> >> Note: I don't know how big is something. Just trying to make some analogy. >> >> " Systemd is big. How can someone compare 100 000 lines of systemd code >> with 1000 lines of init code. Also, Bootscripts are simple, they just >> require 5 or 10 lines. " >> >> This one is not true in many ways. Systemd will act as many programs as >> it's possible. >> >> Bootscripts functions use at least 5 or so programs including grep, awk, >> bash itself and so on. So you can count 10 000 more lines to the 1000 >> lines of init program. > > Those are part of LSB Core. Using them does not add overhead. > Scroll down. >> Also, it interfaces directly with libkmod without any need for modprobe >> tools. Count out 1000 lines more to that. > > I don't use modules. You're not only user of LFS. There are people who use it. >> It uses builtin fsck functions that only interface with fsck.fstype, so >> no need for big initscript for that. > > So we are going to remove e2fsprogs? The largest script we have is > checkfs and that is only 144 lines. Most are error messages and > comments. Easy to read, easy to change. > systemd will still interface with fsck.ext4 for example which is part of e2fsprogs, but it does implement something internal for fsck tough which I don't understand (the systemd-fsck). >> So no offense, I was just trying to explain that systemd is not that >> bigger, but it does include some features that someone might not want, >> need or like. > > No offense. Why would you think that? > > I think the biggest problem with systed is lack of control by the user. > Reading a script and making a line or two change is quite easy. We > have a total of about 2500 lines of shell scripts in lfs divided into > about 20 files. > > Analyzing a large compile program that has 222 c programs 139 header > files and 149025 lines of (c/h) code is not easy at all. > > Yes, it has increased functionality but also is opaque and forces that > functionality on users whether they want it or not. I was trying to make point for that. But I wasn't good enough at it. I agree it is hard analyzing 149025 lines of code, but those lines reimplement most of the tools you said "are part of LSB core" since it is easier and faster to eg set hostname or create file using system call than run some external program which will dlopen more shared libs and so on. I understood that like so. Yeah, in those <insert number here> lines there are lot of stuff which are not really part of the init system as I said. >> Also, dbus-python is required at runtime for systemd-analyze. > > I suppose we will need to do a minimal install in LFS and a more > complete install with all the bells and whistles in BLFS. Sigh. Well, udev is done like that. And systemd-udev still can use g-i, glib (for gudev) and same stuff like in "blfs udev" ... -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
