By Zack Brown
|
The Linux kernel mailing list comprises the core of Linux development activities. Traffic volumes are immense, often reaching 10,000 messages in a week, and keeping up to date with the entire scope of development is a virtually impossible task for one person. One of the few brave souls to take on this task is Zack Brown. |
An anonymous person suggested implementing the Kademlia protocol at the kernel level. This, the person suggested, would make various anonymizing peer-to-peer networks easier to create and might enable global participation by all Linux-based systems. Valeo de Vries said this seemed to be something that could just be done in userspace, and Valdis Kletnieks agreed with that.
The original poster suggested that a kernel implementation would replace all the existing userspace implementations, thus allowing total unification of the global Linux userbase into a single massive peer-to-peer system.
No one warmed to the idea, and everyone basically agreed that the anonymous person had failed to explain why this couldn't just be done in userspace, as all other Kademlia implementations had been done.
So that was the beginning and ending of that. H. Peter Anvin probably summed it up best, saying, "the reasons a network protocol goes in the kernel is either because it needs a multiplex that isn't possible in userspace (UDP, for example, needs a port number multiplex), or because acceptable performance isn't possible in userspace (this mostly applies to NFS)." None of those reasons applied here, so the project was a dead duck.
Davidlohr Bueso posted a patch to create a new file in ProcFS. /proc/<PID>/age would give the age, in seconds, of the process having that process ID. It was almost a one-line patch, but a number of folks felt that the same thing could be accomplished in userspace easily enough.
Davidlohr didn't disagree with this, but he did say that he hadn't found any really straightforward way to get the information. He also pointed out that other files also under /proc contained information that could be obtained from userspace. Why include those files, but not his?
Whatever the reasons, the discussion petered out quickly, and it doesn't look as though /proc/<PID>/age is going to get into the kernel anytime soon. But it might get into the ps command. That's where Andi Kleen suggested would be a good place for it.
David Airlie, the maintainer of DRM (Direct Rendering Manager) in the kernel, said he expected to see a number of companies in the embedded space start submitting 3D drivers to the kernel in the near future. And he wanted to make it clear to them that he would only accept drivers that actually supported the hardware and that were open source. He would not accept any drivers that were solely intended to support a proprietary driver on top of them, which would really be the thing to handle the hardware.
It was a nice post, and he outlined a lot of his reasons. If you want to read it, it's archived at http://lkml.org/lkml/2010/7/1/853.
An interesting discussion ensued. Daniel Walker asked whether David would accept a driver that accepted some subset of the full set of features. David replied that this did start to be more useful, but he pointed out that there could be problems if the open source users started enhancing the driver in ways that weren't compatible with the company's enhanced proprietary version that was intended to sit on top.
Part of the discussion did get a little ugly, with accusations of mixed motives flying around. David works for Red Hat, and there were some pointed remarks as to whether he would have taken the same stance if he worked somewhere else. But various folks argued that this was an absurd position, and that David was just going along with his open source philosophy and not engaged in any special corporate plot to make things difficult for hardware vendors.
The discussion was very interesting, in spite of the flames. It does seem to me that if a company wanted to get a driver into the kernel so they could use it as a layer underneath their proprietary userspace code, it might prove difficult for the kernel maintainers to prevent them from doing so.
At a certain level of functionality, it seems as though the kernel driver would just be more valuable to include than not; and, how would David or anybody else be able to tell for sure that this driver was not producing the real goods?
Clearly, this is a topic that will come up again and again.
Mattia Jona-Lasinio announced that he'd written an in-kernel VT102 terminal emulator. He called it LCD-Linux. The idea was that sometimes the kernel would be running on devices with little tiny LCD displays, and Mattia had coded in some custom escape sequences that were specific to them. One of the main features is the ability to define an 80x25 virtual text console, the correct size for VT102, but still much larger than could fit on one of those tiny displays. By supporting a little window into that large terminal, Mattia's emulator could behave like a real VT102, without sacrificing compatibility.
Alan Cox pointed out that there's already console support in the kernel, which is used for pretty much everything. He didn't see a need for an entirely new VT102 implementation. Mattia replied that he'd considered just using the standard console, but he'd realized that what he really wanted to was to enhance it with extra escape characters, to enable custom characters, backward writing, backlighting, and other things. Implementing these things in the venerable Linux console was a bit scary for him - maybe because any changes he made would have to work on every single user console in the known universe - or risk breaking them. So, he elected to write a new terminal emulator instead.
It turned out, as Alan mentioned, that there is actually a lot of interest in improving the standard Linux console code, possibly in exactly the ways Mattia had been working. In particular, the 3D graphics folks were very interested in this sort of extension, Alan said. Mattia said he'd put together a detailed to-do list, in that case.
James Simmons also got interested, having done some abortive work on this in the past. He posted his own to-do list, attempting to abstract out various portions of the console and implement them "properly," without the awful hacks he saw in the code currently.
Mattia also analyzed what would be needed and posted his own list, remarking, "We are talking about a massive rewrite of code, also including a redesign of the console layer and (at least) the VGA driver (vgacon) and framebuffer driver (fbcon), not just a couple of patches to throw in." James replied, "the good news is I have been here before. The good news is that the console code has been abstracted out of most low-level drivers, so it makes life much easier this time around. Also, today, we are starting to have a greater amount of hardware that can do multi-seat."
The discussion was clearly heating up into real action, so it seems as though the ancient Linux console code will be getting a full makeover, leading to a whole realm of compatibility with modern display hardware that has been lacking until now.
Nick Piggin has been working on improving VFS (Virtual Filesystem) scalability, and he recently announced creating a new Git repository to house all the contributions made by himself and others. One of the main improvements has been to let processes do name lookups without creating data storms in their wake. The previous code produced a lot of data activity during this type of lookup, which slowed everything down.
Other features were in the tree and, over the course of the discussion, a lot more patches were added. The reason all this is important is that the VFS is at the heart of all filesystem implementations. If the VFS has a scalability issue, that issue affects every filesystem a user might choose. If one of Nick's fixes speeds up the VFS a little, that's an improvement that could potentially be seen in all filesystems. The VFS is pretty central, and pretty amazing.