AW: [PATCH] Fix incorrect OS reporting in uname -o
Von: Patrick 'P. J.' McDermott Gesendet: Mittwoch, 18. September 2013 05:48 On 2013-09-17 18:56, Rich Felker wrote: - strcpy(uname_info.os, GNU/Linux); + strcpy(uname_info.os, +#ifdef __GLIBC__ + GNU/ +#endif + Linux); I'd agree that most BusyBox-based systems can hardly be called GNU/Linux, even with glibc. It seems inappropriate to call a system GNU if it has little or no GNU software. But I'd call such a system BusyBox/Linux instead, since BusyBox is the userspace, regardless of the C library in my opinion. - strcpy(uname_info.os, GNU/Linux); + strcpy(uname_info.os, BusyBox/Linux); uname -o is to print the operating system. What business has the name of a shell, however many builtins that may have, in the specification of the operating system? I neither need nor want a different operating system reported by each shell I happen to use. -- Best regards, Dietmar Schindler manroland web systems GmbH -- Managing Director: Eckhard Hoerner-Marass Registered Office: Augsburg -- Trade Register: AG Augsburg -- HRB-No. 26816 -- VAT: DE281389840 Confidentiality note: This eMail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, you are hereby notified that any use or dissemination of this communication is strictly prohibited. If you have received this eMail in error, then please delete this eMail. ! Please consider your environmental responsibility before printing this eMail ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Fix incorrect OS reporting in uname -o
On Wed, Sep 18, 2013 at 12:56 AM, Rich Felker dal...@aerifal.cx wrote: See attached. What is the point of such a change? People (presumably) use uname -o to determine whether the OS is Linux, or BSD, or other Unix. On Fedora, it says GNU/Linux. I suspect many other distros have the same. My guess is, whoever parses uname -o has his code prepared to understand GNU/Linux. This may be not the case with bare Linux! This change can create someone's scripts. There should be a reason why this is useful... ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Fix incorrect OS reporting in uname -o
On Thu, Sep 19, 2013 at 04:18:59PM +0200, Denys Vlasenko wrote: On Wed, Sep 18, 2013 at 12:56 AM, Rich Felker dal...@aerifal.cx wrote: See attached. What is the point of such a change? People (presumably) use uname -o to determine whether the OS is Linux, or BSD, or other Unix. On Fedora, it says GNU/Linux. I suspect many other distros have the same. My guess is, whoever parses uname -o has his code prepared to understand GNU/Linux. This may be not the case with bare Linux! This change can create someone's scripts. Does anyone use uname -o? My understanding is that the entire reason it was added to coreutils (it's nonstandard, BTW) was political: the FSF wanted to change uname -s to print GNU/Linux, either by changing the syscall behavior in the kernel or patching up the results. Of course the kernel folks said no (or it was just assumed that they would), and distros also said no (such a change would be patched out by distros for the exact reason you mentioned -- breaking scripts), so their only option was to add a new useless option to print GNU/Linux. Please correct me if my understanding of the history is wrong. There should be a reason why this is useful... There are a number of people who do not want their systems misrepresented as being GNU systems when they're not. Often this is just political, but it may be relevant in some corporate environments that have policies against GNU software being used for (dubious) legal reasons. As for what constitutes a non-GNU Linux system, that may be hard to nail down exactly, but I think that the conditions (1) not using glibc, and (2) using Busybox instead of coreutils, are more than sufficient to be non-GNU. Even if other GNU components are installed, it's clearly not a GNU OS. Rich ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: dumpkmap/loadkmap misses handling of K_ALLOCATED and K_NOSUCHMAP
On Tue, Sep 17, 2013 at 3:09 AM, John Spencer maillist-busy...@barfooze.de wrote: using this debug patch --- a/console-tools/loadkmap.c +++ b/console-tools/loadkmap.c @@ -67,7 +67,10 @@ int loadkmap_main(int argc UNUSED_PARAM, char **argv) ke.kb_index = j; ke.kb_table = i; ke.kb_value = ibuff[j]; - ioctl(fd, KDSKBENT, ke); + if(ioctl(fd, KDSKBENT, ke)) + dprintf(2, warning: failed to set key slot %zu,%zu to %d, reason: %s\n, + i, j, ke.kb_value, strerror(errno)); + } } } one can see that loadkmap does not handle the value K_ALLOCATED == 638 correctly. when we dump and load the kmap multiple times, the number of errors increase. if we begin with loadkeys /share/keymaps/i386/qwertz/de_CH-latin1.map.gz (loadkeys from kbd-1.15.3) dumpkmap test.kmap loadkmap test.kmap warning: failed to set key slot 6,0 to 638, reason: Invalid argument dumpkmap test.kmap loadkmap test.kmap warning: failed to set key slot 6,0 to 638, reason: Invalid argument warning: failed to set key slot 9,0 to 638, reason: Invalid argument warning: failed to set key slot 10,0 to 638, reason: Invalid argument unfortunately both kernel source code and kbd source is undocumented when they deal with K_ALLOCATED and K_NOSUCHMAP, so i am uncertain on how to fix it. Maybe just a comment will do? /* * Note: table[idx:0] can contain special value * K_ALLOCATED (marks allocated tables in kernel). * dumpkmap saves the value as-is; but attempts * to load it here fail, since it isn't a valid * key value: it is K(KT_SPEC,126) == 28 + 126, * whereas last valid KT_SPEC is * K_BARENUMLOCK == K(KT_SPEC,19). * So far we just ignore these errors: */ ioctl(fd, KDSKBENT, ke); ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
