On Thu, 2006-05-18 at 12:34 +1000, Peter Flodin wrote:

...

Peter Flodin wrote:

...

Excellent! Novell has apparently just 'solved' all Linux driver issues, in a single swoop.

If what they are proposing takes off, it will be really good. The end point if I have understood right, is going to the computer store and there are green lizards on the hardware boxes, saying it has a driver for SUSE.

Exactly. A driver for at least one SUSE kernel. Not a driver for Linux. From the FAQ: "The technology is all open source and included in openSUSE. Novell is

On 5/18/06, Carl-Daniel Hailfinger wrote: providing and explaining the inner workings of this technology to the industry and other Linux vendors. Our intention is to further the general adoption of Linux."

So the scenario is this (shoot me if I am wrong):

I buy some hardware from a vendor that is taking part in this. I install the hardware, and it is registered in Yast as an add-on - this tells YAST what kernel the driver is for and an update URL.

While on this subject, can someone give a simple explanation as to why I need to install a new driver when I go from say 2.6.15 to 2.6.16 or even worse 2.6.15-2 to 1.6.15-3? Is there that drastic a change in the kernel that would render the driver totally useless? perhaps this is the real reason vendors don't supply drivers. What vendor has the man power to keep track of every little kernel change and provide an updated driver for every distribution. If I were a vendor I wouldn't. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998

On 5/18/06, Kenneth Schneider wrote:

On Thu, 2006-05-18 at 12:34 +1000, Peter Flodin wrote:

...

...

Peter Flodin wrote:

...

Excellent! Novell has apparently just 'solved' all Linux driver issues, in a single swoop.

If what they are proposing takes off, it will be really good. The end point if I have understood right, is going to the computer store and there are green lizards on the hardware boxes, saying it has a driver for SUSE.

Exactly. A driver for at least one SUSE kernel. Not a driver for Linux. From the FAQ: "The technology is all open source and included in openSUSE. Novell is

On 5/18/06, Carl-Daniel Hailfinger wrote: providing and explaining the inner workings of this technology to the industry and other Linux vendors. Our intention is to further the general adoption of Linux."

So the scenario is this (shoot me if I am wrong):

I buy some hardware from a vendor that is taking part in this. I install the hardware, and it is registered in Yast as an add-on - this tells YAST what kernel the driver is for and an update URL.

While on this subject, can someone give a simple explanation as to why I need to install a new driver when I go from say 2.6.15 to 2.6.16 or even worse 2.6.15-2 to 1.6.15-3? Is there that drastic a change in the kernel that would render the driver totally useless? perhaps this is the real reason vendors don't supply drivers. What vendor has the man power to keep track of every little kernel change and provide an updated driver for every distribution. If I were a vendor I wouldn't.

You didn't actually read the pages did you? This is the whole point of what Novell is proposing. Vendors will be notified of kernel changes, Novell will build some of these drivers on the behalf of vendors, some vendors will build themselves, some will use the resources of openSUSE (which I can only assume is the build server). I never understood why the build server was advertised as it will be able to build packages for other distros, but the pieces are starting to fit together. Time is the last judge of everything, but this all has the potential of being significant for Linux in general. Peter 'Pflodo' Flodin.

On Thu, May 18, 2006 at 12:34:58PM +1000, Peter Flodin wrote:

From the FAQ: "The technology is all open source and included in openSUSE. Novell is providing and explaining the inner workings of this technology to the industry and other Linux vendors. Our intention is to further the general adoption of Linux."

It reads as if openSUSE is a distribution. Also the other places where openSUSE is used could be confusing and misleading. As I see it openSUSE is a community, a group of people, not a process or a technical entity, like a Distro or a buildservice. I know it is a wiki, so I can easily change it. I just want to know if others see the words openSUSE here as a group of people or as something technical. (also each word openSUSE should link to opneSUSE.org, but that is another issue) -- houghi http://houghi.org http://www.plainfaqs.org/linux/ http://www.netmeister.org/news/learn2quote.html

Today I went outside. My pupils have never been tinier...

On Thu, May 18, 2006 at 04:04:36AM -0400, Carl Hartung wrote:

Well, since you've asked: "openSUSE" strikes me as a pretty decent 'brand' name in it's own right. It's a great context-neutral 'wrapper' or 'umbrella' for the entire realm. It certainly 'rolls off the tongue' easily and is a nice fit for both contexts, community *and* 'product'. There is also a strong complementary 'brand recognition' factor, as well, since "open" is now ubiquitous, hence familiar and understood. Prepending it to the original 'SUSE' brand name, I think, makes the 'product' sound more accessible, or 'friendly.' Maybe less daunting, too? In short, I think people are gravitating towards using openSUSE as a 'catch-all' or 'ad hoc' label because it really is a natural fit for both purposes.

I do not want to start a discussion about the name openSUSE. I just want to know if it is used correctly with the definition we have NOW. From what you write I can only get that it is not so, so I will change it on the wiki. Wether or not openSUSE should be a catch-all is a discussion to be helt in another thread. -- houghi http://houghi.org http://www.plainfaqs.org/linux/ http://www.netmeister.org/news/learn2quote.html

Today I went outside. My pupils have never been tinier...

Peter Flodin wrote:

On 5/18/06, Carl-Daniel Hailfinger wrote:

...

Exactly. A driver for at least one SUSE kernel. Not a driver for Linux.

So the scenario is this (shoot me if I am wrong): [...] If I go and update my kernel, YAST knows there is a dependency from this driver and it will go and check the update URL, if the vendor is good, they will have updated their driver (perhaps even using the openSUSE Build Service), and my kernel is updated along with driver.

"If the vendor is good", the support level will be as good as in older SUSE versions. That's good. If you're running your own kernel under SUSE, you're still stranded. Maybe I'm less positive about this because I almost always have to build my own kernels on important machines (because of suspend-to-ram quirks or because I need a feature only available in newer kernels). Unless the vendors provide the source for their drivers, they are useless for me. Regards, Carl-Daniel -- http://www.hailfinger.org/

On Thu, May 18, 2006 at 08:58:30AM +0200, jdd wrote:

Peter Flodin wrote:

...

If what they are proposing takes off, it will be really good. The end point if I have understood right, is going to the computer store and there are green lizards on the hardware boxes, saying it has a driver for SUSE.

"If updated drivers matching the kernel version of the security update are available, YaST will fetch and install them alongside the security update, else it will interact with the user and guide them on how to proceed. "

don't seems very different from the preceding situation.

just Novell offers a collaborative effort (good), but will the harware vendors do?

it seems the kernel structure have some problem with hardware drivers

The whole thing is mostly infrastructure... You see it in 10.1 already: - support for external installation sources was a key feature for this - the kernel provides enhanced checksum for various parts rpm -q --provides kernel-default .... kernel(mm) = 3d6b445a058e7d3f .... - The kernel modules require those checksums rpm -q --requires wlan-kmp-default ... kernel(mm) = 3d6b445a058e7d3f ... - YaST/Zmd can check those requires / provides and fetch fixed / changed kernel modules automatically when fetching the new kernels. Ciao, Marcus

On Thu, May 18, 2006 at 09:30:27AM +0200, jdd wrote:

Marcus Meissner wrote:

...

- YaST/Zmd can check those requires / provides and fetch fixed / changed kernel modules automatically when fetching the new kernels.

yes, I understand the process. However this dont mean the modules exists.

and the checksum may be broken for a kernel part not at all related to this particular module, isn't it (depends of what "various parts" are :-()?

? There is fallback handling if on upgrade a newer driver is not yet asupplied. Ciao, Marcus

On Thu, May 18, 2006 at 02:39:52PM +0200, jdd wrote:

Marcus Meissner wrote:

...

On Thu, May 18, 2006 at 09:30:27AM +0200, jdd wrote:

...

Marcus Meissner wrote:

...

- YaST/Zmd can check those requires / provides and fetch fixed / changed kernel modules automatically when fetching the new kernels.

yes, I understand the process. However this dont mean the modules exists.

and the checksum may be broken for a kernel part not at all related to this particular module, isn't it (depends of what "various parts" are :-()?

?

There is fallback handling if on upgrade a newer driver is not yet asupplied.

I did not understand your question either ...

sorry, I don't understand "fallback handling"? on a security patch, you can't go back to the preceding kernel?

If a kernel module is not recompiled in time for a kABI changing update, the previous version is tried. Ciao, Marcus

On Thu, 2006-05-18 at 14:54 +0200, jdd wrote:

Marcus Meissner wrote:

...

If a kernel module is not recompiled in time for a kABI changing update, the previous version is tried.

the basic problem is that when a new kernel is installed, the old module don't works anymore (vmware, for example)

If I understand well, in such a case the old module is tested to see if in runs ?

But it won't even install because the kernel version<> module version. Which was the point to my previous question about why a driver cannot be used with a newer kernel version. The 2.6 kernel is still the 2.6 kernel even if it has .3-5 or .3-55 at the end. If someone writes a driver for the 2.6 kernel it should work no matter what revision level the kernel goes to. But then I am not a programmer only a frustrated user. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998

Kenneth Schneider wrote:

But it won't even install because the kernel version<> module version. Which was the point to my previous question about why a driver cannot be used with a newer kernel version. The 2.6 kernel is still the 2.6 kernel even if it has .3-5 or .3-55 at the end. If someone writes a driver for the 2.6 kernel it should work no matter what revision level the kernel goes to. But then I am not a programmer only a frustrated user.

Since I am a kernel programmer, please let me explain. The 2.6 kernel series has been going through a remarkably fast evolution since the 2.6.0 release in December 2003. This speed was only possible because the internal kernel interfaces could be changed continuously to match newer requirements. All in-kernel drivers were automatically adapted to the new interfaces on each change, so this was no problem. External drivers, on the other hand, suffer with each interface change. That's why all kernel developers want drivers to be submitted to the standard kernel as soon as possible. Note that so-called stable series (e.g. 2.6.16 -> 2.6.16.12) used in Linux distributions almost never change any interfaces. There are a few reasons why drivers are not submitted to the kernel: * the driver authors do not want it -> their fault, their users suffer. * the driver authors don't know about submitting -> educate them. * the driver crashes or corrupts data from time to time and thus gets rejected -> help the authors with testing so they can fix their bugs and submit the driver. There is one additional reason why a driver is not in the kernel you're working with: * the driver was written or submitted after release of that kernel -> you need a backport of the driver for that kernel, which can be provided by either Novell Developer Services or the device vendor. "But why can't I use a driver for 2.6.16.x also for 2.6.16.y?" Simple. It works perfectly most of the time. There are two reasons why it may fail: 1. A (security) bug is discovered in one driver interface and it has to be changed to fix that bug. Happens rarely. (Solaris had such a bug which could be exploited for years because they didn't want to change the interface.) 2. The driver uses tricks which depend on bugs and peculiarities of a certain specific kernel or on the meaning of special flags which are declared not-for-drivers. Happens often, especially with vmware/nvidia/ati drivers. It is never a good idea to depend on things you're not suposed/allowed to use. Hope this answers your question. Regards, Carl-Daniel -- http://www.hailfinger.org/

On Thu, May 18, 2006 at 01:30:54PM -0200, Alexey Eremenko wrote:

...

Since I am a kernel programmer, please let me explain. The 2.6 kernel series has been going through a remarkably fast evolution since the 2.6.0 release in December 2003. This speed was only possible because the internal kernel interfaces could be changed continuously to match newer requirements.

Is there any hope to make kernel external driver API (must have stable interfaces) for third party developers (like nvidia & vmware) - so that their drivers will work well with *all* distros and *all* future versions?

No. Ciao, Marcus

On Thu, 2006-05-18 at 17:16 +0200, Carl-Daniel Hailfinger wrote:

...

Since I am a kernel programmer, please let me explain. The 2.6 kernel series has been going through a remarkably fast evolution since the 2.6.0 release in December 2003. This speed was only possible because the internal kernel interfaces could be changed continuously to match newer requirements. All in-kernel drivers were automatically adapted to the new interfaces on each change, so this was no problem. External drivers, on the other hand, suffer with each interface change. That's why all kernel developers want drivers to be submitted to the standard kernel as soon as possible. Note that so-called stable series (e.g. 2.6.16 -> 2.6.16.12) used in Linux distributions almost never change any interfaces.

One more thing, keep up the good work and keep in mind that there will always be people the will moan, groan, bitch and complain about interoperability only because we do not know the full inner workings of

On Thu, 2006-05-18 at 11:41 -0400, Kenneth Schneider wrote: the kernel. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998