Hi, I should work on kernel rpm for my bachelor thesis. I plan to get dreamplug and make kernel rpm for kirkwood processors. After that i can work on other devices. Peter On 29 March 2011 21:26, <omalleys@xxxxxxx> wrote: > > Quoting Gordan Bobic <gordan@xxxxxxxxxx>: > > > omalleys@xxxxxxx wrote: > >> Quoting Gordan Bobic <gordan@xxxxxxxxxx>: > >> > >>> It'd have to be more finely grained than sub-architecture since a kernel > >>> for one target won't necessarily work on other CPU of the same > >>> sub-architecture (e.g. a Kirkwood kernel won't work on all ARMv5 > >>> processors). > >> > >> Is there a way around this? I mean like being able to make a megakernal > >> with a ton of modules that has support for every board and autodetects > >> hardware? > >> > >> When you look at the defconfigs for arm, you see about 50 of them. It > >> would be nice to have a "generic" arm, or a generic arm5 configuration > >> that would be a megakernel with all the hardware in modules or something > >> that can autodetect the board and proc. Even broken out to armv5, armv6, > >> etc would be nice. > > > > Whether the kernel is modifiable to allow for that, I don't know, but it > > certainly doesn't seem to be possible to do that with the current > > vanilla kernel. > > I -assume- it is possible, but I don't know for sure either. > It would help quite a bit even if it was just forward compatible. > > > >> If the split is not hardfp, I would seriously consider looking at > >> bootstrapping FAT binaries for optimisations between v5 and v7. Im > >> pretty sure this is how Apple did some of the optimisations for Altivec > >> for OS X which means some of this code maybe sitting in the Darwin > >> archives. > > > > I haven't tested this myself, but I seem to remember somebody here > > reporting that the typical improvement from optimizing for ARMv7 while > > sticking with softfp was in the low single figure % numbers. I'm not > > sure it justifies the effort. > > If you can slide neon optimisation in, it would make it worth it for > certain programs. > > > >> (Apple started off by using something similar to the perl script to > >> relink, with OS 10.0 it took like 20 minute to download and install an > >> update, and about 3 hours to "optimise", they ended up backgrounding the > >> process and then they switched to something else which I think is the > >> bootstrap.) > >> > >> (the 68k-> PPC fat binaries, actually was two separate binaries of the > >> program, and the bootstrap just picked which "fork" in HFS to read for > >> the binary from which you can't do on linux easily.) > > > > IMO the fat binary support should be handled on the compiler level, not > > post-processing. There's also the issue of dlls - you'd need the dynamic > > linking to be aware of it too. And you might end up having /lib5s, > > /lib5h, /lib6s, /lib6h, /lib7s, /lib7h (like we have /lib and /lib64 on > > x86/x86-64). > > Actually i don't think you can mix hard and soft so per system so that > has to be a separate release. :P > > There should be say a 3-4 char designation for the /lib > since say libhnc would be lib hard neon cuda support. > Im not sure the H is needed, but the point is more that it needs to be > standardized in an extensible format non-confusing format. > Like if there was a haploid vector processor, then you dont have a > libh for both hard-fp and libh for vector. > > > All that seems like a lot more effort than maintaining two separate > > builds, and I cannot think of a reasonable use case where it would be of > > vital importance to have binary compatibility. Why bother with binary > > compatibility when you have the source. :) > > The issue I see is ARM appears to be moving quite fast right now, and > in order to keep up, I don't think it is wise to keep releasing a new > distro for every new arch. I just don't think that is a good habit to > get into. Or else our distribution ends up to be a mess like the > Kernel is. > > By having "fat" compatibility, it gives the ability to speed up the 20 > packages that you can get significant improvement from, without having > the manpower to work out the other 1300. I am guessing the majority of > the issues with the distro, are related to the whole ARM arch and not > just a subset of the arch. > > Also, I see this as a bigger issue moving forward and especially when > you start adding vectorization optimisation to the equation and the > armv21 "lightning" processor is released. > > -- > > To sound like a hypocrite... > > I actually don't have an issue with a build of say armv7 hardfp for > F15 especially if the patches are getting pushed upstream, by the time > koji gets to F15, I assume 99% of the bugs will be fixed and it will > be merely a recompile. :P > > > > _______________________________________________ > arm mailing list > arm@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/arm -- :wq _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
