Linked by Thom Holwerda on Fri 29th Jul 2005 19:02 UTC, submitted by diegocg
Linux Every year most Linux hackers attend a conference where they talk about all those topics only kernel hackers talk about. Papers of all the talks are now available, with a wide range of topics: NTPL, XEN, page cache performance, I/O scheduling, future ext3 development, VM, and more. Also, as every year, LWN's excellent kernel summit coverage is now freely available.
Thread beginning with comment 11012
To read all comments associated with this story, please click here.
ask osnews
by butters on Fri 29th Jul 2005 21:32 UTC
butters
Member since:
2005-07-08

Since this post is hard to have a flame war about, I will start things off with a question:

Form reading the coverage of the Linux Kernel summit, it seems that kernel development is increasingly being pushed around by 3rd party hardware and software vendors. Although the outside interests would like to have it their way, the kernel developers remain grounded in their commitment to the community model. Do you think that the Linux kernel developers should continue encouraging 3rd parties to play by the community's rules (and risk slowing or stalling Linux adoption), or should they allow 3rd parties to retain control over mainline kernel modules specific to their products? To what extent?

I recommend reading http://lwn.net/Articles/144269/ for some background.

Reply Score: 1

RE: ask osnews
by Lumbergh on Sat 30th Jul 2005 04:22 in reply to "ask osnews"
Lumbergh Member since:
2005-06-29

The link you point to is a great example of the contradicting goals of hardware manufacturers and what Linus wants.

Until there is a little give and take on both sides there's always going to be driver issues with linux. And until there is a stable kernel API nothing is likely to change.

Reply Parent Score: 1

RE[2]: ask osnews
by on Sat 30th Jul 2005 17:27 in reply to "RE: ask osnews"
Member since:

The link you point to is a great example of the contradicting goals of hardware manufacturers and what Linus wants.

Until there is a little give and take on both sides there's always going to be driver issues with linux. And until there is a stable kernel API nothing is likely to change.


It is a great summary of the conference.

As for give and take...I don't see a good way to do it except for;

* Move all propriatory bits to firmware.

* Start development on 3rd party drivers in the open as part of the mainline kernel. (Includes treating the drivers as open source even prior to public disclosure. This eliminates some problems with the transition.)

* Drop the idea that the ABI will eventually be stable.

That last one is important for many kernel developers because;

* If the ABI were stable, closed drivers would become common and would cause developers to spend time tracking down phantom problems with drivers they don't have the source to. (This is the reason for the kernel tainted flag.)

* If the ABI were stable, there would be one fewer reason to bring the drivers into the mainline kernel source.

* If the ABI were stable, it could not be improved.

Reply Parent Score: 0

RE: ask osnews
by on Sat 30th Jul 2005 16:24 in reply to "ask osnews"
Member since:

Do you think that the Linux kernel developers should continue encouraging 3rd parties to play by the community's rules (and risk slowing or stalling Linux adoption), or should they allow 3rd parties to retain control over mainline kernel modules specific to their products? To what extent?

If the source will be open, and 3rd parties want to 'retain control' over mainline kernel modules...they can, though not in the sense of being the only place to go. They have to put up or get out of the way. Basically, the whole idea of 'control' in OSS is based on deed; if you do it, you have control...if you don't or others do a better job...you do not have as much control.

For example: Next Tuesday, if Linus decides that he is more interested in finger painting and drops any future coding, someone will replace him. He is not the leader of the Linux kernel project now because he started the project. He is the leader because he leads well and is trusted. He is in control based on merit. He is in control based on effort. He is in control based on trust.

Any other person or group -- corporate or private -- has a chance to do the same. If they are able and willing is another question entirely.

If you are talking about closed source, they can use methods like Nvidia's and some of the binary software modem drivers do; release a binary (closed) with an open sourced kernel driver.

What they loose is;

* The ability to get feedback and source changes.

* Any end user or developer support from the kernel developers.

What they gain is;

* The ability to keep the source closed. In some cases, this is necessary though the legitimate cases are very small.

Reply Parent Score: 0

RE: ask osnews
by on Sat 30th Jul 2005 17:13 in reply to "ask osnews"
Member since:

OK, after going back and reading the fine article, I do have one basic idea besides the normal knee-jerk reactions to people who only like to stir hornets.

To set the stage, here are what seem to be the core issues that have 3rd parties interested;

* ABI stability specifically to support closed source.

* Reuse of object code developed for Windows. (Not specifically stated, but implied in a few places by multiple people.)

* Keeping business plans secret as long as possible.

The problems that the mainline kernel developers have with these are;

* ABI + closed source: If something goes wrong, the source isn't available to debug the problem. This is much of the problem with Windows drivers. To solve that, Microsoft introduced a beurocratic method to certifify drivers on that platform.

* Reuse of Windows binary object code: The problem with this is that the decisions made to develop a Windows driver aren't necessarily optimal for Linux. Ham fisted approaches to force the OS to do what is required can cause problems that lead us right back to the same problems mentioned above. Also, since Windows object code targets only x86 processors, any bugs that are hidden under x86 may show up when recompiled for other platforms...if they are recompiled at all.

* Secrets in general: Can't write code or debug if there are too many.

The solution that seems to make the most sense is to treat the commercial driver like a public project as soon as possible -- even well before it can be disclosed to the public for business reasons.

Before release to the public, get good developers, give them time, and write code based on the idea that it will be ported. Start development in an open manner before public disclosure, put any propritory bits that do not tightly interact with the OS in firmware, and transition to public development with working code and cheap developer samples. At that point, getting the code included in the mainline kernel is more likely as the parts that matter to the device users are fully disclosed. Documentation of the hardware would also be nice.

Reply Parent Score: 0