The 2.6.37 kernel is out
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."
Posted Jan 5, 2011 4:04 UTC (Wed)
by foom (subscriber, #14868)
[Link] (7 responses)
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?
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
Posted Jan 5, 2011 5:36 UTC (Wed)
by foom (subscriber, #14868)
[Link]
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.
Posted Jan 5, 2011 7:02 UTC (Wed)
by ncm (guest, #165)
[Link]
Posted Jan 5, 2011 14:19 UTC (Wed)
by mezcalero (subscriber, #45103)
[Link] (3 responses)
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.
Posted Jan 5, 2011 15:36 UTC (Wed)
by foom (subscriber, #14868)
[Link] (2 responses)
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.
Posted Jan 5, 2011 18:18 UTC (Wed)
by larryr (guest, #4030)
[Link] (1 responses)
Posted Jan 6, 2011 3:03 UTC (Thu)
by foom (subscriber, #14868)
[Link]
Posted Jan 5, 2011 6:49 UTC (Wed)
by ncm (guest, #165)
[Link]
Linus has such a droll sense of humor.
Posted Jan 5, 2011 16:15 UTC (Wed)
by ufa (subscriber, #56005)
[Link] (3 responses)
bump
Posted Jan 5, 2011 18:43 UTC (Wed)
by jthill (subscriber, #56558)
[Link] (2 responses)
Posted Jan 6, 2011 0:10 UTC (Thu)
by cowsandmilk (guest, #55475)
[Link] (1 responses)
Posted Jan 6, 2011 17:22 UTC (Thu)
by jthill (subscriber, #56558)
[Link]
Posted Jan 6, 2011 1:55 UTC (Thu)
by bronson (subscriber, #4806)
[Link]
http://www.h-online.com/open/features/What-s-new-in-Linux...
Posted Jan 8, 2011 21:39 UTC (Sat)
by TheExplorer (guest, #72266)
[Link]
The 2.6.37 kernel is out
The 2.6.37 kernel is out
The 2.6.37 kernel is out
The 2.6.37 kernel is out
The 2.6.37 kernel is out
The 2.6.37 kernel is out
The 2.6.37 kernel is out
The 2.6.37 kernel is out
"hopefully the last 'blank screen' regression on intel graphics".
Black screen on intel graphics
The 2.6.37 kernel is out
The 2.6.37 kernel is out
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
mmm. yeah, it seemed odd anyone would question it.
The 2.6.37 kernel is out
The 2.6.37 kernel is out
The 2.6.37 kernel is out