On Fri, Apr 27, 2012 at 05:46:39PM -0400, Jon Masters wrote: > Well, the kernel does expose what we want...kinda. We have a > "compatible" property in the device tree that exposes, e.g.: > > [root@hsv-panda-3-v5tel devices]# xxd /proc/device-tree/compatible > 0000000: 7469 2c6f 6d61 7034 2d70 616e 6461 0074 ti,omap4-panda.t > 0000010: 692c 6f6d 6170 3434 3330 00 i,omap4430. > > Note that this is not "omap", but it would match on "omap*" if we were > allowed to have a "mapping" at the sub-arch level rather than at the > machine specific level (which I can totally see why you dislike that - > there could be any number of new machines, but the odds of a new > sub-arch like "omap" coming or going are far less common). On Calxeda's > "highbank" system, we actually get exactly "highbank" in the compatible > string. I would suggest these options exist: Oh, excellent. That seems like a much better plan. > 1). We use the device-tree property "compatible", we adopt an interim > solution for compatibility with current systems that allows a limited > "hashmap" of sorts (but not machine specific, just "omap*", etc.), and > meanwhile have upstream add the right compatible entries to their dtb > (device tree blob - the generated version of the device tree data, which > you can think of as being a flatfile version of OpenFirmware). Are any of these provided by the firmware rather than the kernel? Changing existing entries that are potentially being consumed by userspace in some way doesn't seem ideal. Possible stretch - could the existing omap kernel package include Provides: for kernel-omap4430, for instance? Then all the naming and policy could be in one place, avoiding the case where you decide to merge or split an existing kernel binary. > 3). We introduce a more generic kernel platform determination mechanism, > and add a file somewhere (sysfs, procfs, an entry in cpuinfo) that > always describes the base platform as a string. It'd probably be nice to at least have the compatible: property available via sysfs in order to avoid parsing binary. > 4). We do something specific in Fedora kernels that impacts uname output > or similar such that we can determine the platform. Doesn't seem ideal, unless it'd get upstream traction. No real reason to create extra problems for any downstream derivatives. > 5). We have some generic utility created across ARM distros that can be > used for this (and also to determine other stuff, like virt support - > though we have some logic in our Fedora specific tools for that now). We > could also have this exposed in the kernel HWCAPs and then have a > utility that could pick it up out of the env, in addition to Anaconda. Seems to be an extra layer of indirection, since that'd need to solve the same set of problems in the first place. Just moving the complexity out of Anaconda and into another bit of userspace doesn't win us a great deal. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
