initially building /dev very early in system booting

[Phil Howard <phil-linux-hotplug-devel@ipal.net>]

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_id\x16865&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