Date: Tue, 21 May 2002 03:09:02 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Andy Sporner <sporner@nentec.de> Cc: hackers@FreeBSD.ORG Subject: Re: Is there an accepted "norm" on how to add members to the kernel 'PROC' structure? Message-ID: <3CEA1CBE.4E622500@mindspring.com> References: <20020520195834.GA54960@elvis.mu.org> <3CEA1179.7090308@nentec.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Andy Sporner wrote: > Hello Hackers, > > I have a need to add a structure to "proc" structure for additional > statistics for my clustering > project. > > Is this a 'holy' structure where such an addition is possible? Are > there limitations? > > Suggestions? I ran into needing to do this for a port of the Rice University LRP code (the older code which wasn't made totally unusable as a default part of FreeBSD by the obnoxious license changes). Basically, I needed to add packet queues to the proc struct (this actually ended up not being really necessary, later, when I figured out how to run an "accept" to completion without a proc struct handy to dereference the credential from). The way they did it was pretty lame: they changed the size of the allocated structure, and then cast it only where they needed to care about the pointers in the extra storage (they didn't even use the real queue macros for the things, maintaining their own linked list code). Basically, you want to be able to add an extension block to any procy structure, and it should have a "type" field and a "next" pointer as the first elements, which you then used to pull your data out of the thing. Ideally, what you would do is reallocate the structure, and then allocate the data in the reallocated part (only if it were a fixed size, I suppose). Doing this uniformly is a hard thing to do for more than one extension (but it *is* possible, if you include a "size" field, at the loss of being able gto use a single zone for all such allocations). Which way you want to go really depends on whether or not *every* proc needs the data, or if it's a sparse allocation thing. In my case, I had to actually end up modifying the allocation for the template itself. The Rice University code failed to do this, actually, so if the active process was the template (e.g. you got an interrupt in the middle of the fork code), you could get screwed by referencing kernel data immediately following the static proc struct declaration (in init_main.c). So if you *do* go that way, remember to declare proc0 to be the other type, and then cast it to the right type, so that it has the larger data area it needs. IMO, you are better off doing the generic extension mechanism, and biting the bullet on the overhead. The linear search of the unordered list for the extension segments in this appraoch is expensive, so it quickly becomes a bad idea for any segment accessed more than a 1:3 as the rest of the proc struct data, and it really bites if everyone starts adding extensions, and the list gets more than one or two entries long. If you expect that, then maybe overallocate the things to start with, and eat the empty space overhead when not using your extensions, instead. This isn't a very easily extensible area of FreeBSD. Anything you do will screw you on "ps" and "libkvm", at least the first time, though. Makes the generic mechanism a one-shot pain. 8-(. -- Terry 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?3CEA1CBE.4E622500>