So 2.6.39-rc1 is out there, and the merge window is closed. I still
have to look over the cleancache pull request (which I got in plenty
of time, but decided that I want to review after the merge window
craziness is over), but other than that, we're done.
What to say about the merge window? It _feels_ like it was all
drivers, filesystems and irq cleanups. The dirstat backs up the
drivers part (65%), but claims that we had way more arch updates than
filesystem stuff (and the bulk of that is ARM, and while _some_ of
that was the irq conversions, most of it is just the normal board
churn). On the arch side, the first steps of unifying m68k and
m68knommu is a nice sign, let's see how that all pans out in the long
run. Oh, and there's the new unicore32 architecture.
Elsewhere, we had a fair amount of VFS cleanup, and also introduced
the "filehandle" interfaces (along with open(..,O_PATH)). Although
most people won't care.
Perhaps a bit more interesting to a larger part of the kernel
community is the new block device plugging model - it makes plugging a
per-thread thing and cleaned up the code considerably. It also avoids
lots of locking in a very hot path, and should generally be a really
good idea. That said, it also at one point ate XFS filesystems for
breakfast, but that's fixed and it's hopefully all good now.
Anything else? I'm sure I've forgotten something really exciting. But
on the whole I think this should be one of those "solid, boring
progress" releases.
Knock wood. I like boring.
Linus
On Tue, Mar 29, 2011 at 02:07:35PM -0700, Linus Torvalds wrote:
> So 2.6.39-rc1 is out there, and the merge window is closed. I still
> have to look over the cleancache pull request (which I got in plenty
> of time, but decided that I want to review after the merge window
> craziness is over), but other than that, we're done.
FYI, strong no for me for this one. None of the comments why it's
utterly wrong have been addresses, and it hasn't even been posted
a single time for review in this merge window.
On Wed, Mar 30, 2011 at 08:01:51AM -0400, Christoph Hellwig wrote:
> On Tue, Mar 29, 2011 at 02:07:35PM -0700, Linus Torvalds wrote:
> > So 2.6.39-rc1 is out there, and the merge window is closed. I still
> > have to look over the cleancache pull request (which I got in plenty
> > of time, but decided that I want to review after the merge window
> > craziness is over), but other than that, we're done.
>
> FYI, strong no for me for this one. None of the comments why it's
> utterly wrong have been addresses, and it hasn't even been posted
<scratches his head>
The one I see is from V3, which was: "but no actual users.". There is code
in zcache (drivers/staging/zcache), and naturally the Xen one that utilize
this API (part of the cleancache API). I am probably missing other ones?
If you meant by "users" real human, there are also reports of folks using it
in Gentoo/SLES, and Oracle's own distro of course. Don't know what the
development version of Gentoo/SLES has right now.
> a single time for review in this merge window.
Nothing in API changed since the last posting:
http://lkml.org/lkml/2010/9/3/383
and linux-next had been working with this patchset.
(you might better using http://archive.eqmx.net/btrfs/Sep10/index.html#msg4439)
to see the thread.
It probably would have been better to repost this "for 2.6.39 review"
but since Andrew Morton put this patchset in his branch it seemed
like it wasn't necessary.
On Wed, Mar 30, 2011 at 10:43:59AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 30, 2011 at 08:01:51AM -0400, Christoph Hellwig wrote:
> > On Tue, Mar 29, 2011 at 02:07:35PM -0700, Linus Torvalds wrote:
> > > So 2.6.39-rc1 is out there, and the merge window is closed. I still
> > > have to look over the cleancache pull request (which I got in plenty
> > > of time, but decided that I want to review after the merge window
> > > craziness is over), but other than that, we're done.
> >
> > FYI, strong no for me for this one. None of the comments why it's
> > utterly wrong have been addresses, and it hasn't even been posted
>
> <scratches his head>
> The one I see is from V3, which was: "but no actual users.". There is code
> in zcache (drivers/staging/zcache), and naturally the Xen one that utilize
> this API (part of the cleancache API). I am probably missing other ones?
Ah, I did: https://lkml.org/lkml/2010/8/20/266 has the full list which
I think had been addressed.
From: Randy Dunlap <[email protected]>
The msi-laptop driver uses input_*() and sparse_keymap_*() interfaces.
It should depend on the INPUT subsystem being present and select
INPUT_SPARSEKMAP so that those interfaces are present.
ERROR: "input_free_device" [drivers/platform/x86/msi-laptop.ko] undefined!
ERROR: "input_register_device" [drivers/platform/x86/msi-laptop.ko] undefined!
ERROR: "sparse_keymap_setup" [drivers/platform/x86/msi-laptop.ko] undefined!
ERROR: "input_allocate_device" [drivers/platform/x86/msi-laptop.ko] undefined!
ERROR: "sparse_keymap_report_event" [drivers/platform/x86/msi-laptop.ko] undefined!
ERROR: "input_unregister_device" [drivers/platform/x86/msi-laptop.ko] undefined!
ERROR: "sparse_keymap_free" [drivers/platform/x86/msi-laptop.ko] undefined!
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Matthew Garrett <[email protected]>
Cc: "Lee, Chun-Yi" <[email protected]>
---
drivers/platform/x86/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- lnx-2639-rc1.orig/drivers/platform/x86/Kconfig
+++ lnx-2639-rc1/drivers/platform/x86/Kconfig
@@ -187,7 +187,8 @@ config MSI_LAPTOP
depends on ACPI
depends on BACKLIGHT_CLASS_DEVICE
depends on RFKILL
- depends on SERIO_I8042
+ depends on INPUT && SERIO_I8042
+ select INPUT_SPARSEKMAP
---help---
This is a driver for laptops built by MSI (MICRO-STAR
INTERNATIONAL):
(1) it still has the totally stupid interface of a global dispatch table.
Either it does make sense to have different providers, in which
case you want the dispatch table on a per-superblock or whatever
granularity, or you really want just one and can have static calls
into it, and get rid of this whole layer
(2) it still requires totally pointless calls from local filesystem to
initialize a pool ID. The filesystem really should not need to
care about any of this.
(3) it's still lacking a good user submitted with it. And with that
I don't mean junk code shoved into staging where it's bitrotting.
It also has an entirely new bug, in that it assumes every inode has
a dentry on the alias list. Did you only ever test this with filesystem
that do not have export operations? Otherwise the no-dentry case should
be fairly trivial to trigger due the placement of the hooks.
And of course there's still no convincing use case for all of this.
On Tue, 29 Mar 2011 14:07:35 -0700, Linus Torvalds <[email protected]> wrote:
> So 2.6.39-rc1 is out there, and the merge window is closed.
Oops, I somehow missed this. Kernel must be getting boring.
If you're feeling generous, please pull. If not, I'll separate out the
one with CC:stable in it and send another request.
The following changes since commit 6aba74f2791287ec407e0f92487a725a25908067:
Merge branch 'irq-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip (2011-03-30 09:35:52 -0700)
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus.git master
Amit Shah (3):
virtio: Decrement avail idx on buffer detach
virtio_pci: Prevent double-free of pci regions after device hot-unplug
virtio: console: Enable call to hvc_remove() on console port remove
Christoph Hellwig (1):
virtio_blk: allow re-reading config space at runtime
Daniel J Blueman (1):
minor ANSI prototype sparse fix
Dmitry Torokhov (2):
module: deal with alignment issues in built-in module versions
module: do not hide __modver_version_show declaration behind ifdef
Richard Kennedy (2):
module: remove 64 bit alignment padding from struct module with CONFIG_TRACE*
module: reorder kparam_array to remove alignment padding on 64 bit builds
Rusty Russell (1):
virtio console: don't manually set or finalize VIRTIO_CONSOLE_F_MULTIPORT.
drivers/block/virtio_blk.c | 88 ++++++++++++++++++++++++++++++++++++-----
drivers/char/virtio_console.c | 16 -------
drivers/virtio/virtio_pci.c | 15 ++++---
drivers/virtio/virtio_ring.c | 1 +
include/linux/module.h | 28 +++++++------
include/linux/moduleparam.h | 7 ++-
kernel/module.c | 4 +-
kernel/params.c | 9 +++-
8 files changed, 114 insertions(+), 54 deletions(-)
Cheers,
Rusty.
於 三，2011-03-30 於 15:20 -0700，Randy Dunlap 提到：
> From: Randy Dunlap <[email protected]>
>
> The msi-laptop driver uses input_*() and sparse_keymap_*() interfaces.
> It should depend on the INPUT subsystem being present and select
> INPUT_SPARSEKMAP so that those interfaces are present.
>
> ERROR: "input_free_device" [drivers/platform/x86/msi-laptop.ko] undefined!
> ERROR: "input_register_device" [drivers/platform/x86/msi-laptop.ko] undefined!
> ERROR: "sparse_keymap_setup" [drivers/platform/x86/msi-laptop.ko] undefined!
> ERROR: "input_allocate_device" [drivers/platform/x86/msi-laptop.ko] undefined!
> ERROR: "sparse_keymap_report_event" [drivers/platform/x86/msi-laptop.ko] undefined!
> ERROR: "input_unregister_device" [drivers/platform/x86/msi-laptop.ko] undefined!
> ERROR: "sparse_keymap_free" [drivers/platform/x86/msi-laptop.ko] undefined!
>
> Signed-off-by: Randy Dunlap <[email protected]>
> Cc: Matthew Garrett <[email protected]>
> Cc: "Lee, Chun-Yi" <[email protected]>
> ---
> drivers/platform/x86/Kconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> --- lnx-2639-rc1.orig/drivers/platform/x86/Kconfig
> +++ lnx-2639-rc1/drivers/platform/x86/Kconfig
> @@ -187,7 +187,8 @@ config MSI_LAPTOP
> depends on ACPI
> depends on BACKLIGHT_CLASS_DEVICE
> depends on RFKILL
> - depends on SERIO_I8042
> + depends on INPUT && SERIO_I8042
> + select INPUT_SPARSEKMAP
> ---help---
> This is a driver for laptops built by MSI (MICRO-STAR
> INTERNATIONAL):
> --
> To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Thank's, it's good to me!
Acked-by: "Lee, Chun-Yi" <[email protected]>
On Wed, Mar 30, 2011 at 06:29:09PM -0400, Christoph Hellwig wrote:
> (1) it still has the totally stupid interface of a global dispatch table.
> Either it does make sense to have different providers, in which
> case you want the dispatch table on a per-superblock or whatever
> granularity, or you really want just one and can have static calls
> into it, and get rid of this whole layer
> (2) it still requires totally pointless calls from local filesystem to
> initialize a pool ID. The filesystem really should not need to
> care about any of this.
Thank you for taking a look at the patches. I think what you are saying
is that the opt-in interface (where only those fs that want it) are using,
is not proper. It should be in for everybody? Hmm.. let me ponder this.
> (3) it's still lacking a good user submitted with it. And with that
> I don't mean junk code shoved into staging where it's bitrotting.
I think when one takes user cases and try to use one type of matrix (say,
how many customers are using it) but use another (how many enterprise
clients are clamoring for it) you get drastically different numbers.
If you just use one ruler to evaluate acceptance, then maybe
unicore32 (just one company), or ILO (small community compared to SCST)
should have not been merged b/c of that? But if you think of other
acceptance rules then it makes sense.
>
> It also has an entirely new bug, in that it assumes every inode has
> a dentry on the alias list. Did you only ever test this with filesystem
> that do not have export operations? Otherwise the no-dentry case should
> be fairly trivial to trigger due the placement of the hooks.
Aha! Thank you for spotting that. Dan did post a patch for this:
https://lkml.org/lkml/2011/3/3/291
And he should have pulled it in his tree <sigh> Will ask him to create
a branch with this bug-fix.
>
> And of course there's still no convincing use case for all of this.
Applied, thanks.
--
Matthew Garrett | [email protected]