Date: Sat, 07 Dec 2002 14:53:38 -0800 From: Peter Wemm <peter@wemm.org> To: "ouyang kai" <oykai@msn.com> Cc: hackers@FreeBSD.org Subject: Re: One Filesystem vnode operations declare problem. Message-ID: <20021207225338.0D2C12A7EA@canning.wemm.org> In-Reply-To: <F28mtViNCm2v94hwUaW000185fe@hotmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"ouyang kai" wrote:
> >From: Peter Wemm <peter@wemm.org>
> >Undefined. The bubble sort that orders these could leave it in any
> >state.
> Woo. thank you.
> In mi_startup(), the kernel will register those device/modules, and excute
> the 'func' declared by SYSINIT, right?
Yes.
> I think the kernel will have not real "/" filesystem until kernel completes
> the SI_SUB_ROOT_CONF register. How the kernel get those info we stored in
> "/" filesystem, such as 'loader.conf' and part of '/etc/rc'? The kernel use
> the BIOS model? I am puzzled.
/boot/loader runs before the kernel and uses the BIOS to access the device.
It passes information to the kernel through metadata, environment variables
and other metadata. The kernel and any kernel threads created before ROOT_CONF
do not have access to file system space.
The init process begins by setting its "/" to the root vnode, effectively
chrooting to the recently mounted file system. Then that process can exec
/sbin/init and /sbin/init can run /etc/rc.
> But in 5.0, both SI_SUB_DEVFS and SI_SUB_DRIVERS(GEOM) will be loaded before
> the SI_SUB_ROOT_CONF. Both of them will initial, specail GEOM, so they will
> create special device in '/dev'. why can we see those device after the
> system is normal.
> For example:
> mount /dev/ad0s2e /usr/share1
> mount /dev/ad0s1f /usr
> now, we can not see the '/dev/ad0s2e' filesystem context.
devfs has two parts. The first is a device registry of sorts.. things like
geom tell devfs that there will be a node called "ad0s2e". Later on it
also provides a mountable file system to export that data to the user
processes. This means that geom and drivers create nodes long before there
is a root file system and devfs remembers them for when /dev is finally
mounted.
> >No, unionfs is a stacked file system. For example, you could create a
> >read/
> >write layer stacked on top of a cdrom. This would allow you to create
> >files
> >which would end up in the top layer, but unmodified files could be read
> >from
> >the bottom layer. If you rm a file, a whiteout record gets created to make
> >it appear that the file got deleted from the cdrom etc.
> >Unfortunately, this works better in theory than in practice due to many
> >layering problems in our kernel and VM system that are still work in
> >progress. That is a whole different topic though.
> Now, I have a more understanding about it. If I want to learn more about
> that, where can I get info from internet? Could you commend some articles or
> documents about that?
Do some searches for "John Heidemann" and the "Ficus project".
> >There is no VOP_SET. I think you mean VFS_SET(). This connects the file
> >system itself to the kernel. VNODEOP_SET() connects the vnode descriptions
> >to the kernel.
> Sorry, I write a mistake.
> >
> >ufs/ffs are a mini-filesystem-stack. ffs provides the on-disk
> >infrastructure,
> >while ufs is layered on top of it to provide name space. This is quite
> >well
> >hidden though and is mostly a behind-the-scenes thing. At one point there
> >was
> >a log structured file system that shared a lot of code this way.
> >
> >The file systems provide multiple operation vectors due to the way
> >that device and named pipe nodes exist. For ufs/ffs, the actual connection
> >point for /dev/ttyv0 (for example) lived on disk. When the user opened
> >it, the file system would substitute the "normal" file based vectors for
> >the specfs vectors. That way, the vnode would behave like a device. And
> >the same goes for the fifo (named pipe) nodes.
> >For FreeBSD 5.0, we have a seperate file system for /dev, so the specfs
> >nodes in ufs/ffs are not normally used. But they do still work and are
> >sometimes used for jail(8) environments.
> Yes, I know in 5.0, we can use 'dev' filesystem. Based on DEVFS, when we
> create device, we usually call 'make_dev', in this function, we can create
> device in DEVFS through 'devfs_create_hook'. Or we destroy device in DEVFS
> through 'devfs_destroy_hook'.I think the DEVFS is special for 'device', I do
> not know why the DEVFS support both 'normal' and 'specfs'.
> I guess it we use normarl file operation such as 'ls' or 'find'in '/dev/',
> it use the 'normarl' vop; we use 'devfs rules', it use the 'special' vop,
> right?
> If I guess right, but the kernel how to know it should use which vop?
It is up to the file system to get it right. The normal procedure is to
use namei() which does VOP_LOOKUP() calls to each file system. As a side
effect of doing a lookup, the file system itself returns a "new" vnode
pointer that corresponds to the name being looked up. If we are using a
ufs/ffs file system then the fs code will set the operations vector in the
vnode iself to point to either the specfs or regular vop entries. See v_op
in struct vnode. For devfs and the seperate /dev case it is similar..
for devfs there are two types of vnodes.. The first is the "special"
device type (devfs_specop_entries[]), and the second is the vnodes that
are used for traversing the directory structure (directory files, symlinks
etc) - devfs_vnodeop_entries[]. The selection is done here:
error = getnewvnode("devfs", mp, devfs_vnodeop_p, &vp);
or
vp->v_op = devfs_specop_p;
If you have a look at vnode_if.c and vnode_if.h in the compile
directory, that should give a few more clues too. sys/kern/vfs_init.c
constructs the tables that these inlines use.
Cheers,
-Peter
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021207225338.0D2C12A7EA>