On Sun, 24 Aug 2003, Marc Aurele La France 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.
>
>Done.  I opted to use uname(2) instead.  This doesn't say anything about
>Linux's "tainted" thingie, but Mike can send a patch to include it if he,
>or anyone else, feels that strongly about it.

Yeah, my original patch used uname(), but one of the critical
pieces of information I wanted in the output was the kernel
tainting flags, so I know if someone is running X under a tainted
kernel or not.  Also, uname output lacked some of the additional
useful things the /proc/version file contains which are helpful
in troubleshooting.  I switched from uname to /proc/version to
get the extra kernel build info and whatnot.  Both of these
things however are very non-generic and the code looks like 
crap... but it worked well.  ;o)

I wasn't sure what would be best to submit upstream other than 
using uname() as you've done, and possibly having conditionalized 
Linux specific code.  That's still a bit ugly though.

Once I update my rpms to the latest codebase, I'll see if I can 
brainstorm some way of getting the best of both worlds without it 
looking like a horrible mess.  If not, it's best keeping the 
horrible mess as a vendor addition.

Just as an additional note, I've tried to keep the convention of 
using Red Hat specific patches not intended to be submitted 
upstream in the form XFree86-a.b.c-redhat-foo.patch   I made 
comments in our spec file to explain this, so people are clearer 
that these patches are not intended for upstream, but they're of 
course useable/modifyable/etc. to anyone who thinks they're 
useful, including the XFree86 project.  Just trying to keep the 
ugly stuff buried.  ;o)

Thanks Marc.

-- 
Mike A. Harris

_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Reply via email to