Date: Sat, 07 Dec 2002 12:08:00 +0800 From: "ouyang kai" <oykai@msn.com> To: peter@wemm.org Cc: hackers@FreeBSD.org Subject: Re: One Filesystem vnode operations declare problem. Message-ID: <F28mtViNCm2v94hwUaW000185fe@hotmail.com>
next in thread | raw e-mail | index | archive | help
>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? 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/ >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? >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? 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 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?F28mtViNCm2v94hwUaW000185fe>