Andrew Morton wrote:
The type-unsafety of existing list_heads gives me conniptions too. Yes,
it'd be nice to have a type-safe version available.
That being said, I don't see why such a thing cannot be a wrapper around
the existing list_head functions. Yes, there will be some ghastly
Hans Reiser [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
The type-unsafety of existing list_heads gives me conniptions too. Yes,
it'd be nice to have a type-safe version available.
[...]
Vladimir spent 24 hours straight unsafing the lists in reiser4, and
didn't finish yet. We need 1-2
Kyle wrote:
Sometimes cleverness can be even worse than ordinary abuse
I have a habit of commenting the code spots where it is not obvious
what is going on.
Someday I am going to learn that everytime I feel the compulsion
to write a Watch out ! or Beware ! or Must ! code comment,
it probably
Chris Shoemaker wrote:
On Fri, Sep 09, 2005 at 10:36:06AM -0700, Hans Reiser wrote:
If we lose every remaining point of this list, we can generate a patch
in a few days, because the VFS work was the only substantive (in coding
hours) task, and it is done. Do I remember right that the
On 9/9/05, Hans Reiser [EMAIL PROTECTED] wrote:
Chris Shoemaker wrote:
On Fri, Sep 09, 2005 at 10:36:06AM -0700, Hans Reiser wrote:
If we lose every remaining point of this list, we can generate a patch
in a few days, because the VFS work was the only substantive (in coding
hours) task,
On Fri, 9 Sep 2005, Hans Reiser wrote:
Chris Shoemaker wrote:
On Fri, Sep 09, 2005 at 10:36:06AM -0700, Hans Reiser wrote:
If we lose every remaining point of this list, we can generate a patch
in a few days, because the VFS work was the only substantive (in coding
hours) task, and it
On Fri, Sep 09, 2005 at 01:42:19PM -0700, Hans Reiser wrote:
Chris Shoemaker wrote:
On Fri, Sep 09, 2005 at 10:36:06AM -0700, Hans Reiser wrote:
If we lose every remaining point of this list, we can generate a patch
in a few days, because the VFS work was the only substantive (in
Christoph Hellwig wrote:
6. remove type safe lists and type safe hash queues.
not done, it is not clear that the person asking for this represents a
unified consensus of lkml. Other persons instead asked that it just be
moved out of reiser4 code into the generic kernel code, which
We haven't been sending much email out, but we have been working away.
We just finished the VFS work, and will send a patch out on Monday.
akpm asked for a bullet list of things suggested on lkml as issues for
inclusion.
There are some things that I would like akpm to confirm represent the
On Fri, Sep 09, 2005 at 10:36:06AM -0700, Hans Reiser wrote:
If we lose every remaining point of this list, we can generate a patch
in a few days, because the VFS work was the only substantive (in coding
hours) task, and it is done. Do I remember right that the submission
deadline is a week
On Fri, Sep 09, 2005 at 10:36:06AM -0700, Hans Reiser wrote:
1. pseudo files or files
disabled. It remains a point of (extraordinary) contention as to whether
it can be fixed, we want to keep the code around until we can devote proper
resources into proving it can be (or until we
On Fri, Sep 09, 2005 at 07:57:40PM +0100, Christoph Hellwig wrote:
A very annoying small thing that comes to mind is the usage of
reiser4_internal. Please remove it, all but exported symbol are
module-private.
Oh, one other things that's totally annoying and makes reading the
code a pain are
Hans Reiser [EMAIL PROTECTED] wrote:
...
Do I remember right that the submission
deadline is a week from Monday for 2.6.14 inclusion?
Next week, supposedly.
But something like a brand new filesystem can go in pretty much any time,
as long as it compiles. Because it can't break anyone's
Andrew Morton wrote:
1. pseudo files or files
disabled. It remains a point of (extraordinary) contention as to
whether it can be fixed, we want to keep the code around until we can
devote proper resources into proving it can be (or until we fail to prove
it can be and
14 matches
Mail list logo
