From mboxrd@z Thu Jan 1 00:00:00 1970 From: Phil Howard Date: Fri, 30 Dec 2005 22:06:44 +0000 Subject: initially building /dev very early in system booting Message-Id: <20051230220644.GA30318@altair.ipal.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org Since I previously asked a question about udevstart inside another thread that ultimately is not really related, and since what my corrent project is may not be understood, I decided to post this message to clarify this and hopefully get some answers or ideas. My issue is about how to initially fill in /dev and not at all about any hotpluggable devices. But this mailing list is the only place "udev" is being discussed, and "udev" seems to be the only significant project to scan and parse "sysfs". So this seems to be the only real resource to ask questions that are obviously related, even though my need (at least right now) does not involve hotplugging. But I can understand that the concept of hotplugging can logically be done as part of the initial system as well. That is, the system starts up with no devices, then simply handles all that were present at the start as if they were just now plugged in. It would be a good approach as that makes for a single way to handle everything. That makes things simpler. Simple is good. What I am trying to do is build a bootable system that is organized so that it is exactly the same regardless of whether it is booted from read/write media such as a harddrive, or read/only media such as CD-ROM or DVD-ROM, or even network booting. I've built CD-ROM bootable systems and have found I need to usually tweak a few things to make it work on CD-ROM. Then those tweaks would confuse or just not work on a harddrive. Much of this involved how the root filesystem was mounted. It was easy to make the boot device be the / mount point on harddrives. But for CD-ROM, this was more complex. And in cases of making multiple-architecture media (e.g. a CD-ROM that would boot on either an Intel x86 based PC or a Sun Sparc machine) it was even more complex. I've come to the conclusion that mounting a media based filesystem/partition as / in the namespace is a legacy that isn't really necessary. Everything I did with bootable CD-ROMs that had a tmpfs filesystem as / worked just fine as long as I made sure that everything that needed to be mounted was in fact where it needed to be. By utilizing symlinks or bind mounts, I could build the namespace exactly as it needed to be, and in many cases even make it more flexible and/or more secure. What I'm effectively doing now is taking what I've done on CD-ROM back to writeable harddrives (even if filesystems will be mounted read/only). I'm currently exploring the initial namespace building with two approaches. One is the traditional init process (PID 1) running my own program to start things up (then exec the real init program to finish bringing the system up). The other is using the new "early userspace" feature of Linux, which is effectively the init process started at an earlier stage before even the root filesystem is mounted (and thus the process image has to come from a file included in the kernel). Clearly, in the "early userspace" method, I won't have a /dev directory at all. While the "pre-init" method could, I want to explore making it also not have a /dev directory. One reason for this is so that the first / and the ultimate / filesystems don't have to be the same. Another reason is just to make things work as much the same between both methods. So that basically brings me to building the /dev directory so early in the initialization that no filesystems can be assumed to be mounted at all. The initial condition is that / is a rootfs, ramfs, or tmpfs fileystem. My program would create needed directories and mount sysfs as /sys. It would also mount a separate tmpfs as /dev because I want to switch / to be read/only at a later point. Now I need to mount actual disk partitions on their respective mount points to build the namespace. I need devices in /dev for each partition to be mounted. I also need to open /dev/console as soon as possible in the case of the "early userspace" method. So that brings me to doing what effectively "udevstart" would seem to do. But I would not literally use "udevstart". Instead, my thinking was to include a subset of that code to build a subset of /dev enough to get the system up to the next stage. At this point I don't need all devices, so the fact that I won't yet have any udev config files (in /etc which is not yet mounted) shouldn't be much of an issue. Mounting filesystems can proceed without the intended metadata for the block devices, and without many of the other devices that will ultimately show up (who needs a sound card to get /etc mounted). Example code that scans and parses /sys for devices, at least for block devices, would be useful. I can write code to do that, but what may be inherint in examples are issues I might not anticipate such as special cases I won't see during my development. That's why I have an interest in "udevstart", and a corresponding interest in why "udevstart" is being depricated. I want to better understand what my program should do to get devices configured at this early stage in bringing up the system (before the traditional init program gets started, so certainly before any hotplug event handling daemon is started by the rc scripts). My program is currently being built with dietlibc and I may use klibc at some point. Including other libraries would at the very least need to be statically linked (dynamic libraries and even the runtime linker cannot be assumed to be present) and their needs (in other references or in just the size) may be an issue. Keeping this program simple and compact is as much a part of the goal as any other (in the sense of being minimal in doing the complex things that do need to get done). So any advice on what is ultimately an effort to scan /sys for devices to build into /dev would be appreciated. It would seem this mailing list would be where people who know about /sys the most would be. -- ----------------------------------------------------------------------------- | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ | | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ | ----------------------------------------------------------------------------- ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel