Re: dumpkmap/loadkmap misses handling of K_ALLOCATED and K_NOSUCHMAP
On Tue, Sep 17, 2013 at 3:09 AM, John Spencer 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) == 2<<8 + 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
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 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: [PATCH] Fix incorrect OS reporting in uname -o
On Wed, Sep 18, 2013 at 12:56 AM, Rich Felker 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
