vmx.nu

[admin]

The following link gives a decent overview of what the various vnode and
VFS operators do.

http://wiki.genunix.org/wiki/index.php/Writing_Filesystems_-_VFS_and_Vnode_interfaces


The following link contains an updated list of the VxWorks 6.6 public
API (for future and present developers).
http://www.slac.stanford.edu/grp/cd/soft/vxworks/doc/6.6/vxworks_kernel_api_reference_vol2_6.6.pdf

When VxWorks 6.2 was introduced, the file systems area was completely
revamped from previous versions. Detection, mounting and unmounting
became vastly easier. A removability framework was installed.

The following link also has more information on the VxWorks filesystems.
http://www.takefive.com/windsurf/techpubs/os/vxworks/v6_2/vxworks_kernel_programmers_guide_6.2.pdf

One of the things I was thinking of doing (for now) was splitting the
device table into two parts. One part would be for block devices (items
that would use a file system, or file system interface), and the other
would be for everything else (character I/O, ...). I figured that this
would result in less immediate code change (driver interfaces and
what-not). Well, block device part would be essentially be a super-set
of the other, and the difference between the two could be decided by the
addition of an extra flag to the device table.

iosLib.c and new driver calls
-----------------------------
One item was definitely planning on doing before getting the Wind River
job was to modify iosLib.c so that each I/O call did not need the
following test ...
if (func != NULL)
status = (*func)(pFdEntry->value);
else
status = OK;
I was planning to add a null driver so that there would never be a
situation where a NULL pointer could be called.

read()/write() and readv()/writev()
-----------------------------------
I was thinking that this may be an area where it would be better to
deviate a little from VxWorks. In VxWorks, read()/write() are the
primary calls and readv()/writev() are wrappers that call
read()/write(). Perhaps it may be better to do it the other way. That
is, make readv()/writev() the primary calls and make read()/write()
wrappers that call the special case reading/writing one vector. In the
future, if user-space processes are implemented, this ...
1. hoists some of the work out of the kernel into user-space.
2. may reduce an application's need for performing multiple
read()/write() system calls.
It would also mean that existing driver interfaces would need to be
updated.

root file system and mount points
---------------------------------
As you probably recall from working with VxWorks in the past, VxWorks
does not have a root file system. In 6.4?, this was sort of fixed with
the introduction of the virtual root file system. They needed to add
this for POSIX compliance. Under normal operation, VxWorks does not
have the concept of a "/" directory. It has devices and that's it. To
get around this, they introduced the virtual root file system (VRFS)
option which is a read-only version of "/". Fortunately POSIX allows
"/" to be read-only. All the devices are conceptually treated as being
mounted off "/" (sub-mounts), although in reality, the same typical
scheme for accessing them is used. Does VxWorks allow sub-mounts with
their VFS?--no. Although not a necessary restriction, we found it
simplified things.


One of the things that will need to be decided is when to allow "raw"
access to the underlying media. UNIX-like operating systems allow both
the raw device and any devices (file systems, partitions, ...) mounted
on top of it to be accessed at the same time. VxWorks took a different
approach--only the top level device can be accessed. If the file system
is recognized, it attempts to mount it. If not, it is mounted with
rawFS which treats the device as a single file. I make mention of this
here as depending upon which route you take, it will affect the caching
that is used in the VFS. In the VFS, there is one vnode per open file.
If a file is opened twice, there is still only one vnode. Then there is
the syncer vnode. This accesses the underlying device. So, if we were
to imagine a picture that is a single layer, in essence, there are many
logical vnodes which eventually map to a single physical vnode. If you
allow the raw device to be accessed independently of the file system,
then all the cached buffers must be associated with the syncer
(physical) vnode. Otherwise, there will be synchronization and locking
problems. If you do not allow the raw device to be accessed
independently of the file system, then buffers can be associated with
either the logical vnode, or the syncer vnode. Both methods have their
own advantages and disadvantages. Disallowing simultaneous access was
the way I was thinking of going.

That's about it for now. I tried briefly to find some more info out
about XBDs, but I haven't been able to get the structure for it online.

Original text by: Peter Mitsis