The 2.6.37 kernel is out [LWN.net]

Linus Torvalds has released the 2.6.37 kernel. Not much has changed since the 2.6.37-rc8 prepatch, just some VFS locking documentation updates, ASoC codex register cache changes, and "small and boring" fixes. There has been a revert to fix "hopefully the last 'blank screen' regression on intel graphics". New features in 2.6.37 include "tiny preempt RCU", more BKL removal work, getting rid of barriers in the block subsystem, much of the Xen Dom0 support, fanotify has been re-enabled, and more. See the KernelNewbies 2.6.37 page for lots more information. "As to the big picture, on the whole I think 2.6.37 has been fairly calm. That will likely change with the merge window, as I'm looking forward to getting the new RCU-based pathname lookup and similar exciting features. So enjoy the calm sanity while it lasts."

to post comments

The 2.6.37 kernel is out

Posted Jan 5, 2011 4:04 UTC (Wed) by foom (subscriber, #14868) [Link] (7 responses)

So, does that mean fanotify can actually do something useful now, like monitor changes in a directory tree? Is a superset of inotify yet?

Last I looked, it couldn't notify on addition or removal of a file in a directory, which seems to me to make it just about completely useless for everything other than a "virus scanner". And I *really* don't understand how the heck a new API which is very similar to inotify, yet has a mostly-overlapping-but-slightly-different set of features got accepted. If you want both sets of features, what, you should just use both file watch APIs at the same time? Come on.

Anyone want to explain to me how this isn't a complete disaster?

The 2.6.37 kernel is out

Posted Jan 5, 2011 4:48 UTC (Wed) by JohnLenz (guest, #42089) [Link] (2 responses)

You can see file addition by watching for OPEN events. For deletion, how would that work? fanotify is a file monitoring interface, not a path monitoring interface. How would you deal with hardlinks? What if a file is hardlinked into two paths in a directory and one of the hardlinks is removed, would you still create an event? What about if the file is unlinked but a program still has an open file descriptor? Also, fanotify passes you a file descriptor so the file couldnt't be deleted yet when you receive the delete event. Remember, the file is not deleted until all file descriptors are closed.

It sounds like we should perhaps have an API for path monitoring events or something which shows path events like creating hard links, creating soft links, unlinking, renaming, etc. But I see no reason why this should be done in fanotify, since fanotify is a file change interface

The 2.6.37 kernel is out

Posted Jan 5, 2011 5:36 UTC (Wed) by foom (subscriber, #14868) [Link]

> For deletion, how would that work?

I'm confused as to why you would ask this: it's not like that's an brand new feature -- these things **already work in inotify**. The new features of fanotify are nice (especially the recursive watch, but also the presence of a pid field, and it being able to hand you an open fd), but why did that come at the expense of the features inotify already had?

So I guess I still have no idea what fanotify is really useful for as it stands. I thought it could be a better interface for doing a real-time-rsync, or doing backups of your whole disk, or perhaps a file indexer (doing manual recursion with inotify for a whole disk is kind of a pain, and leads to lost events...). But it can't be used for any of that.

So, it's not at all a better inotify. It's something completely different with a bunch of features lots of people wish inotify had, but without the features people already use (and need) in inotify.

The 2.6.37 kernel is out

Posted Jan 5, 2011 7:02 UTC (Wed) by ncm (guest, #165) [Link]

Directories are files. Deleting a file or link means changing the directory the file was linked from.

The 2.6.37 kernel is out

Posted Jan 5, 2011 14:19 UTC (Wed) by mezcalero (subscriber, #45103) [Link] (3 responses)

fanotify is useful for at least three use cases where inotify wasn't useful at all: for indexers/crawlers, for readahead implementations, and for antivirus solutions. All these three need recursive looks and in the last case synchronous events. fanotify delivers that, inotify doesn't.

Right now, inotify is a lot more useful when watching particular directories (i.e. a nautilus window which shall be a live view on some directory), for most other things fanotify is the better choice.

The 2.6.37 kernel is out

Posted Jan 5, 2011 15:36 UTC (Wed) by foom (subscriber, #14868) [Link] (2 responses)

I don't see how you can possibly use it for an indexer. Of course, recursive watches are a great idea -- and if they were added on top of the functionality inotify provided, that'd be wonderful. Users have been asking for that for a long time.

But, for an index generated by the indexer to be useful, it needs to be able to tell the user where the file with the searched-for-content is located -- so it needs to be notified about renames too, which fanotify doesn't provide. Am I wrong?

Boot-time readahead and antivirus is such a narrow solution-space that I don't see how this whole new infrastructure and API is justified if it can only really be used for those two things.

The 2.6.37 kernel is out

Posted Jan 5, 2011 18:18 UTC (Wed) by larryr (guest, #4030) [Link] (1 responses)

Can renames be detected via directory changes, similar in some sense to git rename "detection"?

The 2.6.37 kernel is out

Posted Jan 6, 2011 3:03 UTC (Thu) by foom (subscriber, #14868) [Link]

I do not have a 2.6.37 kernel installed to test, but my understanding is that renames cause no events to be emitted at all.

Black screen on intel graphics

Posted Jan 5, 2011 6:49 UTC (Wed) by ncm (guest, #165) [Link]

"hopefully the last 'blank screen' regression on intel graphics".

Linus has such a droll sense of humor.

The 2.6.37 kernel is out

Posted Jan 5, 2011 16:15 UTC (Wed) by ufa (subscriber, #56005) [Link] (3 responses)

First thing in kernel Newbies: Linux 2.6.37 not released yet.

bump

The 2.6.37 kernel is out

Posted Jan 5, 2011 18:43 UTC (Wed) by jthill (subscriber, #56558) [Link] (2 responses)

jthill@gadabout:~/src/linux-2.6$ git fetch remote: Counting objects: 126, done. remote: Compressing objects: 100% (87/87), done. remote: Total 87 (delta 69), reused 0 (delta 0) Unpacking objects: 100% (87/87), done. From git://github.com/mirrors/linux-2.6 989d873..3c0eee3 master -> origin/master * [new tag] v2.6.37 -> v2.6.37 jthill@gadabout:~/src/linux-2.6$

The 2.6.37 kernel is out

Posted Jan 6, 2011 0:10 UTC (Thu) by cowsandmilk (guest, #55475) [Link] (1 responses)

more than like he was trying to get someone at KernelNewbies to update their page, not express disbelief that it was released...

The 2.6.37 kernel is out

Posted Jan 6, 2011 17:22 UTC (Thu) by jthill (subscriber, #56558) [Link]

mmm. yeah, it seemed odd anyone would question it.

The 2.6.37 kernel is out

Posted Jan 6, 2011 1:55 UTC (Thu) by bronson (subscriber, #4806) [Link]

The H has had a good series of articles on what's new in 2.6.37 too:

http://www.h-online.com/open/features/What-s-new-in-Linux...

The 2.6.37 kernel is out

Posted Jan 8, 2011 21:39 UTC (Sat) by TheExplorer (guest, #72266) [Link]

I'm seeing some errors across the screen while trying to disable some usual things for my hardware since I do not use them, for e.g. AGP Support (Device Drivers -> Graphical Settings). Can anyone confirm this?