On Sat, 2005-01-29 at 19:32 +0100, Robert Millan wrote: > On Fri, Jan 28, 2005 at 10:25:20AM -0500, Albert Cahalan wrote: > > On Fri, 2005-01-28 at 00:53 +0100, Robert Millan wrote: > > > I'm attaching two patches, one with the debian-specific changes and > > > another > > > with the upstream changes. I think this addresses all your concerns about > > > my previous patch. > > > > There is simply no need to be patching minimal.c. > > This file does not normally get compiled. > > It won't work without my patch. If this file is unneeded, why not just > removing it?
It's convenient to ship everything together in one tarball. One might use minimal.c for a rescue disk or embedded system. > > As for the other change, I guess that's about right, but > > perhaps you could supply a Linux kernel version via /proc. > > Then, as you /proc becomes more capable, you just change > > the Linux version being reported. > > What do you use LINUX_VERSION for? Mostly it is for filling in /proc fields that have changed meaning over time. Usage is not all that critical I think. > The version in /proc/version is intended > to match with the implementation in the same version of Linux procfs. It's > unrelated to other kernel features. So for what linprocfs is concerned, we're > Linux 2.4, for what RT signals are concerned, we're Linux 2.0, etc. > > Even the linprocfs implementation is far from complete. I don't think we're > safe claiming anything other than 2.0 in /proc/version. Well, give it a try. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
