2.4.14-pa1 seems to works fine on my B180

Hi all,

For my part 2.4.14-pa1 seems to works fine on my B180L (without or with modules).
Kbd unplug replug ok.
XFree86 seems to works as well as with 2.4.9 (personnaly I run Xfce-3.8.11 with the kind fondecran from ESIEE: nice).

Congratulation to all (a so nice job in so short time :))
Joel

-------------------------------------------------
This mail sent through Tiscalinet Webmail (http://webmail.tiscali.be)

Astro based machines (eg C3000) still HPMC with:

	sync; cd/tmp; cp /boot/vmlinux .; sync;

I found one nit in sba_dma_supported() but that's not the problem. Has anyone tried C200 (or similar? ie something with ccio)

thanks,
grant

Hello,

The latest snapshot on ftp.parisc-linux.org seems to be:

linux-20011108.tar.gz 08-Nov-2001 15:58 26.8M

Why aren't snapshots being generated automatically anymore? I don't have access to CVS, so that's why I need the snapshots; and I guess someone wanting to start keeping current with CVS would prefer downloading a snapshot and updating that, rather than checking out from scratch?

Regards,

Albert

On Thu, 2001-11-15 00:41:48 +0200, Albert Strasheim <[email protected]> wrote in message <[email protected]>:

...which remembers me that I emailed with Grant these days about making the CVS repository available via rsync. He also thought that that would be a nice thing to have... I volunteered to do the setup if time is all off. How about that?

MfG, JBG

Jan-Benedict Glaw   .   [email protected]   .   +49-172-7608481
	http://lug-owl.de/~jbglaw/software/snapshot2cvs/

I've heard nothing back about this. Sorry - I can't autonomously give out logins to the cvs machine or I would have already.
Do you have a URL for a short how-to?
I might take a crack at it if no one else with access speaks up.

grant

I set up my home computer as an rsync server to mirror some stuff to school. This is a PC running suse 7.2. If i remember correctly, the steps were:

1. Install it, of course.
2. Enable the server in /etc/inetd.conf

rsync stream tcp nowait root /usr/sbin/tcpd /usr/sbin/rsyncd --daemon

3. Edit the configuration file, /etc/rsync.conf. Here is an example of an anonymous setting:

gid = users
uid = nobody
read only = true
use chroot = true
transfer logging = true
log format = %h %o %f %l %b
log file = /var/log/rsyncd.log

[Example]
path = /home/Example
comment = An Example

     Rafael

4. Adjust, test, and maintain the firewall
5. Write and maintain a blurb for the parisc-linux.org web site so more than one person can use this.
6. Answer questions from people who don't know how to use rsync or who have problems. Some people will try it because it's there, not because it is useful for them.

Sorry I was unresponsive about this but I'm just not real excited about it. I was tempted to say "find 3 more people who will say they will use this service and then let's do it".

	-P

I use this command:

cd /your/localCVScopy/ rsync -avzc --progress --stats thepalinux.host.com::Example .

will retrieve the Example directory in archive and compressed mode, a little verbose too. Note that this will overwrite any modified file you have in your tree.

     Rafael

On Wed, 2001-11-14 19:47:05 -0700, Paul Bame <[email protected]> wrote in message <[email protected]>:

I think it won't be that hard to find 3 people willing to use it. It was my idea to install it, so, of course, I'm willing to use it (I already use this for the MIPS linux CVS tree at oss.sgi.com and I absolutely *love* it!).

MfG, JBG

Jan-Benedict Glaw   .   [email protected]   .   +49-172-7608481
	http://lug-owl.de/~jbglaw/software/snapshot2cvs/

Quoth Grant Grundler:

I've not responded individually to the comments in the thread following this post, but I think there's a bit of confusion.

There's not much point in setting rsync access to the CVS repository, except for mirroring purposes. (And even then, you probably would only want it to be rsync in one direction; maintaining two or more live CVS repositories and attempting to keep them synchronised with rsync would be an exercise in hard work.)

What is useful though, and what is being done by several projects, is to maintain one or more checked-out trees from their CVS repository and have these trees available by anonymous rsync. Most popular CVS projects don't branch, and so this is very easy: a regular cron job keeps a CVS HEAD checkout fresh, and the tree is served by rsync or some other server of choice (ftp/http).

The usefulness of this - as it is not replacing cvs in any way - is that a user may easily bring their tree in sync with HEAD (or whichever branch is being tracked) and then still be able to perform the usual cvs operations on it (eg diff, log etc).

I know that I would make use of an anonymous rsync service if it were available. I do agree with the point made by some others though, that if advertised there are likely to be people who will try it just for fun and then generate a lot of list noise when they have problems. On the other hand, this is a risk you also take by putting up a CVS server, or running a mailing list. There's a balance there somewhere. =)

Andrew.

Andrew Shugg <[email protected]>                   http://www.neep.com.au/

"Just remember, Mr Fawlty, there's always someone worse off than yourself."
"Is there?  Well I'd like to meet him.  I could do with a good laugh."

Indeed ;-)
I would like to get my hands on a recent snapshot as well. Thanks.

Kenneth

----- Original Message -----
From: "Albert Strasheim" <[email protected]>
To: <[email protected]>
Sent: Wednesday, November 14, 2001 11:41 PM
Subject: Re: [parisc-linux] 2.4.14-pa1 seems to works fine on my B180

I'd be willing to try, but will the new kernel build with the old, pre 'don't apt-get upgrade!!' userland tools?

Thanks,
Jurriaan

Holed up in your little room, we talk for hour on empty hour,
pacing up and down between the walls that we have built ourselves.
	New Model Army - Long Goodbye
GNU/Linux 2.4.15-pre4 on Debian/Alpha 64-bits 990 bogomips load:0.08 0.21 0.15

Hello Jurrian,

Quoting Jurriaan on Alpha <[email protected]>:

You could be confident, I successfully re-compile the kernel from a cvs checkout on my B180 natively (what I do from some month now) with a running kernel 2.4.9-pa78.

Have a nice kernel :<)) ,
Joel

-------------------------------------------------
This mail sent through Tiscalinet Webmail (http://webmail.tiscali.be)

Yes, I've hooked up some FW/Diff disk behind the Bluefish card in the C200 trying to duplicate the scsi error seen by other people, I have effectively been doing this in a continous loop on serveral disks in parallel ... works for me(tm).

mkp is not seeing the disk corruption using the 2.4.14-pa1 kernel on his C160 either, which used to corrupt this way also....

Not that this is much help, but hopefully will provide a data point ....

- Ryan

Ryan Bradetich wrote:
...

I found the bug in sba and it seems that ccio has the same bug. The basic problem was coalescing of DMA mapping requests was resulting in DMA requests bigger than DMA_CHUNK_SIZE.

thanks to all who responded.

grant

ps. I found the bug pretty quickly once I enabled ASSERTs
that I had embedded in the code when I wrote it.

Hi everybody,
Just got a HP K class 9000 series with dual 240Mhz PA-RISC 8200
processors,32 serial ports, 24 scsi drives, 6 ups's, dat drive and fast wide diff scsi tape drive in a 2 m case. Electrician comes over tomorrow to hook it up for me. Im totaly new to this architecture.

Whats the current state of linux on parisc, is it stable enough to deploy as a web/mail server?

Regards
Robert Stanford

On Tue, 2001-12-18 21:28:42 +1000, robert stanford <[email protected]> wrote in message <1008674922.25986.4.camel@rotapile>:

*plonk*

SCNR, JBG

Jan-Benedict Glaw   .   [email protected]   .   +49-172-7608481
	 -- New APT-Proxy written in shell script --
	   http://lug-owl.de/~jbglaw/software/ap2/

Jan,
If that was you falling over, that's about right.
But dropping a K-class would be a bit louder ;^)

Robert,
K-class is only partially supported.
serial ports you probably can forget.
Anything connected via HP-PB slot (aka NIO) doesn't work either. Search the mail archives (lists.parisc-linux.org) for "K-class" for hints on getting a K-class booted.

grant

Jan-Benedict Glaw <[email protected]> said:

[...]

mirror is smarter than that...

So? A script that is smart enough can figure them out too...

With mirror you can use file patterns to include/exclude (e.g. get just the .bz2 versions (not redundant .gz)), only consider "new" files (i.e., exclude anything more than a week old), etc.

Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Followup to:  <[email protected]>
By author:    Horst von Brand <[email protected]>
In newsgroup: linux.dev.kernel

You can do that with rsync as well. If there is something specific you need that isn't there I'm sure if you report it it will be there soon, too.

-hpa

Jan-Benedict Glaw <[email protected]> said:

[...]

Besides, if you haven't got access to the hardware involved and relevant test cases, your efforts can be positively harmful.

Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

On Fri, 2004-06-18 23:34:08 -0400, Horst von Brand <[email protected]> wrote in message <[email protected]>:

Well, there's a second direction of patch flow: Linus' Latest'n'Greatest towards custom trees. I'm quite sure most vendors will do constant builds and any breakage will (in a fast manner) be detected quite soon...

MfG, JBG

   Jan-Benedict Glaw       [email protected]    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[...]

Git-bisected-to?

Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513

Nice Box :)

Hi Folks,

I am writing this message to bring a huge problem to light. SuSE has been systematically forking the linux kernel and shipping all kinds of modifications and still call their kernels 2.6.5 (for example).

Either they ship the stock Linux kernel sources or they stop calling their distributions as Linux-2.6.x based.

Kernel headers are being changed willy-nilly and SuSE are completely running rough-shod over the linux kernel with the result ONLY software from SuSE works.

Enclosed is a simple diff between SuSE's so-called Linux 2.6.5-7.75-bigsmp and the Linux 2.6.5 kernel sources from www.kernel.org:

Files linux-2.6.5/arch/i386/boot98/setup.S and linux-2.6.5-7.75/arch/i386/boot98/setup.S differ Files linux-2.6.5/arch/i386/defconfig and linux-2.6.5-7.75/arch/i386/defconfig differ Only in linux-2.6.5-7.75/arch/i386: defconfig.bigsmp
Only in linux-2.6.5-7.75/arch/i386: defconfig.debug
Only in linux-2.6.5-7.75/arch/i386: defconfig.default
Only in linux-2.6.5-7.75/arch/i386: defconfig.smp
Only in linux-2.6.5-7.75/arch/i386: defconfig.um

I would invite anybody to do a diff between the Linux 2.6.5 from kernel.org and SuSE 9.1's Linux 2.6.5 kernels.

This is absolutely not our problem and we don't know who to contact at SuSE to fix this problem. Our software works perfectly with Fedora/Debian/Gentoo/Mandrake/Redhat/etc.

I think SuSE's lying when they call their Linux kernel a 2.6.5 kernel when there are massive differences. They aren't even compatible with Linux 2.6.6.

I urge all those who have the power to sway distributions to immediately fix their kernels so that small developers like us don't have to keep updating our software. This is worse than Microsoft's practices.

best regards

Dev Mazumdar
President
---------------------------------------------------------------------
4Front Technologies
4035 Lafayette Place, Unit F, Culver City, CA 90232, USA
Tel: 310 202 8530 Fax: 310 202 0496 URL: http://www.opensound.com
---------------------------------------------------------------------

Ok. They edit setup.S. This doesn't change APIs.

SuSE doesn't ship the default kernel .config. *SHOCK!* Neither does anyone else.

And added their own configs for the kernels rpms they roll. What a travesty!

I don't know what you were trying to prove, but thanks for failing miserably.

Regards,

Kyle McMartin

Well, Slackware Linux usually ships with an unmodified kernel.org kernel (there are rare cases of patches that fix security issues though). I find this a very nice property of Slackware since there are never any problems when replacing the default kernel with a custom build kernel.org one... There are other minor distributions that also ship with kernel.org kernels - I don't have a list at hand, but I've run into several over the years.

--
Jesper Juhl <[email protected]>

Whoops, should have read the parent email better. Slackware does not use the default kernel .config, it does however use the kernel.org source without additional patches.. I agree, nobody ships a defconfig kernel.

--
Jesper Juhl <[email protected]>

Jesper Juhl <[email protected]> said:

[...]

I have been running stock Linus kernels for ages on Red Hat. Sure, RH patches their kernels extensively, but the trouble is usually with stuff like modutils and such needed for the experimental series.

Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Umm. They said they're linux-2.6.x based ... ie they're BASED on 2.6, not identical. No major vendor ships completely virgin source.

I think you're getting somewhat carried away. Yes, there are lots of mods. Most of them are merged back into mainline already (as of 2.6.7).

So what's broken then? Specifically which kernel interface are you calling that has a broken behaviour?

They didn't say it was 2.6.5, they said it was based on it.

In what way?

I'd be more inclined to suspect you're relying on some behaviour that isn't really defined ...

And no, I don't work for SuSE.

M.

Our commercial OSS drivers work perfectly with Linux 2.6.5, 2.6.6, 2.6.7 and they are failing to install with SuSE's 2.6.5 kernel. The reason is that they have gone and changed the kernel headers which mean that nothing works.

For instance our kernel interface module doesn't compile anymore we see the following errors:

Why is this happening?. It's working fine with Linux 2.6.5 and also worked with Linux 2.6.4 kernels from SuSE 9.1

best regards
Dev Mazumdar
---------------------------------------------------------------------
4Front Technologies
4035 Lafayette Place, Unit F, Culver City, CA 90232, USA
Tel: 310 202 8530 Fax: 310 202 0496 URL: http://www.opensound.com
---------------------------------------------------------------------

Bad luck. The OSS and ALSA driver in the kernel tree work fine even with SuSE's tree ;-)

And now stop trolling. I don't like the gazillions of crappy IBM patches in their tree either but people that are too clueless to build their own code shouldn't complain.

Are you seriously trying to tell me that you write drivers, and you can't figure out a simple include file dependency problem?

M.

On Fre, 2004-06-18 at 02:27, 4Front Technologies wrote:
[...]

[ compile errors ]

What is SuSEs answer to the question since it it obviously a bug in their kernel?

Bernd

Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Hello,

Not really. The 2.6 kernel series allow to put output files in a different directory than the sources -- see the O= option; there is a little documentation in the main Makefile. Without the O= option, the kernel sources and object files needed to compile external modules will reside in the same directory. With the O= option, they will reside in different directories. This means that a single /lib/modules/$(uname -r)/build symlink is not sufficient anymore. Therefore we have the build symlink pointing to the output files, and a new source symlink pointing to the real source tree. This change hasn't found its way into mainline yet, which is unfortunate. For the discussion, see
http://marc.theaimsgroup.com/?l=linux-kernel&m=108628265102121&w=2 and follow-ups. I keep pinging Sam Ravnborg (the kbuild maintainer), but apparently he is busy with other projects at the moment.

In addition, there is an extra Makefile in /lib/modules/$(uname -r)/build that has the usual targets needed for module building, so the traditional way of building modules (make -C /lib/modules/$(uname -r)/build modules SUBDIRS=$(pwd)) still works. There is no need to build scripts, scripts_basic, or whatever in that directory.

Based on this difference, there are two principal ways to build external modules since 2.6.7 (and through back-porting also in the current SUSE kernels, which are based on 2.6.5). We chose to ship the kernel sources in /usr/src/linux in a (mostly) unconfigured state, and put the output files needed for building external modules below /usr/src/linux-obj/.

This means that you have several choices:

- Configure the kernel sources in /usr/src/linux as you wish.

- Use one of the standard SUSE configurations.

I have written a HOWTO describing how to work with the SUSE kernel sources, which is available as /usr/src/linux/README.SUSE in our packages. An up-to-date online version is available at
http://www.suse.de/~agruen/kernel-doc/.

Sincerely,

Andreas Gruenbacher <[email protected]>
SUSE Labs, SUSE LINUX AG

On Fri, 2004-06-18 at 17:48, Andreas Gruenbacher wrote:

Hi,

Once again, please do not do this. As some others already have pointed out already, many (of not most) projects out there that builds against the running kernel use '/lib/modules/$(uname-r)/build' to locate the SOURCE, and will be broken. Rather use an 'output' or some such symlink to store the object files, but keep the meaning of 'build' intact.

If, then please treat it like any other stable interface, and depreciate it in 2.7, and change (but better, remove it, so that there will be no misunderstanding) in 2.8.

Thanks,

Martin Schlemmer

[SNIP]

Andreas,

Thanks for the perfect explanation to our problems. The question then arises as to why does SUSE do KBUILDS in this way and the vanilla kernels or Redhat/Fedora/Mandrake/Debian kernels use another way?. What I'd like to see is at least some standard.

SuSE's Linux 2.6.4 kernels did it the Vanilla kernel way where /lib/modules/2.6.4/build pointed to /usr/src/linux.

The issue is also SuSE's 2.6.4 kernel added the REGPARM patch which was only introduced in Linux 2.6.5 for example. Wouldn't it be better if SuSE had shipped their kernel as Linux 2.6.5?. The point is what constitutes a "baseline" Linux kernel?. You can add all your patches but if now the kernel is more in tune with Linux 2.6.7, just call it Linux 2.6.7 - calling it 2.6.5 will break a lot of software. that isn't included with your kernel sources.

I don't care if SuSE adds patches to drivers but to patch the base kernel/headers in way that breaks out-of-kernel drivers is something we would like to see addressed.

Ofcourse we will now have to modify our software to detect a SuSE distribution but it's waste of time and energy because the other distros don't use your concepts. If you deem that your way of building modules is the "right thing" then I'd love to see Linus move to such a system in his vanilla kernel source tree.

Most out-of-kernel drivers like ours or other vendors simply rely on kernel include files and not on the actual .c files. THe location and contents of such kernel includes should be inviolable if there is a kernel version associated with it.

best regards

Dev Mazumdar
---------------------------------------------------------------------
4Front Technologies
4035 Lafayette Place, Unit F, Culver City, CA 90232, USA
Tel: 310 202 8530 Fax: 310 202 0496 URL: http://www.opensound.com
---------------------------------------------------------------------

Sounds like you're making a demand. Who are you and why are we interested in your demands?

Timothy,

Who are you to revoke my request to SuSE and other distributors and others who share my views on LKML?

What is wrong with making a demand for standardization?. It's high time that things got a bit more organized. And where do you see a demand....I just said "like to see". Which is more of a request the way I understand English.

It's high time people like me spoke up for standardization and some sense of organization. If the majority doesn't want to listen fine, it's a free world, but you have no right to silence me for airing my views.

best regards

Dev Mazumdar
---------------------------------------------------------------------
4Front Technologies
4035 Lafayette Place, Unit F, Culver City, CA 90232, USA
Tel: 310 202 8530 Fax: 310 202 0496 URL: http://www.opensound.com
---------------------------------------------------------------------

Who are you to demand it in the first place. As far as I can see, you've contributed nothing notable to the kernel development community (But please correct me if I'm wrong). Why should we listen to you, when you haven't given us reason to. All you've done is demand things of the LKML, but why should we listen to your demands instead of our own.

If you want things more organized, then please code it up and submit a series of clean patches against the current kernel. Besides, a lack of organization is sometimes a good thing. (See _The_Cathedral_and_the_Bazaar_:
<http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/>).

We're not silencing you for airing your views. If anything, we're silencing you because your views get in the way of us doing real work. If you want to be productive and give us a clean set of patches, then go ahead, but all you're doing right now is making the signal-to-noise ratio on the LKML worse.

Cheers,
Kyle Moffett

A minor correction. We have not contributed much recently (if not counting few minor patches that have been rejected). However the oldest layers (until 1996/1997) of the kernel OSS drivers are mostly our work.

It depends on if you are developing just for yourself and few of your friends. However if you like your work being used by majority of computer users then it would be a good idea to listen all kind of input. Even input you don't like to hear.

We will do that in the near future.

Lack of organization is good thing in the right place. However lack of standardization in a wrong place is not good. For example the ls command cannot be renamed to "dir", "stat", "list-files" or anything else.

Equally well it's going to be usefull to have a standardized command (say /lib/modules/uname -r/build/scripts/kbuild /my/source/directory) rather than having different make commands required by each Linux distribution. Nothing prevents the distribution maintainers from optimizing that command in a way they like as long as the usage remains the same.

Best regards,

Hannu
-----
Hannu Savolainen ([email protected])
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages) OH2GLH QTH: Karkkila, Finland LOC: KP20CM

Ahh, my apologies then. I am sincerely sorry for any offense I may have caused.

The original poster did not provide a specific set of issues that needed to be resolved, they just posted a very messy email with several statements that didn't make sense. Even later, when they were asked what issues they were having, they just dodged the question. Then the email that I responded to had the attitude of "You guys are only here to fix my problems," which is totally unacceptable.

Well of course! I said "lack of organization is _sometimes_ a good thing." I agree wholeheartedly. And I'd actually rather not have ls named "dir", cause I'd rather avoid my painful DOS memories. :-D

Ahh, see, from the original poster's comments it was not apparent that their problem was the lack of a standardized build system. In any case, the primary problem is the lack of a configured kernel source tree. My advice to them is to just use the standard module building mechanism:
1) User decides that he/she wants a module
2) User cd's to wherever his/her kernel source tree is
3) User runs "make-kpkg" or whatever his/her distro's kernel tool is.
4) User installs the package generated.

It seems to me that there should not be an automated kernel or module build procedure. Either the user knows what they're doing, is following directions over the phone from somebody who knows what their doing, or has no clue. The users that have no clue should probably not be trying to compile their own modules anyway.

Cheers,
Kyle Moffett

Nobody moved to silence you. What he asked was:

"In light of the fact that you started flaming SuSE regarding their behavior, when it turned out to be a *documented* way that SuSE does things (see the README.SUSE file, point (3)), please explain why *we* should bother listening to you, rather than just adding you to whatever style of killfile is supported by our mail reading software?"

I may be an idiot kernel hacker, but I don't *demand* that anybody listen to me. I *hope* that when I post, somebody with clue thinks I'm worth listening to. Some of my patches get accepted, some get ignored, some get feedback. I suspect that's in large degree correlated to how correct/stupid the patch is. ;)

But the only people in the Linux world that *have* to listen to me are the customer support staff at those vendors that I've purchased a support contract.

_I_ am not revoking anything. I don't have the right to do that. _I_ am simply asking a rhetorical question.

Tell you what. You donate some money OSDL with some strings attached, and IF they agree to that, THEN you can make some demands.

I don't believe English is the issue here. I believe your attitude, which is a demanding one, is apparent from everything you write.

My observation is that kernel developers HATE demands but LOVE to answer polite questions. This is, in part, because NO ONE is in a position to DEMAND ANYTHING from kernel developers. Many of them do it as a hobby on their own time for the fun of it. Demands are un-fun.

People have been speaking up about that for a LONG time, and the question has been answered ad nauseaum. Making suggestions for standardization, particularly specific well-thought-out suggestions is a welcome exercise. DEMANDING it is not welcome.

I am not telling you how _I_ feel about this. I'm telling you what my observations are about the people who would be the ones to do the work were you to convince them to do it. Vinegar is not the way to get them to do what you want.

I cannot and will not silence you. To be honest, I find this whole discussion amusing because yet another whiner has some onto LKML trying to tell people how to think and what to do, and they're just going to get laughed at like everyone else who does it.

However, I am informing you that you might want to silence yourself and/or modify your approach, because your approach, so far, has only polarized people against you. This is my observation. You don't have to believe me.

Let me tell you how _I_ would get something I want from kernel developers. There are various things I would try, and more than one of them maybe applicable:

1) Ask if the thing I want already exists and if I'm just too stupid to find it.
2) Beg and plead really hard for people to take the time to address my insignificant little needs.
3) Explain how my need is a wonderful idea and many people would benefit from it, pointing out that my idea may be stupid and short-sighted, but I won't know until I ask.
4) Start a discussion which gets people excited about the idea.
5) Describe my problem, describe my need, and ask for suggestions on how to meet my need through some entirely different means than how I THINK I should do it, because if something seems broken, it's probably because my thinking is broken.
6) Go without.
7) Pay money to OSDL so that I can be somewhat in a better position to "request" things.

A keyword to learn here is "humility". I am nobody. You are nobody. Even Linus isn't really in a position to DEMAND that anyone do anything.
Lots of people disagree with Linus and that is one of the reasons for
distro vendors forking the kernel. Linux is like a democracy or an anarchy where everyone gets to decide for themselves if they want to comply with anyone else's opinions.

Most people who make requests on LKML seem to implicitly understand this. But you are not the only one who doesn't. I can't force you to understand, but I can tell you that if you don't, people will be VERY unwilling to listen to you.

Oh, and BTW, while I don't use SuSE on the desktop personally, we use it plenty where I work. We think it's GREAT. We also think lots of other distros are great too. But that's just our opinion. :)

We gave up trying to use kernel versions to determine what features/interface to use for a given kernel long ago. Instead we have configure check for a particular interface and use "#ifdef HAVE_foo", not "#if LINUX_KERNEL_VERSION".

I can understand why SuSE does this - there is no way they can ship the "latest" kernel and still have tested it thoroughly, yet if they find a specific defect they need to fix it (preferrably in the same way that a later kernel fixes it).

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/

Andreas,

We precisely use this mechanism - we use /lib/modules/<version>/build/include/linux/config.h to figure such features out but when the "build" part of the path doesn't point to the right source tree,
where do you look?. SuSE ships kernel sources "unconfigured" which means that
you have to rely on something else to tell you what the exact kernel
configuration looks like.

You can look at /proc/config.gz but that's not a standard on all distros either.

best regards

Dev Mazumdar
-----------------------------------------------------------
4Front Technologies
4035 Lafayette Place, Unit F, Culver City, CA 90232, USA.
Tel: (310) 202 8530 URL: www.opensound.com
Fax: (310) 202 0496 Email: [email protected]
-----------------------------------------------------------

Right, but hopefully you can tell it's a SuSE machine via other means, and then apply a suitable workaround.

Or are you claiming that SuSE is *so* weird that you can't even apply a test like:

if [ -test $SuSE ]; then

	echo Smells like a SuSE box - which of the following best describes your box?
	i=1
	for foo in ($likely_dirs) do;
		echo ${i}: $foo
		i=`expr $i + 1`
	done;
	read flavor
	echo You chose $flavor...
	ln -s /usr/src/linux/$flavor my_build

fi

the problem with this is that you can have the situation where it's a SuSE box with a kernel.org kernel. I've had significant problems with installers for 3rd party software that decided what distro they were running on based on what kernel version showed up in uname

by the way there's useually a *version file in /etc that tells you what version of a particular distro you are running on (or at least what it was before it got tweaked)

David Lang

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Of course, this only happens in 2 main categories of situations:

1) The sysadmin watches it fail, and says "D'Oh! I've been shot in the foot because of my customized configuration", and proceeds to work around it (if you're clued enough to get into that mess, you're usually clued enough to fix it).

2) The previous, now-departed sysadmin got you into the mess - at this point, the error is a sign telling you it's time to get your system rebuilt to some maintainable configuration.

The installer will almost certainly fail on any sort of linux-from-scratch configuration as well. I pity the poor software developer that thinks that an automated build should work in every case(*) - requiring the sysadmin to make a few symlinks if the system config is odd/unknown isn't at all outlandish or unheard of.

(*) I've seen at least one box where uname reported 2.4.12 or so, even though the kernel was 2.4.20 or so - said box had been dutifully upgraded on a regular basis and the kernel rebuild, via 'patch'. Due to a unseen mod in the top level Makefile, the patch fragment that updated the variables kept failing. Never got noticed till some kernel code that did a check on the version finally got upset and compiled in the wrong stuff....

It's usually possible to figure out the distribution and version by looking at /etc/issue. However it's impossible to figure out who has made the kernel image. It's possible to identify Mandrake kernels and few others. However in general all kernel versions look the same.

There are about 10 major Linux distributions (for i386) and nobody knows how many minor ones. In addition each of them has multiple versions (still in use by potential customers). In addition it's possible that the system is running some different kernel than the distribution one (such as a kernel.org one or some special purpose one).

The current situation is that every company who like to ship open source drivers with their hardware will have to automatically detect large amount of kernel and distribution combinations and try to decide which kind of installation approach is needed. After everything is settled then some distribution changes it's interfaces and the circus begins once again. Finally when a change is made to the installation procedure then how to test if it still works with all 100 or 200 different systems and kernel images that have already been tested during past years.

I think many persons reading this list don't realize that a significant number of Linux installations are still using 7.x or even 6.x versions of whatever distribution they had originally installed in the system. Companies doing Linux software (be it open source or closed source) need to support them in addition to the state of the art distributions. So would it be too much to ask that kernels based on the same major version do certain things in the same way.

Does anybody have ever tried to install any open source drivers that are not included in the kernel source tree yet?

Best regards,

Hannu
-----
Hannu Savolainen ([email protected])
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages) OH2GLH QTH: Karkkila, Finland LOC: KP20CM

ueing /etc/issue is a BAD idea, while that may work for completely unmodified systems, many companies require legalese be put in there.

or they need to go through the process of getting their driver included in the main kernel and these headaches go away.

it's less likly that the people running the 6.x distros are going to be installing the latest and greatest hardware that needs the new out-of-kernel driver, but if you think you need to create modules that will work with every kernel since 2.0 have fun.

David Lang

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

How would you handle the following modules that aren't drivers - like filesystems:

- ClusterFS
- Intermezzo
- Sistina

There are loads of other very specific drivers for embedded systems that
have no real applicability in the mainstream kernel like DSP boards, specialized
encryption board drivers, military grade video capture/display devices. There are other things like PCI-Express "development" drivers that aren't stable and developers need a way to build them outside the kernel.

Infact it's good programming practices to ensure that drivers/modules build independant of the kernel. There are too many companies like Win4Lin/VMWare that only offer support for Redhat or SuSE kernels with debian, gentoo and other's left out of the action.

You and others can keep suggesting that put the world+kitchen sink into the kernel and have the problems go away but it's not realistic. Many drivers are still maintained outside the kernel and you aren't providing a solution.

Right now the kernel configuration has become complex enough that someone ought
to write a cool program that probes the customer's hardware + OS system and be able to build an optimized kernel + drivers + modules with minimal user intervention. Make it a commercial app and mint money because there's such a dire need. Most Linux users aren't able to do this and this basically means you have little ability to test all kinds of kernel configuration combinations.

How about just dealing with Linux 2.6.0 to Linux 2.6.7?. It's become bad enough that you need stuff like ifdef REGPARM, ifdef NOREGPARM, ifdef GCC 3.2, ifdef GCC 3.4, ifdef SMP, and other ifdefs if you're doing a bunch of /proc types of sysadmin stuff

best regards
Dev Mazumdar
-----------------------------------------------------------
4Front Technologies
4035 Lafayette Place, Unit F, Culver City, CA 90232, USA.
Tel: (310) 202 8530 URL: www.opensound.com
Fax: (310) 202 0496 Email: [email protected]
-----------------------------------------------------------

Everybody who still thinks it's going to be possible to have all possible drivers in the single package should go to /lib/modules and execute

du -sk */kernel

In my test machine the directory sizes seem to be between 10M and 300M depending on how the kernel was configured. For the Fedora Core 2 kernels the sizes are around 25M. When Linux was young it was possible to have the whole distribution fitted in that amount of space.

What would the modules directory look like if the next generation devices get included there too? Or if all the drivers for currently unsupported defence, telecom, aviation, instrumentation and other special purpose devices get included in the kernel source tree?

Best regards,

Hannu
-----
Hannu Savolainen ([email protected])
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages) OH2GLH QTH: Karkkila, Finland LOC: KP20CM

Having more maintained drivers in the kernel can't be a bad thing. For a standard desktop or server, having all these drivers installed under /lib/modules is also beneficial. Makers of embedded distributions will continue to heavily customize their kernel and applications, as they always did.

Xav

Having more drivers in the kernel is not bad. However having every possible driver there is stupid.

A friend of mine created (years ago) an innovative oxygene analyzer for forest industry. They sold that to all possible factories in Finland and then got out of business because there were no more customers. What do all the millions of Linux users benefit if the driver for such device is included in the kernel? If Linux is really going to be the #1 operating system in the future then Linux drivers for this kind of devices will be quite common. In fact a large number of Linux kernel experts will work on this kind of projects. Isn't there any idea in making their life easier by dropping the silly idea that everything can be included in the kernel tree.

Best regards,

Hannu
-----
Hannu Savolainen ([email protected])
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages) OH2GLH QTH: Karkkila, Finland LOC: KP20CM

I don't think that number of Linux drivers will grow faster than Net bandwodth, CPU speeds and disk capacity. So, in relative terms downloading and compiling kernel tarballs will not become slower.

Keeping drivers in single place greatly improves chances of peer review, bit rot prevention (think about fixes for newer GCC versions), etc.

vda

Breaking interfaces to drivers gratuitously would be insane, we're breaking api to drivers only when we *have* to after thinking twice about the problem and after excluding backwards compatible alternatives. And normally the worst thing that can happen is that the driver doesn't compile anymore.

Here I'm not talking about your buildsystem issue you run into, I'm talking about true sourcelevel breakeage to kernel modules out of the kernel that you may find too and that are more difficult to solve than the buildsystem command already described in the readme.suse.

To make the last recent example we had to break the source API with the drivers to fix the release_pages race that Andrew found and fixed in mainline too. That changes page->count into page->_count and quite some drivers broke even outside the kernel. I had the choice of not breaking the API but that would had forced us to disable irq and take a per-zone spinlock in every last put_page(), definitely not desiderable in a enterprise OS where number matters. I appreciate the ability to fix things right and to boost performance to the maximum whenever possible, like it happens in the mainline kernel tree. I even had a lengthy private discussion with Andrew and it was him suggesting me the local_irq_disable + atomic_dec_and_lock as the only possible alternative, but it wasn't attractive enough for performance reasons. Furthermore in a few years people would be more annoyed by page->count than by page->_count as people moves into more recent mainline releases.

At another time during 2.4 to support databases using >16G of ram and running thousand of processes I had to break the pte_offset API to create pte-highmem to avoid the pte to fill the whole lowmem zone and run the box oom (luckily at around the same time vmalloc_to_page was created too, so a more generic API that would work with mainline too could be suggested to driver developers, and in turn even in this case over time people should have been more confortable with vmalloc_to_page).

These things don't happen often, but they sometime have to happen and it's good we can fix them right, unlike if we were shipping a non-open-source OS that forced us to retain the same API to modules to boot the machine and in turn to introduce ugly and slow hacks to workaround bugs. These days the kernel is quite mature so hopefully they won't happen anymore during stable cycles (I mean after 2.6.7 that already had to break page->_count) but you never know.

NOTE: the source API with the kernel modules must not be confused with the _binary_ ABI with userspace. the ABI with userspace is a completely different matter. The ABI with userspace (like syscalls) must be the same for all linux versions. That is very important. The kernel API to modules not being fixed is a feature and not a bug.

This kind of "breaks" are not so fatal provided that there is some way to detect them reliably. Usually it's possible to check LINUX_VERSION_CODE and use different approaches depending on the kernel version. However this doesn't always work because distribution vendors often back port features from the newer kernels into their distribution kernels which have older LINUX_VERSION_CODE. A better approach would be marking them with #define HAVE_NEW_something in the header file that implements this change.

In the long term frequent changes in kernel interfaces cause problems because drivers that try to stay compatible with as many kernel versions as possible will start looking like #ifdef spaghetti.

Best regards,

Hannu
-----
Hannu Savolainen ([email protected])
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages) OH2GLH QTH: Karkkila, Finland LOC: KP20CM

What's the point in staying "compatible with as many kernels versions as possible"? IMHO it's enough to be able to build and work with latest 2.6, latest 2.4 and maybe latest 2.2. Not _that_ much of #ifdefs.

(/me was looking into ntp code recently. *That* is #ifdef hell) --
vda

Hi Denis,

You'd be surprised how many people are still running Redhat 7.3 or howmany people are still running some version of Linux 2.4.2x. Sometimes its not easy telling the customer to upgrade to the latest Linux kernel from www.kernel.org because they don't have the expertise to compile kernels - heck some distributions don't even install gcc/make unless you select "Development System" during installation. (FreeBSD is more sane in that regard that they install gcc/make with the base system).

best regards
Dev Mazumdar

-----------------------------------------------------------
4Front Technologies
4035 Lafayette Place, Unit F, Culver City, CA 90232, USA.
Tel: (310) 202 8530		URL: www.opensound.com
Fax: (310) 202 0496 		Email: [email protected]
-----------------------------------------------------------

I believe we are seeing this kind of problems all the time. This is not just a kernel 'problem'. Just take a look at the autoconf info page and the tests that a portable program has to run.

Of course the makers of (i.e.) glib could just try to find a source tree that would compile everywhere but they know that this is impossible so they have to run tests like :

(warning: long list)
checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... 64 checking for _LARGE_FILES value needed for large files... no checking for locale.h... yes
checking for LC_MESSAGES... yes
checking libintl.h usability... yes
checking libintl.h presence... yes
checking for libintl.h... yes
checking for dgettext in libc... yes
checking size of char... 1
checking for short... yes
checking size of short... 2
checking for nl_langinfo... yes
checking for nl_langinfo and CODESET... yes
checking whether we are using the GNU C Library 2.1 or newer... yes checking for vasprintf... yes
checking for unsetenv... yes
checking for getc_unlocked... yes
checking for C99 vsnprintf... yes
checking for nl_langinfo (CODESET)... yes
checking for OpenBSD strlcpy/strlcat... no
checking for an implementation of va_copy()... yes
checking for an implementation of __va_copy()... yes
checking whether va_lists can be copied by value... yes checking for RTLD_GLOBAL brokenness... no
checking for preceeding underscore in symbols... no
checking for dlerror... yes
checking size of pthread_t... 4
checking for pthread_attr_setstacksize... yes
checking for minimal/maximal thread priority... sched_get_priority_min(SCHED_OTHER)/sched_get_priority_max(SCHED_OTHER) checking for posix yield function... sched_yield
checking whether to use the PID niceness surrogate for thread priorities... yes
checking size of pthread_mutex_t... 24
checking byte contents of PTHREAD_MUTEX_INITIALIZER... 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
checking value of POLLIN... 1
checking value of POLLOUT... 4
checking value of POLLPRI... 2
checking value of POLLERR... 8
checking value of POLLHUP... 16
checking value of POLLNVAL... 32

.. and many more ..

I don't believe that your source code is more complex than theirs. Maybe the solution to your problem is as simple as 'info autoconf'. You know that there are more than one ways to compile kernel modules so you just have to test each one of them and see which one works. We're talking about no more than 30 minutes work. After that you may add another distro in the supported distributions list of your module.

<<V13>>

Using include/linux/config.h only tells you which kernel config options are set/unset. That doesn't tell you anything about API changes between kernel versions, vendor backports of some of those features, etc.

For example, one vendor ships their 2.4 kernel with the .direct_IO address_space_operation with "struct file *" as the second parameter, while most other kernels pass "struct inode *" as that same parameter. Ideally, when they made that API change they should have #defined HAVE_DIO_FILE or something in the fs.h header so it can be detected. Instead we have configure tests to know which struct is being passed.

There are similar changes in kernel-internal APIs between versions, structs (kiobuf is lots of fun), architectures, etc. What my point was is that just looking at CONFIG_POSIX_ACL or whatever isn't necessarily going to tell you the whole story, and even if some change was made in kernel 2.6.6 doesn't mean that other vendor kernels at 2.6.5 won't also have that.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/

Which is wrong, because existing behavior in separate source and object directory case is that 'build' symlink points to source tree.

You BROKE it by redirecting it elsewhere.

I hope that your breakage never gets merged to mainline.

Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD

It looks like SuSE as the first distribution took the sane approach to seperate source and output files.
I presume they have documented this somewhere - and I have a patch from Andreas G. that should actually solve this if a module is compiled in the usual way like you do.

So you seems to be bitten by a distributor starting to use a new facility in kbuild.

Why did you not post the error in your first mail btw?

Sam

Sam,

The problem is that we had our software working correctly with Linux 2.6.7 and when we started to get a flood of support requests from our customers, I just pulled down the sources from kernel.org to see what might be the differences and when you start seeing huge 12.8 Megs of differences between 2.6.5 from kernel.org and SuSE's 2.6.5 kernel, you start to wonder if the problem is with your software.

The fact is that we discovered belatedly that the whole problem was nothing but a broken build link to the correct sources makes my point that a) there are no standards for shipping sources for out-of-kernel modules to be able to build b) massive variations from the vanilla kernels causes developers to have to keep doing #ifdef SUSE or #ifdef REDHAT or #ifdef DEBIAN and #if (SUSE && LINUX-2.6.5) && !(REDHAT && LINUX 2.6.5) and so on....is a cause for massive amounts of grief.

I apologize for not having the forsight to figure out that KBUILD was the problem.

best regards

Dev Mazumdar
-----------------------------------------------------------
4Front Technologies
4035 Lafayette Place, Unit F, Culver City, CA 90232, USA.
Tel: (310) 202 8530 URL: www.opensound.com
Fax: (310) 202 0496 Email: [email protected]
-----------------------------------------------------------

Your customers are your customers and thats your business. And if SUSE is the problem then complain there.

As I said before: Adjust your tie !

Thomas
_____________________________________________________________________

"When customers are visiting, engineers are not allowed to wear ties. That way the customer can tell who is the engineer and who is the salesman (and therefore whom to believe.). Ties cut off blood flow to the brain, making it easier for the salesmen to do their jobs."
_____________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: [email protected]

Splitting source and object directories is indeed sane. But SUSE implementation broke the 'build' symlink which has been the recommended way for a long time to get to the main kernel Makefile directory.

I have asked you n times to refrain from merging the 'build' symlink breakage. I ask you again to not merge that breakage.

Please merge the 'object' symlink version instead.

SUSE folks made a silly mistake and broke stuff. It was even more silly for them to try to submit that breakage to mainline.

Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD

Hi,

Letting the symlink point to the build directory is the only sane option. What's missing is that the native kernel tree itself should generate a small Makefile in the build directory.
SuSE did the right thing, it now just needs proper integration.

bye, Roman

The point is that many things will break. Sure, I speak partly out of the point of view of somebody who now and then do some distro work, but also thinking about all those out there who might compile by hand.

I can see that how they want to do it might be more logical, but please with sugar on, do not do it in 2.6.

Thanks.

Martin Schlemmer

No. That breaks stuff. Only sane solution IMO is to leave the /lib/modules/uname -r/build symlink alone, and add another /lib/modules/uname -r/object symlink that points to the object tree.

Separate source and object tree feature has been in mainline for at least half a year. Linus has released 8 stable kernels in the 2.6 line of kernels. Distros have released uncounted number of kernels based on those 2.6 kernels. All of those kernels, except latest SUSE damaged ones, have the /lib/modules/uname -r/build symlink pointing to source tree if they are compiled to use separate object tree.

My point is that this separate source and object trees thingy is not anything new, even though some SUSE people seem to think so. If SUSE people choose to break their kernels, it is their problem and their customers' problem. I don't see any reason why mainline should be broken just because SUSE people chose break their kernels.

Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD

Are you referring to userspace applications which fail under Suse's kernel, or are you referring to kernel code?

If the former then yes, this may well be a bug in the Suse kernel - please provide the means to reproduce it.

If the latter (your drivers don't work in Suse's kernel) then this too could be a bug in the Suse changes, or in your driver. Again, more details would be needed to diagnose it.

I expect your distress is a little misplaced - someone somewhere has a silly little bug and once that's found and fixed, things will be OK.

As to your broader point - yes, I too am disturbed by *any* divergence from a kernel.org kernel. Because it means that there is some feature which the mainstream kernel is missing, or some problem which remains unresolved. Especially if there are variations in user-visible features - that would be very bad for everyone.

Either way, each unmerged patch is a little failing which costs the users of the patched kernel as well as the users of the unpatched kernels.

I don't have a lot of substantiation for this, but I think the reason why suse are sitting on 1500 patches is a combination of:

a) They're on 2.6.5 and have included a lot of patches which are already in 2.6.6 and 2.6.7

b) They shipped the kitchen sink with 2.4 and their customers still want to wash the dishes in 2.6.

c) Maybe they haven't been terribly stern about throwing things away.

I would like to see a little more all-round effort to reduce the variation between kernels, and perhaps Suse moved onto 2.6 a little later than they should and have a resourcing problem. Hopefully we'll be seeing more patches from them soon.

Heh, very funny. Seriously, though, one "kitchen sink" feature that they had been shipping in 2.4 was iBCS. Given the recent revival in UFS1/2 FS support, it really would be "nice to see" the iBCS binary compatibility code revived and merged into 2.6. I'm sure that people in the scientific community would really appreciate this since there are still many new and legacy apps which were/are only for solaris/x86 and/or sco/x86.

I know I'm sure to invite flames for this one, but serious thought should be given to re-merging the khttpd using Ingo Molnar's tux code. The khttpd been part of the kernel for such a long time and since it now works in 2.6 again, why not re-instate it? FWICT, it is "fairly" self-contained, so the overall impact on existing code should be minimal.

Cheers,
Nicholas

The guy seems to have some personal agenda, posting specifics would ruin his otherwise fine troll.

Precisely.

Yep, at some point in a release schedule you have to stop blindly merging patches from upstream -mm and -linus. But lots of patches are bug fixes which were "back ported" (really just merged) from Linus or your kernel.

And then at some point you start over, merge up, and get rid of these (almost) thousands of patches.

A lot of the patches are already in -mm or -linus later versions. I'm sure once crunch time is over more patches will get merged upstream, but I do think that we have been a _lot_ better at merging with 2.6 than previously.

The last thing anyone wants is the situation we had/have with (basically all) 2.4 vendor kernels.

Jens Axboe

Absolutely agreed. Nobody likes maintaining hundreds of patches for multiple versions of a distribution, especially not the companies that pay the salary of the programmers tied up doing that kind of work ;)

There are sound economic reasons why Linux companies should merge their stuff back into the upstream kernel; or better yet, develop the functionality in the upstream kernel before merging it into the distribution tree (eg. NPTL, selinux enhancements, O(1) scheduler).

Maintaining a patch for one version of the distribution, in order to get a feature to customers sooner, is perfectly doable and may make economic sense.

Maintaining an out-of-tree patch forever because you didn't get around to merging it into the upstream kernel doesn't. It is nothing but a waste of effort, doing the same work over and over again for every version of the product, instead of doing the work once and then focussing your engineers on implementing new functionality.

Yes, this is a hint at certain embedded developers. You know who you are and chances are you also know what you would like to develop if you no longer had to spend your time porting the same old patches from one version of the product to the next.

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

The shame of things is that the economic/effort problem appears to often be "solved" by never migrating to new kernel versions, or otherwise by amortizing the work involved with infrequent migrations.

I wish I had answers.

-- wli

On Fri, 2004-06-18 08:13:15 -0700, William Lee Irwin III <[email protected]> wrote in message <[email protected]>:

Unfortunately, you're *very* right on this. Eg. read the linux-mips list (at linux-mips.org). You'll see that this list is often hit by people having problems. Normally, they hack on kernels like 2.4.16 or the like. These are totally unrelated projects, people and companies. I can't find words for that. They're missing a year of development and even feel sane with it. That's what vendors gave them...

There's a lot of Linux beyond LKML, with a common problem: outdated source trees, with a shitload of patches. Linus could need another hacker or two working full-time on reviewing / importing those patches! For what I guess, those should better be native Indian speakers...

MfG, JBG

   Jan-Benedict Glaw       [email protected]    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

Hmm, my indian colleagues speak perfect english. Why make this comment at all btw...

regards,

Paul Jakma	[email protected]	[email protected]	Key ID: 64A2FF6A
	warning: do not ever send email to [email protected]
Fortune:
The only certainty is that nothing is certain.
		-- Pliny the Elder

On Fri, 2004-06-18 13:17:31 -0400, Paul Jakma <[email protected]> wrote in message <[email protected]>:

India. I think that's a great thing for an upcoming country. However the sad thing is that those hackers seem to work behind quite closed doors (or little internet access). I commonly see this situation:

- Nobody (except their bosses) know about their work. It's nowhere announced, published or discusses.
- They just work, but sometimes miss to *think* about their work. Why should anybody work on a 2.4.16 codebase if there's 2.4.26 available? Heck, they're missing > 2 years of development and bug fixes!
- They often ask stupid/bogus questions in such a way that I think they were poorly prepared by whomever is paying for the work to do their job. I fear that problems are solved (on a regular basis) by trial-and-error (and putting 20 people to solve a single problem) than by first discussing it.

While looking at the questions, my thoughts are typically:

- They could do a *really* good job iff they were better integrated into LKML and other mailing lists. They need to read, and they need ask. Starting hacking with no well-designed idea for a solution is the poorest design of problem solving I've ever seen.
- A lot of (valueable) work is being done, but LKML and the vanialla tree will typically never ever see it. It's done, put into some embedded device, sold, and never ever touched again.

Don't get me wrong. I'm not against Indian people (in fact, I do have quite some email contacts on regular basis to some eg. Bangladeshi people). I'm just a little sad about the whole lot of effort that's lost IMHO on a regular basis, *and* that those guys over there get so little help (because they seem to not have a steady internet uplink for their use).

MfG, JBG

   Jan-Benedict Glaw       [email protected]    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

It is good to see this issue discussed on LKML. (It shows a recognition of issues I deal with in my space every day.) There are indeed armies of developers who work on Linux, but who are stuck in version backwaters. These developers almost never visit or contribute to LKML. The reasons for this situation are numerous, and not easily solved with a wave of the "just contribute stuff" wand.

One important factor is that very often the people directly responsible for code generation in the embedded space are simply not available for interfacing with the community. In the embedded space, there is
tons of fragmentation and very little network effects between developers. There are language problems, culture problems, legal problems, and an array of factors which create barriers for developers at major CE companies contributing to Linux.

At the CE Linux Forum, we are trying to reduce or eliminate some of these barriers, but it is difficult.

Realistic ideas for reducing these barriers are very welcome. Believe it or not, most CE companies I work with WANT to contribute back, but have a very difficult time with the details.

Here's a shameless plug: I'm having a CELinux BOF at OLS to discuss this and other issues. It's the night of Wednesday, July 21. Anyone can drop by if they are interested in this topic.

The idea of having some dedicated developers perform this function is actually a pretty good one, although I wouldn't burden Linus with managing them. That is, it might be useful to have some people following behind embedded product developers trying to glean, generalize, forward-port and otherwise clean-up patches that would otherwise never see the light of day.

=============================
Tim Bird
Architecture Group Co-Chair
CE Linux Forum
Senior Staff Engineer
Sony Electronics
E-mail: [email protected]
=============================

Now, THAT is a good idea.

On Fri, 2004-06-18 15:45:53 -0400, Timothy Miller <[email protected]> wrote in message <[email protected]>:

I trade that since, um, months. I'd even *like* to do that, but I need to earn some money, too:) Some time ago, I even brought this up as an idea to OSDL, but that ticket was closed some time later...

MfG, JBG

   Jan-Benedict Glaw       [email protected]    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

Since the people benefitting from this work are the embedded developers, it would seem logical that they should bear the cost of this effort, too.

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Absolutely! For the CE space, the resources for this should come from CE companies. I've been thinking about the practicalities and logistics of doing this in the CE Linux Forum, or of encouraging member companies to do this for their own products. I wouldn't even consider making a request that non-CE-related people do this.

=============================
Tim Bird
Architecture Group Co-Chair
CE Linux Forum
Senior Staff Engineer
Sony Electronics
E-mail: [email protected]
=============================

On Fri, 2004-06-18 13:20:02 -0700, Tim Bird <[email protected]> wrote in message <[email protected]>:

Well, I'd prefer having (one or more) people to do work on the whole area, not onle CE / embedded related stuff. It woule be *really* cool to have somebody to whom you just post a URL to your repo to care about reviewing it, sending it upstream etc. I guess embedded work is a big player there, but don't forget the minor architectures and other repos with li'l enhancements.

MfG, JBG

   Jan-Benedict Glaw       [email protected]    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

On Fri, 2004-06-18 16:05:46 -0400, Rik van Riel <[email protected]>
wrote in message <Pine.LNX.4.44.0406181604270.8065-100000@chimarrao.boston.redhat.com>:

It's not only all the embedded stuff (where the -tiny tree is a nice start!). Remember the bits of the pc98 arch that got ripped these days? Remember the CRIS architecture being hopefully out of sync? They're all good candidates to profit from such a helper.

MfG, JBG

   Jan-Benedict Glaw       [email protected]    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

The framebuffer is also so far behind. 9 out of 10 patches are dropped. The reason being is that everyone is a volunteer doing this in there spare time. We don't have the man power, hardware, nor the support to do the work that is needed. There are a huge number of drivers that could be included but never are. The companies we work for will not support the work we do in our spare time because there is no instant $$$$$.

So what is going to be done about this? Will this be the usually hot air? I seen this discussed before but nothiing ever happens :-( I don't see any one setting up to the plate.

On Fri, 2004-06-18 22:03:51 +0100, [email protected] <[email protected]> wrote in message <[email protected]>:

Very right. Companies don't see any general benefit, if there isn't any $$ to come in soon.

Hope the CE Forum will show some engagement there. Or OSDL. Or IBM. Or ... But usually, that's hot air. No direct income :--<

MfG, JBG

   Jan-Benedict Glaw       [email protected]    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

Come on people, not everything is counted in dollars or euros. Lots of people enjoy doing auxiliary work in their spare time and get loads done. If it doesn't work for you, then maybe you are not the right for the job or maybe you are doing something wrong.

Jens Axboe

On Fri, 2004-06-18 23:13:53 +0200, Jens Axboe <[email protected]> wrote in message <[email protected]>:

Well, sometimes I actually do some nice work to put on the table, but keeping an eye on a good number of vendor trees is IMHO *far* beyond what you'd actually do at some late evening at the weekends. That's way more than a good full-time job. At least, I think so.

MfG, JBG

   Jan-Benedict Glaw       [email protected]    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

I have heard companies complain about the free beer mentality linux users have. I guess they have the same problem :-(

I agree. Its not a matter of money but of time. Of course it is nice to pay bills. Quality takes time. That is just reality. The question is how much time can you put in it over say a week period. If you work for a living doing something else there goes 40 hours working on a open source project.

On Sat, 2004-06-19 00:18:58 +0100, [email protected] <[email protected]> wrote in message <[email protected]>:

That's not only 40 hours. Little over an hour per day for driving, and then there's overtime work, too....

MfG, JBG

   Jan-Benedict Glaw       [email protected]    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

You know, that would sound much more impressive if drivers *already* *in* *the* *tree* would get fixed.

I've offered you help with resync several months ago. And I'm fairly sure that there was no reaction from you. So when you start complaining about lack of manpower...

On Fri, 2004-06-18 23:05:01 +0100, [email protected] <[email protected]> wrote in message <[email protected]>:

Reminds me that there were some 20 drivers for differently attached lance network chips in the kernel source tree:)

MfG, JBG

   Jan-Benedict Glaw       [email protected]    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[email protected] <[email protected]> :
[...]

Do you mean dropped as "Posted on fb-devel but nobody cared" ?

(no need to keep me in the Cc: loop except for this specific point, thank you)

--
Ueimor

On Sat, 2004-06-19 14:42:14 +0200, Francois Romieu <[email protected]> wrote in message <[email protected]>:

Maybe. And even that's a sad thing. Work has been done, and (without knowing the exact state of the fb development) I'm sure James did a good job on them. Caring for patches (so they make their way upstream) can take as long as doing the programming. If this work could be layed off, that would be nice:)

So we need Rusty's "Not-so-trivial patch monkey(s)"...

MfG, JBG

   Jan-Benedict Glaw       [email protected]    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

Caring for patches can easily take a multiple of the time to write the patches.

:-)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

More like patches come in but no one has enough time to sit down and go thre wthem and try them out.

On Fri, 2004-06-18 12:02:48 -0700, Tim Bird <[email protected]> wrote in message <[email protected]>:

Want to offer some airplane ticket Europe -> Canada and back? I'd love at attend!

Couldn't have said that any better:)

MfG, JBG

   Jan-Benedict Glaw       [email protected]    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

And they have problems for which fixes were merged into the upstream kernel well over a year ago.

If these developers had just merged their own stuff into the upstream kernel, they wouldn't have had to deal with all the ancient kernel bugs - the community has solved them already and the embedded developers could just inherit those fixes from upstream.

In short, the work of merging your functionality back upstream is a way to reduce the total amount of work that needs to be done.

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Iroquois or Souix?

-- John E. Jasen ([email protected])
-- No one will sorrow for me when I die, because those who would
-- are dead already. -- Lan Mandragoran, The Wheel of Time, New Spring

How about Navajo? That's (supposedly) a beautiful language.

 2:27PM  up 136 days, 23:41, 1 user, load averages: 0.15, 0.13, 0.11

A Hausdorff topological space is a continuous image of the unit interval if 
and only if it is a compact connected locally connected metrizable space.

Speaking as someone who had to port 2.4.20 to a custom embedded platform, starting from a fork of a fork (Wolfgang Denk's fork of linuxppc-2.4-devel fork of mainline) was the quickest way to get to a running board. (ie, the quickest way for me to get on to the next phase of the software, which was all the driver code, and custom userspace stuff for controlling everything).

At the end of the project, I looked at the patches, and tried to work out what would be required to get the board running on mainline. It was a lot of work. Which, I hasten to add, is a massive understatement.

Perhaps it has gotten better with 2.6. I don't know. But I'd hope that those with the knowledge can eventually roll back in the needed changes to mainline. It certainly would make this developer's life more pleasant.

In the meantime, I'd like to thank the people behind the linuxppc-2.4-devel tree, and Wolfgang, for making my life much easier than it could have been.

Ray

Problem is, what happens if vendor X ships a feature and that feature is deemed unacceptable for the kernel.org kernel?

There are examples of this and as I've earlier indicated, I'd be OK with merging some fairly stinky things after 2.7 forks off, as a service to the major kernel.org customers and as a general lets-keep-things-in-sync exercise.

But we then need to do it all again in 2.8.x. It's hard to see how to fix this apart from either merging everything into the main tree or dropping things from vendor trees. Or waiting for someone to come up with an acceptable form of whatever it is the patch does.

That's why responsible vendors develop their feature in the upstream kernel before they merge it into their own product.

That way they know in advance they'll won't need to maintain the feature as a separate patch for more than one product ;)

Ideally the vendor would come up with an acceptable form in the first place. Not out of a moral obligation to the Linux community, but because doing that means free QA and better quality source code that's easier to support...

Sure, it is some short term work for the vendor, but it'll save work in the long run.

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

On Fri, 2004-06-18 17:03:14 -0400, Rik van Riel <[email protected]>
wrote in message <Pine.LNX.4.44.0406181700400.8065-100000@chimarrao.boston.redhat.com>:

That's a fact that bosses typically ignore.

MfG, JBG

   Jan-Benedict Glaw       [email protected]    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

Very good question, as these features/patches are often the ones that are ugliest and the hardest to maintain. Or the ones that make you slightly source incompatible with mainline, which is always ugly.

Within reason (I trust your taste and judgement completely), I fully support that and think this is key to maintaing closer proximity between mainline and vendor kernels. There are _always_ going to be uglies (don't ask me why)...

Wish I had an answer for that. Things can and do get dropped from vendor trees, doesn't cover all cases naturally.

Jens Axboe

I'm afraid that to a certain and hopefully very limitted extend that's why the distributors need to pay kernel maintainers themselves... *sigh* I fear the answer is called "business reason", and this time it affects the kernel, the next time someone does it with gcc, glibc or whatever.

All engineering can do is to kick back as hard as possible and support eachother by publically kicking back when someone else is forced to do it - so they can run to their management and complain "see what kind of bad publicity that gave us!" and hopefully make them at least raise the bar (& price) of doing it next time ;-)

The "waiting for someone.*does." approach before merging into mainline is the only sane answer IMHO; merging a patch in a vendor kernel should ultimately lead to that, or at least I'm very convinced that's our goal.

It's not _always_ reached of course, in which case either a feature is obsoleted, a migration to a different implementation of said feature needed for customers, or one gets (grudgingly) to carry the patch until the next major lifecycle change. And 2.4 was hopefully the very height of those cases and we are settling down again.

Sincerely,
Lars Marowsky-Brée <[email protected]>

High Availability & Clustering	      \ ever tried. ever failed. no matter.
SUSE Labs			      | try again. fail again. fail better.
Research & Development, SUSE LINUX AG \ 	-- Samuel Beckett

"Software" == "3rd-party kernel modules" in this case, right?

Remember what had been told to you about in-kernel interfaces? That's right, that they can be changed at zero notice. Now, if SuSE told you otherwise, you might have a cause to complain. Had they?

If they'd promised in-kernel interface stability and lied - sure, go ahead and nail them to the wall. If not - STFU and eat what you are bloody given.

Al, not particulary fond of SuSE, but even less so - of misdirecting wankers like that...

That's right Al, 4Front, ATI, Nvidia are all evil!. OK so now get on with life.

It's time everybody started to pay some attention to in-kernel interfaces because Linux has graduated out of your personal sandbox to where other people want to use Linux and they aren't kernel developers.

Sure we can fix the problem with SuSE - we've been doing this for the past 7 years. And we know a thing or two about Linux kernels but wouldn't it be better for the Linux community in general to have such source issue stabilized?

best regards

Dev Mazumdar
---------------------------------------------------------------------
4Front Technologies
4035 Lafayette Place, Unit F, Culver City, CA 90232, USA
Tel: 310 202 8530 Fax: 310 202 0496 URL: http://www.opensound.com
---------------------------------------------------------------------

How dare you? What in damnation name had given you any reason to assume that demagogy has anything to do with that?

It's not about "evil" (whatever, if anything, that word might mean). It's not about Nvidia.
It's not about ATI.

It's about your (personal or institutional - I couldn't care less) lack of basic integrity. It's about exercises in misdirection worth a politician. And it's about attempts to come and demand that which had been clearly denied to you by those who get to decide what you will be given.

For the record, I have zero problems with whatever license you are using and my only problem with your business model is that you appear to assume that the mere fact of your existence gives you the right to demand something from people who owe you nothing.

*PLONK*

Hi,

Look into your own diapers, learn the meaning of "documented interfaces" and come back if you can show that SuSE broke exactly this.

bye, Roman

Roman,

Like when did you start developing for Linux?. We go back as far as 1991. OK? No need for such attacks. Look Andrew thinks we have a problem here and let's work this issue out for the betterment of Linux.

The problem with SuSE is that /lib/modules/2.6.5-7.75/build is all screwy. Either you do the right thing like Fedora or Redhat and ship the proper KBUILD environment or link it to /usr/src/linux and atleast have the kernel headers intact.

Additionally, there are glaring problems with their headers. Why don't you take a look at http://www.opensound.com/suse91diff.gz - it's a diff against Linux 2.6.5 and it's 12.8Megs of diffs!. For heavens' sake, with so many diffs they should be calling their kernel 3.x or something or stop using the Linux 2.6.xx naming convention.

best regards
Dev Mazumdar
---------------------------------------------------------------------
4Front Technologies
4035 Lafayette Place, Unit F, Culver City, CA 90232, USA
Tel: 310 202 8530 Fax: 310 202 0496 URL: http://www.opensound.com
---------------------------------------------------------------------

Hi,

To quote from your previous mail:

That doesn't really like documented interfaces to me. The SuSE kernel build system may be unconventional, but so far you failed miserably to prove that they did anything wrong. You should actually be thankful to them, that you can fix your broken build scripts to use _documented_ interfaces.

bye, Roman

Right. The documented command is "make install". However an undocumented detail is that that doesn't work with "virgin" kernel sources (nothing compiled yet). The above command seems to be needed to prepare the source tree for building the module. The "documented" alternative would be full make in the kernel source tree but that is massive overkill (in addition it doesn't work with most distribution kernels).

The actual problem is that there is no standardized way to compile modules outside the kernel source tree. There will be serious problems if different distributions need slightly different installation procedure. Who is going to be able to tell the customer what exactly he should do?

So even as hardware vendor releases an open source drivers for their hardware nobody can use them before the driver gets included to the distribution kernels. Ok, this is not a problem as long as every single driver for every single device in the world is included in the kernel. However I bet this will break kernel (and distribution) maintainers' necks within not so many years.

Best regards,

Hannu
-----
Hannu Savolainen ([email protected])
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages) OH2GLH QTH: Karkkila, Finland LOC: KP20CM

Hi,

If the kernel is not configured, there is nothing you can do. You cannot automatically configure the kernel and hope it matches the running kernel. Simply use the standard methods to build an external module and any decent distribution should make sure these work and AFAICS SuSE did exactly that.

Wrong, there is no automatic way to build an external that takes care of all possible problems and there never will be.

No, there will be serious problems if module authors use undocumented features and demand for them to work forever.

bye, Roman

Really?

I always do

make modules_install
installkernel <kversion> arch/i386/boot/bzImage System.map

The arch-independent installkernel script should perform the necessary actions to install the kernel image in a bootable area.

In 2.6.x there is a way to do this :)

Sam Ravnborg recently posted documentation for this, as well.

Jeff

<shameless plug>
and we suggest using DKMS for exactly this purpose, until you get your code merged into the kernel.org trees. http://linux.dell.com/dkms/
</shameless plug>

Matt Domsch
Sr. Software Engineer, Lead Engineer
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

Hi Matt,

Something like this is precisely what's needed for Linux!. Let's hope that dkms gets incorporated into the base Linux kernel environment.

best regards
Dev Mazumdar
-----------------------------------------------------------
4Front Technologies
4035 Lafayette Place, Unit F, Culver City, CA 90232, USA.
Tel: (310) 202 8530 URL: www.opensound.com
Fax: (310) 202 0496 Email: [email protected]
-----------------------------------------------------------

Sorry. I was supposed to write make modules.

Best regards,

Hannu
-----
Hannu Savolainen ([email protected])
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages) OH2GLH QTH: Karkkila, Finland LOC: KP20CM

make modules_prepare

Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

If renaming /proc/bus/usb/devices to /proc/bus/usb/devices_please-use-sysfs-instead is not breaking of "documented interface" then I have no idea what "documented interface" is...
Best regards,
Petr Vandrovec

I would not call this file an interface, but utter bullshit. Just because it breaks all these bullshit devices...

USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

Yep. I'm not interested in the file contents, but in behavior of poll on that file (which fires when device is plugged or unplugged).

Only thing which is at least simillar is dnotify on /sys/bus/usb/devices, but as dnotify needs (preferrably RT) signal, it is not trivial to use it from libraries due to problems with allocating unused RT signal (and then you need some pipe to deliver notifications from signal handler to "safe" process context).

Or do I miss some nice and simple interface which can be used for notifications about newly plugged (USB) devices?
Thanks,
Petr Vandrovec

hotplug?

There are different levels of evil. I never heard Nvidia complaining about SUSE header files here.

You can _USE_ Linux without being a kernel developer. You talk about _YOUR_ business problems and not about problems related to this community.

So why are you complaining ? You have done this for 7 years, do it for another
7. The Linux community is not responsible for _YOUR_ problems with SUSE or complain at the appropriate SUSE mailing list.

Stop trolling!

Thomas
_____________________________________________________________________

"When customers are visiting, engineers are not allowed to wear ties. That way the customer can tell who is the engineer and who is the salesman (and therefore whom to believe.). Ties cut off blood flow to the brain, making it easier for the salesmen to do their jobs."
_____________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: [email protected]

No, it is still our personal sandbox actually, and it is you who must pay attention to in-kernel interfaces.

Or were you hoping that we're all here just to make your life easier?

The problem is that we ARE paying attention to in-kernel interfaces or else why would our software work on Linux 2.6.7 or Fedora or Mandrake?

I don't expect you to make my life easier. Why don't we all take a huge plunge backwards to circa 1958 and start programming by throwing switches?. Are you against making linux better or what?

best regards

Dev Mazumdar
---------------------------------------------------------------------
4Front Technologies
4035 Lafayette Place, Unit F, Culver City, CA 90232, USA
Tel: 310 202 8530 Fax: 310 202 0496 URL: http://www.opensound.com
---------------------------------------------------------------------

As Andrew pointed out, it is probably a simple bug in the SuSE kernel or your code. You aren't having this problem because we're changing interfaces willy nilly.

I think maybe you should get a good night's sleep before posting again.

Because the patched kernels shipped by Redhat and Mandrake didn't introduce this particular bug?

Look, I sympathize a bit. I am Joe User, and I have run a hand configured stock kernel for about as long as I've known how, for much the reasons you describe. I am in the happy position of not having any users other than myself.

Novell/SuSE don't have that luxury, and for various reasons run patched kernels. If this weren't common knowledge, there might be some legitimate complaint that a bug in SuSE is improperly seen as a bug in Linux proper. But it's not like SuSE (or Redhat, or Debian) has some man behind a curtain pulling strings and patching kernels while Dorothy watches on oblivious. No one was lied to. It's just a bug, file it with the maintainer (SuSE), and get on with your life.

However I for one, would like to see more of these vendor patches in the mainline. I think it's the wrong place for the vendor to add value, most of the time. The peer review of getting into Linus's tree would make me sleep better at night if I depended on features provided by vendor patches. Hopefully, there will be a day when the idea of shipping a patched kernel is ridiculous for 99% of vendor needs.

-Erik

Quote from 4Front Technologies <[email protected]>:

Nah, I don't think the novelty would last very long - can you imagine toggling something like KDE in on the front panel?

Now, a less huge plunge back to 1977 hardware might be fun. If anybody is throwing away unwanted VAX hardware in the London and Kent area, I might be interested :-).

John.

On Fri, 2004-06-18 08:45:53 +0100, John Bradford <[email protected]> wrote in message <[email protected]>:

/me as well (Germany, Nordrhein-Westfalen). I'm doing real Linux development on those machines:) By the way, a GCC hacker is needed...

MfG, JBG

   Jan-Benedict Glaw       [email protected]    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

No, because Linux encourages distributions to try out features they think their customers need. Suse/Novell is shipping enterprise kernels which work on large hardware, have the optimizations needed for supported hardware vendors and for third party like RDBMS.

They even backport drivers so their kernels are more stable and compatible for their customers.

If you look at debian kernels, they have even more patches. Some of them are even needed to actually make them boot on some platforms.

Greetings
Bernd

eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/

BTW, do those changes get merged back upstream?

Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

I think you wanted to say "they aren't programmers". Such people have no business building their own kernels and modules: either they learn how to fix trivial header problems like the ones you described, or they stick with precompiled software from their distributors.

Ciao, Flavio

Does NVidia's code break on SuSE 9.1?

What do I need commercial OSS for after all when Alsa works well for me?

How about if you either documented the point where SuSE's patches broke DOCUMENTED behaviour or shut up instead?

Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95

Well, for what it's worth, there are a few devices out there for which there is no open source driver:
0000:02:02.0 Multimedia audio controller: Creative Labs [SB Live! Value] EMU10k1X
(Dell Dimension 2100, *I think* - it's at work right, and I'm not)

I believe 4Front provides the only driver for that specific device (it's a crippled EMU10k1, probably what could be called a "WinSoundchip")

Ryan Anderson
  sometimes Pug Majere

We have an alpha driver in our CVS tree for this chip as well.

Jaroslav

-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs

So what? If the mutilated hardware requires a commercial driver one might as well spend the third-party driver cost on better hardware.

No reason for 4Front to bitch around without providing a precise bug list or patches. They want revenues, they need to invest. It's as simple as that.

Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95

The beauty of FOSS is that people have a *choice* of where to spend their money. If you prefer an o/s which limits your choices there is one... upgrade the hardware is not always a choice, not all Linux systems are PCs, even the Intel-based systems.

   -bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
 last possible moment - but no longer"  -me

Stop whining.

People often complain about Linux lacking a stable kernel driver ABI. They act like it's some kind of conspiracy. The truth of the matter is, Linux designers prefer technical flexibility over stable internal interfaces. This is part of Linux philosophy -- it's part of the what defines Linux -- and so if you use Linux, this is something you simply have to ACCEPT.

If you don't want to accept that, develop for some other OS. No one's begging you to develop commercial products for Linux.

Another important thing to note that whiners like yourself seem to miss is that kernel interfaces aren't really any more table in other operating systems. Have you ever developed kernel drivers for different versions of Solaris? Windows? HPUX? Tru64? AIX? OpenVMS? Where I work, we develop drivers for all of those platforms, and every version of every one of those kernels is different from every other version that requires us to rewrite and recompile our drivers for each one separately.

So the fact that Linux doesn't have a stable driver ABI is actually one of its most mundane and commonplace attributes.

Can't you just supply SUSE users with a new kernel RPM or patch that you package to work with your program or kernel module?

It's not the best situation, but what other choice do you have? Other companies do it.
See:
http://www.netraverse.com/member/downloads/kernel_download.php

Our software doesn't need any patches like Win4Lin. Our software works off the standard Linux kernel sources (if they were intact).

THe problem here is that SuSE has gone and changed all the kernel headers so that now software doesn't compile. It does work if you were using the stock kerne.org sources.

best regards

Dev Mazumdar
---------------------------------------------------------------------
4Front Technologies
4035 Lafayette Place, Unit F, Culver City, CA 90232, USA
Tel: 310 202 8530 Fax: 310 202 0496 URL: http://www.opensound.com
---------------------------------------------------------------------

Personally I'd make sure the drivers worked with the stock kernel and if they don't work with a distro's release then the bug is theirs. File it with them, include detail and see what happens. If they choose to deviate from the default by such a large degree that what is correctly written and works with the default no longer works with them, the ball is in their court.

If need be, tell them you'll accept patches. :)

Just my 2c.

    Red herrings strewn hither and yon.

The distributions you named earlier all patch the kernels they ship with their distribution.

There's only a handfull that install a vanilla kernel by default (out of the >200 distributions available)

debian, redhat & gentoo patch their kernels.

Is your problem that a kernel is not the kernel.org vanilla version? (If so have a fit @ debian, redhat and gentoo as well )

Or that Suse's does not work with your income generating product?

Regards,

Bastiaan

Redhat/Debian/Gentoo do the right thing by the kernel from www.kernel.org.

We can fix our problems. It's just that it's becomming a treadmill. What's with you guys?. Would you really like to see Linux forking?

best regards

Dev Mazumdar
---------------------------------------------------------------------
4Front Technologies
4035 Lafayette Place, Unit F, Culver City, CA 90232, USA
Tel: 310 202 8530 Fax: 310 202 0496 URL: http://www.opensound.com
---------------------------------------------------------------------

Fix your problems and shut up.

I'm impressed of your altruistic solicitousness about the future of Linux.

Thomas
_____________________________________________________________________

"When customers are visiting, engineers are not allowed to wear ties. That way the customer can tell who is the engineer and who is the salesman (and therefore whom to believe.). Ties cut off blood flow to the brain, making it easier for the salesmen to do their jobs."
_____________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: [email protected]

And therefor you whine here ?

You make Linux better ? By providing closed source drivers and complaining that they wont compile everywhere ? HEHEHE

This statement reveals your deep unawareness of the social contract behind this community and the reality of forking since it started.

Your swollen-headed self-pleasing nature makes you even resistant to sarcasm.

Thanks for providing a nice flame topic and now I have to go back and maintain some diverging non mainline kernel trees.

Hint: Maybe you should adjust your tie. See below.

Thomas
_____________________________________________________________________

"When customers are visiting, engineers are not allowed to wear ties. That way the customer can tell who is the engineer and who is the salesman (and therefore whom to believe.). Ties cut off blood flow to the brain, making it easier for the salesmen to do their jobs."
_____________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: [email protected]

On Thu, 2004-06-17 18:46:11 -0700, 4Front Technologies <[email protected]> wrote in message <[email protected]>:

I like playing with non-i386 hardware, that is, I do have (at least) one "forked" kernel for each architecture, possibly even more than one... It's just that --most of the time-- it's missing time that leads to forked trees (that need unification some time after...). Bet on it, I'd really like getting hired for keeping an eye on all those trees and working on reviewing/merging them all back to Linus' tree! It's probably nothing different with the SuSE kernels. You've hit a bug here, so let's solve that. But their large patch set won't go away completely:

- Legacy drivers ported from 2.2.x and 2.4.x? Customer should use newer drivers.
- Bugs fixed? Bugfix needs review and merge! (Hire me, if you can:)
- New drivers? Review and merge!
- New features that touch all the kernel? Needs a lot of discussion...

So, some parts are easy, some are not. Your problem's bugfix for sure isn't hard to do, but large chunks of their patch may need *long* lasting discussion...

MfG, JBG

   Jan-Benedict Glaw       [email protected]    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

Consider getting your driver into the standard kernel - then you get less problems with header changes. (Those who change headers usually keep the standard tree working.) If you want to keep a driver for yourself though, then you need to keep fixing it continously jsut to keep up with the standard kernel. And if you want SUSE customers, then you need to keep up with their patches too. An so on for all the other distributions.

_Why not_? It is not something I worry about. Forks happen, but go away as the forked stuff either is merged back into the std. kernel (if it is good) or becomes obsolete after a few months. Anyone who maintains their own fork get the burden of keeping up with Linus - this limits the forking.

Helge Hafting

the right thing = compatible with your drivers.

who says all the modifications suse does to their kernel is on the bad side? im sure they some kind of reason to change the kernel code. true, its not exactly the same as the vanilla kernel.
and true, it would be best if they could make do compatible code, however, and as you are supposed to be a developer, you must know that it is not possible to always keep compatibility.
and as earlier mentioned, "it has 11mb differences."
oh well well, the unzipped suse diff from you, is 13mb, but that doesent really matter, however, what matters is all the overhead diff creates. if you open the diff you can see that it will probably only be half the differences the suse kernel really has, like 6.5mb or something near it.

i dont want to say theres no possibility that there really is a kernel bug. but saying "madness" is abit harsh to do.

Regards, Redeeman
[email protected]

Linux forks all the time, and that's a good thing.

Jeff

Who defined "using vanilla kernels" as "the right thing"?

Certainly not kernel developers.

It should also be noted that the 'gentoo-sources' kernel that is, last I checked, the default (or at least the recommended kernel) for Gentoo is patched (1.1 MB of bzip2'd patches at the time of this writing). That Redhat uses their own patched kernel is no secret either.

So his statement is not only misguided, but patently false.

Alex Goddard
agoddard at purdue dot edu

If SuSE is such a problem for you, then don't support their distro.

The GPL explicitly allows them to do what they are doing with their kernels. There is nothing unethical about them shipping patched kernels and calling them "Linux".

The problem is not with SuSE. The problem is with your expectations.

internal kernel apis change and are fair game. As a RH kernel maintainer I can guarantee you that you will suffer too from internal kernel changes in RH/Fedora kernels. Or from changes within the 2.6.x series. Linux needs such changes to allow faster and cleaner development. The cost is on the external modules; it has a good side too, it provides an incentive for external modules to merge into the kernel so that they get fixed automatic. Having such incentives is in my opinion a good thing.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

4Front Technologies wrote:
| Hi Folks,

file a bug against suse 9.1 and work with them. Its not the Kernels Developers fault or problem what kind of patches distributions use.

please stop your whining.

- --
Clemens Schwaighofer - IT Engineer & System Administration
==========================================================
TEQUILA\Japan, 6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN
Tel: +81-(0)3-3545-7703 Fax: +81-(0)3-3545-7343
http://www.tequila.co.jp
==========================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA0qOTjBz/yQjBxz8RApKPAJ9mkZqZYqOeYWZA8qlq1IvBEQ4kvwCgsB++ D/atmDIOkhXgAn8wgwp8Pxo=
=+/zK
-----END PGP SIGNATURE-----

If you have a specific problem, describe it, and linux kernel maintainers and SuSE would be glad to help you.

But this kind of whiny rant only serves to make "4Front Technologies" look like a bunch of unprofessional dorks. It's one thing for some 13-year-old script kiddy to act like a baby, but it really looks bad when the representative of a company acts like this.

Arjan, I agree with what you're saying, but it looks to me that the 4front guy was complaining about the lack of meaningful EXTRAVERSION. Hard to say for sure when he's raving though...

-- Pete

Last time I checked, SUSE kernels include " characters in EXTRAVERSION and KERNELRELEASE Makefile strings. Those " characters need to be filtered out before EXTRAVERSION and KERNELRELEASE strings can be used.

Just another SUSE sillyness.

Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD

What kind of crap 've you been smokin'? Sue your dealer.

With all due respect,
Lars Marowsky-Brée <[email protected]>

High Availability & Clustering	      \ ever tried. ever failed. no matter.
SUSE Labs			      | try again. fail again. fail better.
Research & Development, SUSE LINUX AG \ 	-- Samuel Beckett

First 6 lines of Kernel Makefile (SuSE 8 ES on AMD64 Opteron):

VERSION = 2
PATCHLEVEL = 4
SUBLEVEL = 21
EXTRAVERSION = -$(CONFIG_RELEASE)-$(CONFIG_CFGNAME)

KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)

Last 7 lines of .config (SuSE 8 ES on AMD64 Opteron):

#
# Build options
#
# CONFIG_SUSE_KERNEL is not set
CONFIG_UNITEDLINUX_KERNEL=y
CONFIG_CFGNAME="smp"
CONFIG_RELEASE=207

Those " characters around "smp" will not go away automatically. To see the difference try these lines in Makefile:

    echo $(KERNELRELEASE)
    echo '$(KERNELRELEASE)'

Those " characters make quite difference in Makefile code like this:

ifneq ($(KERNELRELEASE),$(shell uname -r))
@echo You compiled this for wrong kernel
endif

You seem to use SUSE email address, so maybe _you_ should be answering this
question: What kind of crap 've you been smokin'?

Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD

Indeed, that was a bug. In our current tree we have this, which gets rid of the superfluous quotes:

EXTRAVERSION = -$(shell echo $(CONFIG_RELEASE)-$(CONFIG_CFGNAME))

Well, it depends in which context you use the string, which is why we didn't catch the bug for a long time. I agree that the quotes shouldn't be there. Mistakes happen.

This test may often turn out not to be very useful: For example, we are building modules for different kernels without booting into each of those kernels. Cross-compiling is another case where the above test doesn't work.

Regards,

Andreas Gruenbacher <[email protected]>
SUSE Labs, SUSE LINUX AG