Bug#345067: [Yaird-devel] Re: Bug#345067: ide-generic on poweprc

[Sven Luther]

On Thu, Mar 09, 2006 at 12:31:58PM +0100, Jonas Smedegaard wrote:
> On Thu, 9 Mar 2006 10:55:12 +0100
> Sven Luther <sven.luther at wanadoo.fr> wrote:
> 
> > the design of both yaird and the kernel ide layer make it very hard
> > to believe such a bug existed. It could be, but would be a bug in the
> > kernel to be solved ASAP, not something to work around in the ramdisk
> > tools, and i believe the hacky workarounds, by hiding the problem,
> > where even more nefast than they helped in any way.
> 
> Why did you not help back then, forcing us ramdisk generator
> maintainers to invent ugly workarounds?

I did comment on the bug reports and discussion and mailing list. I didn't
have time to do more, but was mostly ignored about this anyway, so i couldn't
do the indepth analysis i have done now. This is my most profund regret on
this issue though.

> Why don't you fix ide-pmac to work modular now, so powerpc kernels kan
> be all modular like other architectures?

Because linuxppc upstream have hinted it is a considerable amount of work, and
nobody want to touch that code with a 10 foot pole, and i have more important
things to do both in debian and in RL. 

Why don't you do it if you think it is so important ? I didn't see you provide
any kind of code as far as i can remember anyway.

> And why don't you simply have the powerpc-kernels build ide-generic as a
> module (rather than not building it at all), to allow the all too
> concerned yaird to load it even if for the wrong reasons and known
> unnecessary for your specific hardware (Pegasos builtin VIA chipset)?

Whatever for ? It is not needed, and worse, there is no proof that it will not
just break existing hardware. Try building ide-generic and not pmac-ide on
your (power|i)book and see what happens.

Poking random x86-only registers on powermacs is nto a good idea, and see the
mention of kyle saying it may not even work on hppa, due to the bridges being
setup differently.

> > > I'll continue working on the wiki, but let's debate through email as
> > 
> > I would appreciate if you could clean the wiki, remove all my
> > ranting, and your wrong assumptions, and put my analysis to the
> > forefront.
> 
> I am uncertain as to what you consider valuable info and what you
> consider ranting, so would appreciate it if you remove your own stuff
> yourself.

The rant is the stuff i added the first time, just keep the front note, and
the analysis immediately following it, but please remove all the stuff you
wrote which has been proven to be patently wrong now.

> I do not agree with shifting the context of the wiki page from tracking
> the chain of problems/workarounds to focusing solely on the core
> (non-existing?) kernel bug, so will not participate in emphasizing your
> current analysis as being central to the page.

I can't believe that ! You prefer to keep your nonsense around, and obtusely
continue to claim there is a kernel bug while it has been proven that it is
not the case, oh well, and then people still wonder why things degenerated as
they did ...

> > You probably noticed that i modified the mention of the ide-core
> > thingy after having examined the symbols in the modules (i asked for
> > an x86 modules.dep for 2.6.8, 2.6.12 and 2.6.15, but nobody provided
> > it to me yet, maybe you can), and did so in a non-controversial way i
> > hope.
> 
> Why don't you just grab a kernel package from the archive and extract
> the files you need from there?

The dependencies are not found in the source code, but are generated at built
time.

> > you have to accept your part, and admit you have been wrong, or we
> > will not be able to be constructive on this issue if you stubornly
> > continue to try to prove you where right.
> 
> Wrong where?
> 
> I hereby (stubbornly) repeat that I strongly suspect a kernel bug exist
> to be worked around in yaird.

Ok, what is the kernel bug, what evidence do you have that this bug exist
anywhere beyond your imagination ? you even couldn't be bothered to go over
the older bug reports and mailing list archives where the issue was first
mentioned, in order to show the bug. So, you should now take your maintainers
work seriously, and do a bit of research or shut up.

> Please note that I do not say that the bug has not been fixed in most
> recent kernels - on the contrary I suspect it was fixed in 2.6.14. What

Notice that yaird became the default, and we started to get bug reports
rolling in only since 2.6.14, so how could what you say have been the case ?
2.6.13 was never uploaded, and 2.6.12 used initrd-tools.

> I say is that the bug is relevant for yaird to deal with to work
> reliably even with 2.6.8. Working with official Debian kernels is not
> the target of yaird. As an example, developers of embedded distros
> (some of which are tied to specific kernel versions due to the use of
> non-free drivers) may favor yaird for their non-Debian ramdisks.

If you think developper of embedded distros will use yaird over tools like
buildroot and co, you are severly deluded and have no idea about that milieu.

Furthermore, you are making a mountain about a imaginary bug, and are not even
able to go looking at the archives of back then and see what the real problem
was, but just bother other folk until they make the job for you out of sheer
spite. 

> > Are you ready to move that responsability to the kernel team, or a
> > common yaird team ? I would gladly help out, as it seems clear that i
> > understand how things work either in yaird or the kernel itself
> > better than you, but i don't speak perl, so we need a real perl
> > native to join the project. This could be the solution, with you
> > doing the day-to-day maintainership, me investigating the problem,
> > and someone else doing the actual perl implementation, at least at
> > first until i become familiar with perl, or Erik surfaces again ? 
> 
> I welcome help.
> 
> I strongly oppose close cooperation between the two of us, given our
> experiences working together so far.

Ok. So much for yaird then, this only leaves you giving up on yaird and
handling it to a maintainer who has a clue and is not interested in arguing
for the sake of it, or yaird being kicked out of etch because of
unmaintainedness.

> And no, I do not agree with you that your judgement is far superior to
> mine. Let's just agree to disagree on that point, shall we :-)

Well, you claim that you fail to understand yaird, you have said so repeteadly
either in erkelenz and in mail or irc these past days. I guess it is clear
that you are clueless, and don't want to take the effort to understand the
issue, relying on your upstream to fix bugs, but as your upstream went MIA,
you are lost.

by your own action and words, i believe that not only my judgement, but also
the one of most other debian developpers is far superior to yours, at least
when yaird and the kernels is concerned.

Sven Luther