Only for a re-open - which is very different to an initial open,
and /dev/tty is deep magic in this situation.
I guess I fail to understand something here, perhaps because I haven't
looked at the code in very much details for several years. How is there
not a 1:1 mapping between tty
On Mon, 25 Aug 2008 13:11:10 -0700
[EMAIL PROTECTED] wrote:
init_dev() is doing too many things all in one function, making it
harder to understand/extend. This and following two patches attempt
to simplify/cleanup the interface a bit.
Only touch tested at this point. Appreciate any
Daniel Lezcano wrote:
Eelco Chaudron wrote:
Hi Dave,
Guess it's useful when you are interested in network statistics per name
space. I'm currently evaluating how much of the name space implementation we
could use in one of our projects (see my other email to the group).
Any idea who
Eelco Chaudron wrote:
Hi Pavel,
Can you let me know where it's fixed? Looking at the 26.0 release I do not
see it (is there a patch)...
//Eelco
On 8/26/08 2:09 PM, Pavel Emelyanov [EMAIL PROTECTED] wrote:
Daniel Lezcano wrote:
Eelco Chaudron wrote:
Hi Dave,
Guess it's useful
Quoting Subrata Modak ([EMAIL PROTECTED]):
Serge,
I have another doubt. Are we also having the plan(s) to add testcases
for testing this new feature (Device whitelist on cgroups) added in
2.6.26 under the DEVICE NAMESPACE category !!
Regards--
Subrata
That's something I expect Veerendra
Serge E. Hallyn wrote:
Quoting Subrata Modak ([EMAIL PROTECTED]):
Serge,
I have another doubt. Are we also having the plan(s) to add testcases
for testing this new feature (Device whitelist on cgroups) added in
2.6.26 under the DEVICE NAMESPACE category !!
Regards--
Subrata
That's
Quoting Pavel Emelyanov ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting Subrata Modak ([EMAIL PROTECTED]):
Serge,
I have another doubt. Are we also having the plan(s) to add testcases
for testing this new feature (Device whitelist on cgroups) added in
2.6.26 under the DEVICE
On Sun, 2008-08-24 at 01:40 -0400, Oren Laadan wrote:
+/* vma subtypes */
+enum {
+ CR_VMA_ANON = 1,
+ CR_VMA_FILE
+};
Is this really necessary, or can we infer it from the contents of the
VMA?
This classification eventually simplifies both dump and restore. For
instance, it
Alan Cox wrote:
In the case of the initial open you don't yet know the tty pointer and
may be creating it. SO the tty isn't a reference because it doesn't exist.
Got it. I was under the (apparently mistaken) notion that only pty tty
structures were created dynamically.
-hpa
On Thu, 2008-08-21 at 12:40 +0200, Louis Rilling wrote:
+struct cr_objhash {
+ struct cr_obj **hash;
+ int next_tag;
+};
+
+#define CR_OBJHASH_NBITS 10 /* 10 bits = 1K buckets */
+#define CR_OBJHASH_ORDER 0 /* 1K buckets * 4 bytes/bucket = 1
page */
Only true when
On Tue, 26 Aug 2008 09:40:20 -0700
H. Peter Anvin [EMAIL PROTECTED] wrote:
Alan Cox wrote:
In the case of the initial open you don't yet know the tty pointer and
may be creating it. SO the tty isn't a reference because it doesn't exist.
Got it. I was under the (apparently mistaken)
Alan Cox wrote:
On Tue, 26 Aug 2008 09:40:20 -0700
H. Peter Anvin [EMAIL PROTECTED] wrote:
Alan Cox wrote:
In the case of the initial open you don't yet know the tty pointer and
may be creating it. SO the tty isn't a reference because it doesn't exist.
Got it. I was under the (apparently
On Mon, Aug 25, 2008 at 10:22 PM, Lai Jiangshan [EMAIL PROTECTED] wrote:
But improving the current code has been on my todo list for a while.
My thought on the best way to fix it is to use a proper seq_file -
that would remove the issues that you have currently with the
unconsumed portion of
On Mon, Aug 25, 2008 at 10:22 PM, Lai Jiangshan [EMAIL PROTECTED] wrote:
It's complicated than necessary and change too much code IMO.
What about the problem that maintaining a single pid array can still
fail for a really large cgroup? I guess we could just say don't
create such large cgroups
Dave Hansen wrote:
On Sun, 2008-08-24 at 01:40 -0400, Oren Laadan wrote:
+/* vma subtypes */
+enum {
+ CR_VMA_ANON = 1,
+ CR_VMA_FILE
+};
Is this really necessary, or can we infer it from the contents of the
VMA?
This classification eventually simplifies both dump and restore. For
Dave Hansen wrote:
On Sun, 2008-08-24 at 22:47 -0400, Oren Laadan wrote:
I replaced all of the uses of these with kmalloc()/kfree() and stack
allocations. I'm really not sure what these buy us since our allocators
are already so fast. tbuf, especially, worries me if it gets used in
any
16 matches
Mail list logo
