On Wed, Jul 02, 2003 at 09:56:20PM +1000, Andrew Over wrote:
> Hi All.
>
> I spent a little while today thinking over how to layout the VFS, and
> this is what I have right now. Keep in mind that this was hashed out
> before we had the ok on the existing code, so everything is called
> something different. On the bright side, structurally it is very
> similar (the underlying file-system abstraction is handled a little
> differently).
i never quite liked the naming conventions used in the vfs code we
have, too many things are called `device' which makes it more
difficult to follow. niether of us could come up with any sensible
names though.
> Also keep in mind this is far from complete, and is intended only as a
> proof of concept.
ok
> We start by maintaining a top-level abstraction very similar to the
> current one. I'll call it a "protocol" abstraction for want of a better
> term.
ok.
> The idea is that for each protocol (where protocol is something along
> the lines of "file", "tftp", "http", ...), we maintain a structure of
> protocol ops viz:
>
> struct __proto_ops {
> int (*verify)(char *filename); // Determine if we can handle it
char *path or char *device or char *devicepath, but just nitting.
> int (*open)(...);
> int (*close)(...);
> int (*read)(...);
int (*write)(...);
even though most filesystem drivers will not permit writing, it will
be possible to write to raw block devices, and it will be possible to
write to tty devices (otherwise making the UI work will be quite
difficult). we also need to write to network devices etc.
> int (*seek)(...);
lseek
> int (*tell)(...);
i don't think we need tell since that functionality is available with
lseek(). (ftell just uses lseek()).
> int (*opendir)(...);
> int (*readdir)(...);
> int (*closedir)(...);
> };
>
> I'll also present an additional structure here, to aid the explanation
> below.
>
> struct __fd {
> int fd;
whats this for?
> struct __proto_ops *ops;
> void *protodata;
> };
>
> Now consider a call to generic open(). It needs to take the following
> actions:
>
> (1) - Parse the filename
> (2) - Determine the correct protocol (call "verify" until one is happy?)
yes, we were also thinking of keeping a linked list of already
known/probed devices so we can avoid doing verify() so much. im not
entirely sure whether this is a gain, or not.
> (3) - Allocate an underlying file descriptor (which is managed within
> the generic functions), and a corresponding __fd structure.
> (4) - Fill in __fd.ops with the appropriate protocol
> (5) - Call __fd.ops->open(...)
> (6) - Massage the return value, and clean up appropriately
>
> Handling things in this manner, we can drop in new protocols without
> trouble... we need only ensure that their verify functions don't overlap
> on the range of acceptable names.
what do you mean here?
> Now consider the file protocol (since this is where we're starting).
>
> At the file level, we require a similar level of abstraction. For each
> filesystem type known to the system, we have a structure like the
> following:
>
> struct __fileops {
> int verify(...);
> int open(...);
> int close(...);
> int read(...);
> int seek(...);
> int tell(...);
> int opendir(...);
> int readdir(...);
> int closedir(...);
> };
>
> And also consider:
>
> struct __filedata {
> struct __fileops fops;
> ??
> };
not sure i see the point of this one...
> When the generic open ends up calling the file open, we have the
> following sequence of events:
>
> (1) - Parse the filename (if necessary)
> (2) - Determine the correct filesystem type (through verify?)
> (3) - Allocate the necessary private structure (__filedata... this will
> be returned and stored as the parent's "protodata", and passed
> into each subsequent call).
> (4) - Call the file system driver open
> (5) - Massage results
> (6) - Cleanup and return
>
> And that's the general idea... almost all other operations are analogous
> (yeah yeah, I'm skipping over a lot of detail here).
i think i have a general idea.. however i have trouble following lots
of structs so if you could illustrate the hierarchy a bit that would
help.
> Random thoughts:
>
> - Do we want to allow a device level abstraction, whereby the top level
> protocol determines the device and passes a device object down to all
> lower protocols (ie typically it'd just be an OF block device,
> but...)?
what do you mean by a device object?
> - If not, who is responsible for determining the appropriate device?
OF provides a device_type node, which can consist of the following
values:
display - framebuffer
block - disk
byte - tape
network - NIC
serial - tty
so for OF its easy, but this kind of determination needs to be made by
something living in sysdeps/1275.
i recommend you read sections 3.2 - 3.5 and 3.7 of the IEEE1275 spec
(available on OpenBIOS site) so you can be a bit familier with what
stuff is in OF (but keep in mind our interface should be generic and
portable, since OF isn't the only potential target).
> - Should things like file position (tell et al), be left to the
> low-level drivers (where possible), or kept at higher layers.
well it depends.
libext2 has its own seeking mechenisms so it keeps track of things on
its own to a degree.
other filesystem drivers we write, such as XFS will probably keep
thier own idea about position within regular files.
OF however provides no means to query seek position, so we need to
keep track of it ourself, this one would probably be kept in rawio.
this aspect needs some thought..
> Obviously, the amount of state data kept in the various places will need
> to change (as implementation problems are discovered). But this is a
> first pass. It's quite similar to what we currently have.
yup, im sure we will run into things we didn't anticipate.
> Anyway, this is rather haphazard (loooooong day today), but I'll try to
> think things through a bit better tomorrow, and see if I can spot any
> holes. I'll also take a closer look at the existing VFS stuff.
good, thanks.
> Flame away,
no no, no flaming, for my health's sake this needs to be a stress free
project ;-)
--
Ethan Benson
http://www.alaska.net/~erbenson/
Attachment:
pgp00012.pgp
Description: PGP signature