Robert Love, well known figure for his kernel hacking, preemptive patch and his recent book (review), joined Ximian recently in an effort to improve the Linux desktop experience via kernel development. Today we feature a mini-Q&A with Robert about this new project.1. You are going to be working on kernel and system-level projects to improve the Linux desktop experience. What does that exactly mean? What these projects are and how will they help the desktop users?
Robert Love: There is no specific definition of what I want to accomplish, because it is my mandate to do whatever is necessary at the kernel and system-level to improve the quality of desktop Linux and thereby take Linux on the desktop to new levels.
Some of my first projects are going to include:
* Hardware integration. The kernel does hardware pretty well right now, but the integration with user-space needs work. For example, applications and the desktop have no knowledge of hardware events, sans polling. A cohesive solution is needed for device management, naming, hotplugging, and integration with the desktop. The solution will involve a lot of different players: at least hotplug, udev, HAL, and D-BUS. Some sort of desktop component, providing a policy manager, events layer, and notification system, will be needed on top. Applications will then interface with this component and libhal, HAL’s library. The user will interface with the desktop component, which will provide policy. One example policy might be, what to do when the user plugs in a camera or inserts a new CD. We should be doing cool stuff, like asking the user if they want to copy their photos to a new album.
* Kernel events layer. We need a simple, low overhead, fast communication channel from the kernel out to user-space, to communicate everything from device status (“your processor is overeating”) to system events (“a new volume has been mounted”). I do not want to reinvent the wheel here, however. I think netlink (an existing socket-based high-speed communication layer in the kernel) forms the perfect kernel-side to the solution. We just need an abstraction and interface on top of it. For the user side of things, D-BUS is the obvious candidate. We definitely want to format the messages to be D-BUS capable, but I think we want to remain agnostic toward which user-space messaging system we actually require.
* Desktop tuning. This includes things such as tuning the kernel to provide a highly responsive and very low latency desktop environment, using things such as the CFQ I/O scheduler, and making sure that desktop and “normal sane machine” performance remains a priority and is not allowed to regress.
Other things are important, too:
* Better X and 3D support.
* A strict insistence on keeping interfaces stable.
* A Linux answer to WinFS.
* Better hardware support of consumer-level devices, especially laptop-related hardware.
* Improved power management.
Despite this long lists, we are really close. The newly-released 2.6 kernel is an excellent desktop kernel, and the current desktop offerings are excellent. I am very stoked — world domination has never been so attainable.
2. In my experience, the most UI-responsive OS I ever used, was BeOS. When I asked my ex-Be engineer husband “how did Be achieve this?”, his response was
“easy, the kernel guy’s cube was next to the app_server’s guy”. Do you also believe that in order to achieve high responsiveness on the desktop the kernel and X/Qt/Gtk guys should have ‘meetings’ and architect their projects in a way that integrate together best instead of trying to patch later?
Robert Love: I think that, in general, it never hurts to have all of the pieces to the puzzle come together and have solutions architected as a whole instead of piecemeal. Conversely, however, it is also important to keep layers conceptually separate. Microsoft is just now seeing this: note their recent decision to move the “core OS” to its own team (by core OS, they mean to separate the kernel and system-level guys out from the rest of the Windows umbrella). It is important to juggle the cooperation and the separation wisely.
That said, I think the reason BeOS is so often touted as being very responsive is that it was highly threaded and traded throughput for latency at many levels.
I believe both Linux and Mac OS X are very response systems too, however. It is all very subjective.
3. Depending on the kernel patches used, mouse movements can be vary from normal to very jerky on the current distros. For example, Fedora has the best mouse movements today in my experience, while other distros or stock kernels (like on Slackware) suffer from bad mouse movements. Is kernel 2.6 any better in this respect by default or extra patches will still be needed?
Robert Love: I do not think the 2.6 kernel should need patches to improve mouse tracking.
4. What goodies the 2.6 kernels is going to bring to users who are mostly interested in the desktop Linux experience?
Robert Love: On the usability front, we have the device model, which brings us better device management, sysfs, and a complete hotplug solution. This means things like udev and HAL are a reality in 2.6.
On the performance front, we have an improved process scheduler, the CFQ I/O scheduler (not yet merged), a preemptive kernel, improved VM, and lower-latency/more-fair algorithms throughout the kernel. All add up to a radically improved desktop experience.
5. At your work at Ximian, are you interested in helping out the goals of freedesktop.org‘s projects, e.g. HAL?
Robert Love: I am a big fan of all of their projects.
Both HAL and D-BUS are immediate interests of mine. I see both of them holding an important role in my “make hardware work” project outlined above.
6. Is there any support for node monitoring and “live queries” on 2.6’s XFS or ReiserFS? If yes, any plans at Ximian to help out projects like GNOME Storage or implement something like having your saved queries get messages from the kernel that new results were added to the query and ultimately inform the user?
Robert Love: I am totally unfamiliar with this!
7. Where would you like to see kernel 2.8 or 3.0 to go towards? Are there plans to implement a “visual” method and help users install easily third party drivers, like nvidia’s or winmodem drivers instead of using the command line to achieve this?
Robert Love: There is definitely no plans to make binary drivers happier. Linus has made it clear: he and many other kernel hackers just do not care about them. I don’t mind that, either!
I would like to see the 2.7 development kernel carry on 2.5’s quest to lower latency and improve fairness in kernel algorithms. Both because there are surely some missed corner cases, and also because it will require eternal vigilance to keep everything smooth in that regard.
I would also like to see the merging of the kernel events layer.
Finally, the obligatory “rewrite the tty layer”!
Robert Love photo: Pierre Blanchet. First published in the May 2003 issue of Linux Journal.
“That said, I think the reason BeOS is so often touted as being very responsive is that it was highly threaded and traded throughput for latency at many levels.”
Latency vs. throughput is always a tradeoff (if you can win on both fronts, the original design was just bad).
I wouldn’t list threading as a factor. In quite a variety of cases the OS felt very responsive even though the number of threads involved was not any higher than it would be e.g. between an X server and an X app.
One of the real reasons why the OS was responsive was that it had very few “giant locks”.
Another reason is that the scheduler was aggressive. The heartbeat was set to 3ms but seldom triggered. Timers were extremely accurate, and the latency from IRQ to uses-space was very low.
Yet another reason was that the client-server communication was highly asynchronous.
And one last reason (the one that Eugenia invoked) was that several core user-space processes (and especially the app_server) were very careful to use the kernel in ways which were known to be effective (surprisingly, those ways mostly involved to try to NOT reschedule too often, so that a useless latency improvement wouldn’t result in a visible loss of throughput).
JBQ, in what ways was app_server different, and similar, to X?
today has been a great day because you have been posting on a lot of stories and it is certainly nice to have a truly informed person making comments on such things.
It should be interesting to see how OpenBeOS behaves when it comes to perceived responsiveness. I still cannot uselinux as a desktop OS because it lags badly (haven’t tried 2.6 yet). Since OBOS are trying to revive the BeOS look’n’feel, it will be interestnig to see how it behaves performance wise. Incidently, the OBOS app_server seems to be near alpha stage as we speak.
also, it would seem to me that Linux is moving in the direction of design that you outlined BeOS to have had.
try fedora, it is very responsive.
>try fedora, it is very responsive.
After doing some stuff on Gnome, try clicking the hat menu. It gets unresponsive for about 3-4 seconds. This (bug? I am not the only one seeing it) only started happen with Fedora, and it doesn’t happen on other distros. Probably some of the patches Red Hat added creates this specific unresponsiveness which is pretty irritating.
We should be doing cool stuff, like asking the user if they want to copy their photos to a new album.
There we go.
Linux is pretty responsive for me. More than any OS I’ve used(XP, OS X). But I’m sure Gentoo had a part to play in that. A few apps take for ever to load and are just outright sluggish, though. (OOo anyone?) Others take a while to load, but once loaded they are responsive. Others just load fast and respond equally well. Then 2.6 changed that all. 🙂
no worse than Windows XP. I get lags like that with my menues in XP so I do not really care as much.
no worse than Windows XP. I get lags like that with my menues in XP so I do not really care as much.
I thought I was the only one getting those lag under Windows XP.
My dual boot with suse 9 is faster then windows XP. Perhaps because suse is able to use much more of my ram then xp, even dipping into swap at times.
2000+
WDJB
1G DDR
“in what ways was app_server different, and similar, to X?”
Well, those are two totally different beasts, actually. X is a standardized and fairly rigid generalized protocol with many different implementations. The app_server on the other hand used a custom and ever-changing specialized protocol.
I can’t talk in detail about any X implementation, the only one I ever had a remote look at was a basic port of XFree86 to BeOS (probably around 1999, and it was not even a current version), and at the time it looked quite primitive and looked more like a reference implementation than like optimized production code (I don’t mean to offend anyone, but sometimes you need to do a few ugly things in order to squeeze performance out of your code).
In terms of protocols, the app_server relied heavily on two mechanisms, shared heaps and kernel-level message queues. It couldn’t have worked without those. Once, for the sake of the experiment, we tried to serialize parts of the app_server protocol through a byte pipe (similar to what X does) and the performance was so poor that we gave up before even making bitmaps work.
Oh, and there was some behind-the-scenes black magic with the way scrollbars were handled (anyone who tried to inherit from BScrollBar would have noticed). At some point some other types of views were handled entirely inside the server, including the Terminal (but very few people used versions of BeOS where that was the case).
Don’t make me puke!
The perfect interface was invented *long* ago:
The File System
Fix Linux to support the most basic features a sane OS needs:
1) Per-process namespaces(already in 2.6, thanks Viro!)
2) (l)user-space filesystems(otherwise (1) is quite useless)
3) 9p support for transparent filesystem access
As for threading, if someone got a clue and did a useful threading system like Plan9 has had for ages; in most other OSes threads are just process with shared mem and some extra useless complexity thrown in, talk about idiotic ideas, for that you should add extra flags to fork() to indicate if you want shared mem, shared namespace, etc. you don’t need the added complexity of threads for that.
\k
I can confirm that we have very bad responsiveness on XP here in the 3 computers we have in my company:
– start menu is very slow, it lags when opening some submenus
– sometimes, the explorer does not respond for several seconds (does not display the disk content, even when only 1-5 files in the directory), most often via the network, but also often on the local hard drives. (systems are two P4 3GHz and 1 centrino 1.5GHz).
I’m sure I’ll get flamed for saying this, but I am really tired of the wide variation in responsiveness of linux depending on distro, hardware etc. I mean, with XP, I pretty much know what to expect with a given set up – memory amount and kind, hard drive speed, video card etc. I can look at a specs of a system and pretty much predict how XP will behave on that system (and that includes various tweaks).
Now, that simply is not the case with linux – you can have exactly the same OS version (same distro, same kernel, same everything) and yet, there is no way to say how this will behave on any given system – other than *maybe* extremely general stuff like “more ram, faster” (and even that is not dead certain sometimes).
I really think that is due to something inherent in a combination of non-optimized drivers, various combinations of DE stuck on top of the kernel each responding differently and apps which in linux rarely seem to be written with responsiveness in mind (mind you, I’m not talking about different distros that mix and match and patch and hack their own brews). It’s a mess. It’s a bigger mess than XP or OSX.
I don’t know about others, but to me personally, responsiveness is very important, and I am amazed at how many linux users are so willing to put up with absolutely dog slow performance – stuff that raises my blood pressure instantly. I don’t know if there is even a cure for linux possible… sure 2.6 might be faster, but boy that’s only ONE of a dozen factors… it’s like pushing on a string. The worst thing is that you can spend weeks tweaking your system, and it still will suddenly and inexplicably go into “slow mode”. Say what you will about the XP cow – at least it is consistently mediocre. Rant over, flame away.
A kqueue implementation for Linux seems like a nice way for delivering arbitary kernel events to userspace. Better than having X diffrent notification schemes for diffrent devices/subsystems, and much better than polling ,say, files in /proc/ .. Any thoughts ?
Oh, read http://people.freebsd.org/~jlemon/papers/kqueue.pdf
and http://people.freebsd.org/~jmg/kqueue.man.html
I thought I was the only one getting those lag under Windows XP.
no youre not. i had stuff like explorer crashes (filemanager and desktop crashes and reloads and stuff – apps who dont want to start because theyre crap – norton security bla for example A LOT) luckily not on my computer, but on some others.
windows people just reinstall everything then, if they care about performance, update to the latest internet worms etc.
it really depends also on what you do to “optimize” your system. some jerks just break more, and some supposed low latency patches make the desktop even more sluggisher. i stayed since 2.4.18 with debians default binary kernel, and i have no ui-lag or similar.
and yea i can wait for some app to load. but never longer than some seconds. (you dont expect gimp to spring up in one second – nor do you expect that from photoshop – rhythmbox also loads as fast as itunes)
one thing bugging me at the moment are some bugs in gnome-theme-manager, but i think when i apt-get the new ones it might well be fixed.
The perfect interface was invented *long* ago:
The File System
The thing is, as I understand from Robert Love’s answers, right now in order for the desktop to detect an usb hard disk being plugged you need to make polling.
Also think that to get hardware stats on linux you do things like catting /proc, and so on.
Filesystem abstraction is nice, but I guess a message passing system for hardware notifications is a necessary step for the desktop. Unless you want to poll the filesystem to detect changes (not very optimal, IMO).
I am the one who posted the comment with mentions of 3 computers under XP.
I am sorry you feel wounded by the fact that several Windows user compare their experience about the lack of responsiveness of Windows XP.
As for Linux, using Mandrake since 7.0 (kernel 2.2) and having used Debian Slink (2.0) before (kernel 2.0), I have always have acceptable responsiveness with it. Kernel 2.4 is a wonder in my opinion. I have a 600 MHz PC at home, and have never experienced latency problems (mouse jumping or xmms skipping) with it, even when I compile scribus or gimp (this can be a 1 hour task on my computer) and have other tasks on.
This maybe related to my light DE configuration (Rox-Filer + Enlightenment), but I have consistently a responsive desktop under heavy load. At work, I can hang (no answer for 10 seconds) XP when Matlab or other soft are computing heavily. Never on Linux.
Sorry if you do not appreciate my experience, but I am no liar and you will have to live with this fact.
PS: by the way, the 3 PCs I mentionned previously all are installed by Professional Windows administrators, not by me.
That will turn Linux in some kind of windows on Linux
kernel, and might even compromise kernel operations.
I like small and simple UNIX philosophy, I do not mess with
KDE and Gnome.
I hope it will never happen. Otherwise I wold have to
migrate to FreeBSD.
DG
> I hope it will never happen. Otherwise I wold have to migrate to FreeBSD.
You should’ve years ago then.
Oh yeah !
http://www.cs.bell-labs.com/sys/doc/names.html
“All resources in Plan 9 look like file systems. That does not mean that they are repositories for permanent files on disk, but that the interface to them is file-oriented: finding files (resources) in a hierarchical name tree, attaching to them by name, and accessing their contents by read and write calls. There are dozens of file system types in Plan 9, but only a few represent traditional files. At this level of abstraction, files in Plan 9 are similar to objects, except that files are already provided with naming, access, and protection methods that must be created afresh for objects.”
“… file systems and name spaces offer an effective model around which to build a distributed system. Used well, they can provide a uniform, familiar, transparent interface to a diverse set of distributed resources. They carry well-understood properties of access, protection, and naming. The integration of devices into the hierarchical file system was the best idea in UNIX. Plan 9 pushes the concepts much further and shows that file systems, when used inventively, have plenty of scope for productive research.”
it’s slow. but
Windows server 2003 is very fast.
—
If this is the direction Novell/Ximian is going, to improve linux desktop in general, not focusing only in one part of the community (the GNOME part), but providing integration and general improvements, they truly deserve my sincere thank you.
RH and SUSE were already going in this direction. There is no reason a GTK/GNOME app could not feel at home in a KDE desktop and vice versa.
Sharing common infrastructuro only make things better.
If you want to find out when a file has changed without polling, there should be a very fast and low-level mechanism to get notified for file changes, like there was in BeOS. In linux there is the dnotify system call, but it is only useful for single directories, and not for whole directory trees. This is an area that definitely needs improvement.
In windows, there is an API that lets you watch a complete directory tree for changes of a certain kind. I would love to see something like this. Things like live queries would be very easy to implement given efficient file systems like reiser4 and file change notification.
“not talking about different distros that mix and match and patch and hack their own brews). It’s a mess. It’s a bigger mess than XP or OSX. ”
Nope. Strip out everything but an equivalent amount of barebones “comes with the OS” software, like Notepad equivalents (Kedit, kppp, etc.) and you would find that they are just about all the same speed. Load a bunch of stuff on windows and you get varying degrees of load times and responsiveness as well. Try bearshare if you want slow.
I’m sure I’ll get flamed for saying this, but I am really tired of the wide variation in responsiveness of linux depending on distro, hardware etc.
I strongly suspect that a lot of the bad responsiveness people report is due to harddrives not being in DMA mode. Way too common, unfortunately.
They do have something like that, its called imon/FAM. Both GNOME and KDE use it.
imon only works for the node you told it to watch, it doesn’t recurse into subdirectories. So if you are monitoring a directory and you add files to a subdirectory of that directory you will get no event from FAM or imon. You have to manually set up your query to do that, no big deal really but it isn’t equivalent to BeOS or Windows.
As far as I remember BeOS can’t node-monitor an entire hierarchy (the name “node-monitoring implies that you can only monitor one node), and I’m sure than queries can’t search on the path.
I know about FAM. But unfortunately it is just a library that does its own polling. This works just fine when you want to watch for the properties of a folder to change to display the changes in a file manager such as konqueror (and that is in fact what it is designed for).
But if you wanted to do something like using tiny files on reiserfs as extendable attributes and doing live queries on them, this would be way too slow. There really needs to be a fast low-level mechanism for watching for file changes in whole directory trees.
Unfortunately I have no idea how to implement something like this. I asked hans reiser about such a feature, but he answered that such a feature would best be implemented in the linux VFS layer.
I have no detailed knowledge on how the VFS layer works and wether it is capable of handling extremely small files, so I can not implement it myself.
But I still think such a feature would be great. You could represent arbitrary attributes as tiny files in a directory, so you would get all the advantages of live queries without breaking the simple unix principle of “everything is a file”….
I do not know how live queries were implemented in BeOS. Obviously you are way more qualified to answer this 🙂
But having a way to monitor an entire filesystem hierarchy for changes would be immensely useful. It would not be simple to implement (all sorts of nasty race conditions when querying a constantly changing file system), but it would be a very simple interface.
It can not be too hard to do this, since NTFS supports it. You can e.g. watch for changes in all files named “test.txt” in your entire C: tree, and it does not even slow the system down noticeably.
Yep, BeOS can not monitor entire hierarchies. OTOH, you can monitor a directory and get notified about entries added/removrd to it and, with that info, start monitoring the new entries.
Also, yes, you can’t do path-based queries. They’re always system-wide. You can, of course, programatically filter the query results to only display the results that match a specific path.
-Bruno
Node monitoring is not really the same thing as queries. You *CAN* ask the system for all files that match “*.txt” and then get notifications about files that match it being created or removed anywhere in the hierarchy. That works pretty weel, in fact, when you consider BFS. OpenBFS even has improvements on this (like searches on non-indexed attributes).
-Bruno
Getting changes for all files matching a certain pattern on the whole directory tree is not as good as what NT provides, but it would work well enough. Is this possible under linux, or are you talking about BeOS?
I am talking about BeOS.
-Bruno
If your processor is overeating you’ve got more problems than just responsiveness in your GUI… or maybe it’s grown too lethargic from all that overeating….? 🙂 time to put the P4 on a crash diet.
I believe FAM only resorts to polling if there is no kernel level mechanism present.
However, if imon or dnotify (the linux equivalent) are patched into the kernel’s VFS, you get very efficient behavior, without polling. dnotify is standard in the kernel since somewhere in 2.4.x.
I wish more people knew about this. It’s such a good way of doing things.
Yes, you are right. FAM uses dnotify if available. But since dnotify can only query a single directory it is basically useless for anything more complicated than a file manager. BeOS live queries or even the NTFS mechanism (whatever it is called) are way ahead of this.
<quot>one thing bugging me at the moment are some bugs in gnome-theme-manager</quot>
done with the 2.5.0
In previous versions of Mandrake when I moved large numbers of files, the system would bog down, and stall.
In the latest MDK 9.2, I did the same tasks without any problems. This was a VERY noticeable improvement… They probably backported stuff from 2.6 to 2.4 for MDK 9.2…
I can’t compare to Win because I’ve been windows free for 46 months!
MarkP
“BeOS live queries or even the NTFS mechanism (whatever it is called) are way ahead of this.”
Who cares? Copying, moving, creating, and unlinking files on unix way, way, waaaay faster than on BeOS and NTFS – why do I or the kernel need to know what is happening with files “live”? “Live queries” sounds like a pathetic hack to overcome bottleneck elsewhere that no one using Unix (or Plan 9) is even thinking about because it’s a non issue.
BeFS was horribly slow (try tarring/untarring and rm -rf ing the kernel source tree on a BeOS). Smart admins know that if they want to do lots of queries they can run a DB server. Come to think of it … never did see a lot of Oracle deployments on BeFS so what good is it for real “queries”?
> Who cares? Copying, moving, creating, and unlinking files on unix way, way, waaaay faster than on BeOS and NTFS – why do I or the kernel need to know what is happening with files “live”? “Live queries” sounds like a pathetic hack to overcome bottleneck elsewhere that no one using Unix (or Plan 9) is even thinking about because it’s a non issue.
Hello idiot.
Sometimes, you want to know when a given file in a directory changes (= log file updated, new file arrived by file transfer, etc) and you don’t want to “ls” that directory every second to find out. It would be a lot easier if the kernel told you “file blahblah located in /blah/blah changed size”.
Now, go back to compiling your shit and leave desktop for Windows XP.
Getting a tad touchy there aren’t we?
Come on people, this is a discussion place. Not a battlefield. An OS is an OS and we *all* know that Windows XP isn’t exactly a shining example of what’s best.
I know that creating and changing files under Linux (especially ReiserFS) is way faster than on NT or BeOS. But I was talking about *watching for file changes* in a directory tree. And that is way, way, waaaay slower under linux than under BeOS or even NT.
I would like to combine the advantages of Reiser4 (excellent performance especially with small files, ***transactions***) with the nice features of BeOS (very fast change notification) to create something really advanced on par or better than the Longhorn WinFS.
Reading your post I get the impression that you do not even understand the problem…
Well, I like the interview. And speaking about Linux being unresponsive I must disagree. My KDE under 2.4.22 was very reponsive and with full release of 2.6.0 it rocks. I would like to say: ,,Go and make it better than ever” to Robert Love. And thanks for all the good work.
From the interview:
“I am very stoked — world domination has never been so attainable.”
This is what keeps me away from deploying Linux on my home systems. We would never want to replace the Windows monopoly with a Linux one. We want a healthy competition (not quite there yet) that spurs development. That such a prominent Linux developer says this is to me very disturbing
Linux can and should be so much more. I’ll stick with *BSD until something radically changes in the Linux community
*flamesuit on*
As a business/personal user, I’m disturbed by Robert’s answer to Eugenia’s question #7.
“Robert Love: There is definitely no plans to make binary drivers happier. Linus has made it clear: he and many other kernel hackers just do not care about them. I don’t mind that, either!”
We, the users, just want to get our work done. Sometimes, that requires installation of a device that requires a driver. We don’t want to recompile anything, just have the device work the way it’s supposed to work. Binary drivers help to make that possible for the non-techie.
Not caring about the user’s experience is a sure way to inhibit “world domination.” MS now dominates because they understand and cater to the “unsophisticated users” that comprise well over 95% of the computer users of the world.
http://home.no.net/rmlwby/
By Rich Lewine (IP: —.ba-dsg.net) – Posted on 2003-12-20 17:57:31
As a business/personal user, I’m disturbed by Robert’s answer to Eugenia’s question #7.
You understand that binary drivers (modules) are just fine? They’re talking about closed-source drivers/modules. nvidia’s stuff is even worse since it’s non-standard junk all over.
No, I didn’t realize that closed source was the object of his comment. Perhaps if I were a programmer it would have been obvious. That just makes my point. Assumptions seem to be made about users capabilities, from both a knowledge and skill perspective.
I do, however, now better understand their position (Linus, Robert, et al); an open source OS should have open source drivers/modules. So the challenge appears to be getting nvidia, etc., to agree and comply. Apparently, not an easy task, even getting them to open their source for others to do the work.
I’m still troubled. OSS leaders seem to be as intransigent as the proprietary bunch. Unless there is a meeting of the minds, a commonality developed, This standoff could go on interminably. The users are the losers. . .and that’s who this stuff is for. Linux is no longer a hobby OS.
The design of Unix is to have few and simple kernel calls which can be used in powerful ways. dnotify does just one thing and does it well. If you want to monitor an entire tree, write a recursive descent function which sets up dnotify for all nodes in the tree. Then, if notified of new directory creations, add dnotify for that directory. No need to make a simple system call complicated.
Yes, it adds a little more code on your part, but only if you need it, not for every programmer who doesn’t need it.
And, efficiency wise, it will be just the same as if you had a single system call to notify on changes to an entire tree.
I agree, it is disturbing to see the standoff between OSS leaders and hardware companies developing proprietary drivers.
Fortunately, there are a few distribution companies that are making that effort for users, but unfortunately, each one solves the problem incompletely, and in their own way.
Hopefully, someone will be big enough to see beyond their own turf, and solve it for all of us.
the problem of dnotify is that it *needs* a file descriptor per file monitored, as file descriptors are limited this makes monitoring a whole tree o subtree impossible.
Linux SE can do this without the need of keeping a file descriptor per file, maybe in 2.7 we will hace a solution based on the hooks provided by Linux SE.
I really don’t get why people consider this a “standoff” between OSS leaders and hardware companies. I think it was Wired that interviewed Linus recently where he indicated that though it is a problem today, it’s not likely to last.
It used to be like pulling teeth to get specs for various SCSI cards from hardware vendors, much less actual open source drivers. Now since Linux is so big on the server side of things, these vendors fall over each other to make sure their devices work with Linux and have no problem releasing code or at least specs for them so that Linux can have fully GPLed drivers for them out of the box.
I (and Linus, as it seems from his interview) believe this will happen with Nvidia and ATI and any other vendors who product binary only drivers for devices geared toward the desktop. Eventually. To make it easier for these vendors to NOT release their code will ensure that they will never release their code.
Given how often new graphics cards, in particular, are released, the argument the vendors use about preventing people from using the code to reverse engineer the card and produce a clone is bogus. Has anyone successfully reverse engineered quickly changing hardware using source code for drivers in an economical way and survived as a business? That’s an honest question, but I’m guessing the answer is no.