Slashdot Mirror
Linux 2.6.17 Released
diegocgteleline.es writes "After almost three months, Linux 2.6.17 has been released. The changes include support for Sun Niagara CPUs, a new I/O mechanism called 'splice' which can improve the performance greatly for some applications, a scheduler domain optimized for multicore machines, driver for the widely used broadcom 43xx wifi chip (Apple's Airport Extreme and such), iptables support for the H.323 protocol, CCID2 support for DCCP, softmac layer for the wireless stack, block queue IO tracing, and many other changes listed at the changelog"
Modules... Only the modules (read: 'drivers') that are needed are loaded. It needs to be in the kernel because it accesses the hardware (the net card) at a fairly low level.
I.O.U One Sig.
sendfile(2) is now a call to splice() so programs that use the old syscall will benefit as well and without modificaiton.
Some stuff I found interesting on the human-friendly changelog.
/proc file /proc/self/mountstats, where mounted file systems can export information (configuration options, performance counters, and so on)
Block queue IO tracing support (blktrace). This allows users to see any traffic happening on a block device queue. In other words, you can get very detailed stadistics of what your disks are doing. User space support tools available in: git://brick.kernel.dk/data/git/blktrace.git
New
Introduce the splice(), tee() and vmsplice() system calls, a new I/O method.
The idea behind splice is the availability of a in-kernel buffer that the user has control over, where "splice()" moves data to/from the buffer from/to an arbitrary file descriptor, while "tee()" copies the data in one buffer to another, ie: it "duplicates" it. The in-buffer however is implemented as a set of reference-counted pointers which the kernel copies around without actually copying the data. So while tee() "duplicates" the in-kernel buffer, in practice it doesn't copy the data but increments the reference pointers, avoiding extra copies of the data. In the same way, splice() can move data from one end to another, but instead of bringing the data from the source to the process' memory and sending back to the destination it just moves it avoiding the extra copy. This new scheme can be used anywhere where a process needs to send something from one end to another, but it doesn't need to touch or even look at the data, just forward it: Avoiding extra copies of data means you don't waste time copying data around (huge performance improvement). For example, you could forward data that comes from a MPEG-4 hardware encoder, and tee() it to duplicate the stream, and write one of the streams to disk, and the other one to a socket for a real-time network broadcast. Again, all without actually physically copying it around in memory.
factor 966971: 966971
Insightful? How about Kino or Cinelerra or Lives or Mainactor?
try hitting '/' on make menuconfig, type ov511 hit enter. That's a hot tip that's saved me quite a bit of time...
It'll find it if it's there.
The stable/development branches might be a nice idea in theory, but in practice it doesn't work. Distros would ship, for example, a "stable" 2.4.xx kernel, except it wouldn't actually be that. They would spot nice features in the 2.5 kernel that they wanted to offer their users, and so back-port them... and any other nice patches floating around the net while they're at it. The result being that the kernels that ship with distros were so heavily modified, that stability (from one machine to another) went right out of the window. You couldn't go to kernel.org and download an updated kernel, as without all the patches, it wouldn't work. So you had to stick to the distro's kernels.
So instead, the 2.6 goal is to have development/stable parts of the cycle, rather than seperate branches. Roughtly: patches that could break things get submitted at the beginning of the cycle, and -pre1/-pre2 tarballs are released. If you want bleeding edge, you go here. Release candidates are released, where developers get chance to fix bugs etc in the code. Then, any code that's still [known to be] buggy gets dropped for the final release (eg, 2.6.17). The developer can work on it, and try add it again during subsequent cycles. When it works, it can be included in a final release.
During this cycle, security and other urgent bug fixes take place in the ultra-stable branch, with version such as 2.6.16.1, 2.6.16.2.
(This is the rough idea I believe, there could be some slight inaccuracies in how it actually takes place, I haven't followed it 100%, but this should be close enough to get the right idea).
The revolution will not be televised... but it will have a page on Wikipedia
That was the theory. But in practice, if Y was even, the kernel was obsolete, while if Y was odd, the kernel was broken. Except, of course, 2.even.0, which was actually stable, but broke compatibility with the previous kernel that worked. And occasionally, 2.even was kept up-to-date because nobody could use 2.odd for development, because it didn't work at all. You could tell that the old model didn't actually work, because no distribution shipped any kernel that used that model; they all shipped 2.even with an arbitrary set of patches (generally hundreds) from 2.odd and elsewhere. With the new model, distros are shipping kernels with only a few patches, and those patches are getting merged upstream.
The stable kernels aren't remotely on the bleeding edge; they contain only features which have been tested over the past three months, after being filtered out of the bleeding-edge development as being things that have already stabilized and stand a good chance of being proven in three months. It's effectively very similar, except the development series isn't left known-broken and the stabilization process happens on a quick schedule, with stuff that isn't ready pushed off to the next cycle rather than delaying the current cycle. Also, the version numbers change by less (development gets -mm, -rc, or -git; stable series change the third digit by one instead of the second by two; and bugfix releases change the fourth digit instead of the third).
Haven't tried the release of 2.6.17 yet, but rcX versions required extracting the firmware for your Broadcom card from a binary such as bcmwl5.sys (Windows driver). The tool bcm43xx-fwcutter does this.
I'm not an Ubuntu guy, but this reference might be useful to anybody trying to make the new Broadcom Wifi driver work in Linux. Very easy steps, and most non-Ubuntu users should find it easy to adapt for their specific distros.
There's no place I could be, since I've found Serenity...
Life is just nature's way of keeping meat fresh.
1) If you can create a condition where a goto is to be placed, you can add that same condition to the top loop in the nest and let it exit out gracefully.
If that leads to clearer code, then in the cases where you can do that, fine. Do that.
However, there are situations when a condition doesn't make sense until you've already
entered the nested loops at least once (for example, when allocating lots of chuncks of memory,
you can't test to see if you've successfully allocated memory until after you've tried to
allocate memory). Also, if there are several conditions that might require a break, but
they can all be handled the same (at least until after you break out of your loops),
do you really want each one to be tested at every loop test? Think how big and confusing that
would make your continuation test for your outer loops.
2) Use a clean-up function. It will return to the correct place without all the spagetti code.
There's nothing wrong with using cleanup functions if they are convienent for your
particular purpose, but if you have to free 11 objects before returning, then you'll
need to pass all 11 to the cleanup function each time you call it. I don't know about
you, but I usually find functions with 5+ arguments to be ugly. I would rather simply have
a 'goto cleanup' that jumps to a label that does all the cleanup in place. An acceptable
compromise would be to define a macro that does the cleanup in place but hides it from casual
code inspection, thus keeping the code clear, but avoiding the use of GOTO.
Using GOTO in the manners I've described will not lead to speghetti code since the flow of control
will be clear and uni-directional (the antithesis of speghetti code). In case (1), the use
of GOTO is equivalent to raising an exception in Java, C++, or Python from within the loop and
capturing the exception outside the loop (idioms commonly accepted in all three communities).
In case (2), the use of GOTO maps multiple exit points to a single exit point. If you feel
that these techniques qualify as speghetti code, then I would suggest that you've never
seen real speghetti code.
When Djikstra wrote "Goto considered harmful", he was talking about using GOTO to jump outside
the scope of the current function, something not possible in with C's goto (C's goto can only
jump to a label within the current function). See BASIC and PASCAL (I think) for examples of GOTO that
can jump anywhere in the program.
*sigh* back to work...