Re: [wli@holomorphy.com: Re: NMU: kernel]
On Mon, May 24, 2004 at 03:14:21PM +0200, Christoph Hellwig wrote:
> On Mon, May 24, 2004 at 03:01:19PM +0200, Sven Luther wrote:
> > Don't be ridicoulous. Out of tree modules should be avoided if possible,
> > not created artificially.
>
> Huh? Out of tree modules are a _lot_ easier to deal with than a kernel
> patch.
For out of tree module writers, yes, but not as debian packages. Not all
out of tree modules adapt to 2.6 gracefully, and not all provide a clean
way for building with make-kpkg and produce a clean debian package.
Just doing make modules_install as root may be easy, but it is _NOT_ the
debian way, and should be frowned upon.
Furthermore, the user need often to rebuild said modules for his own
system, which needs some infrastructure (ideally a full unpacked kernel
source, configured for the kernel flavor he uses) to be built.
> > Also, I guess even if it is of dubious quality, i guess it is of better
> > quality than some of the driver actually present in the tre, some of
> > them don't even build.
>
> There's a bunch of legacy filesystems that are indeed buggy and haven't
> been updated. I wouldn't compile those into a kernel for any
> architecture, though.
So, you can't make presence in the kernel source a guarantee for
quality. And i was not speaking only about filesystems, but also about
hardware drivers. I also remember some time when HIGHMEM was buggy on
power3, or when cpufreq was broken on non pmac powerpc.
> > > You abuse your position as powerpc kernel maintainer to get your
> > > pet patches in without proper review.
> >
> > Bah, you have to check the history of it. Before i took over the powerpc
> > packages, almost nobody used the official kernel for powerpc, all used
> > self built kernels from the -benh tree. The kernel packages only
> > supported powermacs, and totaly ignored all other subarches. This is a
> > module _I_ need on my powerpc architecture, _I_ take the responsability
> > for in case of breakage, and _I_ do the job to get the stuff packaged.
> > (Well, wiuth Jens recently, but at the start it was just me). The
> > powerpc kernel guys didn't even do proper tagging of their corresponding
> > bitkeeper tree.
>
> The statement above was in reference to the orinoco and asfs patches. I
> see it hard to arue you need them to install, and afterwards you'd be
> much better served with a kernel-patch- patckage for either patch that
> you can maintain, and people can apply on all architectures if they feel
> interested in it.
Huh ? Did i say that ? I believe it is more sure to have them tested on
one architecture it is used most, before unleashing it on every
unsuspecting architecture, most of them it was never tested on
previously.
> > And, sorry, but this is the way thing work in debian, it is the
> > maintainer who decide what should (or should not) be in the package, and
> > he is the ultimate authority on this, and now you come out of nowhere,
> > and want to give leasons on how i should do the work, sorry, but that is
> > not going to work. And upto now, i have seen no evidence whatsoever that
> > you did more than speak about this stuff anyway, so you are in a rather
> > bad place for giving leasons, ...
>
> I've made sure that about 80% changes in kernel-patch-debian are
> reviewed by the upstream maintainers and in most cases included now.
Sure, great for you, this hardly frames you as an authority of the per
arch case though.
> OTOH for people who only care for their little castle made of sand such
> work is probably not interesting at all.
You are despissing the work of the per arch maintainers again, please
scale down your attitude on this.
Sure it is interesting, but such work life in its own timeframe, and for
the stuff that is actually included in the powerpc patch, which is not
all that much, i believe either it is not ready to be pushed into the
main kernels, but still usefull for the debian powerpc, or the path to
it being included upstream is too lengthy to be worth it. As an
anecdote, i have been trying to push my pegasos 1 patches to the -benh
tree since almost a year (well, since summer last year), and altough
benh said he would look at it, he didn't find time for it, for which i
didn't blame him since i also didn't take time to push them through
other channels, and as said some of those stuff needs to be cleaned up,
but then on the other said, i have mailed the author of the via-ide
driver, asking for counsel on how to solve the hack i have there
properly, but never got anyresponse from him, so you can't said i am not
interested in getting the stuff upstream, just that if you are not _in_,
you have maybe a harder time to find the right way to push those changes
in.
And i would very much welcome counsel on how to do this properly, i was
quite disapointed to notice that even if the 2.6 kernel handled IDE
channels per channel, it didn't get the right irq for the second
channel, nor was there an obvious way of doing it.
> Besides that I have worked on kernel maintaince for a comercial
> distributor in the past, am very active upstream contributor, and have
> worked with all kinds of people (including distribution vendors,
> volunteers, hardware companies, etc..) to get their changes up to
> standards and included upstream. I certainly know what I'm talking
> about and to help the new debian kernel maintainer with that experience.
See, the new debian kernel maintainer, which means that we who have been
doing per port maitnenance are a not worth mentioning.
> > > How do you easily make sure new Architecture: all patches don't break
> > > a large per-arch patch later?
> >
> > Well, you don't, there is actually no easy way to do this, even if you
> > have a centralized design. I guess it is the responsability of the new
> > arch: all patch to make sure it doesn't conflict with the different per
> > arch patches, as it is the responsability of the per arch patch to make
> > sure it doesn't conflict with changes of the kernel-source package.
>
> Umm, no. If the per-arch patches are small and everything remotely
> possible is in the common tree it's easy to check for breakage in
> the arch patches. If not it'll randomly break and no one will care.
So, what did i say. It is the responsability of the arch maintainer to
be compatible with the centralized kernel-source package, but there is
no way we will take responsability for compatibility with any random
patch not packaged outside the kernel-source package.
> > I can assure you that the user feedback and BTS provide for almost
> > immediate notice when such a port package break, and the patch
> > maintainer fies the problem, no big issue there.
> >
> > This is how debian works, things go into unstable (or eperimental) and
> > get tested. If they break, people notice, do a bug report, and it gets
> > fixed.
> >
> > > Why does the orinoc driver do snooping on ppc and not others?
> >
> > because the main wifi card on ppc happen to be the airport card and it
> > is widely used and people need the snooping support ?
>
> define "need". Besides that there's no more ppc notebook in production
> using the linux-supported, orinoco-based airport card.
Yeah, which is why second hand ibook G3 800 are a hot item right now.
> > Because most x86
> > users use mostly proprietary drivers to achieve the same thing ?
>
> Huh? I use exactly the same orinoc drivers on ppc and x86, usually
> just upstream but when I need snooping I know where to look for the
> patches.
See. So, you could take the responsability to test the orinoco patches,
and if they also work for you, it would be easy enough to migrate them
from the popc package into the kernel-source package.
The main problem is one of flexibility and communication. It is way
easier to just put it in the powerpc patch at first, and then have it
testedi by the debian/unstable users, than to ask for its inclusion in a
centralized repository or whatever. This is also the reason the per
package maintenance debian has works better for us than let's say a BSD
like system.
And most modern wifi cards come with binary only drivers. What do you
plan to do about this ?
> > Because
> > there is no other arch which does notebook today ?
>
> x86_64, alpha? sparc? what about the various mips/arm/sh based
> handhelds?
x86_64 is x86 still, and doesn't count. And i suppose there are more
m68k notebooks out there than alpha/sparc ones. about handhelds, i am
not entirely sure these would benefit from the orinioco driver, not sure
though. But again, if there is a need, then the driver can be migrated.
Ideally i would see the patches organised as follow :
-> the official kernel source tree.
-> 'official' debian patches.
-> per arch port patches.
The two latest being maybe dvidied between official and eperimental
patches or something such. A subversion repository would make migration
of those among these different patch pools quite easy.
> > And also, this is not so much a problem than a feature. It is small
> > scale testing before full scale deployement. If it works well on ppc,
> > and some users say, hey we want this also on x86, they adapt the patch,
> > or ask the kernel maintainers to do it, and voila, it is available also
> > on x86 or even all arches (altough i doubt you will go out and snoop
> > wifi stuff with your sun workstation :).
>
> but with my tadpole sparcbook if it's pcmcia driver was supported..
Well, welcome to the world of non-mainstream users. So, build yourself a
kernel with said patch, and if it works, fill a bug report against the
kernel-source package to have it included, and another (or the same)
against the powerpc kernel package to have it removed. What is so
difficult with that ? This is the way debian works, and it has done
rather well these past 10 years.
> Also there's lots of pci-based orinoc variants sharing the base driver,
> see drivers/net/wireless/ for the details.
Same as above.
> Anyway, your counter-arguing your above statement here. only for those
> people actually using orinoco the patch has any affect, and of those
> it's unlikely one group "needs" it more than the others.
Ah, but the difference is that for one group (or one person of that
group) the "need" is enough to be transformed in action, that is
actually including the driver in the powerpc kernel patch, while for the
whole group of others it was not even worth it providing a bug report.
This is how it works in the free/open/whatever world, those who really
need something do the job, and it happens, for those who can't get
bothered, they can only hope someone else will do it.
Friendly,
Sven Luther
>
Reply to: