On 04/27/2012 11:54 AM, Matthew Garrett wrote: > On Fri, Apr 27, 2012 at 10:44:08AM -0500, David A. Marlin wrote: >> Matthew Garrett wrote: >>> Well ugh. Any chance of the kernel being able to expose this >>> mapping, since presumably it already exists there in some form? >> Not that I have found. For more details, please see my response to >> David Cantrel's comments. > > I know the kernel doesn't at the moment, but we have its source code as > well... 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: 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). 2). We use the device-tree property "compatible" but we refuse to work with anything that doesn't have an up-to-date enough dtb to contain an appropriate generic entry like "highbank", "omap", etc. This assumes we'll keep our kernel names matching closely enough - e.g. our "omap" kernel is actually supporting OMAP3 and OMAP4 derived platforms. But I suspect since this is common, we can get "omap" to be used in dtb. 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. 4). We do something specific in Fedora kernels that impacts uname output or similar such that we can determine the platform. 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. Other options exist, too. These are just 5 for you to give me feedback on. Meanwhile, David has something working we can manage with while we wait for your upstream-Anaconda-acceptable suggestions. Thanks, Jon. _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
