Slashdot Mirror

https://www.mjmwired.net/kerne...

Executive Summary: You think you want a stable kernel interface, but you really do not, and you don't even know it. What you want is a stable running driver, and you get that only if your driver is in the main kernel tree. You also get lots of other good benefits if your driver is in the main kernel tree, all of which has made Linux into such a strong, stable, and mature operating system which is the reason you are using it in the first place.

Again with this "a fixed driver ABI would fix all business"

The internal kernal abi changes because it's INTERNAL. If I wrote a piece of software, then someone else proceeded to write a binary that hooked into my software without integrating it properly (getting it to mainline) then when my software changes of COURSE they should expect that some of my internal functions have changed... it's called progress.

You want a stable internal abi, then pick a kernel version, a compiler, an architecture (because even with a single version, changing the compiler WILL change the abi) and stick to it, no changes equals no changes.

Otherwise any change at all would break it.

For further reference, see here

Your argument isn't new, and has been dubunked by respected kernel engineers. See Greg Kroah-Hartman's OLS 2006 keynote and stable_api_nonsense.txt. At best, allowing old drivers to load might provide compatibility for a few minor revisions of the kernel. It's a short step from that to proposing a regular (annual?) ABI update, and then you have drivers that might work for, say, 12 months, but are always ultimately going to break. (I say *might* because who is going to test these old drivers on new kernels? Even with hypothetical ABI compatibility, the reality is that changes in kernel behavior, scheduling, etc. can break a driver). The only way to ensure that a driver gets updated is to have the source. Even with Windows there is no complete compatibility, Microsoft releases a new baseline kernel every couple of years, and your old drivers will not work any more. It is common for companies to not update their old drivers for new Windows releases, which isn't really that useful when you have deployed systems still using that hardware.

Not this hardware abi driver interface bullshit again, you bring it up all the time.. and it is addressed all the time. ( I think this is the third of fourth time I've replied to you on this topic on /. alone, usually long write-ups but don't have the time today)

While this is old, it is something you may find interesting. In short, you don't want a fixed abi, what you want, are stable drivers.

I don't believe you. See Mandatory File Locking For The Linux Operating System. Even with that, all you have to do is clear the gid bit to kill the "mandatory" lock, and the so-called locks are subject to race conditions.

Where were you when I was installing? I could'a used your help!

I'm actually a newbie to Fedora on x86, 12 was my first, before that I ran YDL on my PS3, and before that Sony's wacky Kondara-ized Red Hat 6 on the PS2! So before I first installed Fedora 12 on a cheap Fry refurb I bought to copy over my /home direcotries before I updated my PS3's firmware into non-OtherOS ability, I googled for guides that would tell you what you REALLY needed to do to make your Fedora system usable for end-user type stuff. You know, Flash, 3D, MP3 support...I found this guy's site:

http://www.mjmwired.net/resources/mjm-fedora-f14.html

Saved my ass. Told me what I needed to do in easy steps, so I didn't have to do this:

You forgot:
- Ripping hair out when adding nouveav to modprobe.d/blacklist.conf (as suggested by nv installer) doesn't work
- Searching internet for an hour to figure out that you have to modify the grub configuration

I'm lazy, which is why I went with the rpmfusion way. I've learned over the years with Linux (since May of 2002)...that in many cases the lazy way is the best most non-frustrating way. It's why I have SELinux disabled. I'm no command line emacs lovin guru so the very thought of editing/creating SELinux rules and doing whatever else that needs to be done to SELinux so that it doesn't get in my way makes me shiver.

did try the nv config program, no luck :-(
But hey, I'm not doing any 3D, and nouveau actually seems to be working quite well, taking the "Just Works" title away from nVidia.

Yeah, for 2D, Nouveau works quite well. If I didn't need 3D, I'd be using it because it "just works" without muss or fuss right after an install. It didn't support 3D on the integrated chip my cheap box has, and it doesn't support all the features of the card I got as a christmas gift that I put in it (a cheap ass GT220, but still way better than the 6150SE). Hmmm let me post the pertinent part of my X configuration to compare against...you never know, it might help.

Section "Device"
        Identifier "Device0"
        Driver "nvidia"
        VendorName "NVIDIA Corporation"
        BoardName "GeForce GT 220"
EndSection

Section "Files"
        ModulePath "/usr/lib64/xorg/modules/extensions/nvidia"
        ModulePath "/usr/lib64/xorg/modules/drivers"
        ModulePath "/usr/lib64/xorg/modules"
EndSection

Section "ServerFlags"
        Option "AIGLX" "on"
EndSection

It makes every process spawned by the user that passes through the bash shell add their process ID to a per-user task control group. See the documentation on control groups for more information about exactly what that means, and what what some of the commands involved aim to do. I'm not sure if this is exactly the same impact as the kernel-level patch, which aimed at per-TTY control groups. That might includes some processes that don't pass through something that executes the .bashrc file along the way.

signed-off-by is for the committer. It certifies that they own the code. See http://www.mjmwired.net/kernel/Documentation/SubmittingPatches

There are other tags for people who review the patch, but they aren't required.

Is that why every new NVidia driver has to be recompiled with a stupid shim to fit your running kernel because the Linux devs can't/won't sort out a stable binary ABI for kernel modules?

No. The reason for that is that nVidia won't just free their fucking video driver. That horseshit doesn't happen with Intel drivers. I misstated my original statement, because I should have specified that I was talking about open drivers (which I thought was self-evident given the context, but I'll own up to my omission). But I stand by it. Once a free driver's in the kernel, it's there forever. See also: http://www.mjmwired.net/kernel/Documentation/stable_api_nonsense.txt

If you have a parallel port, an adapter is trivial to build for old joysticks using only passive components. There are Linux drivers for such adapters. I guess there are drivers for Windows aswell.

A Windows driver exists, you can find it if you google ppjoy (parallel port joystick).

If you have a parallel port, an adapter is trivial to build for old joysticks using only passive components.
There are Linux drivers for such adapters. I guess there are drivers for Windows aswell.

Otherwise, it will just perform a word read, and if the pointer isn't aligned you get garbage.
Some but not all arm chips can be told to generate an exception in this case.

from http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/1228.html
ARM processors with full MMUs (e.g. ARM920T) support optional alignment checking where the processor will check every access to ensure it is correctly aligned. The MMU will raise a data abort if an incorrectly aligned access occurs.

Some ARM partners using simple cores such as the ARM7TDMI have implemented alignment-checking for their ASIC/ASSP. This can be done with an additional hardware block external to the ARM core, which monitors the access size and the least significant bits of the address bus for every data access. The ASIC/ASSP can be configured to raise the ABORT signal in the case of an unaligned access. ARM recommends that such logic is included on ASIC/ASSP devices where code will be ported from other architectures.

Linux can use these exceptions to fix up access if you desire (or you can set it up to generate a bus error signal to help in debugging)

from http://www.mjmwired.net/kernel/Documentation/arm/mem_alignment
15 Now for user space applications, it is possible to configure the alignment
16 trap to SIGBUS any code performing unaligned access (good for debugging bad
17 code), or even fixup the access by software like for kernel code. The later
18 mode isn't recommended for performance reasons (just think about the
19 floating point emulation that works about the same way). Fix your code
20 instead!

That's just BS. It is answered by kernel developers several times: http://www.mjmwired.net/kernel/Documentation/stable_api_nonsense.txt [mjmwired.net]

Thanks for sharing that link, its a good one. I especially like these quotes from it:

• You think you want a stable kernel interface, but you really do not, and you don't even know it.
• Assuming that we had a stable kernel source interface for the kernel, a binary interface would naturally happen too, right? Wrong

  I especially liked the 6 good side effects of having your driver in the main kernel tree and the fact that the article points out

  that Linux, not Microsoft, not OS X, supports a LARGER number of different devices “out of the box” than any other operating system in history of computers.

  This is among the common FUD that is spread by proprietary vendors in the hopes (and quite successfully in the past) of keeping Linux adoption down.

  Another FUD statement is that Linux is not widely adopted, when it is actually a much bigger market than Microsoft would like for it to be...and why their marketing machine works overtime to confuse people.

  The problem is definitely NOT Linux, as the example of how they modified the kernel for USB and it is still running at the fastest USB rates possible and that drivers put into the kernel at version .09 still work in kernel version 2.6 and up. Absolutely rock stable if the hardware vendors will put their drivers into the kernel, which many refuse to do.

  There is a solution to the proprietary hardware vendors constantly breaking Linux with proprietary drivers, only purchase your hardware from a Linux hardware PC builder and vendor who knows Linux and will not put proprietary hardware (hardware with no working device drivers for Linux) in their hardware. There are two excellent options: ZaReason and System 76. Both vendors know and build Linux PCs.

  You can always install Windows if you want to on their PCs, but down the road you can depend on the fact that hardware bought from them will continue to work with many different distros of Linux. Meaning there will be more than one operating system that can be used on the hardware years from now.

  So who cares if Microsoft locks down the big box stores to further slow Linux adoption, let them...buy your hardware from a Linux vendor like ZaReason or System 76. At least you know your hardware will work tomorrow and 10 years from now.

  I look forward to the day when either ZaReason or System 76 starts building Linux PCs with Coreboot. (Linux compatible BIOS)

  I predict that Linux will become so popular that proprietary vendors will actually want their drivers in the kernel, if that is where they belong. How many years is anyone's guess.

That's just BS. It is answered by kernel developers several times: http://www.mjmwired.net/kernel/Documentation/stable_api_nonsense.txt [mjmwired.net]

No, it's not "nonsense", and that article doesn't even really address the real issue. It mostly talks about source compatibility (something I never suggested), and only gives the benefits of drivers-in-the-kernel as a tiny bullet list late in the document.

The real issue is this: why do drivers have to reside in the kernel *at all*?

Especially if you're concerned about stability of a system, and even more especially with newer hot-swappable hardware, such as USB devices.

Right now, if your video driver crashes in Vista or Windows 7, Windows'll reboot it and bring your computer right back to where it was before. (It won't even interrupt your game of WOW.) This is how the world should be: allow anybody and their dog to write drivers, but put controls in place to ensure that drivers can't affect the entire system.

Even MORE ideally, Linux would put a system in place where it could run drivers originally written for Windows or OS X. Then you'd get massive hardware support as if by magic.

Bad 3rd party hardware drivers are the cause of 99% of Windows Bluescreens.

And...

I don't understand your statement that the kernel should not contain drivers.

How do you consolidate these two thoughts in your brain?

As: Drivers should be managed by kernel people (which they do). If you wanted to move all drivers outside the (now micro-)kernel, you should have made that point clear.

The grandparent is right: Linux needs a standard and solid driver interface. Not only do hardware makers have to jump the hurdle of "Linux has very few users", the kernel developers have decided to throw in a whole mess of new hurdles which make Linux driver development *harder* than for commercial OSes.

That's just BS. It is answered by kernel developers several times: http://www.mjmwired.net/kernel/Documentation/stable_api_nonsense.txt

They also say:
"We have repeatedly found [Binary modules] to be detrimental to Linux users, businesses, and the greater Linux ecosystem. Such modules negate the openness, stability, flexibility, and maintainability of the Linux development model."
https://www.linuxfoundation.org/collaborate/publications/kernel-driver-statement

For getting a Linux driver, you do not have to spend money/time at all. http://lwn.net/Articles/219791/

So, you start out behind because you don't have a huge user base, and you set yourself further behind because it's harder to write the driver.

Additionally, if you put the necessary scaffolding in place, you could create a system where no drivers run in the kernel, and thus no drivers are able to blue-screen the computer. BeOS did this in, what, 1994? Surely Linux can do it in 2009. Heck, Windows 7 is almost at that goal.

There are a lot of markets Linux can succeed in without addressing this-- ereaders, cellphones, etc-- but on the desktop? This should be priority one.

You can come up with proofs of concept for a lot of things, but the value of Linux lies in its code maintainance. Citing dead operating systems isn't helping. I'd say kernel panics are extremely rare.

Ah so now you're arguing that they should freeze the interface, and prevent any more improvements.

Read http://www.mjmwired.net/kernel/Documentation/stable_api_nonsense.txt

unfortunately column 10 is not the number of sectors written, it is number of milliseconds spent doing IO

http://www.mjmwired.net/kernel/Documentation/iostats.txt

You mean...like...Documentation/SubmittingDrivers? The helpful file that comes with every distribution of the kernel? That lays out a few very specific requirements for getting a driver into the kernel?

Your lack of knowledge doesn't imply a lack of available information. The reason Asus drivers aren't merged lies directly on the Asus developers' own shoulders.

The source is there. If the code is shitty, then the right thing to do is to make it not shitty, instead of adding shittiness to another piece of software to work around it.

Also, note:
Patch #1: Adds an EXT4 specific ioctl. Meaning the interested application must specifically call this. Obviously no current apps do. Maybe databases and such will use it.
Patch #2 and #3: These only apply "if the filesystem is mounted with data=ordered". This is the default setting, but the user or distribution can change it, so the application can't rely on this being true 100% of the time anyway.

As per the documentation, ext4 has 3 modes to choose from with different tradeoffs between performance and reliability. The default is the middle one.

man mount

Look for data=journal

There's more than one mode of journaling in ext[3-4]...

Or if you're too lazy.

It's absolutely true that Linux has a terrible time suspending to RAM (or coming back from suspend) on certain hardware. It has DEFINITELY been improving over the past two years though (one of my systems was fixed around 9 months ago).

First up make sure you are using the latest kernel you can (new fixes for suspend issues seem to have gone into each of the past few kernel releases including the very latest one). If you have the time you might be able to use the OpenSUSE instructions on debugging suspend to RAM to isolate where the fault lies.

Assuming the problem is more than monitor being off (i.e. the system is completely hanging without any binary only drivers being loaded) if you know how to run the very latest kernels (a prerelease 2.6.29) could you file a bug report over on Kernel Bugzilla after you've checked out the Linux kernel suspend debugging howto?

Could you please explain that a bit?

It's my understanding that high throughput drivers usually use DMA.

In my experience polled mode drivers are pretty rare. Especially in high throughput.

That's not quite the reason behind not implementing the stable interface, as I discovered in another thread. The real issue is dependant on the C compiler version and kernel build options which kill compatibility with binary modules

The Linux Kernel Developers disagree with you.

BTW, size doesn't translate into slowness or bugginess ... those two are related to bad design rather than simply having more code

The problem with a stable kernel API is that you can't fix those bad design decisions anymore because somewhere a driver might exist that depends on that old API.

Even so, you still have to have the driver as a slightly seperate component from the kernal, even if it isn't a via a publically stable API

No you don't. That's the whole point.

For everything else, there's already a standard interface through /dev/* for most of the devices.

That's the userspace interface. Over 200 system calls have been added since Linux kernel 0.99 and none of them have been removed. That means programs that ran on Linux in 1992 still run on Linux today. Almost all of the programs that ran on Windows 3.0 simply don't run today on Windows.

That's what a stable API means. Linux has one for userspace, Microsoft does not. However over 50 of those system calls are for compatibility purposes. That's 50 functions that have to be maintained even though there are almost no programs that use them. Microsoft's userspace API is so large it was impossible for them to continue supporting the old `Win16` api.

Less than 20 system calls get added every year. Can you imagine? Less than 20 new public functions every year? And you're seriously suggesting such a schism be introduced into the kernel, while clearly not understanding the costs, and being blissfully unaware the number of conversations that have led into this.

To you, it seems the question should be "why not have a stable kernel API? That would make it easier for hardware manufacturers to make drivers", and I'm saying, since they clearly cannot write drivers anyway, why do we want to go through efforts to have a stable kernel API?

the kernel application binary interfaces are a moving target.

That's why we have glibc, which abstracts that ABI from applications.

Kernel driver interface - the horse was already beaten to death many times ( see here ).

a consistent configuration system, to enable distribution;

Windows tried that with Registry - and it didn't worked. And it will never work since "one size never fits all" requirements of all applications.

native file versioning;

Was tried many times before and failed miserably. As long as majority of files are blobs, versioning on level of file system makes no sense. Versioning on level of applications is implemented already more or less everywhere it was needed and SVN/git is there for the rest of applications.

audio APIs;

See ALSA and its user-space libraries.

See SDL.

and the integration of X11 with apps.

As was shown by FreeDesktop initiative not really needed nor X folks want to be bothered by all the end user bells and whistles.

Finally, he argues that Linux needs a committee to insure that all GUIs work consistently and integrate better on the back-end with the kernel.

Committee?? Buahahhahahaha!!!1!!cos(0)!!!!!!!

All what he says was tried before (see (11)) and generally can be described as "failed".

Ahhh, jealous of the garbage collection, and tempted by the C-like syntax, are we? :)

Fear not, fellow camel-caser, Linux already has Binary Kernel Support for Linux!

SysRq? Uh, I don't know, maybe for SysRq?
Besides, it doubles as "Print Screen", a nice handy button for taking screenshots.

What Scroll Lock does, I'm not sure. I suspect it does the same thing as C-s, in which case yes, it would be a useful button to have. Ah, it also stops scolling during POST.

Besides, not much stopping you from remapping all the buttons that are useless to you to whatever you deem useful..

If you want to let the BIOS "know" you can use the platform option in /sys/power/disk. If this is broken you can use shutdown instead. I believe the former effectively uses S4 and may have beneficial results (e.g. faster startup when powering back on, power light pulsing while hibernating/restarting) if it isn't broken.

If you want to let the BIOS "know" you can use the platform option in /sys/power/disk. If this is broken you can use shutdown instead. I believe the former effectively uses S4 and may have beneficial results (e.g. faster startup when powering back on, power light pulsing while hibernating/restarting) if it isn't broken.

I recall that Linux has a compile-time option for enabling CPU hotplug too: link. However I'm not sure whether it's the same thing.

It's hard to test whether you've broken a driver when you don't have the hardware to test with. Perhaps the future will be Qemu emulation of all the different hardware in your system : )

This is not to say that there need to be tests for things that can be caught at compile time or run time regardless of hardware but there is only so far you can take it.

It's not like the kernel doesn't have any testing done on it though. There's the Linux Test Project which seems to test new kernel's nightly. If you ever look in the kernel hacking menu of the kernel configuration you will see tests ranging from Ingo Molnar's lock dependency tester (which checks to see locks are taken in the right order at run time), memory poisoning, spurious IRQ at un/registration time, rcu torture testing, softlockup testing, stack overflow checking, marking parts of the kernel readonly, changing page attributes every 30 seconds... Couple that with people like Coverity reporting static analysis checks on the code. Tools like sparse have been developed to try and so some of the static checks on kernel developer machines while they are building the code.

But this is not enough. Bugs STILL get through and there are still no go areas of code. If you've got the skills to write tests for the Linux kernel PLEASE do! Even having more people testing and reporting issues with the latest releases of the kernel would also help. It's only going to get more buggy without help...

Fedora 8 had PulseAudio as well. However Fedora 9 seemed to work much better. I have Flash, Sound and Realplayer (i.e. another mozilla plugin) working perfectly in Fedora 9 x86_64. Some notes here: Fedora 9 Guide.

Btw, the "core" has been dropped (FC9 -> F9).

I remember reading somewhere today that this release puts Fedora "back on track for predictability". I wonder if that bodes well for their perception?

In any event anyone who has followed along with the "Fedora Philosophy" knows that they always had the objective of releasing fairly quickly and all the while trying the latest and greatest technologies, however rough they are. You don't have to be a genius to know where the newest technologies end up all polished: RHEL.

I tried out the RC3 release a week ago and felt it a slight notable improvement over Fedora 7 in terms of polish and performance although that's just a brief evaluation. Here are some links (most I just pulled off the last link):

http://fedoraproject.org/wiki/Releases/8/ReleaseSummary
http://docs.fedoraproject.org/release-notes/f8/
http://docs.fedoraproject.org/install-guide/
http://fedoraproject.org/wiki/Bugs/F8Common
http://www.mjmwired.net/resources/mjm-fedora-f8.html

Oh wait ... looks like fedoraproject site is overwhelmed!

This link explains it all.

Indeed, my /etc/acpi/events/power.conf looks like:


# ACPID config to power down machine if powerbutton is pressed, but only if
# no gnome-power-manager is running

event=button/power.*
action=/bin/ps awwux | /bin/grep gnome-power-manager | /bin/grep -qv grep || /sbin/shutdown -h now


If your laptop had a builtin webcam, you could probably get it to take a picture when it was powered on, then E-mail the picture to somewhere.

~
~

Played just fine on my F7 box in Firefox.

Follow this, may haylp ya sum:

Linux needs a stable ABI like I need a hole in my head. Wouldn't you agree?

Well I started on RH5. And it was not easy. But RH has gotten better with every release, and my main system has been RH since RH 6. I do keep a windows box around for some tasks, but that box is not allowed to go online. Fedora 7 has been really, really easy.
The automatic updater has worked 100%. The add/remove software has given me anything I want. No more fussing with dependecies, that is all automatic now. If you have a system with Nvidia graphics you should have no problem with getting accelerated graphics working.
Read this to guide you step by step.
http://www.mjmwired.net/resources/mjm-fedora-f7.ht ml

Good luck, and welcome to the Light Side.

You think you want a stable kernel ABI, but you really don't.

I can easily make 320kbps MP3 rips of the CD, but I don't currently have an .ogg encoder. If you want to "try before you buy," you can follow these instructions for adding MP3 support to FC6. If you'd like me sell you some .oggs, I'd be happy to do so: just send me an email and we'll set that up.

I am curious. Does a "newbie" actually buy a book on a linux distribution? I would assume that plenty of online guides are much easier, cheaper and are (arguably) a better choice.

For example:
http://gagme.com/greg/linux/fc6-tips.php
http://www.mjmwired.net/resources/mjm-fedora-fc6.h tml
http://stanton-finley.net/fedora_core_5_installati on_notes.html

If I'm pessimistic about the "free" part about Linux, would I spend $30 on a book? Additionally, so much changes in a given 6 month period for something like Fedora. Is is really beneficial to recommend a book to someone when any given chapter could be totally outdated for the next release?

The Fedora core doesn't come with the Linux kernel source. This used to be included with the distribution. I dislike the way that you have to monkey around to get the Linux Kernel to compile on Fedora. What is being done to resolve this? http://www.mjmwired.net/resources/mjm-kernel-fc4.h tml. Installing and recompiling the kernel should be simple and straightforward not difficult.

Also Vmware is somewhat difficult to install on Fedora 4. I had to use a patch to get it to work with one of the kernels.

It seems that a lot of people find it difficult to get multimedia apps working on their Linux systems. Last week I installed FC5 on my PIII Thinkpad. Out-of-the-box multimedia support was pretty bad. I didsome searching on Google and found several sites about upgrading. They involved adding new repositories and then installing with YUM. What I did was add the repository and then use the graphical interface to select the packages and click install. it was pretty painless. Now I can even view WMV and ASF files.

Disclaimer: Even though I've never run a Linux desktop until last week, I administrate several linux servers, so I guess I'm not an "ordinary" PC user.

FC5 Tips & Tricks
Personal FC5 Installation Guide

There are some pages: installation guide, installation notes which should be valuable starting points.

I used FC4-test3 for about a month just for testing purposes, and from the few hours I have used FC4-final, it doesn't look there are that many significant changes. The Release Notes and the "Installation Guide" are pretty good starting resources for some issues.

One major trouble I had was GCC4, playing around I found that many had problems compiling under GCC4, so I am wondering if many of the repositories (when they come online) will compile with GCC4 or GCC3.x? ... As a personal choice, I installed GCC3.4 to /opt and found it useful to keep a second compiler around for now. ... If anything, I imagine that many OSS projects will be forced to start looking into supporting GCC4.

As for speed and amazing things, not much really. I did notice that ACPI worked great on my A7V8X-X, which had been bugging me from FC2,3. I don't know how "amazing" the newer Gnome, OOo and other updates are.

SELinux took a huge enhancement and is integrated much tighter. No doubt some will find this annoying, but should be easy to disable.

I was disappointed some things moved to 'Extras' (xmms,xfce), but that's not necessarily bad. I would hate to have 6 cd's to download instead of 5.

Overall okay release so far. I'm sure there will be plenty of issues soon to arrive! There are some general installation notes I have on my website.

To address most of your problems:
Fedora Core 3 Installation Guide
MPlayer Fedora Guide

To address most of your problems:
Fedora Core 3 Installation Guide
MPlayer Fedora Guide

Fedora Core 3 Installation Guide