Kernel Traffic #64 And The 2.4 Kernel TODO

sohp writes: "Alan Cox's summary writeup of the things remaining before 2.4 highlights Kernel Traffic #64. It's quite a long list -- I'm not holding my breath for 2.4 " Kernel Traffic is a pretty cool overview thing if you can't handle the burden of actually subscribing to the list itself ...

Comments

fstab - more details?

[torpor]

Can you provide more details about how to set up /etc/fstab, or point me (us) in the direction of a web page that has a reference for how to use these new features in the Kernel?

I'd be really happy to get into using 2.3.99, but I don't really have a lot of time to wade through the sources looking for details on how to use the new features. I'm sorry if this is a stupid question, but maybe there's a page out there that contains a guideline for the new features and more importantly - how they might be used?

Re:fstab - more details?

[kijiki]

echo "none /var/shm shm defaults 0 0" >> /etc/fstab

That should do ya. make sure you use ">>" not ">" or you'll clobber your fstab (that's bad).

Re:fstab - more details?

[bbarrett]

As a couple people pointed out, you just need to add the line: none /var/shm shm defaults 0 0 to the /etc/fstab. Since you kind of asked, a description of the entry. The first part (none) is the physical file system. For an ext2 partition, this might be something like /dev/hda1. The second entry (/var/shm) is the mount point. Don't forget to create the directory /var/shm. The third part (shm) is the file system type. This can be one of a bunch of things. The fourth option (defaults) lists any options that should be sent along to mount when mounting the file system. Look at the mount man page for more info on this. The last two numbers (0 0) give info to dump and fsck. The first tells dump whether to include this mountpoint. 0 means this mount point will never be dumped. (dump of course being for backups). The second 0 is used by fsck to know that this filesystem does not need to be checked. A non-zero number gives the order of checking on filesystems that might need such things. One other thing. Read the Documentation/Changes file in the kernel source. It includes information such as the shm setup, including how to do it. There are a couple other important notes in there. Well worth the read.

Me too!

[Stormie]

Yes, this is a classic "Me too!" comment. Kernel Traffic is wonderful, a godsend to someone like myself who really is interested in what's going on in kernel-land, but can't possibly read 100 messages a day (or whatever) on the mailing list. Anyone else in the same boat (and I'm sure heaps of Slashdotters are) would be mad not to check it out every week.

And, if you're not aware, Kernel Cousins is a collection of "cousins" to Kernel Traffic, for other mailing lists. Currently the Gimp, Wine, Samba and Debian HURD mailing lists are summarised weekly or thereabouts. So if you're interested in the bleeding edge of any of those projects, there's something for you too.

Massive kudos to Zack Brown and the other traffickers for these summaries!!

If you want its functionality, run 2.3.Latest

[Christopher B. Brown]

There's no "hype" in talking about source code that you can already download.

Incidentally, the portion of the Kernel Traffic discussion where Linus discusses devfs , mentioning thus:

I want the numberic crap to GO AWAY. It's stupid, it's unmaintainable, and I do _not_ want to have the same old "device number" problems in new guises.

A hierarchical name-space with true names is the obviously correct way to name kernel parameters. And doing that any other way than exporting it as a filesystem is stupid and wrong.

Guys, remember what made UNIX successful, and Plan-9 seductive? The "everything is a file" notion is a powerful notion, and should NOT be dismissed because of some petty issues with people being too lazy to parse a full name.

The same is true of ASCII contents. Binary files for configuration data are BAD. This is true for kernel interfaces the same way it is true of interfaces outside the kernel.

I tell you, you don't want the mess of having things like the Windows registry - we want to have dot-files that are ASCII, and readable with a regular editor, that you can do grep's on, and that can be manipulated easily with perl.

This is one of those things that shows that Linus most definitely does have a clue. Further devfs changes will likely have an impact on VFS code, and thus be "injurious" to Alexander Viro. And it looks like there may be some side-effects whereby /proc gets nearly "reimplemented." And I can see the glimmerings of the VFS changes providing the kernel support needed to make managing ACLs and kernel capabilities a whole lot better.

It may take some time, and may not be complete until 2.5, but there is definitely some ongoing Good Stuff getting implemented in the Linux kernel.

That could be the key to scalability!

[tilly]

I am talking, of course, Larry McVoy's thoughts on scalability and SMP clusters. Here is a link on the problems with SMP, and here are the slides without explanation.

The theory goes like this. In an SMP system all of the CPUs have to be made to pay attention when any of the CPUs wants to do something where races would be bad. To do that you need good latency, which means that you need to fine-tune what is locked where and for how long. This introduces a lot of overhead.

Instead what Larry wants is to have a machine with a lot of CPUs turn itself internally into a cluster of Linux machines that just happen to network Really Fast. There are good theoretical reasons why this should scale Really Well.

One of the key items in this vision is the ability to run virtual machines within Linux. Guess what User Mode Linux is? :-) The other piece of the puzzle is making a cluster work like one machine, and Ron Minnich has been doing some work there.

In 2 years, care for a 1000 CPU multi-threaded database server? With failover? :-) :-) :-)

Cheers,
Ben

Linus==Jesus?

[cullman]

Reading the first couple of pages where all of Linus' quotes are in red text, I had some Deja Vu. Reminds me a bit of the New Testament.

Re:Unbelievable

[Salamander]

>But this software is BETA, which is why it's in the UNSTABLE kernel numbering scheme.

Unlike some of the other BS people have posted in response to my original comments, this may be a genuine philosophical difference. You see, I've been working for ten years in a world where "beta" means that the people responsible for the product have done everything they could to ensure that it's free of major defects, but they want to get some real-world experience before they "close the book" and call it done. A beta isn't expected to be perfect, but it shouldn't have any _known_ defects of a certain severity level and adequate testing should already have been done to verify that nothing's in there that will later seem "obvious". Linux 2.3.x clearly does not meet this standard. Maybe this standard is too stringent and inappropriate for Linux 2.3.x, what with the cooperative development model and all. In fact, I believe that is probably the case. However, I think the current state of Linux 2.3.x fails to meet _any_ reasonable quality standard, even one more appropriate to the situation.

I still believe that there's a certain level of diligence that should be expected before beta, before alpha, before hand-off to QA, even before other team members get their hands on a new piece of code. Obvious standard tests should be run to check for regressions, for one thing, and the code should not leave that developer's hands while such obvious regressions exist. For example, I run Connectathon tests before I check in even to a development branch, and if I see a new failure I don't check in. That doesn't mean I'm special, either; it's basic stuff that should be required of every developer. What I'm seeing, and what I'm complaining about, is that even these very basic rules clearly are not being followed in Linux development.

Nobody in their right mind expects any software to be perfect, least of all something clearly labelled "unstable", but I think it's perfectly reasonable to expect that things won't be broken _more than they have to be_. And that's not just a philosophical thing, either. Detecting and fixing bugs sooner rather than later is also more efficient. What if fixing O_SYNC requires more than superficial changes, requiring everyone else to change their code yet again after they'd already changed it once to go along with the new VFS stuff? Wouldn't it have been better if the person who broke O_SYNC had been required to fix it _before_ the whole suite of related VFS changes was sent out to affect everyone?

Re:User-mode Linux

[jdike]

> It seems to me to be like a VMWare that only
> does Linux (to put it simplistically).

That's sort of the effect from the user's point of view, but if I understand vmware, it slides underneath the two OS's and makes them run side-by-side with one appearing in a window in the other. With the user-mode port, it is really Linux inside Linux. If you run it and do a ps, you will see a whole bunch of "linux" processes, plus what they really are inside the virtual machine.

> trying out new
> kernels/distributions/configurations without
> needing to mess with your current setup.

This part is fun. The kernel boots out of a file in your normal filesystem. I've got Red Hat, Debian, Slackware, and SuSE filesystems. This makes it a lot easier to play with new distros.

> One also wonders then if Linux could be ported
> to other call interfaces

There's been talk of a windows port. According to one of the guys on my mailing lists, 95 is out, but 98 and NT look possible. The really important thing is the ability to intercept and annull system calls. If that's there, everything else can probably be made to work.

Jeff

User-mode Linux

[Phallus]

This looks rather interesting, a "port of the Linux kernel to its own system call interface. It runs in a set of processes, resulting in a user-mode virtual machine.". This is supposed to be being folded into 2.4. It seems to me to be like a VMWare that only does Linux (to put it simplistically).

The two most exciting things here for me are being able to look at the kernel in user-space while running, in ways that wouldn't be possible on a traditionally running Linux, and trying out new kernels/distributions/configurations without needing to mess with your current setup. For kernel developers in particular this could be very valuable.

One also wonders then if Linux could be ported to other call interfaces - Linux under *BSD/*dows/etc for dual booters who need to do something quickly in Linux while still in their other OS.

The web page is here.

tangent - art and creation are a higher purpose

I'm not holding my breath for 2.4

[SurfsUp]

I'm not holding my breath for 2.4

That's very wise ;-) If you've been running 2.3.99 you'll know there are still a few "issues" remaining, though these kinds of things hardly stand comparison with the bug list of a certain monopol^H^H^H^H^Hsoftware provider I could mention.

On the whole though, when it is ready, and it's a lot closer than you'd think from the jobs list, it's going to be a real killer. Just a couple of things: Built-in pcmcia and USB; extensive support for video, including USB Webcams; vastly improved SMP support; a new virtual device filesystem that makes major/minor device numbers go away; bags more drivers for all kinds of things; many, many other goodies I didn't mention.

I'll weigh in with a guesstimate of 3 months to 2.4.0 then another 2 months before you see 2.4.x start appearing in distributions. Very, very definiately worth waiting for, or just download it now and use it if you can't wait :-)

Don't forget to put an entry into fstab for shm (shared memory) - this has now become part of vfs, and your distribution won't know about that.
--

A day at the races...

[Cycon]

Good afternoon ladies and gentlemen, and welcome to the OSS racing track. Let's look at today's lineup:

1) Linux 2.4
2) Debian 2.2 (potato)
3) Mozilla 1.0
4) XFree86 4.0 (The real version)
5) The multi-headed XFS/Reiserfs/ext3 beast
6) KDE 2.0
7) Evolution (The upcoming GNOME email app)
8) (insert your favorite software-under-development here)

Anyone willing to make a few bets as to which one we're going to see first? Hmmm, maybe this would make for a descent poll... (c:

--Cycon

Disgusting perfectionists.

[Black Parrot]

Excluding the "Done" and "Probably Post 2.4" sublists, they have exactly 95 issues to address. And even that number includes quite a few "Fixed but not yet merged" items.

If it was Microsoft, they would have shipped it 62,905 fixes ago.

C'mon, guys. If you raise customer expectations you're gonna wreck the industry. It's waaaay too expensive to ship shit that actually works.

--