Re: 2.6.21-ext4-1
- From: Theodore Tso <tytso@xxxxxxx>
- Date: Mon, 30 Apr 2007 13:45:30 -0400
On Mon, Apr 30, 2007 at 01:16:19PM -0400, Jeff Garzik wrote:
Why isn't this stuff going upstream rapidly?
Some of the patches are ready to be pushed upstream, and that will be
happening shortly.
In the case of the fallocate patches, the system call interface hadn't
been completely closed, so we don't want to push it until we have
closure and consensus. The previous versions of the patches used an
ioctl interface that would have gotten potshots from the
all-ioctls-are-evil camp, and it was clear that a unified system call
interface was the right thing. So we wanted to make sure the XFS
folks were happy with the interface as well before we pushed it.
In general, yes, ext4 development has been a little slow; part of the
problem is that we have a lot of people, but a number of folks are new
and their patches need review before they are ready for upstream
acceptance, and a number of other folks who should be doing the review
have been overloaded with multiple other projects and have been
time-sharing.
The whole point of having ext4 in the kernel is to do development
upstream, in the public view, getting new stuff in ASAP (even if that
means changing or pulling some stuff later).
That's true, but we also get flamed when the patches don't meet
various criteria, up to and including breaking on ia64. We are in the
process of setting up automated testing to help address that problem,
but it's a taken a little while to get that going. I'm also trying to
schedule more time so I can do the needed review of the patches so
they meet basic upstream standards so we *can* push them. If other
folks would like to help with the review process, that would be more
than welcome.
But yes, we will try to get more of the patches pushed sooner rather
than later. Point taken.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- 2.6.21-ext4-1
- From: Theodore Ts'o
- Re: 2.6.21-ext4-1
- From: Jeff Garzik
- 2.6.21-ext4-1
- Prev by Date: Revert "[POWERPC] <various>"
- Next by Date: [4/6] go BUG on vmallocspace in __pa() (was: Re: [-mm patch] i386: enable 4k stacks by default)
- Previous by thread: Re: 2.6.21-ext4-1
- Next by thread: Re: [patch 3/9] AVR32: Spinlock initializer cleanup
- Index(es):
Relevant Pages
- Re: [patch 00/17] multi size, and giant hugetlb page support, 1GB hugetlb for x86
... > only with just 1G hugepages, though, we haven't yet taught ... Yes I don't
like the proc interface, nor the way it has been extended ... the per-node nr_hugepages).
... >> The other thing I did was try to shuffle the patches around a bit. ...
(Linux-Kernel) - [RFC] Changes to the driver model class code.
... start us on the way toward cleaning up the driver model code so that ... of
interface for the main class code itself. ... taken his tty and input patches that
convert those subsystems over to ... So I'll be slowly converting the kernel over to using
this new ... (Linux-Kernel) - Re: [ANNOUNCE] hotplug-ng 002 release
... Or just send those patches earlier:) ... > ended up ignoring the interface
bits altogether. ... as this patch ... send the line "unsubscribe linux-kernel"
in ... (Linux-Kernel) - Re: [ANNOUNCE] hotplug-ng 002 release
... > Or just send those patches earlier:) ... >> ended up ignoring the
interface bits altogether. ... > a USB device, but by the time these files are
created, it should be fine ... send the line "unsubscribe linux-kernel" in ... (Linux-Kernel) - Re: mapping PCI registers with write combining (and PAT on x86)...
... already handles this for the architectures that currently support it. ... BIOS
to know which page protections are good. ... interface to use PATs instead. ...
No one had any serious objections to my patches as they were. ... (Linux-Kernel)
