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 http://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
---------------------------------------------------------------------
On Thu, Jun 17, 2004 at 05:09:17PM -0700, 4Front Technologies wrote:
> Files linux-2.6.5/arch/i386/boot98/setup.S and
> linux-2.6.5-7.75/arch/i386/boot98/setup.S differ
>
Ok. They edit setup.S. This doesn't change APIs.
> Files linux-2.6.5/arch/i386/defconfig and
> linux-2.6.5-7.75/arch/i386/defconfig differ
>
SuSE doesn't ship the default kernel .config. *SHOCK!* Neither does
anyone else.
> 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
>
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
> 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.
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.
> 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.
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).
> 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.
So what's broken then? Specifically which kernel interface are you
calling that has a broken behaviour?
> I think SuSE's lying when they call their Linux kernel a 2.6.5 kernel
> when there are massive differences.
They didn't say it was 2.6.5, they said it was based on it.
> They aren't even compatible with Linux 2.6.6.
In what way?
> 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.
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.
Martin J. Bligh wrote:
>>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.
>
>
> 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.
>
>
>>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.
>
>
> 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).
>
>
>>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.
>
>
> So what's broken then? Specifically which kernel interface are you
> calling that has a broken behaviour?
>
>
>>I think SuSE's lying when they call their Linux kernel a 2.6.5 kernel
>>when there are massive differences.
>
>
> They didn't say it was 2.6.5, they said it was based on it.
>
>
>>They aren't even compatible with Linux 2.6.6.
>
>
> In what way?
>
>
>>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.
>
>
> 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:
> make -C /lib/modules/`uname -r`/build scripts scripts_basic include/linux/version.h
> make[1]: Entering directory `/usr/src/linux-2.6.5-7.75-obj/i386/bigsmp'
> make[1]: Nothing to be done for `scripts'.
> make[1]: *** No rule to make target `scripts_basic'. Stop.
> make[1]: Leaving directory `/usr/src/linux-2.6.5-7.75-obj/i386/bigsmp'
> make: *** [ossbuild] Error 2
>
> Trying to compile using INCLUDE=/lib/modules/2.6.5-7.75-bigsmp/build/include
> In file included from /usr/include/asm/smp.h:18,
> from /usr/include/linux/smp.h:17,
> from /usr/include/linux/sched.h:23,
> from /usr/include/linux/module.h:10,
> from src/sndshield.c:49:
> /usr/include/asm/mpspec.h:6:25: mach_mpspec.h: No such file or directory
> In file included from /usr/include/asm/smp.h:18,
> from /usr/include/linux/smp.h:17,
> from /usr/include/linux/sched.h:23,
> from /usr/include/linux/module.h:10,
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
---------------------------------------------------------------------
> 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.
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.
4Front Technologies <[email protected]> wrote:
>
> 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.
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.
On Thu, Jun 17, 2004 at 05:09:17PM -0700, 4Front Technologies wrote:
> 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.
"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...
[email protected] wrote:
> On Thu, Jun 17, 2004 at 05:09:17PM -0700, 4Front Technologies wrote:
>
>>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.
>
>
> "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
---------------------------------------------------------------------
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
On Thu, 17 Jun 2004 17:09:17 -0700, 4Front Technologies
<[email protected]> wrote:
>
> 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 http://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
> ---------------------------------------------------------------------
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
thinkliberty wrote:
> 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
---------------------------------------------------------------------
On Thu, Jun 17, 2004 at 06:00:45PM -0700, 4Front Technologies wrote:
> That's right Al, 4Front, ATI, Nvidia are all evil!. OK so now get on with
> life.
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,
On Thu, 17 Jun 2004, 4Front Technologies wrote:
> 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.
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
On Thu, Jun 17, 2004 at 06:12:03PM -0700, 4Front Technologies wrote:
> 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.
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.
> b) They shipped the kitchen sink with 2.4 and their customers still want
> to wash the dishes in 2.6.
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
On Friday 18 June 2004 03:00, 4Front Technologies wrote:
> > 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.
There are different levels of evil. I never heard Nvidia complaining about
SUSE header files here.
> 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.
You can _USE_ Linux without being a kernel developer. You talk about _YOUR_
business problems and not about problems related to this community.
> 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?
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
_____________________________________________________________________
>From slash dot org
"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]
Roman Zippel wrote:
> Hi,
>
> On Thu, 17 Jun 2004, 4Front Technologies wrote:
>
>
>>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.
>
>
> 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
---------------------------------------------------------------------
4Front Technologies wrote:
>
> 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.
>
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?
Nick Piggin wrote:
> 4Front Technologies wrote:
>
>>
>> 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.
>>
>
> No, it is still our personal sandbox actually, and it is you
> who must pay attention to in-kernel interfaces.
>
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?
> Or were you hoping that we're all here just to make your life
> easier?
>
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
---------------------------------------------------------------------
In article <[email protected]> you wrote:
> 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?
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/
On Fri, 2004-06-18 at 03:12, 4Front Technologies wrote:
> 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.
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
4Front Technologies wrote:
> Nick Piggin wrote:
>
>> 4Front Technologies wrote:
>>
>>>
>>> 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.
>>>
>>
>> No, it is still our personal sandbox actually, and it is you
>> who must pay attention to in-kernel interfaces.
>>
> 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?
>
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.
>> Or were you hoping that we're all here just to make your life
>> easier?
>>
> 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?
>
I think maybe you should get a good night's sleep before posting
again.
Bastiaan Spandaw wrote:
>
> 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 )
>
Redhat/Debian/Gentoo do the right thing by the kernel from http://www.kernel.org.
> Or that Suse's does not work with your income generating product?
>
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
---------------------------------------------------------------------
On Friday 18 June 2004 03:46, 4Front Technologies wrote:
> > Or that Suse's does not work with your income generating product?
>
> We can fix our problems. It's just that it's becomming a treadmill.
Fix your problems and shut up.
> What's with you guys?. Would you really like to see Linux forking?
I'm impressed of your altruistic solicitousness about the future of Linux.
--
Thomas
_____________________________________________________________________
>From slash dot org
"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, 17 Jun 2004 18:37:17 -0700, 4Front Technologies
<[email protected]> wrote:
>
> Nick Piggin wrote:
> > 4Front Technologies wrote:
> >
> >>
> >> 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.
> >>
> >
> > No, it is still our personal sandbox actually, and it is you
> > who must pay attention to in-kernel interfaces.
> >
> 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?
>
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
> > Or were you hoping that we're all here just to make your life
> > easier?
> >
> 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
> ---------------------------------------------------------------------
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
> 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:
>
>> make -C /lib/modules/`uname -r`/build scripts scripts_basic include/linux/version.h
>> make[1]: Entering directory `/usr/src/linux-2.6.5-7.75-obj/i386/bigsmp'
>> make[1]: Nothing to be done for `scripts'.
>> make[1]: *** No rule to make target `scripts_basic'. Stop.
>> make[1]: Leaving directory `/usr/src/linux-2.6.5-7.75-obj/i386/bigsmp'
>> make: *** [ossbuild] Error 2
>>
>> Trying to compile using INCLUDE=/lib/modules/2.6.5-7.75-bigsmp/build/include
>> In file included from /usr/include/asm/smp.h:18,
>> from /usr/include/linux/smp.h:17,
>> from /usr/include/linux/sched.h:23,
>> from /usr/include/linux/module.h:10,
>> from src/sndshield.c:49:
>> /usr/include/asm/mpspec.h:6:25: mach_mpspec.h: No such file or directory
>> In file included from /usr/include/asm/smp.h:18,
>> from /usr/include/linux/smp.h:17,
>> from /usr/include/linux/sched.h:23,
>> from /usr/include/linux/module.h:10,
>
>
>
> 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
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 Thu, 2004-06-17 18:46:11 -0700, 4Front Technologies <[email protected]>
wrote in message <[email protected]>:
> What's with you guys?. Would you really like to see Linux forking?
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));
On Fri, 2004-06-18 at 02:09, 4Front Technologies wrote:
> 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).
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.
Quote from 4Front Technologies <[email protected]>:
> 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?
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.
-----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-----
On Thu, Jun 17 2004, Andrew Morton wrote:
> 4Front Technologies <[email protected]> wrote:
> >
> > 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.
>
> 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.
The guy seems to have some personal agenda, posting specifics would ruin
his otherwise fine troll.
> 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.
Precisely.
> 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
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.
> 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.
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
4Front Technologies wrote:
> Bastiaan Spandaw wrote:
>
>>
>> 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 )
>>
>
> Redhat/Debian/Gentoo do the right thing by the kernel from
> http://www.kernel.org.
>
>> Or that Suse's does not work with your income generating product?
>>
> We can fix our problems. It's just that it's becomming a treadmill.
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.
> What's with you guys?. Would you really like to see Linux forking?
_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
>
>
>
> 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
> ---------------------------------------------------------------------
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Fri, 2004-06-18 08:45:53 +0100, John Bradford <[email protected]>
wrote in message <[email protected]>:
> Quote from 4Front Technologies <[email protected]>:
> 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 :-).
/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));
4Front Technologies wrote:
> 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.
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
On Fri, Jun 18, 2004 at 03:20:48AM +0200, Roman Zippel wrote:
> On Thu, 17 Jun 2004, 4Front Technologies wrote:
>
> > 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.
>
> Look into your own diapers, learn the meaning of "documented interfaces"
> and come back if you can show that SuSE broke exactly this.
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
Hi,
On Thu, 17 Jun 2004, 4Front Technologies wrote:
> 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.
To quote from your previous mail:
> make -C /lib/modules/`uname -r`/build scripts scripts_basic include/linux/version.h
> make[1]: Entering directory `/usr/src/linux-2.6.5-7.75-obj/i386/bigsmp'
> make[1]: Nothing to be done for `scripts'.
> make[1]: *** No rule to make target `scripts_basic'. Stop.
> make[1]: Leaving directory `/usr/src/linux-2.6.5-7.75-obj/i386/bigsmp'
> make: *** [ossbuild] Error 2
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
On Thu, 17 Jun 2004, 4Front Technologies wrote:
> That's right Al, 4Front, ATI, Nvidia are all evil!. OK so now get on with
> life.
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
On Fre, 2004-06-18 at 02:27, 4Front Technologies wrote:
[...]
> 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.
[ compile 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
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
Bernd Eckenfels wrote:
> 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.
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)
On Fri, 2004-06-18 at 03:46, 4Front Technologies wrote:
> Content-Transfer-Encoding: 7bit
> Sender: [email protected]
> Precedence: bulk
> X-Mailing-List: [email protected]
>
> Bastiaan Spandaw wrote:
> >
> > 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 )
> >
>
> Redhat/Debian/Gentoo do the right thing by the kernel from http://www.kernel.org.
the right thing = compatible with your drivers.
>
> > Or that Suse's does not work with your income generating product?
> >
> 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?
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.
>
>
>
>
> 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
> ---------------------------------------------------------------------
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Regards, Redeeman
[email protected]
On Fri, Jun 18, Petr Vandrovec wrote:
> On Fri, Jun 18, 2004 at 03:20:48AM +0200, Roman Zippel wrote:
> > On Thu, 17 Jun 2004, 4Front Technologies wrote:
> >
> > > 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.
> >
> > Look into your own diapers, learn the meaning of "documented interfaces"
> > and come back if you can show that SuSE broke exactly this.
>
> 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...
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
On Fri, Jun 18, 2004 at 03:47:32PM +0200, Olaf Hering wrote:
> On Fri, Jun 18, Petr Vandrovec wrote:
>
> > On Fri, Jun 18, 2004 at 03:20:48AM +0200, Roman Zippel wrote:
> > > On Thu, 17 Jun 2004, 4Front Technologies wrote:
> > >
> > > > 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.
> > >
> > > Look into your own diapers, learn the meaning of "documented interfaces"
> > > and come back if you can show that SuSE broke exactly this.
> >
> > 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...
>
> I would not call this file an interface, but utter bullshit. Just
> because it breaks all these bullshit devices...
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
On Fri, 18 Jun 2004, Jens Axboe wrote:
> On Thu, Jun 17 2004, Andrew Morton wrote:
> > Hopefully we'll be seeing more patches from them soon.
> The last thing anyone wants is the situation we had/have with
> (basically all) 2.4 vendor kernels.
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
On Thu, 17 Jun 2004, Kyle McMartin wrote:
> On Thu, Jun 17, 2004 at 05:09:17PM -0700, 4Front Technologies wrote:
> > Files linux-2.6.5/arch/i386/boot98/setup.S and
> > linux-2.6.5-7.75/arch/i386/boot98/setup.S differ
> >
> Ok. They edit setup.S. This doesn't change APIs.
>
> > Files linux-2.6.5/arch/i386/defconfig and
> > linux-2.6.5-7.75/arch/i386/defconfig differ
> >
> SuSE doesn't ship the default kernel .config. *SHOCK!* Neither does
> anyone else.
>
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]>
On Fri, 18 Jun 2004, Jesper Juhl wrote:
> On Thu, 17 Jun 2004, Kyle McMartin wrote:
>
> > On Thu, Jun 17, 2004 at 05:09:17PM -0700, 4Front Technologies wrote:
> > > Files linux-2.6.5/arch/i386/boot98/setup.S and
> > > linux-2.6.5-7.75/arch/i386/boot98/setup.S differ
> > >
> > Ok. They edit setup.S. This doesn't change APIs.
> >
> > > Files linux-2.6.5/arch/i386/defconfig and
> > > linux-2.6.5-7.75/arch/i386/defconfig differ
> > >
> > SuSE doesn't ship the default kernel .config. *SHOCK!* Neither does
> > anyone else.
> >
> 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.
>
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]>
> Or do I miss some nice and simple interface which can be used for
> notifications about newly plugged (USB) devices?
hotplug?
On Fri, Jun 18, 2004 at 10:43:19AM -0400, Rik van Riel wrote:
> 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.
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
4Front Technologies wrote:
> 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.
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.
4Front Technologies wrote:
> thinkliberty wrote:
>
>> 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.
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.
4Front Technologies wrote:
> What's with you guys?. Would you really like to see Linux forking?
Linux forks all the time, and that's a good thing.
Jeff
4Front Technologies wrote:
> 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?
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.
4Front Technologies wrote:
>
> Redhat/Debian/Gentoo do the right thing by the kernel from http://www.kernel.org.
>
Who defined "using vanilla kernels" as "the right thing"?
Certainly not kernel developers.
On Fri, 2004-06-18 08:13:15 -0700, William Lee Irwin III <[email protected]>
wrote in message <[email protected]>:
> On Fri, Jun 18, 2004 at 10:43:19AM -0400, Rik van Riel wrote:
> > 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.
>
> 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.
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));
Hello,
On Fri, 2004-06-18 at 02:27, 4Front Technologies wrote:
> 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.
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/.
> For instance our kernel interface module doesn't compile anymore we see the following
> errors:
>
> > make -C /lib/modules/`uname -r`/build scripts scripts_basic include/linux/version.h
> > make[1]: Entering directory `/usr/src/linux-2.6.5-7.75-obj/i386/bigsmp'
> > make[1]: Nothing to be done for `scripts'.
> > make[1]: *** No rule to make target `scripts_basic'. Stop.
> > make[1]: Leaving directory `/usr/src/linux-2.6.5-7.75-obj/i386/bigsmp'
> > make: *** [ossbuild] Error 2
> >
> > Trying to compile using INCLUDE=/lib/modules/2.6.5-7.75-bigsmp/build/include
> > In file included from /usr/include/asm/smp.h:18,
> > from /usr/include/linux/smp.h:17,
> > from /usr/include/linux/sched.h:23,
> > from /usr/include/linux/module.h:10,
> > from src/sndshield.c:49:
> > /usr/include/asm/mpspec.h:6:25: mach_mpspec.h: No such file or directory
> > In file included from /usr/include/asm/smp.h:18,
> > from /usr/include/linux/smp.h:17,
> > from /usr/include/linux/sched.h:23,
> > from /usr/include/linux/module.h:10,
>
>
>
> 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
Sincerely,
--
Andreas Gruenbacher <[email protected]>
SUSE Labs, SUSE LINUX AG
On Fri, 18 Jun 2004, Timothy Miller wrote:
>
>
> 4Front Technologies wrote:
>
>>
>> Redhat/Debian/Gentoo do the right thing by the kernel from http://www.kernel.org.
>
> 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
On Fri, 18 Jun 2004, Jan-Benedict Glaw wrote:
> For what I guess, those should better be native Indian speakers...
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
> 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.
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
On Fri, 2004-06-18 at 17:48, Andreas Gruenbacher wrote:
Hi,
> 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.
>
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
On Fri, 18 Jun 2004, Roman Zippel wrote:
> To quote from your previous mail:
>
> > make -C /lib/modules/`uname -r`/build scripts scripts_basic include/linux/version.h
>
> That doesn't really like documented interfaces to me.
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
Andreas Gruenbacher wrote:
> Hello,
[SNIP]
> 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/.
>
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
---------------------------------------------------------------------
4Front Technologies wrote:
> 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.
Sounds like you're making a demand. Who are you and why are we
interested in your demands?
On Fri, 2004-06-18 13:17:31 -0400, Paul Jakma <[email protected]>
wrote in message <[email protected]>:
> On Fri, 18 Jun 2004, Jan-Benedict Glaw wrote:
> >For what I guess, those should better be native Indian speakers...
>
> Hmm, my indian colleagues speak perfect english. Why make this
> comment at all btw...
>From my current view, there's a lot of work being done in and around
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));
Timothy Miller wrote:
>
>
> 4Front Technologies wrote:
>
>> 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.
>
>
>
> 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
---------------------------------------------------------------------
On Jun 18, 2004, at 14:23, 4Front Technologies wrote:
> Timothy,
>
> Who are you to revoke my request to SuSE and other distributors and
> others who share
> my views on LKML?
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.
> 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.
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/>).
> 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.
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
On Jun 18, 2004 10:53 -0700, 4Front Technologies wrote:
> 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.
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/
Jan-Benedict Glaw wrote:
> On Fri, 2004-06-18 08:13:15 -0700, William Lee Irwin III
> <[email protected]>
> wrote in message <[email protected]>:
>
>>On Fri, Jun 18, 2004 at 10:43:19AM -0400, Rik van Riel wrote:
>>
>>>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.
>>
>>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.
>
> 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...
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.
>
> 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!
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]
=============================
On Fri, 18 Jun 2004 11:23:52 PDT, 4Front Technologies said:
> 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.
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.
Andreas Dilger wrote:
> On Jun 18, 2004 10:53 -0700, 4Front Technologies wrote:
>
>>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.
>
>
> 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).
>
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: http://www.opensound.com
Fax: (310) 202 0496 Email: [email protected]
-----------------------------------------------------------
4Front Technologies wrote:
> Timothy Miller wrote:
>
>>
>>
>> 4Front Technologies wrote:
>>
>>> 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.
>>
>>
>>
>>
>> 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?
_I_ am not revoking anything. I don't have the right to do that. _I_
am simply asking a rhetorical question.
>
> 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.
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.
>
> It's high time people like me spoke up for standardization and some
> sense of
> organization.
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.
> 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.
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. :)
Tim Bird wrote:
> 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.
Now, THAT is a good idea.
On Fri, 18 Jun 2004 13:12:34 PDT, 4Front Technologies said:
> 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.
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
On Fri, 18 Jun 2004 08:40:15 +0200
Arjan van de Ven <[email protected]> wrote:
> On Fri, 2004-06-18 at 02:09, 4Front Technologies wrote:
> > 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).
>
> 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.
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
On Fri, 18 Jun 2004, Jan-Benedict Glaw wrote:
> On Fri, 2004-06-18 08:13:15 -0700, William Lee Irwin III <[email protected]>
> > The shame of things is that the economic/effort problem appears to
> > often be "solved" by never migrating to new kernel versions, ...
> 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.
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
On Fri, 18 Jun 2004, Tim Bird wrote:
> Jan-Benedict Glaw wrote:
> 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.
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
Hi,
On Fri, 18 Jun 2004, Hannu Savolainen wrote:
> > To quote from your previous mail:
> >
> > > make -C /lib/modules/`uname -r`/build scripts scripts_basic include/linux/version.h
> >
> > That doesn't really like documented interfaces to me.
> 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.
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.
> The actual problem is that there is no standardized way to compile modules
> outside the kernel source tree.
Wrong, there is no automatic way to build an external that takes care of
all possible problems and there never will be.
> There will be serious problems if
> different distributions need slightly different installation procedure.
No, there will be serious problems if module authors use undocumented
features and demand for them to work forever.
bye, Roman
Rik van Riel wrote:
> On Fri, 18 Jun 2004, Tim Bird wrote:
>
>>Jan-Benedict Glaw wrote:
>
>
>>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.
>
>
> 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.
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 16:05:46 -0400, Rik van Riel <[email protected]>
wrote in message <Pine.LNX.4.44.0406181604270.8065-100000@chimarrao.boston.redhat.com>:
> On Fri, 18 Jun 2004, Tim Bird wrote:
> 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.
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));
On Fri, 2004-06-18 13:20:02 -0700, Tim Bird <[email protected]>
wrote in message <[email protected]>:
> >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.
> 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.
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, 18 Jun 2004 13:29:11 PDT, David Lang said:
> 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
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....
On Fri, 18 Jun 2004, Andrew Morton wrote:
> Rik van Riel <[email protected]> wrote:
> >
> > 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.
>
> Problem is, what happens if vendor X ships a feature and that feature is
> deemed unacceptable for the kernel.org kernel?
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 ;)
> 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.
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 22:03:51 +0100, [email protected] <[email protected]>
wrote in message <[email protected]>:
> On Fri, 18 Jun 2004, Jan-Benedict Glaw wrote:
> > 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.
>
> 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
> $$$$$.
Very right. Companies don't see any general benefit, if there isn't any
$$ to come in soon.
> 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.
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));
On Fri, Jun 18 2004, Jan-Benedict Glaw wrote:
> On Fri, 2004-06-18 22:03:51 +0100, [email protected] <[email protected]>
> wrote in message <[email protected]>:
> > On Fri, 18 Jun 2004, Jan-Benedict Glaw wrote:
> > > 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.
> >
> > 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
> > $$$$$.
>
> Very right. Companies don't see any general benefit, if there isn't any
> $$ to come in soon.
>
> > 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.
>
> Hope the CE Forum will show some engagement there. Or OSDL. Or IBM.
> Or ... But usually, that's hot air. No direct income :--<
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, Jun 18 2004, Andrew Morton wrote:
> Rik van Riel <[email protected]> wrote:
> >
> > 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.
>
> Problem is, what happens if vendor X ships a feature and that feature is
> deemed unacceptable for the kernel.org kernel?
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.
> 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.
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)...
> 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.
Wish I had an answer for that. Things can and do get dropped from vendor
trees, doesn't cover all cases naturally.
--
Jens Axboe
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>:
> On Fri, 18 Jun 2004, Andrew Morton wrote:
> Sure, it is some short term work for the vendor, but it'll
> save work in the long run.
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));
On Fri, 2004-06-18 23:13:53 +0200, Jens Axboe <[email protected]>
wrote in message <[email protected]>:
> On Fri, Jun 18 2004, Jan-Benedict Glaw wrote:
> > Hope the CE Forum will show some engagement there. Or OSDL. Or IBM.
> > Or ... But usually, that's hot air. No direct income :--<
>
> 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.
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));
On Fri, 18 Jun 2004, Jan-Benedict Glaw wrote:
> 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>:
> > On Fri, 18 Jun 2004, Tim Bird wrote:
>
> > 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.
>
> 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.
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 Jun 18, 2004, at 16:31, Hannu Savolainen wrote:
> 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.
Ahh, my apologies then. I am sincerely sorry for any offense I may have
caused.
>> you've done is demand things of the LKML, but why should we listen to
>> your demands instead of our own.
> 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.
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.
>> 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/
>> >).
> 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.
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
> 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.
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
Hannu Savolainen wrote:
> On Fri, 18 Jun 2004, Roman Zippel wrote:
>
>
>>To quote from your previous mail:
>>
>>
>>>make -C /lib/modules/`uname -r`/build scripts scripts_basic include/linux/version.h
>>
>>That doesn't really like documented interfaces to me.
>
> Right. The documented command is "make install". However an undocumented
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.
> 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?
In 2.6.x there is a way to do this :)
Sam Ravnborg recently posted documentation for this, as well.
Jeff
On Fri, Jun 18, 2004 at 10:03:51PM +0100, [email protected] wrote:
> 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.
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]>:
> On Fri, Jun 18, 2004 at 10:03:51PM +0100, [email protected] wrote:
> You know, that would sound much more impressive if drivers *already* *in*
> *the* *tree* would get fixed.
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));
On Fri, Jun 18, 2004 at 05:52:46PM -0400, Jeff Garzik wrote:
> Hannu Savolainen wrote:
>
> >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?
>
> In 2.6.x there is a way to do this :)
>
> Sam Ravnborg recently posted documentation for this, as well.
<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 & http://www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
Sam Ravnborg wrote:
> On Thu, Jun 17, 2004 at 05:27:45PM -0700, 4Front Technologies wrote:
>
>>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:
>>
>>
>>>make -C /lib/modules/`uname -r`/build scripts scripts_basic
>>>include/linux/version.h
>>>make[1]: Entering directory `/usr/src/linux-2.6.5-7.75-obj/i386/bigsmp'
>>>make[1]: Nothing to be done for `scripts'.
>>>make[1]: *** No rule to make target `scripts_basic'. Stop.
>>>make[1]: Leaving directory `/usr/src/linux-2.6.5-7.75-obj/i386/bigsmp'
>>>make: *** [ossbuild] Error 2
>>>
>>>Trying to compile using
>>>INCLUDE=/lib/modules/2.6.5-7.75-bigsmp/build/include
>>>In file included from /usr/include/asm/smp.h:18,
>>> from /usr/include/linux/smp.h:17,
>>> from /usr/include/linux/sched.h:23,
>>> from /usr/include/linux/module.h:10,
>>> from src/sndshield.c:49:
>>>/usr/include/asm/mpspec.h:6:25: mach_mpspec.h: No such file or directory
>>>In file included from /usr/include/asm/smp.h:18,
>>> from /usr/include/linux/smp.h:17,
>>> from /usr/include/linux/sched.h:23,
>>> from /usr/include/linux/module.h:10,
>>
>>
>>
>>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
>
>
> 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: http://www.opensound.com
Fax: (310) 202 0496 Email: [email protected]
-----------------------------------------------------------
Rik van Riel <[email protected]> wrote:
>
> 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.
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.
On Friday 18 June 2004 22:59, 4Front Technologies wrote:
> 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,
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
_____________________________________________________________________
>From slash dot org
"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]
Matt Domsch wrote:
>
> <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>
>
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: http://www.opensound.com
Fax: (310) 202 0496 Email: [email protected]
-----------------------------------------------------------
On Friday 18 June 2004 04:56, 4Front Technologies wrote:
>
> Problem fixed!. it's SuSE's fault!. They didn't symlink
> /lib/modules/<kernel ver>/build to the correct source tree.
And therefor you whine here ?
> >>What's with you guys?. Would you really like to see Linux forking?
> >
> > I'm impressed of your altruistic solicitousness about the future of Linux
>
> Thanks, we're trying to make Linux better for everybody.
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
_____________________________________________________________________
>From slash dot org
"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 Fri, 2004-06-18 23:13:53 +0200, Jens Axboe <[email protected]>
> wrote in message <[email protected]>:
> > On Fri, Jun 18 2004, Jan-Benedict Glaw wrote:
>
> > > Hope the CE Forum will show some engagement there. Or OSDL. Or IBM.
> > > Or ... But usually, that's hot air. No direct income :--<
I have heard companies complain about the free beer mentality linux users
have. I guess they have the same problem :-(
> > 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.
>
> 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.
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 Fri, 18 Jun 2004, Kyle Moffett wrote:
> On Jun 18, 2004, at 14:23, 4Front Technologies wrote:
> > Timothy,
> >
> > Who are you to revoke my request to SuSE and other distributors and
> > others who share
> > my views on LKML?
>
> 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).
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.
> you've done is demand things of the LKML, but why should we listen to
> your demands instead of our own.
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.
> > 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.
>
> If you want things more organized, then please code it up and submit a
> series of
> clean patches against the current kernel.
We will do that in the near future.
> 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/>).
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
On Thu, Jun 17, 2004 at 05:27:45PM -0700, 4Front Technologies wrote:
>
> 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:
>
> >make -C /lib/modules/`uname -r`/build scripts scripts_basic
> >include/linux/version.h
> >make[1]: Entering directory `/usr/src/linux-2.6.5-7.75-obj/i386/bigsmp'
> >make[1]: Nothing to be done for `scripts'.
> >make[1]: *** No rule to make target `scripts_basic'. Stop.
> >make[1]: Leaving directory `/usr/src/linux-2.6.5-7.75-obj/i386/bigsmp'
> >make: *** [ossbuild] Error 2
> >
> >Trying to compile using
> >INCLUDE=/lib/modules/2.6.5-7.75-bigsmp/build/include
> >In file included from /usr/include/asm/smp.h:18,
> > from /usr/include/linux/smp.h:17,
> > from /usr/include/linux/sched.h:23,
> > from /usr/include/linux/module.h:10,
> > from src/sndshield.c:49:
> >/usr/include/asm/mpspec.h:6:25: mach_mpspec.h: No such file or directory
> >In file included from /usr/include/asm/smp.h:18,
> > from /usr/include/linux/smp.h:17,
> > from /usr/include/linux/sched.h:23,
> > from /usr/include/linux/module.h:10,
>
>
>
> 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
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
On Fri, 2004-06-18 12:02:48 -0700, Tim Bird <[email protected]>
wrote in message <[email protected]>:
> 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.
Want to offer some airplane ticket Europe -> Canada and back? I'd love
at attend!
> >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!
>
> 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.
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));
On Fri, 18 Jun 2004 [email protected] wrote:
> On Fri, 18 Jun 2004 13:12:34 PDT, 4Front Technologies said:
>
>> 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.
>
> Right, but hopefully you can tell it's a SuSE machine via other means, and
> then apply a suitable workaround.
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
On Fri, 2004-06-18 15:45:53 -0400, Timothy Miller <[email protected]>
wrote in message <[email protected]>:
> Tim Bird wrote:
>
> >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.
>
> Now, THAT is a good idea.
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));
On Jun 18, 2004 13:12 -0700, 4Front Technologies wrote:
> Andreas Dilger wrote:
> >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).
> >
>
> 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.
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/
On Sat, 2004-06-19 00:18:58 +0100, [email protected] <[email protected]>
wrote in message <[email protected]>:
> 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.
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));
On Fri, 18 Jun 2004, Jeff Garzik wrote:
> > Right. The documented command is "make install". However an undocumented
>
> Really?
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
On Fri, 18 Jun 2004, Jan-Benedict Glaw wrote:
> For what I guess, those should better be native Indian speakers...
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
> > For what I guess, those should better be native Indian speakers...
>
> Iroquois or Souix?
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.
[email protected] <[email protected]> :
[...]
> 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
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]>:
> [email protected] <[email protected]> :
> [...]
> > 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
>
> Do you mean dropped as "Posted on fb-devel but nobody cared" ?
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));
Andreas Gruenbacher wrote:
> On Fri, 2004-06-18 at 02:27, 4Front Technologies wrote:
> > 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.
>
> 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.
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.
> This change hasn't found its way into mainline yet, which is unfortunate.
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
Sam Ravnborg wrote:
> It looks like SuSE as the first distribution took the sane approach to
> seperate source and output files.
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 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.
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.
> So you seems to be bitten by a distributor starting to use a new
> facility in kbuild.
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
Pete Zaitcev wrote:
> Arjan van de Ven <[email protected]> wrote:
> > On Fri, 2004-06-18 at 02:09, 4Front Technologies wrote:
> > > 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).
> >
> > 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.
>
> 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...
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
Hi,
On Sat, 19 Jun 2004, Jari Ruusu wrote:
> > So you seems to be bitten by a distributor starting to use a new
> > facility in kbuild.
>
> SUSE folks made a silly mistake and broke stuff. It was even more silly for
> them to try to submit that breakage to mainline.
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
On 2004-06-19T19:35:56,
Jari Ruusu <[email protected]> said:
> 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.
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
On 2004-06-18T23:17:57,
Jens Axboe <[email protected]> said:
> > Problem is, what happens if vendor X ships a feature and that feature is
> > deemed unacceptable for the kernel.org kernel?
> 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.
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 ;-)
> > 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.
> Wish I had an answer for that. Things can and do get dropped from vendor
> trees, doesn't cover all cases naturally.
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
On Sat, 2004-06-19 at 20:01, Roman Zippel wrote:
> Hi,
>
> On Sat, 19 Jun 2004, Jari Ruusu wrote:
>
> > > So you seems to be bitten by a distributor starting to use a new
> > > facility in kbuild.
> >
> > SUSE folks made a silly mistake and broke stuff. It was even more silly for
> > them to try to submit that breakage to mainline.
>
> 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.
>
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
On Fri, Jun 18, 2004 at 12:25:23PM +0200, Matthias Andree wrote:
> On Thu, 17 Jun 2004, 4Front Technologies wrote:
>
> > That's right Al, 4Front, ATI, Nvidia are all evil!. OK so now get on with
> > life.
>
> Does NVidia's code break on SuSE 9.1?
>
> What do I need commercial OSS for after all when Alsa works well for me?
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
On Sun, 20 Jun 2004, Ryan Anderson wrote:
> > What do I need commercial OSS for after all when Alsa works well for me?
>
> 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")
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
On Sat, 19 Jun 2004, Jan-Benedict Glaw wrote:
> On Sat, 2004-06-19 14:42:14 +0200, Francois Romieu <[email protected]>
> wrote in message <[email protected]>:
> > [email protected] <[email protected]> :
> > [...]
> > > 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
> >
> > Do you mean dropped as "Posted on fb-devel but nobody cared" ?
>
> 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:)
Caring for patches can easily take a multiple of the time to write the patches.
> So we need Rusty's "Not-so-trivial patch monkey(s)"...
:-)
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
On Fri, 18 Jun 2004, David Lang wrote:
> 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)
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
Lars Marowsky-Bree wrote:
> On 2004-06-19T19:35:56,
> Jari Ruusu <[email protected]> said:
> > 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.
>
> What kind of crap 've you been smokin'? Sue your dealer.
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
Roman Zippel wrote:
> On Sat, 19 Jun 2004, Jari Ruusu wrote:
> > SUSE folks made a silly mistake and broke stuff. It was even more silly for
> > them to try to submit that breakage to mainline.
>
> Letting the symlink point to the build directory is the only sane option.
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.
> 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.
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
On Sun, 2004-06-20 at 17:43, Jari Ruusu wrote:
> Lars Marowsky-Bree wrote:
> > On 2004-06-19T19:35:56,
> > Jari Ruusu <[email protected]> said:
> > > 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.
> >
> > What kind of crap 've you been smokin'? Sue your dealer.
>
> First 6 lines of Kernel Makefile (SuSE 8 ES on AMD64 Opteron):
>
> VERSION = 2
> PATCHLEVEL = 4
> SUBLEVEL = 21
> EXTRAVERSION = -$(CONFIG_RELEASE)-$(CONFIG_CFGNAME)
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))
> 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)'
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.
> Those " characters make quite difference in Makefile code like this:
>
> ifneq ($(KERNELRELEASE),$(shell uname -r))
> @echo You compiled this for wrong kernel
> endif
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
On Sun, 20 Jun 2004, Hannu Savolainen wrote:
> On Fri, 18 Jun 2004, David Lang wrote:
>
>> 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)
> 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.
ueing /etc/issue is a BAD idea, while that may work for completely
unmodified systems, many companies require legalese be put in there.
> 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.
or they need to go through the process of getting their driver included in
the main kernel and these headaches go away.
> 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.
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
David Lang wrote:
>
> or they need to go through the process of getting their driver included
> in the main kernel and these headaches go away.
>
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.
>
> 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.
>
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
>
> David Lang
>
best regards
Dev Mazumdar
-----------------------------------------------------------
4Front Technologies
4035 Lafayette Place, Unit F, Culver City, CA 90232, USA.
Tel: (310) 202 8530 URL: http://www.opensound.com
Fax: (310) 202 0496 Email: [email protected]
-----------------------------------------------------------
On Sun, 20 Jun 2004, 4Front Technologies wrote:
> 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.
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
On Mon, 2004-06-21 at 10:07 +0300, Hannu Savolainen wrote:
> 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?
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
On Mon, 21 Jun 2004, Xavier Bestel wrote:
> 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.
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
Jesper Juhl <[email protected]> said:
[...]
> 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.
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
Jan-Benedict Glaw <[email protected]> said:
[...]
> 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.
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
Hannu Savolainen <[email protected]> said:
> On Fri, 18 Jun 2004, Roman Zippel wrote:
>
> > To quote from your previous mail:
> >
> > > make -C /lib/modules/`uname -r`/build scripts scripts_basic include/linux/version.h
> >
> > That doesn't really like documented interfaces to me.
> 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).
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
On Monday 21 June 2004 11:27, Hannu Savolainen wrote:
> On Mon, 21 Jun 2004, Xavier Bestel wrote:
> > 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.
>
> 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.
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
On Sun, Jun 20, 2004 at 06:16:26PM -0700, 4Front Technologies wrote:
> 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.
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.
On Tue, 22 Jun 2004, Andrea Arcangeli wrote:
> 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.
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
On Tuesday 22 June 2004 10:54, Hannu Savolainen wrote:
> 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.
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
On Fri, 2004-06-18 23:34:08 -0400, Horst von Brand <[email protected]>
wrote in message <[email protected]>:
> Jan-Benedict Glaw <[email protected]> said:
> > 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.
>
> Besides, if you haven't got access to the hardware involved and relevant
> test cases, your efforts can be positively harmful.
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));
On 22 Jun 04 at 4:06, Andrea Arcangeli wrote:
> 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
FYI, vmware modules broke during your change because 2.4.20-xx kernels from
RedHat moved page_count() from linux/mm.h to linux/mm_inline.h, and made
it unavailable for non-GPL modules. So we had to do
#ifndef page_count
#define page_count(p) (p)->count
#endif
and this #ifndef test was broken by making page_count inline function.
But I'd like to publicly thank you for your effort, I really appreciate
it.
Best regards,
Petr Vandrovec
On Tue, 2004-06-22 16:38:15 +0200, Petr Vandrovec <[email protected]>
wrote in message <[email protected]>:
> On 22 Jun 04 at 4:06, Andrea Arcangeli wrote:
> FYI, vmware modules broke during your change because 2.4.20-xx kernels from
> RedHat moved page_count() from linux/mm.h to linux/mm_inline.h, and made
> it unavailable for non-GPL modules. So we had to do
>
> #ifndef page_count
> #define page_count(p) (p)->count
> #endif
>
> and this #ifndef test was broken by making page_count inline function.
Just merge the vmware modules upstream. Then, such breakage will be
detected early and probably fixed without putting a lot of work into it
(from your point of view).
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 Sun, 20 Jun 2004, Ryan Anderson wrote:
> > What do I need commercial OSS for after all when Alsa works well for me?
>
> 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")
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.
Cc: omitted because this thread isn't important enough IMO
--
Matthias Andree
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95
Denis Vlasenko wrote:
> On Tuesday 22 June 2004 10:54, Hannu Savolainen wrote:
>
>>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.
>
>
> 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 http://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: http://www.opensound.com
Fax: (310) 202 0496 Email: [email protected]
-----------------------------------------------------------
On Tue, Jun 22, 2004 at 05:12:36PM +0200, Jan-Benedict Glaw wrote:
> Just merge the vmware modules upstream. Then, such breakage will be
> detected early and probably fixed without putting a lot of work into it
> (from your point of view).
a) vmware modules themselves aren't under a free license
b) even if they were there's not really much interest in modules that can't
work with non-free userspace
On Tue, 2004-06-22 18:32:15 +0100, Christoph Hellwig <[email protected]>
wrote in message <[email protected]>:
> On Tue, Jun 22, 2004 at 05:12:36PM +0200, Jan-Benedict Glaw wrote:
> > Just merge the vmware modules upstream. Then, such breakage will be
> > detected early and probably fixed without putting a lot of work into it
> > (from your point of view).
>
> a) vmware modules themselves aren't under a free license
That can be changed.
> b) even if they were there's not really much interest in modules that can't
> work with non-free userspace
...as well as this issue. They'd get some (limited but sufficient) free
maintainence for their software back. See? No technical issues 8^P The
very same could be said about 4Front's OSS drivers.
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));
Matthias Andree wrote:
> On Sun, 20 Jun 2004, Ryan Anderson wrote:
>
>
>>>What do I need commercial OSS for after all when Alsa works well for me?
>>
>>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")
>
>
> So what? If the mutilated hardware requires a commercial driver one
> might as well spend the third-party driver cost on better hardware.
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
> [email protected] <[email protected]> :
> [...]
> > 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
>
> 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)
More like patches come in but no one has enough time to sit down and go
thre wthem and try them out.
On Tue, Jun 22, 2004 at 08:42:20PM +0200, Jan-Benedict Glaw wrote:
> On Tue, 2004-06-22 18:32:15 +0100, Christoph Hellwig <[email protected]>
> wrote in message <[email protected]>:
> > On Tue, Jun 22, 2004 at 05:12:36PM +0200, Jan-Benedict Glaw wrote:
> > > Just merge the vmware modules upstream. Then, such breakage will be
> > > detected early and probably fixed without putting a lot of work into it
> > > (from your point of view).
> >
> > a) vmware modules themselves aren't under a free license
>
> That can be changed.
Yes.
> > b) even if they were there's not really much interest in modules that can't
> > work with non-free userspace
>
> ...as well as this issue. They'd get some (limited but sufficient) free
> maintainence for their software back. See? No technical issues 8^P The
> very same could be said about 4Front's OSS drivers.
I doubt. I emailed with Alan Cox back in 2000 (when VMware 2.0 was to be
released), and he told me that there is no way vmmon & vmnet could find
its way into kernel, regardless of license we'll pick.
We do not have to go for examples very far - bochs currently does not
provide any networking backend which would work like real network card,
without any restrictions on MAC addresses, host-guest or guest-guest
communications. Patch to get it to work over vmnet's interface was task
for half of one afternoon. Would that change opinion of peoples who accept
only free software? I doubt...
So for now it will probably stay way it is - updates are semi-regullary
distributed from my site, some distros picks them up and repackage for
their customers, and everybody is happy that it more or less works.
Best regards,
Petr Vandrovec
On Tuesday 22 June 2004 10:54, Hannu Savolainen wrote:
> 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.
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.
> Hannu
<<V13>>
Jan-Benedict Glaw wrote:
> On Tue, 2004-06-22 18:32:15 +0100, Christoph Hellwig <[email protected]>
> wrote in message <[email protected]>:
>
>>On Tue, Jun 22, 2004 at 05:12:36PM +0200, Jan-Benedict Glaw wrote:
>>
>>>Just merge the vmware modules upstream. Then, such breakage will be
>>>detected early and probably fixed without putting a lot of work into it
>>>(from your point of view).
>>
>>a) vmware modules themselves aren't under a free license
>
>
> That can be changed.
Whatever it is that VMware needs in the kernel can probably be
generalized in some way that makes it useful to other things (like
Win4Lin) and then merged into mainline.
On Wed, Jun 23, 2004 at 10:58:27AM -0400, Timothy Miller wrote:
> Whatever it is that VMware needs in the kernel can probably be
> generalized in some way that makes it useful to other things (like
> Win4Lin) and then merged into mainline.
We already have drivers/net/tun.c thaqt works nicely with Hercules and MoL
for me, but I guess the vmware folks want some additional deep magic.
On Wed, Jun 23, 2004 at 04:03:14PM +0100, Christoph Hellwig wrote:
> On Wed, Jun 23, 2004 at 10:58:27AM -0400, Timothy Miller wrote:
> > Whatever it is that VMware needs in the kernel can probably be
> > generalized in some way that makes it useful to other things (like
> > Win4Lin) and then merged into mainline.
>
> We already have drivers/net/tun.c thaqt works nicely with Hercules and MoL
> for me, but I guess the vmware folks want some additional deep magic.
Unless I missed something, there can be only one userspace reader/writter
attached to the device, while vmnet works like real network segment to
which you can connect any number of userspace processes, and each of
processes gets only packets which are targeted for it (as each process
has its own MAC address). And vmnet interface does not have to have
any representation in host's networking (it can be used just as a channel
for communication between two VMs), which is important if your guests
are running potentially dangerous code, like network worms.
vmnet module actually provides tun-like character device, but with several
differences:
* You can connect any number of userspace processes to it.
* You can connect kernel end to nothing (complete guest-host separation), or
* You can create new network device for kernel end (you'll route between
guests and real world) or
* You can attach this character device to some existing network device,
creating "bridge".
Of these features tun supports only third (creating new kernel network device),
and with help of "normal" bridge also fourth. Correct me if I'm wrong.
Best regards,
Petr Vandrovec
On Wed, Jun 23, 2004 at 06:03:20PM +0200, Petr Vandrovec wrote:
> On Wed, Jun 23, 2004 at 04:03:14PM +0100, Christoph Hellwig wrote:
> > On Wed, Jun 23, 2004 at 10:58:27AM -0400, Timothy Miller wrote:
> > > Whatever it is that VMware needs in the kernel can probably be
> > > generalized in some way that makes it useful to other things (like
> > > Win4Lin) and then merged into mainline.
> >
> > We already have drivers/net/tun.c thaqt works nicely with Hercules and MoL
> > for me, but I guess the vmware folks want some additional deep magic.
>
> Unless I missed something, there can be only one userspace reader/writter
> attached to the device, while vmnet works like real network segment to
> which you can connect any number of userspace processes, and each of
> processes gets only packets which are targeted for it (as each process
> has its own MAC address). And vmnet interface does not have to have
> any representation in host's networking (it can be used just as a channel
> for communication between two VMs), which is important if your guests
> are running potentially dangerous code, like network worms.
>
> vmnet module actually provides tun-like character device, but with several
> differences:
> * You can connect any number of userspace processes to it.
> * You can connect kernel end to nothing (complete guest-host separation), or
These can be done purely in userspace - a daemon can exchange the data
between the processes (VMs).
> * You can create new network device for kernel end (you'll route between
> guests and real world) or
This can be done with tun, preferably opened by the abovementioned
daemon.
> * You can attach this character device to some existing network device,
> creating "bridge".
And this is IMO pretty ugly to do. It is probably needed to get NetBEUI
working between the VM and real network.
> Of these features tun supports only third (creating new kernel network device),
> and with help of "normal" bridge also fourth. Correct me if I'm wrong.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On 2004-06-23T20:26:13,
Vojtech Pavlik <[email protected]> said:
> > vmnet module actually provides tun-like character device, but with several
> > differences:
> > * You can connect any number of userspace processes to it.
> > * You can connect kernel end to nothing (complete guest-host separation), or
>
> These can be done purely in userspace - a daemon can exchange the data
> between the processes (VMs).
... as UML already does it, anyway. I'm pretty sure the various methods
UML uses are quite applicable to VM too.
Sincerely,
Lars Marowsky-Br?e <[email protected]>
--
High Availability & Clustering \ ever tried. ever failed. no matter.
SUSE Labs, Research and Development | try again. fail again. fail better.
SUSE LINUX AG - A Novell company \ -- Samuel Beckett