On Fri, 2008-11-28 at 10:19 +, Al Viro wrote:
> On Wed, Nov 26, 2008 at 08:04:39PM -0500, Oren Laadan wrote:
> > +int cr_scan_fds(struct files_struct *files, int **fdtable)
> > +{
> > + struct fdtable *fdt;
> > + int *fds;
> > + int i, n = 0;
> > + int tot = CR_DEFAULT_FDTABLE;
> > +
>
On Fri, 2008-11-28 at 10:53 +, Al Viro wrote:
>
> > +static int cr_ctx_checkpoint(struct cr_ctx *ctx, pid_t pid)
> > +{
> > + ctx->root_pid = pid;
> > +
> > + /*
> > + * assume checkpointer is in container's root vfs
> > + * FIXME: this works for now, but will change with rea
Document /proc/timer_list ABI, version 2.
This partially documents /timer_list, including the
proposed 'Version 0.5' extensions that add a jiffie timer
display.
v2 exists to address some of the concerns Michael Kerrisk
brought up. What was left out: I did not document old
versions of /timer_list
On Sat, 29 Nov 2008 15:49:07 -0800 Greg KH wrote:
> On Sun, Nov 30, 2008 at 12:42:07AM +0300, Alexey Dobriyan wrote:
> > On Sat, Nov 29, 2008 at 06:44:49PM +0100, Remi Colinet wrote:
> > > This patch add a new /proc/mempool file in order to display mempool usage.
> > >
> > > The feature can be di
On Fri, 2008-11-28 at 10:45 +, Al Viro wrote:
> On Wed, Nov 26, 2008 at 08:04:33PM -0500, Oren Laadan wrote:
> > +Currently, namespaces are not saved or restored. They will be treated
> > +as a class of a shared object. In particular, it is assumed that the
> > +task's file system namespace is
On Mon, 2008-12-01 at 10:12 -0800, Randy Dunlap wrote:
> On Sat, 29 Nov 2008 15:49:07 -0800 Greg KH wrote:
>
> > On Sun, Nov 30, 2008 at 12:42:07AM +0300, Alexey Dobriyan wrote:
> > > On Sat, Nov 29, 2008 at 06:44:49PM +0100, Remi Colinet wrote:
> > > > This patch add a new /proc/mempool file in o
On Fri, 2008-11-28 at 11:27 +, Al Viro wrote:
> On Wed, Nov 26, 2008 at 08:04:40PM -0500, Oren Laadan wrote:
> > +/**
> > + * cr_attach_get_file - attach (and get) lonely file ptr to a file
> > descriptor
> > + * @file: lonely file pointer
> > + */
> > +static int cr_attach_get_file(struct fil
On Mon, 01 Dec 2008 13:13:31 -0600
Matt Mackall <[EMAIL PROTECTED]> wrote:
> On Mon, 2008-12-01 at 10:12 -0800, Randy Dunlap wrote:
> > On Sat, 29 Nov 2008 15:49:07 -0800 Greg KH wrote:
> >
> > > On Sun, Nov 30, 2008 at 12:42:07AM +0300, Alexey Dobriyan wrote:
> > > > On Sat, Nov 29, 2008 at 06:4
On Mon, Dec 1, 2008 at 10:02 PM, Andrew Morton
<[EMAIL PROTECTED]> wrote:
> On Mon, 01 Dec 2008 13:13:31 -0600
> Matt Mackall <[EMAIL PROTECTED]> wrote:
>
>> On Mon, 2008-12-01 at 10:12 -0800, Randy Dunlap wrote:
>> > On Sat, 29 Nov 2008 15:49:07 -0800 Greg KH wrote:
>> >
>> > > On Sun, Nov 30, 200
On Mon, 1 Dec 2008, Pekka Enberg wrote:
>
> Hmm, I thought Documentation/ABI/ was supposed to tell us what's an
> ABI you can depend on and what's not. I mean, you shouldn't be
> depending on anything but the interfaces documented in
> Documentation/ABI/stable/, no?
Who is the f*cking MORON tha
On Mon, 1 Dec 2008, Linus Torvalds wrote:
>
> The fact that something is documented (whether correctly or not) has
> absolutely _zero_ impact on anything at all. What makes something an ABI
> is that it's useful and available. The only way something isn't an ABI is
> by _explicitly_ making su
Dave Hansen wrote:
> On Fri, 2008-11-28 at 10:19 +, Al Viro wrote:
>> On Wed, Nov 26, 2008 at 08:04:39PM -0500, Oren Laadan wrote:
>>> +int cr_scan_fds(struct files_struct *files, int **fdtable)
>>> +{
>>> + struct fdtable *fdt;
>>> + int *fds;
>>> + int i, n = 0;
>>> + int tot = CR_D
Dave Hansen wrote:
> On Fri, 2008-11-28 at 11:27 +, Al Viro wrote:
>> On Wed, Nov 26, 2008 at 08:04:40PM -0500, Oren Laadan wrote:
>>> +/**
>>> + * cr_attach_get_file - attach (and get) lonely file ptr to a file
>>> descriptor
>>> + * @file: lonely file pointer
>>> + */
>>> +static int cr_at
On Mon, 2008-12-01 at 15:23 -0500, Oren Laadan wrote:
> Verifying that the size doesn't change does not ensure that the table's
> contents remained the same, so we can still end up with obsolete data.
With the realloc() scheme, we have virtually no guarantees about how the
fdtable that we read rel
On Mon, 2008-12-01 at 15:41 -0500, Oren Laadan wrote:
> >>> + fd = cr_attach_file(file); /* no need to cleanup 'file' below */
> >>> + if (fd < 0) {
> >>> + filp_close(file, NULL);
> >>> + ret = fd;
> >>> + goto out;
> >>> + }
> >>> +
> >>> + /* register n
Dave Hansen wrote:
> On Fri, 2008-11-28 at 10:53 +, Al Viro wrote:
>>> +static int cr_ctx_checkpoint(struct cr_ctx *ctx, pid_t pid)
>>> +{
>>> + ctx->root_pid = pid;
>>> +
>>> + /*
>>> + * assume checkpointer is in container's root vfs
>>> + * FIXME: this works for now, but
Dave Hansen wrote:
> On Mon, 2008-12-01 at 15:41 -0500, Oren Laadan wrote:
> + fd = cr_attach_file(file); /* no need to cleanup 'file' below */
> + if (fd < 0) {
> + filp_close(file, NULL);
> + ret = fd;
> + goto out;
> + }
> +
On Mon, 1 Dec 2008, Dave Hansen wrote:
>
> Why is this done in two steps? It first grabs a list of fd numbers
> which needs to be validated, then goes back and turns those into 'struct
> file's which it saves off. Is there a problem with doing that
> fd->'struct file' conversion under the file
On Mon, 2008-12-01 at 16:00 -0500, Oren Laadan wrote:
> > Is that sufficient? It seems like we're depending on the fd's reference
> > to the 'struct file' to keep it valid in the hash. If something happens
> > to the fd (like the other thread messing with it) the 'struct file' can
> > still go aw
Dave Hansen wrote:
> On Mon, 2008-12-01 at 15:23 -0500, Oren Laadan wrote:
>> Verifying that the size doesn't change does not ensure that the table's
>> contents remained the same, so we can still end up with obsolete data.
>
> With the realloc() scheme, we have virtually no guarantees about how
On Mon, 2008-12-01 at 13:02 -0800, Linus Torvalds wrote:
> On Mon, 1 Dec 2008, Dave Hansen wrote:
> >
> > Why is this done in two steps? It first grabs a list of fd numbers
> > which needs to be validated, then goes back and turns those into 'struct
> > file's which it saves off. Is there a prob
Hi Linus,
On Mon, 1 Dec 2008, Pekka Enberg wrote:
>> Hmm, I thought Documentation/ABI/ was supposed to tell us what's an
>> ABI you can depend on and what's not. I mean, you shouldn't be
>> depending on anything but the interfaces documented in
>> Documentation/ABI/stable/, no?
On Mon, Dec 1, 200
On Tue, 2008-12-02 at 00:02 +0200, Pekka Enberg wrote:
> Hi Linus,
>
> On Mon, 1 Dec 2008, Pekka Enberg wrote:
> >> Hmm, I thought Documentation/ABI/ was supposed to tell us what's an
> >> ABI you can depend on and what's not. I mean, you shouldn't be
> >> depending on anything but the interfaces
On Mon, 2008-12-01 at 16:00 -0500, Oren Laadan wrote:
> Dave Hansen wrote:
> > On Mon, 2008-12-01 at 15:41 -0500, Oren Laadan wrote:
> > + fd = cr_attach_file(file); /* no need to cleanup 'file' below
> > */
> > + if (fd < 0) {
> > + filp_close(file, NULL);
> >>>
On Mon, 2008-12-01 at 13:07 -0800, Dave Hansen wrote:
> > When a shared object is inserted to the hash we automatically take another
> > reference to it (according to its type) for as long as it remains in the
> > hash. See: 'cr_obj_ref_grab()' and 'cr_obj_ref_drop()'. So by moving that
> > call
On Tue, 2 Dec 2008, Pekka Enberg wrote:
>
> OK, but why do we have those different ABI "stages" in
> Documentation/ABI then? The README file there seems to contradict what
> you say. Or maybe I'm reading it wrong...
I think that whole Documentation/ABI stuff is utter tosh, and should just
be t
Hi All,
Let me first apologise if I am posting this to the wrong mailing list, I
have never done any official kernel hacking before, so I am a little
lost as to where I should send things.
I am a self taught programmer working in many languages for over 15
years now. I have been writing a server
27 matches
Mail list logo
