Woo. thank you.From: Peter Wemm <[EMAIL PROTECTED]> Undefined. The bubble sort that orders these could leave it in any state.
In mi_startup(), the kernel will register those device/modules, and excute the 'func' declared by SYSINIT, right?
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.
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.
No, unionfs is a stacked file system. For example, you could create a read/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?
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.
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.
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'.
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.
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?
Thank you very much!
Best Regards
Ouyang Kai
_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
