On Thu, Jul 17, 2003 at 12:13:23PM -0400, Pisupati, Ajay wrote:
> Ethan,
> Here's basically a summary of what I plan to do w/ open.c. most of
> this stuff is
> essentially paraphrasing what you have already told me. so please bear w/
> me.
>
> if(node) nodespec=2;
> if(file) filespec=4;
> spec=nodespec+filespec;
>
> if(spec == 2)
> {
> /* only the node is specified */
> /* call rawio_driver to open it */
> }
> else if(spec == 4)
> {
> /* only file path is specified */
> /* determine if path is absolute or not */
> /* ???? call fs_driver->open(ofpath) ???*/
> }
> else if(spec == 6)
> {
> /* both device and file path are given */
> /* verify fs driver */
> /* ???? call fs_driver->open(ofpath) ???*/
> }
>
> when spec=6,
> we check for the correct fs_driver
> [1] Have you decided on how we are going to do this?
> - will it involve basically calling open again w/ only the
> device node specified?
well i think we should keep some sort of accounting so we don't need
to re-verify the same device over and over...
verifification is done by calling each drivers verify() till one works.
> [2] After verification, open needs to call fs_driver->open() correct?
> which in turn calls open again to open the device node
yes the filesystem driver will open() the raw device.
> are you comfortable w/ the __fd.h definition or do you think changes need to
> be made?
i don't like the naming conventions since they are unclear and
confusing, but i don't have much better ideas.
also i am not quite sure its complete enough, as you can see in my
ext2 driver places where libext2 returns a pointer for an opened
filesystem, or a opened file i have EXT2_FS and EXT2_FILE markers,
since i don't really see a obvious place to store these pointers.
> when only the file path is given, I am assuming that a default device is
> already going to be set (and open).
it should be yes, if not return ENOENT or EINVAL or something.
as for open, not necessarily. for ext2 there is a concept of a
`opened filesystem' and we certainly should not be opening a
filesystem twice when we happen to open two files off of it, libext2
can handle multiple open files on a single open fs. the other fs
drivers should also work this way. (currently they don't, but they
have to be rewritten anyway).
generally once the last file on a filesystem is closed, the fs should
be closed too.
> I guess there is going to be an "active directory" as well (set by the
> client using chdir() or something like that)
> or the file will be checked relative to the last directory
yup. my idea for chdir() is to work like so:
chdir("hd:3,/"); // standard way to implement yaboot default/partition.
chdir("/boot"); // if prior happened this is valid, if not then not.
i think this is a reasonable compromise to get close to unix behavior
as practical, and without creating a big mess in client programs of
doing mount() umount() calls all over the place, (as well as dumping
the majority of device path parsing onto the client).
basically the idea is the OF device tree is the root filesystem, and
all connected disks with filesystems are already mounted within that hierarchy.
its arguable that this is slightly OF centric, however most firmwares
in use today seem to have at least some form of a device tree, so this
sementec should work. x86 BIOS doesn't apply so well since it barly
has any concept of device naming/addressing at all, but if someone
really wants to port prom-libc to such a archaic and broken system
they will have to work around more challenges then just that (and it
won't be me).
--
Ethan Benson
http://www.alaska.net/~erbenson/
Attachment:
pgp00029.pgp
Description: PGP signature