Re: [RFC] Drop the Coreutils Uname patch
On Tue, Apr 24, at 07:27 Matthew Burgess wrote: On Tuesday 24 April 2007 08:27, Randy McMurchy wrote: Randy McMurchy wrote these words on 04/24/07 02:11 CST: Then -1 to Matt's proposal to remove the patch. Seems dumb to remove a patch that provides a better end product. In my haste in replying I didn't think through this response, please: s/Seems dumb to/I would prefer that we didn't/ Oh, ever the diplomat Randy :-) The reasons I wanted to drop the patch were in my original RFC, the main one being that it's never going to get accepted upstream as the functionality to determine the processor type belongs in the kernel. Thinking over that again though, that's exactly the same situation faced by the Coreutils i18n patch - it provides useful functionality but in a manner that upstream won't accept. So, maybe it wasn't a very strong argument after all. Given the above, and the fact that those that responded want the patch kept, I'll just let it lie for now. How about a compromise. In fact as more I am thinking about it, it's the right thing to do. How about a note in the Coreutils page? Where, we will mention the behavior of the unpatched uname, as it get reported by Greg, and then we will simple say that the dev-team decided to apply the patch, because of the xi-psi (as we say in my neighborhood) reasons. And we will simple mention the reasons. I would go even further and maybe submitted a good report/bug to both kernel/Coreutils teams. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] Drop the Coreutils Uname patch
Matthew Burgess wrote these words on 04/20/07 16:55 CST: Given that all 3 books use different patches, it serves a purely cosmetic purpose (as far as I know), and upstream will not entertain the patch at all in its current form, I'd like to drop it. Thoughts, comments? On the computer I'm typing this message on, 'uname -a' reports this: Linux rmlscsi 2.6.14.3 #1 PREEMPT Sat Mar 25 07:47:39 CST 2006 i686 pentium3 i386 GNU/Linux What would it report without the patch? -- Randy rmlscsi: [bogomips 1003.24] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 01:50:01 up 30 min, 1 user, load average: 0.21, 0.13, 0.11 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] Drop the Coreutils Uname patch
On Tuesday April 24 2007 02:50, Randy McMurchy wrote: Matthew Burgess wrote these words on 04/20/07 16:55 CST: Given that all 3 books use different patches, it serves a purely cosmetic purpose (as far as I know), and upstream will not entertain the patch at all in its current form, I'd like to drop it. Thoughts, comments? On the computer I'm typing this message on, 'uname -a' reports this: Linux rmlscsi 2.6.14.3 #1 PREEMPT Sat Mar 25 07:47:39 CST 2006 i686 pentium3 i386 GNU/Linux What would it report without the patch? The pentium3 would become unknown. The patch sets uname -p. robert pgpAVmnoqvetk.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] Drop the Coreutils Uname patch
Robert Connolly wrote these words on 04/24/07 01:57 CST: On Tuesday April 24 2007 02:50, Randy McMurchy wrote: What would it report without the patch? The pentium3 would become unknown. The patch sets uname -p. Then -1 to Matt's proposal to remove the patch. Seems dumb to remove a patch that provides a better end product. Why would we want to remove a perfectly functional patch that provides a decent machine name instead of unknown? -- Randy rmlscsi: [bogomips 1003.24] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] Drop the Coreutils Uname patch
Randy McMurchy wrote these words on 04/24/07 02:11 CST: Then -1 to Matt's proposal to remove the patch. Seems dumb to remove a patch that provides a better end product. In my haste in replying I didn't think through this response, please: s/Seems dumb to/I would prefer that we didn't/ -- Randy rmlscsi: [bogomips 1003.24] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 02:25:00 up 1:05, 1 user, load average: 0.11, 0.44, 0.60 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] Drop the Coreutils Uname patch
Matthew Burgess wrote: Hi, http://wiki.linuxfromscratch.org/lfs/ticket/1990 proposes to have LFS use the same uname patch for Coreutils that HLFS uses. Note also that CLFS uses another version of the uname code that adds outputs for more architectures still. Given that all 3 books use different patches, it serves a purely cosmetic purpose (as far as I know), and upstream will not entertain the patch at all in its current form, I'd like to drop it. As the ticket mentions, the correct way to implement this, according to upstream, is to have the kernel make the processor type available via a syscall. Thoughts, comments? It is a cosmetic patch, but I like it. I don't see a particular advantage to having all the books use the same patch. In other words, it would be much more effort to maintain it than it's worth. Why would we want to change the LFS book to keep the patch in sync if it changed for some exotic architecture being addressed in CLFS? Looking at the ticket, it might be useful to change the patch to use position independent assembly. I think the problem with putting a syscall into the kernel is that it would be difficult to ensure that it is set properly for all architectures (e.g. Sparc or S390). Overall, I would be in favor of using the patch, but not keeping it in sync with the other *LFS books unless it affected the IA32 architectures. I am not in favor of dropping the patch completely. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] Drop the Coreutils Uname patch
On Tuesday 24 April 2007 08:27, Randy McMurchy wrote: Randy McMurchy wrote these words on 04/24/07 02:11 CST: Then -1 to Matt's proposal to remove the patch. Seems dumb to remove a patch that provides a better end product. In my haste in replying I didn't think through this response, please: s/Seems dumb to/I would prefer that we didn't/ Oh, ever the diplomat Randy :-) The reasons I wanted to drop the patch were in my original RFC, the main one being that it's never going to get accepted upstream as the functionality to determine the processor type belongs in the kernel. Thinking over that again though, that's exactly the same situation faced by the Coreutils i18n patch - it provides useful functionality but in a manner that upstream won't accept. So, maybe it wasn't a very strong argument after all. Given the above, and the fact that those that responded want the patch kept, I'll just let it lie for now. Thanks, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] Drop the Coreutils Uname patch
Robert Connolly wrote: On Tuesday April 24 2007 02:50, Randy McMurchy wrote: On the computer I'm typing this message on, 'uname -a' reports this: Linux rmlscsi 2.6.14.3 #1 PREEMPT Sat Mar 25 07:47:39 CST 2006 i686 pentium3 i386 GNU/Linux What would it report without the patch? The pentium3 would become unknown. The patch sets uname -p. You are technically incorrect. An unpatched `uname -a' simply omits the -p and -i fields when they are unknown. $ uname --help Usage: uname [OPTION]... Print certain system information. With no OPTION, same as -s. -a, --allprint all information, in the following order, except omit -p and -i if unknown: Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] Drop the Coreutils Uname patch
Greg Schafer wrote: Robert Connolly wrote: On Tuesday April 24 2007 02:50, Randy McMurchy wrote: On the computer I'm typing this message on, 'uname -a' reports this: Linux rmlscsi 2.6.14.3 #1 PREEMPT Sat Mar 25 07:47:39 CST 2006 i686 pentium3 i386 GNU/Linux What would it report without the patch? The pentium3 would become unknown. The patch sets uname -p. You are technically incorrect. An unpatched `uname -a' simply omits the -p and -i fields when they are unknown. $ uname --help Usage: uname [OPTION]... Print certain system information. With no OPTION, same as -s. -a, --allprint all information, in the following order, except omit -p and -i if unknown: That looks like a recent change to the behavior. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] Drop the Coreutils Uname patch
On Friday April 20 2007 17:55, Matthew Burgess wrote: Hi, http://wiki.linuxfromscratch.org/lfs/ticket/1990 proposes to have LFS use the same uname patch for Coreutils that HLFS uses. Note also that CLFS uses another version of the uname code that adds outputs for more architectures still. Given that all 3 books use different patches, it serves a purely cosmetic purpose (as far as I know), and upstream will not entertain the patch at all in its current form, I'd like to drop it. As the ticket mentions, the correct way to implement this, according to upstream, is to have the kernel make the processor type available via a syscall. Thoughts, comments? Regards, Matt. The Posix standard for the uname utility and the utsname structure are not identical... the standard for the uname utility allows for machine class and processor type, which are not supplied by utsname. So according to the Posix standard, the uname utility is expected to somehow detect the processor type without help from the kernel, and this is impossible to do in a portable way. The Linux kernel team can't add the processor type to utsname without violating standards. They could however add it somewhere else. robert pgpbjVWrt6Te0.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
