Linux kernel 6.11 lands with vintage TV support

Released remotely from Vienna, Linux kernel 6.11 is here, with improved monochrome TV support. Yes, in 2024. Emperor penguin Linus Torvalds was attending the Open Source Summit in the Austrian capital, but that didn't stop him working-from-hotel and emitting the latest and greatest Linux kernel. Along with the usual raft of …

[david 12]

"This was little help with the DOS-based Windows 9x"

That's just trolling, and make you look stupid, but apart from that, DMA was a lot of help with DOS, including with disk access. You may remember that IBM PC's were fairly slow machines by modern standards: not only was DMA faster, it freed up the processor to do other processing.

I got a 2x speed up by moving part of my memory access to DMA.

[CowHorseFrog]

Re: "This was little help with the DOS-based Windows 9x"

But DOS was single task single user ? What other tasks could be done in parallel ? Surely the CPU just waited for DMA to finish copying the disk buffer to some target.

[K555]

Re: "This was little help with the DOS-based Windows 9x"

DOS may have been, but they're talking about Windows 95. Windows 95 handled multi-tasking and took over things like file system / disc access.

[Liam Proven]

Re: "This was little help with the DOS-based Windows 9x"

> Windows 95 handled multi-tasking and took over things like file system / disc access.

Yes it did -- but its multitasking kernel was not re-entrant. The kernel itself was a resolutely one-thing-at-a-time sort of affair.

[david 12]

Re: "This was little help with the DOS-based Windows 9x"

Windows 95 handled multi-tasking and took over things like file system / disc access.

And thus disk and memory both access had nothing to do with DOS.

The Win95 DMA disk drivers offered significant performance benefits: the assertion that they offered "little benefit" is just factually incorrect.

The assertion that the Win95 DMA memory management and DMA disk drivers were "DOS based" is equally false.

"Windows" is a brand name. MS developed a string of "Windows" products starting with a GUI system for dos -- sort of like GNOME or KDE for linux, developed the GUI system into a 32 bit OS, then dumped the product line for NT. Describing the Brand Name as "based on another brand name" is just trolling. Asserting that Win95 DMA disk drivers are "based" on a completely different software system is just false. Asserting that they offered little benefit is just ignorance.

[Anonymous Coward]

Re: "This was little help with the DOS-based Windows 9x"

DOS itself was more or less a program loader and a handful if common library functions. It didn't give you any multitasking on its own, but it also didn't really get in the way if you wanted to take full control over the CPU and do anything the system itself is otherwise capable of. DOS extenders like DOS/4GW were practically an OS in their own right, in order to let you run in 32 bit protected mode from DOS. In other words, DOS didn't have to support much, the application developers did, for better or worse.

This is also why LOADLIN was possible, for directly booting a Linux kernel from inside DOS.

[Orv]

Re: "This was little help with the DOS-based Windows 9x"

Wow, that brought back some memories! I'd completely forgotten about LOADLIN until now. It all seemed so new and exciting back then.

[Liam Proven]

Re: "This was little help with the DOS-based Windows 9x"

[Author here]

> That's just trolling, and make you look stupid

Why is it that in the 21st century people interpret "I do not agree with this person" as "this person is an evil troll"?

> but apart from that, DMA was a lot of help with DOS, including with disk access.

Sure, it helped a little bit. A device doing DMA to or from RAM in hardware is quicker than PIO, even in an optimised loop. Generally, if double-buffering isn't required, and if there's no IRQ line clash, and subject to various other factors.

But that is not the point here.

The point is that when the Win95 or Win98 kernel said "load the file at block 0xDEADBEEF into RAM at 0xCAFE01" then the disk controller could take over and do it... but Windows then sat there and waited until it was done.

When WinNT did it, it issued the same instruction and then that thread paused and the kernel scheduled other threads in its place and the OS kept on working. Disk access might be stalled but there was also a global cache and accesses to the cache continued.

This had 2 visible side effects.

[1] If you hit Ctrl+Alt+Esc and watched task manager, as soon as the Intel PIIX driver (or whatever) loaded, you could immediately _see_ CPU usage on heavy disk activity fall from 90+% to 5-10%

[2] Not so much during OS boot because that is by nature disk bound, but if you loaded a big image file or an AVI file into a video editor, _that app_ stalled waiting for I/O to complete but _the rest of the OS kept working_.

These were true even on a uniprocessor PC but the effect was more pronounced on an SMP machine.

And DOS and Win9x could never ever do that. No kernel threads.

[david 12]

Re: "This was little help with the DOS-based Windows 9x"

The point is that when the Win95 or Win98 kernel

If the author had wanted to make that point, they could have done that instead of making the false statement "was of little benefit", and without the suggestion that the Win95 method was "DOS based".

[phuzz]

Re: "This was little help with the DOS-based Windows 9x"

(The person you're replying to is the author.)

[jake]

If anybody is interested ...

PV just dropped 6.11.1 into /testing for slackware-current ...

Personally, I'll give it a miss for a week or three (all my hardware runs just fine on the 5.10.x LTS kernel) ... and may in fact just wait until the 6.12 probable-LTS kernel drops.