Date: Mon, 27 May 2002 11:51:00 +0200 From: Andy Sporner <sporner@nentec.de> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-hackers <freebsd-hackers@FreeBSD.ORG> Subject: Re: Can I get some comment on my RFC??? Message-ID: <3CF20184.8000302@nentec.de> References: <3CEDFEEB.30305@nentec.de> <3CEEA7C4.B08415DD@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: >Andy Sporner wrote: > >>Hi Hackers, >> >>I would really like to have some input otherwise I might consider how >>usefull my >>participation on this list really is... >> > >Well, far be it for me not to comment, particularly if the lack of >comments could hinder your future participation... > I had the impression, thought it is rapidly diminishing that only certain people make impacts. I guess it is all about how to ask the question ;-) > >To me, this looks like a partial implementation of resource >containers, with the ability to put each process into an >arbitrary resource group > > >If your need is to track all processes owned by "init", which is >what you say, then really, you are trying to solve a much >smaller problem than the patches you give solve. > It's possible I incorrectly stated the problem. I needed a container system to track an application (which might include daemon processes that normally attach themselves to init as a parent, or change their Group id) in a way they could not shake off the tagging. The idea was in the cluster software to guage how much resources (by walking the process table and adding up the resources (CPU for example)). This was to be used to find the best node to (re)start an application on failure of a node or on the initial start of the application. My initial approach was very static (no such patch) and it worked, but not well enough. For the sake of brevity, I wanted use the actual usage against the configured limit (a soft limit) to make decision on where to (re)start an application. I spent about 3 hours one afternoon in one of my better hacking moods putting this together. > >However, I think your patches are really very useful. > Coming from you, I take high regard from this, thanks! > >Obviously, you could do this by GID, instead, if your different >classes of "demanding users" ran under different default GIDs; >and since an applicaiton could run under a GID via a single >system call, and since it's required to make a system call to >run under a different "application ID"... > >I'm not really positive that you've done anything that's really >orthogonal to the default GID, in terms of providing additional >information -- with the exception of the inheritance. > That's the point, inheritance (and as I said I want this to be the stuff the process can not shake off it's feet--without knowledge of how). > >I would suggest that you restrict access to the cse_set_id(2) >call. I would also suggest that you change it's name, and make >it a mux system call: it's likely that people are going to find >all sorts of things they want to do with the value of this; an >obvious one will be "getcseid", and another obvious one will be >"getpcseid" (this latter is lacking for groups; thus your ID >bears the same relationship to GID as UID bears to GID; i.e. it's >an orthogonal credential value). > I agree, I will do this. I also agree this this should be make as universal as possible. The only sticking point *might* be the other members of the structure that will be later used for process migration (as in Mosix). I have a working approach to failing over network sockets, though lacking in implementation. With this hardware device I am making that can switch the sheer number of trafic, I will use it as a front-end to a cluster and as part of the "migration" the registration of the endpoint will be changed on the "front-end". On another point of usage, it could be a good way of tracking affinity of resources (as with process migration) so you don't have cross-node page fault wars (IE: Shared memory), so that if you move one process, you would have to move all in the group. I would like to start a dialog on this, but yes, I know the cluster list would be the right place ;-) BTW: CSE stands for (Clustered System Environment) so a name change would be very much needed to support a generic case. Perhaps the best thing is to split the patch into two and place the other members in another structure (since it is likely to grow) and perhaps if this patch is usefull it would be good to have it without having to have the clustering stuff too. > *** Many other good points *** Thanks for your import--that was the goal of my 'RFC'. Now I have enough to go back and do some more work on it. I will post the new changes to my website later this week along with another piece of candy (graphical top), which was another piece salvaged from my clustering stuff. It's not clear if I will continue this clustering project for many reasons (mostly time related), days seem like months when I say I will put things out and I am sure there are those that think it doesn't exist at all. So this way I can do things more incrementally if at all. Best Regards -Andy 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?3CF20184.8000302>