Re: scanning sysfs to populate /dev
phil-news-nospam_at_ipal.net
Date: 04/26/05
- Next message: Zeljko Vrba: "ANN: secure password generator v1.2"
- Previous message: Grant Edwards: "Re: How to access remote SourceSafe database from Linux box?"
- In reply to: Ryan Reich: "Re: scanning sysfs to populate /dev"
- Next in thread: Ryan Reich: "Re: scanning sysfs to populate /dev"
- Reply: Ryan Reich: "Re: scanning sysfs to populate /dev"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 26 Apr 2005 14:55:55 GMT
On Tue, 26 Apr 2005 14:07:38 GMT Ryan Reich <ryanr@uchicago.edu> wrote:
| I get what you're trying to do but thinking about it from an abstract
| perspective there doesn't seem to be a way to acquire permissions data. Before
| you've mounted filesystems the only information you have access to is: defaults
| programmed into the kernel, defaults programmed into your utility, and defaults
| written into a config file also in the initramfs, which is much the same thing
| if you have to compile it into the kernel image. You also get access to
| whatever the kernel can learn from the actual hardware.
Right. The config file could be done, but it is just a different way
(perhaps easier for many people if I want to put a parser in) than doing
it in C.
| My thoughts on this are that the early userspace philosophy is not to set up a
| perfect system before init even runs, but simply to arrange for the rc system to
| see a functional environment that it can then put the finishing touches on. I
| can see it being worthwhile for your utility to do some heuristics and figure
| out which device / is on, or load some drivers and start up LVM or RAID if
| necessary, or some such thing that the kernel developers wouldn't want to put
| into their startup code, but once you have the ability to actually mount your
| filesystems why would you need to do anything more from early userspace when you
| would have the infinite capacity for configuration available from data on disk?
There will definitely need to be 2 levels of configuration going on, the
first of which is not as easy to change, and thus needs to as general as
possible. But I'm also trying to make it as correct as possible. Any
devices that always need a particular permission mode, should get that
here so the functionality is as complete as it possibly can be by the time
the regular init/rc systemstarts. The reason I want to do that is because
the traditional init/rc code would see the disk filesystem based device
nodes in the ordinary case. But for this setup, I want to approximate
that as much as possible so that a minimum of change is needed to the
init/rc stuff.
Traditionally, the kernel only deals with devices by their device code.
Having a device namespace in the kernel, is a departure from that
philosophy. The first appearance is the ability of the kernel to
recognize root=/dev/hda1 in place of root=301. The next appearance was
the whole devfs design. That had its problems so now we have sysfs.
Actually, network interfaces are a namespace that appeared even before any
of this. I'm not opposed to the kernel knowing namespace, as that can be
an easy way to deal with the huge device space that looms. But consider
that namespace was previously an external (of the kernel) policy, and now
it is migrating to device drivers. Shouldn't common metadata have gone
along with it (not all of it, just what is considered essential enough to
be universally the same). Basically, what I want to find is that
essential universal metadata policy. Then the rc scripts can tweak it
from there.
| Alternatively, of course, you can always do the following: do the heuristics and
| get / mounted at, say /newroot. Then run udevstart pointing it at the config
| file in /newroot/etc/udev to have it create nodes in /newroot/dev with whatever
| permissions you like. You have to have mounted / even to create the nodes at
| all, so this seems just as flexible as trying to read the tea leaves about what
| the permissions ought to be.
For various reasons I won't be using the udevstart program. The sysfs
scanning code will be in my own program. It is already written, anyway,
and is not hard to do.
|> Perhaps what I need to do is build all the devices first, than later, once
|> the disk filesystems are mounted, go back and update their ownership and
|> permission according to either some config file or a "dev" directory on a
|> filesystem that gets mounted (but isn't mounted at "/dev/"). I could recurse
|> through the /dev tree that was created, and for each node, if one exists in
|> some other directory of choice, update file meta data from that source.
|
| This was my initial suggestion but I think the one above works well since you
| don't have to do the same work twice.
This would allow a traditionally organized system, one that has a /dev
directory even though it won't be used as such, to work. And it will also
allow a non-traditional system that is built with no /dev directory to
work as well (since /dev is being built in ramfs or tmpfs space ... that
already being a passthrough kernel parameter option my program will pick
up on, like rootfs=ramfs or rootfs=tmpfs). I will look for a specific
config file, perhaps "/etc/dev.cf", and read it get metadata to apply to
the created device nodes. Lacking that, it is up to the init/rc
program/scripts to tweak it as desired. But my objective is to get it as
close as possible, so things like "/etc/dev.cf" can be as small as
possible, and a very functional system if entirely absent (with an
absolute requirement that what I do not inhibit letting the administrator
login as root via ssh).
What I am doing different is this. The "/" mount point will be the
originally mounted rootfs filesystem (unless rootfs=ramfs or
rootfs=tmpfs[,options] is specified to replace it). Then /dev and /etc
will reside in that filesystem with /dev being populated from the sysfs
scan, and /etc being populated from a copy of the "etc" directory found on
the designated filesystem that would have in a traditional system been the
root filesystem. Other directories like /bin /lib /opt /sbin /usr /var
will be mouned from (using the bind mount feature) specific directories in
filesystems in one or more filesystems. Filesystems that can be mounted
read-only (those that are the source for /bin /lib /opt /sbin /usr for
example) will be. Or maybe they will be network mounts (NFS, NBD, etc).
Here is what you might see from df:
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 0 0 0 0% /
/dev/hda1 248944 162972 85972 66% /admin
/dev/hda3:bin 4075456 3712760 362696 92% /bin
/dev/hda1:boot 248944 162972 85972 66% /boot
tmpfs[dev] 193036 512 192524 1% /dev
devpts 0 0 0 - /dev/pts
tmpfs[shm] 193036 0 193036 0% /dev/shm
tmpfs[etc] 193036 9720 183316 5% /etc
/dev/hda4:home 113631392 110765312 2866080 98% /home
/dev/hda3:lib 4075456 3712760 362696 92% /lib
/dev/hda3:opt 4075456 3712760 362696 92% /opt
proc 0 0 0 - /proc
/dev/hda5:root 128440 103140 25300 81% /root
/dev/hda3:sbin 4075456 3712760 362696 92% /sbin
sysfs 0 0 0 - /sys
/dev/hda7:tmp 642536 38288 604248 6% /tmp
/dev/hda3:usr 4075456 3712760 362696 92% /usr
/dev/hda5:var 128440 103140 25300 81% /var
tmpfs[lock] 193036 0 193036 0% /var/lock
/dev/hda8:log 128440 47976 80464 38% /var/log
tmpfs[run] 193036 52 192984 1% /var/run
/dev/hda6:var/mail 128440 32840 95600 26% /var/mail
/dev/hda7:var/tmp 642536 38288 604248 6% /var/tmp
/dev/hda4:web 113631392 110765312 2866080 98% /web
-- ----------------------------------------------------------------------------- | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ | | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ | -----------------------------------------------------------------------------
- Next message: Zeljko Vrba: "ANN: secure password generator v1.2"
- Previous message: Grant Edwards: "Re: How to access remote SourceSafe database from Linux box?"
- In reply to: Ryan Reich: "Re: scanning sysfs to populate /dev"
- Next in thread: Ryan Reich: "Re: scanning sysfs to populate /dev"
- Reply: Ryan Reich: "Re: scanning sysfs to populate /dev"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
