David Woodhouse wrote: > On Wed, 2008-01-09 at 15:26 +0000, Matt Sealey wrote: >> If anyone wants to help/assist/suggest any updates to efika.forth, >> create binary tools which assist the installation of the script for >> users and for placement on Linux distro CDs etc. I would be very >> grateful, but it seems we have hit the Wall of Apathy where users >> complain for a feature but are not willing to work for it. > > We're already shipping efika.forth in Fedora rawhide, and in my updated > spins of Fedora 8. It's a pain in the arse, but it kind of works.
I already said I don't like that solution either :] efika.forth may change between Fedora 8 spins and user downloading it, meaning updated kernels in the repositories stop working or so. This is what I am hoping to stop happening by having the kernel *really just not do anything* so it is entirely the fault of efika.forth or firmware releases not happening, and not a bastardised combination of both. > It would be much better if the kernel would 'just work'. The ideal way > of achieving that is for the firmware to be fixed -- but that's been > promised for a long time now, and we just don't believe you any more. So > working round it in the kernel seems to be the next best option. I don't blame you for thinking that; announcing a firmware update was a rather ill-thought-out decision not made by anyone who works on the firmware or with firmware issues. Don't rely on a real flashable firmware update any time soon, but don't take that as a task to "fix" the Linux kernel instead. Your firmware update is and will be for the time being, that Forth script, which is easy enough to paste into a serial console into nvramrc, or run from GRUB, or run manually and edit the boot line at the bottom.. When a new firmware appears, and for all you and I know this could happen this afternoon, this patch will become obselete and needs to be removed - even Grant's version, because there is no guarantee whatsoever that Nico will call the device /builtin/mdio when the search for the device in the driver is for a compatible of "ethernet-phy" for example. By hard coding these things into Linux you are shaping firmware development and making it harder. You are fixing things in the efika.forth script which needn't be fixed - now we will need to keep the script entirely compatible with that patch, even if it's wrong. I don't like this situation because it causes me more work. The guys in Germany don't release new firmwares BECAUSE of the chop and change of Linux device tree expectations. If we released a firmware every time you have a new idea on how it should look, there would be one every month, and no other bugs would have time to be fixed due to the extensive regression testing firmware has to go through on multiple current and future board revisions with multiple current and future kernels. >> (I am invoking the Open Source Fallacy of that if the source is >> available you can patch it, I say that patching Linux is not the >> solution, but patching the firmware is. But nobody is willing to >> work on patching the firmware and keeping Linux entirely independant >> of our so-deemed "crappy" firmware) > > /me looks at http://git.infradead.org/?p=openfirmware.git > /me looks at the Efika... It would be quicker to update efika.forth with an installer (I already told you how I would do it.. the whole technical detail!) than to bring up SmartFirmware again for the Efika. I really want to shift the burden to Genesi and not onto the Linux kernel, as involving Linux patches means double the work, which will delay firmware releases, delay efika.forth updates due to extended testing with myriad different versions of patches etc. It is better if the Linux kernel is simply a known quantity, non-working without external assistance, if that be the case. It is not your fault if the Linux kernel doesn't work on stock Efikas, it's OURS. However without significant support behind fixing the firmware (Genesi is working on it and efika.forth is PART of that - a good testing bed with no flashing required!) and with patches being continually submitted to the kernel to work around supposed firmware weaknesses, it is just going to be too complicated. After all, if Linux just trashes the firmware, replaces anything it doesn't deem right, why bother releasing a new firmware ever? The patch alone states the case that you do not need us to ever fix anything, I don't think you really mean to go there. -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
