Eric S. Johansson wrote:
> Ronald Pijnacker wrote:
>
>> John Nelson wrote:
>>
>>> [...] The best long-term solution, IMHO, is to go with Sergey
>>> Okhapkin's suggestion (in this same thread) and find a way to make
>>> the colinux daemon "educate" the kernel at boot time that certain
>>> major/minor numbers devices are actually aliases for other ones (so,
>>> for example, we could make /dev/hdb1 and /dev/cobd2 become the same
>>> thing), but only when running in hosted -- not native -- mode.
>>
>>
>> That still leaves the problem of having different settings other than
>> fstab (networking, xdm.conf, default-runlevel entries to name a few).
>> In my script I can handle these quite well. I've spend some time
>> investigating initd, but gave up after a while (lack of good
>> documentation). I don't see an elegant alternative solution. This
>> is something that a lot of users will run into, I guess.
>
>
> I've often thought it would be useful in many contexts to have
> indirect symlinks. Specifically a symlinks which returns a file based
> on an entry in a database. This file could be a real file based on
> some calculation or even a window onto a file or database.
> ...
> It would functionally be the same as symlink so we could reuse is much
> of that path as possible. I wish I knew whether or not something like
> the VFS layer would be a good point for file switching but assuming it
> is, as soon as you could detect that you had a indirect link, you
> would do a look up in a database or dbm file for the original path,
> what you need to run to generates the real path and once you have the
> real path, return the appropriate information (real inode etc. etc.)
Okay, I'm going to philosophize for a bit... (I figure that it's a good
idea right about now since we all seem to be groping around for
solutions and not really liking many of the ones that we already have.)
The proc, devfs file systems already do this type of virtualization
thing, inasmuch as the files are really just "virtual" files. For that
matter, NFS and SMBFS also do it to a certain degree, inasmuch as
accessing those files doesn't actually open anything on the local
machine, but rather causes network activity to occur. My point here is
just that a file is not necessarily a group of bytes on a local hard
drive - it can be disk information, but can also be network info, kernel
info, or basically anything else we care to implement.
For the short term, I'd say that the devfs/udev approach is best for
dealing with fstab related issues, but we are really talking about
concocting a system that has multiple configuration *profiles*. When I
think about this, the best precedent that occurs to me is either in a
laptop computer that acquires whole new bits of hardware when connected
to a docking station, or else USB devices that are designed to be
inserted/removed regularly. Since I am philosophizing here, I'd
generalize this to say that the system configuration changes dynamically
with its environment. (Of course, the changes are not arbitrary, and
cannot be to any extent, but this is just a caveat.)
Part of the problem we're dealing with is that the existing
configuration system in Unix is basically a bunch of flat-file databases
(that is, all data pertaining to a particular configuration is contained
within one or more flat-files). While extraordinarily easy to work
with, it has nagging property of being static -- there really is no such
thing as a schizophrenic fstab file, for example, that suddenly
*becomes* the correct version because of an environmental change. The
historical solution to this has always been to employ indirection --
where the place to look for the configuration doesn't actually have
anything in it except a reference of some kind that points to the
current, correct location. Unix uses this extensively to handle
separate user instances (mostly using environmental variables such as
$HOME, $USER, or even the dreaded '~'). Anyone who has ever perused the
Windows registry will also notice the same type of thing happening there
-- consider the HKEY_CURRENT_USER subtree, or the fact that each
configuration is in a "control set". For that matter, all of the
DosDevices we like to use with CoLinux are actually aliases for
different COM identifies (although I haven't checked, I suspect they
actually point to the device drivers for those particular pieces of
hardware). I am not sufficiently familiar with MacOS to say how they do
it, but I have always been impressed with the their ability to take
"plug 'n play" to a new level when it comes to USB peripherals -- for
the most part, they just work.
The great thing about the original thread problem (mount disks when
fstab can't be counted on) is that devfs and udev (Sergey Okhapkin's
later suggestion) provides this *exact* type of dynamic referencing
that we need to make this happen. Nevertheless, the solution, while
effective, is still sloppy since it depends on a side-effect to work.
The side effect to which I am referring is that it depends on the
presence of a kernel driver with major number 117 -- that's our magic
cobd number -- in order to decide when it should symlink /dev/hdx to the
appropriate /dev/cobdy. Although we would tell them to _always_ symlink
/dev/hda2 to /dev/cobd1 (for example), it only actually does it if
device (117,1) is present -- so the fact that our linux system still
works when booted natively is a side-effect. I think we really ought to
depend on something a little more reliable than the presence of a device
major number. Regardless of this qualm, it still works, and does not
require us to modify the file system before any fs checks are made,
which is a definite plus.
So far, the best solution for every other type of config file seems to
be to replace it (or else replace its symlink). I can't say I really
like this one either but I am at a loss as to a better approach. The
reason I don't like it is because we have essentially moved the switch
(ie the choice of going with one configuration or another) all the way
to the hard drive. While I think the *choices* should be there, the
thing controlling whether we go with choice A or B ought to be in
memory. To me, the existing solution seems like driving 50 kilometers
to another town to buy milk when you could just walk to the grocer down
the street. Perhaps I am being overly nit-picky on this one, but I am
also at a loss for how to fix it, since the /etc directory must exist on
the root file system, which will make it *really* hard to virtualize it
in way.
Of course, what I'd really like to see (personally) is the ability to
have a symlink destination given dynamically (which I think is kind of
like what Eric Johansson was talking about). Instead of having the
symlink fixed in the filesystem, it would be advantageous to have it
point to something in memory, which in turn points to some other file.
The closest thing to this that I'm aware of is block special files (like
/dev/cobd, /dev/hda, etc), but that's just ugly, since we'd really like
to know what the file was linked to, just like we can see what a symlink
points to.
So far as I am aware, ext2 doesn't support anything like this, and I
doubt if any other common file systems do either. Obviously, there
would need to be some kind of daemon running that would effect the
precise choice whenever one of its link files was accessed, but the
issue still remains as to how a link to this daemon would exist in an
ext2 filesystem (which it would have to be able to do so long as we
can't virtualize /etc). Of course, it goes without saying that an
ability like this would be a tremendous boon for anything requiring
dynamic configuration. But others would simply argue that flat files
should be done away with entirely and replaced with hierarchical
databases (which is precisely what Microsoft did when it moved from away
INI files to the registry, and what the Gnome people have done with gconf).
Unix systems are already quite good at switching things up based on
user, and we are trying to figure out the best way forward for switching
things up based on hardware environment. Maybe we should try to glean
inspiration from MacOS X (which is a BSD derrivative and handles dynamic
hardware nicely) and Knoppix (which is dynamically self-configuring).
That is, of course, unless any of you out there has any good ideas as to
how to virtualize a file on an existing file system.
Anyway, I'm just philosophizing here, perhaps its time I got back into
the real world. Back to work...
|