|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] xen-commandline document
>>> On 15.01.19 at 10:38, <andrew.cooper3@xxxxxxxxxx> wrote: > On 15/01/2019 09:23, Juergen Gross wrote: >> Recently there have been several requests to add disclaimers >> like "only applicable if CONFIG_xyz defined" to >> docs/misc/xen-command-line.pandoc. >> >> As that file will be used as source for the installed file >> /usr/share/doc/xen/html/misc/xen-command-line.html there might be >> a better alternative instead of adding such disclaimers: what if >> we put such options in #ifdef CONFIG_xyz sections and let CPP >> create a file with only those options documented which are >> applicable to the installed hypervisor? >> >> The source file used would be still available for the developer >> (who should understand the #ifdefs) while on a Xen host only the >> available options would be documented. For locations like >> >> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html >> >> we could use an "allyesconfig" for each architecture as config >> source. >> >> Thoughts? > > allyesconfig doesn't work with mutually incompatible options, where one > of them will definitely be n > > Overall, I'm fairly -1 to this idea. I don't like the idea of merging > the xen/ and docs/ builds to be able to make this happen, and while it > may be fairly simple and easy in the ARGO case, it is most definitely > not in the XSM case. > > There is a specific reason why documentation isn't written in C, and IMO > it should be kept that way. Which then, by extension, also makes it preferable for it to not talk about C identifiers (here: manifest constants). See my other reply in particular regarding the mentioning of the CONFIG_ prefixes. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |