Permalink
Browse files

add missing :

  • Loading branch information...
1 parent 77eb72a commit f39a7c19114c30d626e1fc950c4f33e41d2c04bc @falconindy committed May 1, 2011
Showing with 1 addition and 1 deletion.
  1. +1 −1 _posts/2011-04-30-what-happens-in-early-userspace.textile
@@ -33,7 +33,7 @@ Clean Bash is what I do. I write lots of it, and I'm damn good at it. I won't ha
Speed was important, because I hear a _lot_ of complaints about how long it takes to generate new images. My initial implementation was roughly on par with mkinitcpio. autodetect images were a bit faster, and full images a bit slower. No good. The silver bullet was, of course, thinking outside the box. mkinitcpio uses a utility from the kernel source tree called gen_init_cpio. It requires that you build a list of contets in a specific file format which is passed to this utility which then poops out an image on stdout. The problem is this: inevitably, when tracing dependencies of modules or binaries, you find duplicates. You have to check for these and avoid adding them. Checking an external file for these things requires either iteration or grep. Both are slow. There's another way. "The Gentoo Wiki":http://en.gentoo-wiki.com/wiki/Initramfs#Creating_a_Separate_File was a big help here in getting me the speed I was looking for. The tradeoff is that you end up using a few Mb of diskspace in /tmp during the process, but I think its worthwhile. It also means you're unable to create devices for the initcpio as an unprivileged user. Not an issue for me.
-On the modularity front: In addition to keeping the concept of "builders", I split the code into 2 pieces -- a main Bash script which lives at "/usr/sbin/geninit"https://github.com/falconindy/geninit/blob/master/geninit, and "/usr/share/geninit/geninit.api":https://github.com/falconindy/geninit/blob/master/geninit.api. The API is a public API for which "builders" (known to mkinitcpio as "install") can draw from to add files to the resultant image. The main file remains as private API. Since its Bash, I can't stop someone from using the "private" API calls, but it's a friendly suggestion.
+On the modularity front: In addition to keeping the concept of "builders", I split the code into 2 pieces -- a main Bash script which lives at "/usr/sbin/geninit":https://github.com/falconindy/geninit/blob/master/geninit, and "/usr/share/geninit/geninit.api":https://github.com/falconindy/geninit/blob/master/geninit.api. The API is a public API for which "builders" (known to mkinitcpio as "install") can draw from to add files to the resultant image. The main file remains as private API. Since its Bash, I can't stop someone from using the "private" API calls, but it's a friendly suggestion.
While I still consider geninit to be a bit of a beta, I'm very excited to see it come to life so quickly. Early adopters are very much appreciatedd to help iron out bugs. It's, of course, "on the AUR":http://aur.archlinux.org/packages.php?ID=48542, and available directly from Github.

0 comments on commit f39a7c1

Please sign in to comment.