Re: Bug#394971: [powerpc64] load the fan control modules
On Thu, Nov 23, 2006 at 02:29:25PM -0200, Otavio Salvador wrote:
> Sven Luther <sven.luther@wanadoo.fr> writes:
>
> >> Also, I wonder if all listed modules really need to be modprobed
> >> individually: modprobe will after all load modules that other modules
> >> depend on automatically.
> >
> > Well, this is not how things are, after investigation and discussion with
> > Benjamin Herrenschmidt, the powerpc/powermac linux kernel maintainer. The
> > current way of doing this is the best compromise for within the 2.6.18 and
> > etch timeframe.
>
> What's the plan for lenny? Is it going to change on 2.6.19 or so?
lenny is etch +1. If lenny take the same time as etch, 18 months, we could
have 2.6.24 for lenny. I hope that this would be fixed by then.
> >> I would expect that i2c-powermac and windfarm_core can safely be dropped.
> >
> > And you would expect wrong. When are you going to stop to try to second guess
> > the work and investigation i do, and try by all mean to show me as incapable ?
>
> Hold on Sven... I need to agree here with Frans. We always should try
> to reduce the amount of code and looks like there's a lot of dependent
> module being loaded by hand in your patch. If it has a reason, it's ok
> but you need to tell us about it.
Ok, fine, i guess benh will wlecome your patches.
If upstream tells me we need to work on this, but right now it is not possible
otherwise, i tend to believe him. It is also upstream work, and i don't really
have time for it, and in any case, we don't have the time for etch to get
those patches migrated upstream, which is needed accordying to the
debian/kernel team policy, and it will be available at the earliest in 2.6.20
if we submit it today.
> It's impossible to you, Frans or everyone to know about everything on
> every arch so as a D-I RM Frans did a question and I think you can
> just reply to it as I usually do and many others does too. There's no
> try to show you as incapable person.
This would be the case if :
1) he had commented on the bug during the month it had been open.
2) he had considered including the pacth last week when he did the 1.42
upload.
3) he had asked me about the breakage and we had uploaded a fixed package
instead of reverting it.
This being not the case, and he keeping me in a unfair and humiliating
position since over 6 months, i am very justified to critic him on this.
And yes, in case you didn't notice, i am angry about the way i have been
handled, and now, so many months after the fact, i am rightly angered.
> > They cannot be dropped, especially i2c-powermac cannot be dropped, since it
> > will not be pulled in by the other modules. There are numerous comments about
> > this fact on both debian-kernel and debian-powerpc, as well as numerous irc
> > conversations on debian-kernel, where you are also present.
>
> Isn't it a bug that could be solve on kernel itself?
Sure, but see above.
> > So, either you chose to get involved, and try to stay informed about the
> > different powerpc developments, or you don't, but then it is only fair to ask
> > you to trust my knowledge and competence, as well as the interaction with the
> > upstream linux/powerpc community such as Benjamin Herrenschmidt. Your current
> > attitude is quite insulting to them and me, please modify it.
>
> Please modify your action too.
Maybe, but it has been since late april, so ...
> As you know I worry about ppc status and try to be updated about
> it. I'm still lacking the need hardware to work on it but it should
> change in near future and I'll get more involviment on it as I did
> before when I had an iBook. Besides, we all do mistake and you aren't
> different.
Sure, i am different, i am the only one who is outcast and humiliated like i
am.
> We should try to review our code and patches to ensure a high quality
> on d-i and it should be done when the patches are pending to be
> commited as Frans is doing now. Please calm down and just reply for
He is only commiting and comenting on them because i did the upload on sunday,
and because i raised a fuss over the revert upload from him.
If he had come to me, and commented about the bug in question, this would be
something else, but given the way this happened, added to the humiliating
handling i am getting from frans and a few others, ...
> the questions and then I'm sure Frans will commit the patch also
> because it's really need for a proper ppc support from d-i side.
Indeed, but the patch was commited a whole month ago, and frans did an upload
of rootskel a week ago, and didn't even bother considering the patch in
question, even though i told him repeteadly that doing d-i test installation
on the XServe without it is really health damaging. I always end up with a
headache and if i work at night, i wake the kids. That is how loud it is.
> >> Finally, why was S50directfb-linux-powerpc added in the Makefile? This
> >> seems unrelated to this patch.
> >
> > It was not. Or should not have been. If it was, it is uniquely a result of a
> > bad manipulation caused by me not having the svn commit right, and you are as
> > thus solely to blame for it.
> >
> > But seriously, find attached my svn diff, there is no trace of a
> > S50directfb-linux-powerpc in my diff, if it was there, it most probably did
> > come from an older commit. I did in fact do an apt-get source of rootskel, and
> > then applied the svn diff output, so i have no idea where this
> > S50directfb-linux-powerpc file came from. I guess it came from earlier
> > experiments done while me and attilio and a few others tried to investigate
> > the g-i breakage.
>
> Yes, it was include in your patch and might be useful if you can send
> a revised patch fixing the modprobe syntax and removing this hook
> from it.
I don't know from where it comes, it is not in my local svn checkout, so ...
> >> Colin suggested that when we apply this patch in the installer, a similar
> >> patch should added in initramfs-tools to make sure that the modules are
> >> loaded too on the installed system. Has that already been coordinated?
> >
> > A similar patch for therm_pm72 is already in the installer, and i have
> > regularly been pushing maks to apply the whole stuff, but without success upto
> > now.
>
> Let me ask it here again. Doesn't the right place to fix it be the
> kernel? Is too difficult to fix it there?
It is, but this is not possible in the etch timeframe.
Friendly,
Sven Luther
Reply to: