On Tue, 12 Aug 2003, Daniel Stone wrote: >> > > This patch puts the kernel version in the banner, on Linux, and also whether >> > > or not it's tainted (providing it's a sufficiently recent kernel). Thanks >> > > to Mike Harris for this patch (slightly altered to remove RH_CUSTOM, etc). >> >> > Please do not accept this Linux-specific hack of a patch; I merged it to Debian, >> > and Mike asked me not to send it upstream. >> >> Granted, as the patch stands. However, I don't mind doing the minimal >> fixing up for inclusion, as this information would be extremely useful in >> some logs. > >Feel free to make it more generic and include it - that would definitely be cool. > >> Why the extra symbol, if I may ask, instead merely using defined(linux)? > >I don't know, I just grabbed it off Mike and did >s/RH_CUSTOM/KERNEL_VERSION_IN_BANNER/; I think RH_CUSTOM is a catch-all for Red >Hat's whacky stuff.
Yes, I wrote the patch to more or less do what I wanted it to do, but in as little time as possible. It works, however it is far from clean code. Just a very very ugly quick hack, not suitable for inclusion. I used RH_CUSTOM to indicate that it is just an ugly custom hack, as I know nobody would include code upstream with such slop in it. My intention, was to some time down the road, rewrite it in an OS and distribution neutral manner, and clean up the ugliness, then offer it for potential inclusion. I figured I'd finish off a number of other hacks first and include them in one fell swoop, once they were in clean enough shape to send upstream. In general, if you see me use RH_CUSTOM, or something else that is obvious wouldn't get accepted upstream, I've done it to indicate that the patch is just a temporary kludge/fix/hack or similar depending on what it's doing. It's intended to be an indicator to others to feel free to use/modify the bits if they like, but to not submit it upstream as-is. The novelty of the quick hack was too great to leave it out until I had time for a proper generic solution. Seeing that information in bug reports has been a tremendous God send, in particular the kernel version running, buildhost, and tainting flags. Of course you're free to tidy it up as you have, and use it as well. I see something has been commited to CVS based on my original, so I'm glad to see someone liked the idea enough to do the dirty work I never got around to doing quite yet. I've got some other patches in current rpms which change the server error messages to be more modern and contain more info. The messages are currently Red Hat centric though - again, to get what I needed done ASAP, with intention to genericize and submit upstream. Basically I've changed the messages to point to bugzilla to report bugs, and a few other similar things. ftp://people.redhat.com/mharris/testing/unstable/XFree86/4.3.0-22/sources/XFree86-4.3.0-redhat-bug-report-address-update.patch That patch in our current rpms, is distro specific, but what I'd like to do before submitting it upstream, is modify it so that the X server default build, has an XFree86 specific message for the project itself, but permits distribution specific overrides to allow various OS distros to override the bug report address and mechanism to find updates. For example, a Red Hat user would want to know both how to report a bug to Red Hat via bugzilla, and to XFree86.org via bugzilla, and they'd want to get updates via our up2date tool if possible, or via ftp from our ftpsite, or alternatively from XFree86.org site's binaries or source tarballs. Assuming the idea is considered sane and acceptable, the exact text of the XFree86.org generic strings I can write up something I think might work best for the project itself, and then submit the patch which allows distro overrides to that text to bugzilla, and David or someone can review and modify to taste and commit it if they deem it a sensible addition. It's a trivial amount of work to do, so I can probably whip out something in short order if deemed to be something useful generically in XFree86. Any feedback appreciated. -- Mike A. Harris _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
