Date: Fri, 4 Mar 2005 17:33:09 -0800 (PST) From: Yan Yu <yanyu@CS.UCLA.EDU> To: FreeBSD-Hackers <hackers@freebsd.org> Subject: filedesc struct in filedesc.h Message-ID: <Pine.GSO.4.58.0503040821570.3051@panther.cs.ucla.edu> In-Reply-To: <42288070.8030507@telus.net> References: <BE4E0FDD.1A486%tomonage2@gmx.de> <42288070.8030507@telus.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, all, I have a Q on filedesc.h: i am wondering whether the order of the field in struct _filedesc_ (in sys/filedesc.h) matters? I added a field to _filedesc_ struct in filedesc.h. It is a dynamically allocated list, just as fd_ofiles, or fd_ofilefalgs. I put my new added list right after fd_fileflags, and allocate/initialize it just as fd_ofiles or fd_ofileflags. Even if I put little of my extra code in except this data field, and codes to allocate and initialize it ( i put it in fdgrowtable(), just as the existing kernel initialize fd_ofiles, or fd_ofileflgs. (i believe i did this allcaotion/initialization part right:) the problem i had is page fault and then crashes the kernel. If I put my extra data fields at the end of _filedesc_ or _filedesc0_ struct, it then works.. My Q is: is there places in the kernel that not directly use the field name to access a member of "filedesc" struct, but implicitly assuming the ordering of the fields in "strcut filedesc", e.g., they may use offset to access a field? so then my new added field may mess up the original code? I found one such place in fdgrowtable() in kern_descrip.c there is one such line: ------------------------------------------ nfileflags = (char *)&ntable[nnfiles]; ------------------------------------------ so it allocates and assumes that fd_ofileflags is right after fd_ofiles in _filedesc_ struct. I am curious is there other places in the kernel that implicitly use the info on the order that those fields are defined? i hope my Q makes sense.. many thanks, yan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.58.0503040821570.3051>