Re: [klibc] process '/usr/bin/rsync' started with executable stack
Kees Cook dixit: >3) fix the use of trampolines in klibc AIUI done in klibc, but post-2.0.7 bye, //mirabilos -- FWIW, I'm quite impressed with mksh interactively. I thought it was much *much* more bare bones. But it turns out it beats the living hell out of ksh93 in that respect. I'd even consider it for my daily use if I hadn't wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh
Re: [PATCH] MAINTAINERS: floppy: take over maintainership
Hi Denis, I just saw this on LWN and would like to thank you for picking up floppy support as it’s important (especially for interfacing with esoteric hardware). I’m also collecting a few drives so I can use a spare if one breaks… usable discs are becoming a problem though ☹ bye, //mirabilos -- When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. -- Wouter, about my Debian/m68k revival
Re: [PATCH v15 23/26] sched: early boot clock (was Re: Bug#918036: linux: uptime after reboot wrong (kvm-clock related?))
Hi Salvatore, >p.s.: my earlier reply to you seem to have been rejected and never > reached you, hope this one does now. if you sent from Googlemail, it may reach me in the next weeks or never *shrug* they don’t play nice with greylisting. The -submitter or @d.o works, though. I’m following up from my $dayjob address as the issue occurred there (which is also Googlemail, unfortunately). >There was now a followup on this, and if you can I think it's best if >you can followup there. > >https://lore.kernel.org/lkml/ca+ck2bc70pnl0wimb0xt99j4nnfi8w3zuuhgak-jspuop9j...@mail.gmail.com/ OK, doing now: Pavel Tatashin wrote: >Could you please send the config file and qemu arguments that were >used to reproduce this problem. This is from a libvirt-managed system. The arguments as shown by “ps axwww” are: qemu-system-x86_64 -enable-kvm -name ci-busyapps -S -machine pc-1.1,accel=kvm,usb=off -m 8192 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 09536d92-dd73-8993-78fb-e0c885acf763 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/ci-busyapps.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/dev/vms/ci-busyapps,format=raw,if=none,id=drive-virtio-disk0,cache=none,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:05:6e:fd,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on I’ve attached the kernel configuration; this is a stock Debian unstable/amd64 system, just upgraded. After upgrading the guest, I merely issued a “reboot” in the guest and did not stop/start qemu. The host is Debian jessie/amd64 (Linux 3.16.0-7-amd64 / 3.16.59-1) in case that matters. Thanks, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Re: Can we drop upstream Linux x32 support?
Andy Lutomirski dixit: >x32 is not this at all. The kernel ABI part of x32 isn't ILP32. It's >IP32, 32-bit size_t, and *64-bit* long. The core kernel doesn't Yeah, I was looking at this from userspace PoV, as I said I’m not a Linux kernel programmer. In BSD we have register_t which is probably the equivalent to your __kernel_long_t? Maybe removing the “long” from the name helps. But yes, x32 is just a (second to i386) ILP32 userspace API in an amd64 kernel. This does imply mapping on the userspace (x32) to kernel (amd64) boundary and back. I would have thought full struct member mapping, as dalias described, to be the most robust. >something similar to work using the normal x86_64 syscalls. And I'm But those would require the longer structs etc. and therefore lose all the benefits of x32… bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)
Re: Can we drop upstream Linux x32 support?
Steven Newbury dixit:
>I can't help but wonder if it wouldn't make more sense to drop x86
>support from long mode than x32. AMD64 x86 support was always intended
Do you mean i386?
x86 = { i386, x32, amd64 }
No, please don’t. I use i386 as “companion architecture” to x32,
only the kernel and actually memory-hungry things (qemu) are
amd64 binaries on my system, and this works very well.
Thanks,
//mirabilos
--
18:47⎜ well channels… you see, I see everything in the
same window anyway 18:48⎜ i know, you have some kind of
telnet with automatic pong 18:48⎜ haha, yes :D
18:49⎜ though that's more tinyirc – sirc is more comfy
Re: Can we drop upstream Linux x32 support?
Andy Lutomirski dixit: >That’s the thing, though: the whole generic kernel compat >infrastructure assumes there are at most two ABIs: native and, if >enabled and relevant, compat. x32 breaks this entirely. MIPS had o32, n32, n64 since like forever. ARM has old ABI, EABI and now 64-bit. Other architectures are yet to come. >IMO the real right solution would be to push the whole problem to >userspace: get an ILP32 system working with almost or entirely LP64 Is this a reflex of Linux kernel developers? ;-) I doubt that userspace is the right place for this, remember the recent glibc vs. syscalls debate. It would also need to multiply across various libcs. >How hard would it be to have __attribute__((ilp64)), with an optional >warning if any embedded structs are not ilp64? This plus a wrapper to You mean LP64. Impossible, because LP64 vs. ILP32 is not the only difference between amd64 and x32. bye, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
Re: Can we drop upstream Linux x32 support?
Andy Lutomirski dixit:
>What happens if someone adds a struct like:
>
>struct nasty_on_x32 {
> __kernel_long_t a;
> void * __user b;
>};
>
>On x86_64, that's two 8-byte fields. On x86_32, it's two four-byte
>fields. On x32, it's an 8-byte field and a 4-byte field. Now what?
Yes, that’s indeed ugly. I understand. But don’t we already have
this problem with architectures which support multiple ABIs at the
same time? An amd64 kernel with i386 userspace comes to mind, or
the multiple MIPS ABIs.
>I'm sure we could have some magic gcc plugin or other nifty tool that
>gives us:
>
>copy_from_user(struct struct_name, kernel_ptr, user_ptr);
Something like that might be useful. Generate call stubs, which
then call the syscall implementation with the actual user-space
struct contents as arguments. Hm, that might be too generic to
be useful. Generate macros that can read from or write specific
structures to userspace?
I think something like this could solve other more general problems
as well, so it might be “nice to have anyway”. Of course it’s work,
and I’m not involved enough in Linux kernel programming to be able
to usefully help with it (doing too much elsewhere already).
>actually do this work. Instead we get ad hoc fixes for each syscall,
>along the lines of preadv64v2(), which get done when somebody notices
Yes, that’s absolutely ugly and ridiculous and all kinds of bad.
On the other hand, from my current experience, someone (Arnd?) noticed
all the currently existing baddies for x32 already and fixed them.
New syscalls are indeed an issue, but perhaps something generating
copyinout stubs could help. This might allow other architectures
that could do with a new ABI but have until now feared the overhead
as well. (IIRC, m68k could do with a new ABI that reserves a register
for TLS, but Geert would know. At the same time, time_t and off_t could
be bumped to 64 bit. Something like that. If changing sizes of types
shared between kernel and user spaces is not something feared…)
Thanks for considering,
//mirabilos
--
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)
Re: Can we drop upstream Linux x32 support?
John Paul Adrian Glaubitz dixit:
>I can't say anything about the syscall interface. However, what I do know
>is that the weird combination of a 32-bit userland with a 64-bit kernel
>interface is sometimes causing issues. For example, application code usually
Yes, but more and more ${foo}64ilp32 architectures are popping up.
>Additionally, x32 support in many applications is either rudimentary
If a signal is sent that this kind of architectures will stay, some
people might be convinced to fix that.
>It's also that the performance benefits of x32 are often eaten up by
>the fact that none of the scripted languages that I know of provide
Non-JITted languages like yours truly’s shell do benefit from it,
though. (mksh works just fine on LP64 but its internal structures
pack massively better on ILP32, for example.)
>If x32 is eventually to be removed, we should also take care of removing
>x32 support from userland code. From the top of my head, this would at least
I don’t think so. The patches also contain
– stuff to support 64-bit time_t on 32-bit architectures, e.g:
- bugfixes like printf("%lld", (long long)timet_value) instead
of assuming time_t fits into a long (also important for other
operating systems…)
- generally switching from generic types like long to specific
types like size_t, ptrdiff_t, etc.
- there was one more but after having written two eMails I forgot it
- oh and, of course, they lay the base for e.g. amd64ilp32 support
bye,
//mirabilos
--
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh
Re: Can we drop upstream Linux x32 support?
Note: please keep me in Cc because I am not subscribed. Linus Torvalds dixit: >I'm not opposed to trying to sunset the support, but let's see who complains.. I will hereby complain. I’m using Debian/x32 on my main desktop at work, and do occasionally help out with porting issues. It’s a good way to make more out of 64-bit machines without going all 64 bit; it’s also helped me find bugs in software. It’s a nice architectural idea, and a way forward for things that are constricted to 32 bits while opening up stuff like 64-bit time_t without taking up half the available CPU registers (while more than doubling the number of the available CPU registers, too). I was also considering investing a nontrivial amount of work into porting klibc to x32, since hpa does not wish to do it himself. Thankfully I have only done a bit yet. Furthermore, x32 was the first of the many *64ilp32 architectures; I know I’ve seen amd64ilp32 and at least one other I don’t recall. It will have prototyped many of the problems users of these will run in, and I’d prefer to keep it (completely selfish because I don’t wish to have to crossgrade a whole system yet again). Thanks for your consideration, //mirabilos -- When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. -- Wouter, about my Debian/m68k revival
Re: Fixing Linux getrandom() in stable
Theodore Y. Ts'o dixit: >that problems helps most of our users, and we shouldn't let the >perfect be the enemy of the good. Agreed. Start small, then enhance one bootloader at a time. Or boot protocol, I assume. >Also note that the bootloader has depend on userspace to refresh the >seed entropy, both in early boot (in case the syscrashes), and at >shutdown (so the entropy captured while the system is running can be Definitely! >saved as seed entropy). And this is trickier in Linux because the >bootloader lives in a different source tree, and is maintained by >different people from the systemd and/or initscripts people, and for Yes, unfortunately. >that matter the bootloader doesn't know which distribution it is But in this case, the distribution can tell the bootloader the path to the file to load. >the *BSD's has its advantages. And this is where perhaps Debian as a >distribution can solve this problem by coordinating action across >multiple Debian packages.) Of course. >The *point* is that we can't really make a turn-key solution which >will work for everyone. For as much we have the desire for a >"Universal OS", something that works for all hardware, all users, and >all workloads, is probably just not attainable here. As Debian, we can try to come close, but, as you said, don’t let the perfect be the enemy of the good. Perhaps there are multiple somethings that, together (or having the local admin choose) can help more people than one simple solution, even if the latter may help a majority. (I’m a fan of minorities, in case you couldn’t tell. I run an x32 system, after all, and helped out m68k a bit…) >(It never was a complete solution, BTW; even before the patches to >address CVE-2018-1108, there were already hardware systems where you >couldn't count on the RNG being initialized in time and getrandom(2) Another question is what it means that the RNG is initialised. It all depends on what in the end boils down to guesswork, although I tip my hat because that RNG code of yours, both the Linux and the BSD version, are pretty impressive. But the point here is that, even if the RNG thinks it’s fully initialised, it may not be “good” yet, depending on circumstances. (Again, it should not stop us from trying.) bye, //mirabilos -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
Re: Fixing Linux getrandom() in stable
Adrian Bunk dixit: >As an example, what happens if I debootstrap and deploy the resulting >filesytem to a large number of identical embedded systems without >entropy sources? Just get into a habit of not doing so, for example by modifying the image during each writing process. Having the bootloader inject entropy into the kernel would of course help (something OpenBSD actually did, which I’d dreamt of only until). Reuse is only problematic then if the system actually booted, i.e. an early userspace thing reading and immediately writing to a file will stave off the remaining issues. >As far as I can see, any solution above would either give me boot hangs >or might result in nasty security issues due to the same (known) entropy >being fed to /dev/random on many machines. > >Similar problems for cases like live CDs and installers. And CPUs, and architectures, without usable boot entropy. For the “CD image” case, though, adding stuff like the MAC addresses of the onboard NICs and the current time would at least shuffle the existing (albeit known) entropy around enough for it to begin to differ. A web service for getting random bits sounds like an idea, until you get to the privacy implications of that (as well as reliability). But if it’s inhouse, it’s doable. >I wonder whether the current issue is just the tip of the iceberg, >and usage of /dev/urandom is a gazillion CVEs waiting to be reported. Did you see the fallback code for Linux in OpenBSD’s code for libbsd? It’s… like trying to find randomly-looking things on an 1990s Unix. This is best fixed in the kernel and earlier, plus an extra read/write in early userspace. Of course, embedding some entropy into the kernel image itself will make the reproducible-builds people entirely unhappy… (this one *is* implemented in MirBSD, complete with a tool to update it). >Due to the gdm bugs mentioned above we know that there are real-life >situations where gdm currently uses "random" data that might be >predictable. The question is which uses actually need entropy estimated good enough? >>b. Tolerate a longer wait for getrandom() to return > >I suspect there might be no guaranteed upper bound for the waiting time. On a discless system with no hardware sources (possibly no network) and no keyboard interaction? Infinite. Of course, if early userspace could reliably update a file, then the file’s content could be estimated as good enough and be credited to the RNG, at least for non-identical/readonly-/shared-media systems. >never block but might return predictable data in some cases. “What level of predictability?” >It would then be up to the application to decide whether predictable >data is acceptable, and what to do in entropy-starved situations. I guess most application authors have no answer for you here. It’s also no solution for the arc4random API… seems like a cultural clash (BSD expectations vs. what Linux can actually deliver). bye, //mirabilos -- “Having a smoking section in a restaurant is like having a peeing section in a swimming pool.” -- Edward Burr
Re: [Y2038] [klibc] kernel/libc uapi changes for y2038
fup2p, this is offtopic for most lists Arnd Bergmann dixit: >It's hard because we don't even know what ioctls are affected at this point, >and I was hoping to get this part merged as a stepping stone in the process >of finding out. Oh okay. >e) ioctls that pass a time value as a 'long' or '__u32' instead of > 'time_t'. Fixing them requires adding new ioctl commands to let > them work beyond 2038, independent of what we do here. Yeah, that’s going to be fun. >MIPS on the other hand is no more broken than any of the other 32-bit >ABIs, because it does not use 64-bit __kernel_long_t in its n32 ABI. I have heard from a MIPS porter that one of the flavours suffers from similar problems as x32, just not to that extent. But I don’t recall my source… >ioctls. My plan at this point is to eliminate all uses of time_t in >the kernel and replace them with time64_t or other safe types. >This way, we will eventually find all code that passes 32-bit time types >to user space and can fix it. This will take care of the time_t >related problems on x32 as well. Ah, interesting approach. And existing userspace, as well as new userspace that does not declare 64-bit time_t readiness, is still safe on currently-not-broken architectures? So, there’s enough time to fix this before the various libcs turn that on (and it had better be fixed by then, because it becomes ABI by then). Nice idea. I am wondering a bit about the ioctls being hard to find. I have not much experience with kernel programming, and even less with Linux than with MS-DOS and BSD, but should not each driver have a central ioctl entry point, from which it should cast the user space data into a (possibly locally declared) structure? bye, //mirabilos -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too… may I quote you on that? sure, tho i doubt anyone will listen ;) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [klibc] kernel/libc uapi changes for y2038
Arnd Bergmann dixit: >In the patch series I posted recently [1], I introduce new system calls to deal >with modified data structures, but left the question open on how these should >be best accessed from libc. The patches introduce a new __kernel_time64_t type Can we please have ioctls fixed for mixed 32/64-bit systems such as MIPS (o32/n32/n64) and x86 (i386/x32/amd64) first, before even more such chance for breakage is introduced? I still need to use an amd64 chroot on my x32 system to do things such as set up iptables, because those ioctls break, because they contain data structures that contain, well, time types. Your proposal has a nōn-zero chance to bring these issues to i386 (and other architectures). Thanks, //mirabilos -- you introduced a merge commit│ % g rebase -i HEAD^^ sorry, no idea and rebasing just fscked │ Segmentation should have cloned into a clean repo │ fault (core dumped) if I rebase that now, it's really ugh │ wuahh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mount tmpfs-as-rootfs (initramfs) with -o nr_blocks=0,nr_inodes=0
I would have preferred to write this patch to be able to pass
rootflags=nr_blocks=0,nr_inodes=0 on the kernel command line,
and then hand these rootflags over to the initramfs (tmpfs)
mount in the same way the kernel hands them over to the block
device rootfs mount. But at least the Debian/m68k initrd also
parses $rootflags from the environment and adds it to the call
to the user-space mount for the eventual root device, which
would make the kernel command line rootflags option be used in
both places (tmpfs and e.g. ext4) which is guaranteed to error
out in at least one of them.
This change is intended to aid people in a setup where the
initrd is the final root filesystem, i.e. not mounted over.
This is especially useful in automated tests running on qemu
for boards with constrained memory (e.g. 64 MiB on sh4).
Considering that the initramfs is normally emptied out then
overmounted, this change is probably safe for setups where
initramfs just hosts early userspace, too, since the tmpfs
backing it is not accessible any more later on, AFAICT.
Signed-off-by: Thorsten Glaser
---
init/do_mounts.c | 4
1 file changed, 4 insertions(+)
diff --git a/init/do_mounts.c b/init/do_mounts.c
index 82f2288..55a4cfe 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -594,6 +594,7 @@ out:
}
static bool is_tmpfs;
+static char tmpfs_rootflags[] = "nr_blocks=0,nr_inodes=0";
static struct dentry *rootfs_mount(struct file_system_type *fs_type,
int flags, const char *dev_name, void *data)
{
@@ -606,6 +607,9 @@ static struct dentry *rootfs_mount(struct file_system_type
*fs_type,
if (IS_ENABLED(CONFIG_TMPFS) && is_tmpfs)
fill = shmem_fill_super;
+ if (is_tmpfs)
+ data = tmpfs_rootflags;
+
return mount_nodev(fs_type, flags, data, fill);
}
--
2.0.0.rc0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH,RFC] random: collect cpu randomness
Theodore Ts'o dixit: >I really like Jvrn's tests doing repeated boot testing and observing >on a SMP system, the slab allocation pattern is quite deterministic. >So even though the numbers might *look* random, an attacker with deep >knowledge of how the kernel was compiled and what memory allocations For this reason, we pre-initialise (one of) the RNG during kernel compile time, using host randomness, in MirBSD. We’re also considering pushing some additional seed using the bootloader, that can be mixed in very very early. As an added benefit, everything in the kernel can call arc4random(), arc4random_buf() and arc4random_uniform() without worrying about initialisation, at all times. (This is mostly for the places where it replaced random(), or which explicitly waited for the regular RNG initialisation to be done, or which reseeded after that.) In GNU/Linux, this could work like, GRUB will offer the contents of /boot/grub/randseed.bin to the Linux kernel, which will add it into the pool using the normal mechanisms, and (very?) early userspace will then recreate that file (to prevent seed reuse, just like the normal /var/db/host.random or /var/lib/urandom/random-seed processing is done). Downside: write access to the boot medium needed. (No GRUB modification needed, this could be passed as “faux kernel module”.) Upside: this is way earlier than anything user space can do, and e.g. early enough to affect things like kernel memory management. bye, //mirabilos -- Ach, mach doch was du willst, du hast doch eh immer Recht! jupp ~/.etc/sig……… unfaßbar… Mit Eszett sogar, unfaßbar!
Re: [PATCH] Use __unused0 instead of __unused for user visible struct member names
Sam Ravnborg dixit: >> Guillem Jover wrote: >> > On BSD systems __unused has traditionally been defined to mean the >> > equivalent of gcc's __attribute__((__unused__)), some parts of the […] >^__ is reserved for libc internal stuff and there is no reason to >name the unused/padding members "__unused". Considering that glibc has seen the light¹ now too, can we please do something about these now? The BSD tools (not just NetBSD®) have been using this for far longer after all… Currently (git pull --ff torvalds master), we have: • 2 occurrences of files *inside* the Linux kernel defining __unused to² __attribute__((unused)) themselves • 68 struct members and function arguments called __unused >So one or a set of patches that rename them all to something more >sensible would be fine. I think __unused0 is okay as it matches current __unused[0-9] in use by other parts of the Linux kernel – although glibc now uses __glibc_reserved[0-9], I think this doesn’t look like the Linux kernel should use it ☻☺ ① http://thread.gmane.org/gmane.comp.lib.glibc.alpha/36439 ② I’ve recently come to the belief that this should be __attribute__((__unused__)) in all cases, i.e. all those attribute namings need double underscores before and after, as some software likes to #define printf to something else, lighttpd does #define bounded something else, so there’s probably software out there containing #define unused foo. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] /dev/random: Insufficient of entropy on many architectures
Stephan Mueller chronox.de> writes: > And here the RNG theory breaks: a whitening function (crypto function) > like the used SHA1 does not add entropy. Thus, the SHA1 just spreads out > the entropy evenly over the output buffer. As entropy can be considered That’s why you also use a (faster, less powerful) mixing function on input. I was wondering: why not use Jenkins’ one-at-a-time hash there? I’ve worked with it a bit, and it has good avalanche behaviour; I didn’t measure any cycles though. Basically, h be an uint32_t register (usually loaded from a memory location and stored to one afterwards), then you do: (h) += (uint8_t)(b); #ifdef with_mirabilos_changes ++(h); #endif (h) += (h) << 10; (h) ^= (h) >> 6; I’m adding 1 after the first step (adding the byte) in order to make even NUL bytes make up a difference. I’m toying with code that has 32 such uint32_t values, making for a total of 128 Bytes of state, and when asked to add some memory content into that pool, just distribute the bytes over the values array, incrementing a counter. (One could probably do something with cmpxchg to make that lockless, but I’m not doing any parallel programming myself.) Then, every once in a while, you’d run the finish function on every value, which is: #ifdef with_mirabilos_changes (h) += (h) << 10; (h) ^= (h) >> 6; #endif (h) += (h) << 3; (h) ^= (h) >> 11; (h) += (h) << 15; My change here is because Jenkins’ OAAT has good avalanche except for the last input byte, so I just fake adding NUL (which doesn’t get avalanched so well, but doesn’t matter) to get the last actual data byte avalanched. Then I write those finialised hash values back to the 128-Byte-buffer then I add that into the main pool using a cryptographic (hash, or stream cipher rekey) function. (In my case, arc4random, if someone wonders.) > >It doesn't matter if you collect predictable data - it neither helps > > Oh yes, it hurts, if you update the entropy estimator on those > predictable bits. Because then you get a deterministic RNG like I’ve seen Theodore apply exponential backoff to any estimation, which is probably a good thing. But yes, you probably will want to guess the entropy of the bytes added and not count things where you’re not too sure of. (In the interrupt case, we have jiffies, cycles and num, so we’d probably best estimate how often interrupts are called, base a number of “timing” bits on that, and account for num; this may very well be less than 8 bit “credited” for a long and two u_int added to the pool, but as long as you get that right and don’t blindly credit a byte as 8 bit, you’re safe. To quote the author of RANDOM.SYS for DOS: “Every bit counts.” It adds uncertainty to the pool, at least by stirring around the already-existing entropy without adding any new (creditable) entropy.) bye, //mirabilos -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] /dev/random: Insufficient of entropy on many architectures
Stephan Mueller chronox.de> writes: > A monotonic counter is fully ok. Note, for /dev/random, the occurrence > of events delivers entropy. Thus, we have to be able to precisely > measure that occurrence. The timer itself does not need to deliver any > entropy as long as it is fast. Rather the other way round… the get_cycles() value is XORd with jiffies in drivers/char/random.c in one instance, and used alongside it in the other, so it should NOT be derived from jiffies or the clocksource. I think the focus on it being high-frequence enough to return a different result every call is also too strict: better have a 16-bit 700 kHz counter than none at all (plus, chances are very good it’s increased between calls for drivers/char/random.c at least). Geert’s question was probably about the requirement to be monotonic… other callers do do things like & 0xFF but the random code doesn’t, so something like use the 16 bit of the fast counter and fill the slower counter into the upper bits would work… but this is a trade-off against interrupt speed. I can’t judge whether it’s better to only use the fast 16-bit counter, considering bus speeds and interrupt counts. We do have jiffies too and use get_cycles() only to introduce more uncertainty, so it may very well be enough… [OT] Oh and for all who have not yet read e.g. Fefe today: http://people.umass.edu/gbecker/BeckerChes13.pdf Basically, RDRAND must not be used except to mix it into the pool, now confirmed. (Kudos to Theodore and Matt for always insisting on this.) bye, //mirabilos -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] m68k: Add infrastructure for machine-specific get_cycles()
Geert Uytterhoeven dixit: >Currently get_cycles() always returns zero. As get_cycles() is called to >add entropy to the random number generator pool, security can be increased You rock for having something before MIPS ;-) (Note that other architectures like CRIS are also affected… just, MIPS probably has the broadest impact… even I have a FreeWRT WLAN AP.) Sorry I can’t provide any feedback because I’m out of my depth on both the hardware and the requirements aspect. bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in "Notes on Programming in C" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Get rid of SUBARCH
On Wed, 21 Aug 2013, Richard Weinberger wrote: > The series touches also m68k, sh, mips and unicore32. > These architectures magically select a cross compiler if ARCH != SUBARCH. > Do really need that behavior? Not precisely that, but it’s very common in m68k land to just cross-build kernels with $ make ARCH=m68k menuconfig $ make ARCH=m68k Maybe a generalising of that feature, and making it independent of SUBARCH (which can then die)? bye, //mirabilos -- [16:04:33] bkix: "veni vidi violini" [16:04:45] bkix: "ich kam, sah und vergeigte"... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: btrfs zero divide
tl;dr: we got the faulty code pinned down, it's m68k specific,
except the m68k specific part didn’t change from 3.2…
Joe Perches dixit:
>Something like this maybe. (uncompiled/untested)
I tried this:
--- div64.h.orig2013-08-08 19:34:32.663540965 +
+++ - 2013-08-08 19:47:30.309776791 +
@@ -6,6 +6,8 @@
#else
#include
+#include
+#include
/* n = n / base; return rem; */
@@ -16,6 +18,11 @@
} __n; \
unsigned long __rem, __upper; \
\
+if (base == 0) { \
+WARN(1, "Attempted division by 0\n"); \
+dump_stack(); \
+__rem = 0; \
+} else { \
__n.n64 = (n); \
if ((__upper = __n.n32[0])) { \
asm ("divul.l %2,%1:%0" \
@@ -26,6 +33,7 @@
: "=d" (__n.n32[1]), "=d" (__rem) \
: "d" (base), "1" (__upper), "0" (__n.n32[1])); \
(n) = __n.n64; \
+} \
__rem; \
})
It didn’t trigger, apparently:
[817508.37] bio: create slab at 1
[817508.51] Btrfs loaded
[817524.11] loop: module loaded
[817534.86] device fsid 01cfa645-5cde-4e4c-9b0b-df7b37bdc495 devid 1
transid 4 /dev/loop0
[817534.86] btrfs: disk space caching is enabled
[817534.86] *** ZERO DIVIDE *** FORMAT=2
[817534.86] Current process id is 32312
[817534.86] BAD KERNEL TRAP:
[817534.86] Modules linked in: loop btrfs lzo_compress zlib_deflate
raid6_pq crc32c libcrc32c xor ipv6 evdev mac_hid ext3 mbcache jbd [last
unloaded: btrfs]
[817534.86] PC: [<31c46612>] __btrfs_map_block+0x134/0x147a [btrfs]
[817534.86] SR: 2000 SP: 0249fab0 a2: 3010f660
[817534.86] d0: d1: 00022000d2: d3:
[817534.86] d4: 0001d5: 0001a0: 021777a4a1: 021777a4
[817534.86] Process mount (pid: 32312, task=3010f660)
[817534.86] Frame format=2 instr addr=31c4660e
[817534.86] Stack from 0249fae8:
0020 1000 00022000 0766a928 07621800
00415d84 0070 077a97c0 0070 0249fb68 0009e250 00d106c0 00011220
0070 0020 00022000 00ff 0009 1000
021777a4 0020 0249fd14 0009e26c 0020
0003 0009dd8a 3007c02c 0766a928 00415d84 1000
0110 31c417ae 0766a928 00415d84 1000
[817534.86] Call Trace: [<1000>] kernel_pg_dir+0x0/0x1000
[817534.86] [<00022000>] _060_fpsp_effadd+0xb2c0/0xd518
[817534.86] [<0009e250>] bvec_alloc+0xa2/0xbe
[817534.86] [<00011220>] sasin+0x87c/0x944
[817534.86] [<00022000>] _060_fpsp_effadd+0xb2c0/0xd518
[817534.86] [<1000>] kernel_pg_dir+0x0/0x1000
[817534.86] [<0009e26c>] bio_alloc_bioset+0x0/0x12e
[817534.86] [<0009dd8a>] bio_add_page+0x4a/0x58
[817534.86] [<1000>] kernel_pg_dir+0x0/0x1000
[817534.86] [<31c417ae>] submit_extent_page.isra.44+0x170/0x1bc [btrfs]
[817534.86] [<1000>] kernel_pg_dir+0x0/0x1000
[817534.86] [<1000>] kernel_pg_dir+0x0/0x1000
[817534.86] [<31c4cbfe>] btrfs_map_bio+0x60/0x48c [btrfs]
[817534.86] [<00022000>] _060_fpsp_effadd+0xb2c0/0xd518
[817534.86] [<00022000>] _060_fpsp_effadd+0xb2c0/0xd518
[817534.86] [<31c24bb2>] btree_submit_bio_hook+0x0/0xae [btrfs]
[817534.86] [<31c41ae4>] end_bio_extent_readpage+0x0/0x69c [btrfs]
[817534.86] [<1000>] kernel_pg_dir+0x0/0x1000
[817534.86] [<31c24984>] btrfs_bio_wq_end_io+0x16/0x50 [btrfs]
[817534.86] [<31c24c0e>] btree_submit_bio_hook+0x5c/0xae [btrfs]
[817534.87] [<00022000>] _060_fpsp_effadd+0xb2c0/0xd518
[817534.87] [<31c3ed7a>] submit_one_bio+0x7c/0xb2 [btrfs]
[817534.87] [<00022000>] _060_fpsp_effadd+0xb2c0/0xd518
[817534.87] [<31c421b8>] __extent_read_full_page+0x0/0x70a [btrfs]
[817534.87] [<00058828>] unlock_page+0x0/0x26
[817534.87] [<31c44780>] read_extent_buffer_pages+0x1a8/0x218 [btrfs]
[817534.88] [<31c4c3b2>] btrfs_num_copies+0x0/0x142 [btrfs]
[817534.88] [<31c23aa6>]
btree_read_extent_buffer_pages.constprop.52+0x42/0xca [btrfs]
[817534.88] [<31c22802>] btree_get_extent+0x0/0x102 [btrfs]
[817534.88] [<00022000>] _060_fpsp_effadd+0xb2c0/0xd518
[817534.88] [<1000>] kernel_pg_dir+0x0/0x1000
[817534.88] [<31c2525e>] read_tree_block+0x38/0x48 [btrfs]
[817534.88] [<31c25226>] read_tree_block+0x0/0x48 [btrfs]
[817534.89] [<31c26d40>] open_ctree+0xe80/0x15e6 [btrfs]
[817534.89] [<00022000>] _060_fpsp_effadd+0xb2c0/0xd518
[817534.89] [<1000>] kernel_pg_dir+0x0/0x1000
[817534.89] [<1000>] kernel_pg_dir+0x0/0x1000
[8175
Re: btrfs zero divide
Josef Bacik dixit: >So stripe_len shouldn't be 0, if it is you have bigger problems :). ☺ >Is this a corrupt fs or something? If there was some sort of I don’t think so, I can access and use that filesystem under 3.2 just fine (it’s what I created it under, too, so it’s possible that it’s indeed corrupt and Linux 3.2 is just the same corrupt to happen to make it work, e.g. wrong endianness used for stripe_len which makes the upper 32 bit of that 64-bit value (usually 0) become the lower 32 bit, or something like that). I have access to that system, and it’s currently running as a Debian/m68k buildd using said filesystem, but I can run commands you tell me to diagnose/analyse it if it won’t get corrupted by those. Joe Perches dixit: >Maybe use a temporary check in do_div Mh. If nobody finds anything I’ll try that. (Doing things like compiling a kernel and testing it takes about two days timeboxed and some hours of active human effort, though, so I’d like to avoid guessing. Plus it’ll disrupt running the Debian buildd…) On second thoughts, this sort of check sounds like a good idea to add to that file in general, depending on some debugging CPPFLAG or Kconfig option. But I’m not the authority on that. bye, //mirabilos -- you introduced a merge commit│ % g rebase -i HEAD^^ sorry, no idea and rebasing just fscked │ Segmentation should have cloned into a clean repo │ fault (core dumped) if I rebase that now, it's really ugh │ wuahh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: btrfs zero divide
Josef Bacik dixit:
>Can you gdb btrfs.ko and do
>
>list *(__btrfs_map_block+0x11c)
Not easily (the kernel image is from a .deb package),
and even in a compile tree gdb just says:
No symbol table is loaded. Use the "file" command.
With a bit of cheating and a cross-compiler, this is:
(gdb) list *0x106e
0x106e is in __btrfs_map_block
(/var/lib/gforge/chroot/home/users/tg/Xl/linux-3.10.1/fs/btrfs/volumes.c:4447).
4442stripe_nr = offset;
4443/*
* stripe_nr counts the total number of stripes we have to
stride
4445 * to get to this block
4446 */
4447do_div(stripe_nr, stripe_len);
4448
4449stripe_offset = stripe_nr * stripe_len;
4450BUG_ON(offset < stripe_offset);
4451
The code is somewhat matching:
0x1062 <+268>: movel %fp@(-140),%d1
0x1066 <+272>: movel %fp@(-164),%d5
0x106a <+276>: movel %fp@(-160),%d6
0x106e <+280>: divul %d5,%d2,%d1
0x1072 <+284>: movel %d0,%fp@(-156)
0x1076 <+288>: movel %d1,%fp@(-152)
0x107a <+292>: movel %d5,%d1
0x107c <+294>: mulsl %fp@(-152),%d1
0x1082 <+300>: mulsl %d4,%d0
0x1086 <+304>: moveal %d1,%a0
0x1088 <+306>: addal %d0,%a0
0x108a <+308>: movel %d6,%d1
0x108c <+310>: mulul %fp@(-152),%d0,%d1
According to the registers…
[ 38.80] d0: d1: 1000d2: d3:
[ 38.83] d4: 0001d5: a0: 3085c72ca1: 3085c72c
… this is (if I parse this right) 1000 /
(64-bit D2:D1 divided by 32-bit D5 store into D1, remainder into D2).
Joe Perches dixit quod…
> do_div seems a likely suspect...
I do admit I don’t understand arch/m68k/include/asm/div64.h
being not a real m68k coder, but “it works elsewhere”…
(And I loathe GCC inline asm with a passion!)
>From the code expansion, I assume (__upper = __n.n32[0]) is
always zero (as we get only one divul instruction). This looks
a bit weird because the numbers in question are all 64 bit
(stripe_nr, offset, logical).
Hm, actually… from a test program…
#include
typedef unsigned long long u64;
int main(void)
{
u64 stripe_nr;
u64 stripe_len;
stripe_nr = 1234;
stripe_len = 2;
printf("in : %llu / %llu\n", stripe_nr, stripe_len);
({ union { unsigned long n32[2]; unsigned long long n64; } __n; unsigned long
__rem, __upper; __n.n64 = (stripe_nr); if ((__upper = __n.n32[0])) { asm
("divul.l %2,%1:%0" : "=d" (__n.n32[0]), "=d" (__upper) : "d" (stripe_len), "0"
(__n.n32[0])); } asm ("divu.l %2,%1:%0" : "=d" (__n.n32[1]), "=d" (__rem) : "d"
(stripe_len), "1" (__upper), "0" (__n.n32[1])); (stripe_nr) = __n.n64; __rem;
});
printf("out: %llu R %llu\n", stripe_nr, stripe_len);
return (0);
}
… I think we get two divul instructions, just with a lot
of moves between them. Hmpf. The frame pointer would be
useful to know, to know the proper values used for these
operations…
… Aaaah okay. Some reading *(gdb.info):: later, indeed:
(gdb) info line 4446
Line 4446 of
"/var/lib/gforge/chroot/home/users/tg/Xl/linux-3.10.1/fs/btrfs/volumes.c"
is at address 0x104a <__btrfs_map_block+244> but contains no code.
(gdb) info line 4448
Line 4448 of
"/var/lib/gforge/chroot/home/users/tg/Xl/linux-3.10.1/fs/btrfs/volumes.c"
is at address 0x107a <__btrfs_map_block+292> but contains no code.
(gdb) disas /r 0x104a,0x107a
Dump of assembler code from 0x104a to 0x107a:
0x104a <__btrfs_map_block+244>: 20 02 movel %d2,%d0
0x104c <__btrfs_map_block+246>: 24 2e ff 70 movel %fp@(-144),%d2
0x1050 <__btrfs_map_block+250>: 4a 80 tstl %d0
0x1052 <__btrfs_map_block+252>: 67 0e beqs 0x1062
<__btrfs_map_block+268>
0x1054 <__btrfs_map_block+254>: 20 02 movel %d2,%d0
0x1056 <__btrfs_map_block+256>: 2c 2e ff 5c movel %fp@(-164),%d6
0x105a <__btrfs_map_block+260>: 2e 2e ff 60 movel %fp@(-160),%d7
0x105e <__btrfs_map_block+264>: 4c 46 00 02 divull %d6,%d2,%d0
0x1062 <__btrfs_map_block+268>: 22 2e ff 74 movel %fp@(-140),%d1
0x1066 <__btrfs_map_block+272>: 2a 2e ff 5c movel %fp@(-164),%d5
0x106a <__btrfs_map_block+276>: 2c 2e ff 60 movel %fp@(-160),%d6
0x106e <__btrfs_map_block+280>: 4c 45 14 02 divul %d5,%d2,%d1
0x1072 <__btrfs_map_block+284>: 2d 40 ff 64 movel %d0,%fp@(-156)
0x1076 <__btrfs_map_block+288>: 2d 41 ff 68 movel %d1,%fp@(-152)
End of assembler dump.
Now, can anyone more fluent in m68k asm make out a problem with it?
bye,
//mirabilos
--
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence. -- Coywolf Qi Hunt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Re: btrfs zero divide
Geert Uytterhoeven dixit: > 0: 222e ff74 movel %fp@(-140),%d1 > 4: 2a2e ff5c movel %fp@(-164),%d5 > 8: 2c2e ff60 movel %fp@(-160),%d6 > c: 4c45 1402 < divul %d5,%d2,%d1 > > 10: 2d40 ff64 movel %d0,%fp@(-156) > 14: 2d41 ff68 movel %d1,%fp@(-152) > 18: 2205movel %d5,%d1 > 1a: 4c2e 1800 ff68 mulsl %fp@(-152),%d1 > 20: 4c04 0800 mulsl %d4,%d0 > 24: 2041moveal %d1,%a0 > 26: d1c0addal %d0,%a0 > 28: 2206movel %d6,%d1 > 2a: 4c2e 1400 ff68 mulul %fp@(-152),%d0,%d1 This is gcc-4.8 compiled, btw… in case that’s a known issue. bye, //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] Use POSIX "$((..))" instead of bashism "$[...]"
Geert Uytterhoeven dixit: >Should these be truncated to 32-bit explicitly, or is this a bug in mksh? mksh in “mksh mode” operates specifically on 32-bit integer data types with defined wraparound and other guarantees beyond what POSIX does. There is an “lksh” binary in the mksh binary package in Debian and derivates now, which is the “legacy mode” that uses the host system’s “long” data type, as POSIX demands, and is now (mksh_46-2) used for /bin/sh. However, on mixed 32/64-bit systems, /bin/sh can have either bit size. Additionally, it is not possible, in POSIX, without invoking ISO C “Undefined Behaviour”, to find out the bitsize of the shell arithmetics. Furthermore, Linux can be cross-compiled, so when building kernels for 64-bit platforms on 32-bit systems, the arithmetics used MUST NOT overflow beyond a signed 32-bit “long”. > [1/3] h8300/boot: Use POSIX "$((..))" instead of bashism "$[...]" > [2/3] ARM: shmobile: Use POSIX "$((..))" instead of bashism "$[...]" > [3/3] sh/boot: Use POSIX "$((..))" instead of bashism "$[...]" Independent of the above, I’ve verified all three and can state that they ⓐ are no regression relative to existing behaviour ⓑ do not invoke any features not in POSIX $((…)) arithmetics ⓒ do not invoke any features not in mksh $((…)) arithmetics This means you can add my Signed-off: Thorsten Glaser However, I urge you to check whether any of these arithmetics can go beyond 32 bit. If they have even the slightest chance to do that, you MUST replace them by something different. One method could be to use bc(1): $(shell printf 'obase=16\nibase=16\n%s+%s\n' $(FOO) $(BAR) | bc) Another method could be to operate on the upper half and the lower half of the 64-bit quantities separately, assuming that calculations do not overflow (in POSIX sh, overflow is, like in ISO C, Undefined Behaviour; a C compiler is permitted to compile the source code in the shell that invokes it to run “rm -rf ~ /” instead) or carry over (e.g. if it’s known that the first half is always 0x7FFF or the last half always you can just add that as “string”). bye, //mirabilos -- FWIW, I'm quite impressed with mksh interactively. I thought it was much *much* more bare bones. But it turns out it beats the living hell out of ksh93 in that respect. I'd even consider it for my daily use if I hadn't wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: m68k: include: asm: the 3rd parameter of 'insl' and 'outsl' need '<< 2'
schmitz dixit: > No need for the #ifdef CONFIG_Q40 - Q40 is the only m68k subarch that builds > the parport_pc module (which includes parport.h), IIRC. Is that correct, > Thorsten? The header is included outside of Q40. There is no Q40 kernel in Debian (yet). So, no. bye, //mirabilos -- 17:08⎜«Vutral» früher gabs keine packenden smartphones und so 17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig 17:10⎜«Vutral» aber auch traurig; früher warst du als nerd voll am arsch 17:10⎜«Vutral» heute bist du als nerd der einzige der wirklich damit klarkommt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] update AMD powerflags comments
Dixi quod… >+ "100mhzsteps", /* 100 MHz multiplier control */ >+ "hwpstate", /* hardware P-state control */ > "", /* tsc invariant mapped to constant_tsc */ Are patches to correct the indentation style desired? I’d just put in two tabs (one after the longer texts) myself… (In case someone wonders, we were comparing server boxen at work today, and nobody seemed to know what stc was; a suggestion was “stable clock” since the box with*out* it had clock stability issues with full-virtualised guests, the other didn’t… turns out that was not it.) bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-314 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Boris Esser, Sebastian Mancke -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] update AMD powerflags comments
from http://www.flounder.com/cpuid8007amd.gif
and http://support.amd.com/us/Embedded_TechDocs/25481.pdf
Signed-off-by: Thorsten Glaser
---
arch/x86/kernel/cpu/powerflags.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/cpu/powerflags.c b/arch/x86/kernel/cpu/powerflags.c
index 7b3fe56..31f0f33 100644
--- a/arch/x86/kernel/cpu/powerflags.c
+++ b/arch/x86/kernel/cpu/powerflags.c
@@ -11,10 +11,10 @@ const char *const x86_power_flags[32] = {
"fid", /* frequency id control */
"vid", /* voltage id control */
"ttp", /* thermal trip */
- "tm",
- "stc",
- "100mhzsteps",
- "hwpstate",
+ "tm", /* hardware thermal control */
+ "stc", /* software thermal control */
+ "100mhzsteps", /* 100 MHz multiplier control */
+ "hwpstate", /* hardware P-state control */
"", /* tsc invariant mapped to constant_tsc */
"cpb", /* core performance boost */
"eff_freq_ro", /* Readonly aperf/mperf */
--
1.7.9
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] kbuild, deb-pkg: Try to determine distribution
I’d personally use -cs because I detest --gnu-long-options, but LGTM. Signed-off-by: Thorsten Glaser -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC GIT PULL] "Nuke 386-DX/SX support" changes for v3.8
H. Peter Anvin zytor.com> writes: > On 12/12/2012 10:04 AM, Linus Torvalds wrote: > > Or do people still use the 486SX? > There were a *bunch* of embedded 486 clones made, some still in > production as far as I know, and I wouldn't be surprised if some of them > lacked FPU. I guess we'll see. This one is fairly recent: Bifferboard ⇒ http://bifferos.co.uk/ bye, //mirabilos -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: make tar*-pkg considered dangerous
Henrique de Moraes Holschuh dixit:
>From: Andi Kleen
>To: linux-kernel@vger.kernel.org, linux-kbu...@vger.kernel.org
>The problem is that the tarball includes /lib/{modules,firmware},
>but on FC17 /lib is a symlink. tar when it unpacks the tarball
>replaces the symlink with the directory. So they end up
>with a /lib which only contains the new kernel files, but nothing else,
Well, this is both a bug in Fedora IMHO, and (objectively) a fault
of the users to not use “tar xzphf” for extracting.
bye,
//mirabilos
--
“It is inappropriate to require that a time represented as
seconds since the Epoch precisely represent the number of
seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: compiling with gcc 3.0
It was posted by Alan Cox where I now add my 0.02 EUR... > > I was trying to compile 2.4.5 with gcc 3.0 but there is a problem > > (conflicting type) between kernel/timer.c and include/linux/sched.h > > Apparently the problem solves with this oneline workarond: > > Yep. Its fixed in the pre-patches I believe now. There are also a pile of > warning fixes that need to be merging. I would still be very wary of relying > on a gcc 3.0.0 built kernel though Since the rwsem had been fixed my 2.4.3-ac7 (with Andrea's generic rwsem) has been rock solid, and it has been built with a binary snapshot of april 2001. We don't have any problems using it yet. I can send the .config if you want. -mirabilos -- C:\>debug -e100 EA F0 FF 00 F0 -g --->Enjoy! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
It was posted by L. K. where I now add my 0.02 EUR... > On Thu, 7 Jun 2001, Albert D. Cahalan wrote: > > Negative temperatures do not really exist. > Are you really sure about this ? I am. I made Abitur (german degree after 13yrs of school) with physics being an important course, and there can not be any temperature less than 0 K (or -273.15°C if you want). This is because temperature is nothing but the movement of pieces of materie (and even photons, ergo energy). -mirabilos -- C:\>debug -e100 EA F0 FF 00 F0 -g --->Enjoy! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC, PATCH] khttpd until-now private patch
Hello,
this is my first try to submit a patch.
I have looked through khttpd and saw some MIME types but others
haven't been there, especially I saw that one could not serve
plain binary files. So I have added some MIME types... a /proc
interface was nice, though.
Secondly I have allowed myself to update the RFC821 date-time
handling. You do not need to add the day of the week field,
and according to RFC282(1,2) UTC should be served ad +
(or - if it is not 100% secure that it really is UTC,
or if UTC is not local time, however I decided to do +).
Feel free to correct me if I am wrong, if not I would like
to see this in the stock kernel.
-mirabilos
Here is the patch:
--- linux-2.4.4-ac9/net/khttpd/main.c Mon May 14 15:16:14 2001
+++ linux/net/khttpd/main.c Mon May 14 15:58:04 2001
@@ -50,6 +50,12 @@
*
/
+/** ChangeLog:
+ 2001-05-14 Thorsten Glaser <[EMAIL PROTECTED]>
+ Add more MIME types for widely-used
+files (mostly binary)
+*/
+
static int errno;
#define __KERNEL_SYSCALLS__
@@ -371,7 +377,17 @@
AddMimeType(".deb","application/x-debian-package");
AddMimeType("lass","application/x-java");
AddMimeType(".mp3","audio/mpeg");
+ AddMimeType(".mpg","video/mpeg");
AddMimeType(".txt","text/plain");
+ AddMimeType(".asc","text/plain; charset=ISO_646.irv:1991");
+ AddMimeType(".bin","application/octet-stream");
+ AddMimeType(".com","application/octet-stream");
+ AddMimeType(".exe","application/octet-stream");
+ AddMimeType(".lzh","application/octet-stream");
+/* because not officially registered and some browser are buggy */
+ AddMimeType(".bz2","application/x-bzip2");
+ AddMimeType(".tbz","application/x-gtar");
+ AddMimeType(".cbz","application/x-cpio");
AddDynamicString("..");
AddDynamicString("cgi-bin");
--- linux-2.4.4-ac9/net/khttpd/rfc_time.c Fri Feb 9 19:29:44 2001
+++ linux/net/khttpd/rfc_time.c Mon May 14 15:55:27 2001
@@ -25,6 +25,13 @@
*
/
+/** ChangeLog:
+ 2001-05-14 Thorsten Glaser <[EMAIL PROTECTED]>
+ According to RFC821 the DayOfTheWeek doesn't need
+to be set.
+ According to RFC2822 UTC should be served as +
+*/
+
#include
#include
#include
@@ -33,9 +40,6 @@
#include "times.h"
#include "prototypes.h"
-static char *dayName[7] = {
- "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"
-};
static char *monthName[12] = {
"Jan", "Feb", "Mar", "Apr", "May", "Jun",
@@ -94,67 +98,57 @@
M=I2-1;
rest=Zulu - TimeDays[Y][M];
- WD=WeekDays[Y][M];
D=rest/86400;
rest=rest%86400;
- WD+=D;
- WD=WD%7;
H=rest/3600;
rest=rest%3600;
Min=rest/60;
- rest=rest%60;
- S=rest;
+ S=rest%60;
BuildYear:
Y+=KHTTPD_YEAROFFSET;
- /* Format: Day, 01 Mon 1999 01:01:01 GMT */
+ /* Format: 01 Mon 2001 01:01:01 + */
/*
We want to do
- sprintf( Buffer, "%s, %02i %s %04i %02i:%02i:%02i GMT",
- dayName[ WD ], D+1, monthName[ M ], Y,
+ sprintf( Buffer, "%02i %s %04i %02i:%02i:%02i +",
+ D+1, monthName[ M ], Y,
H, Min, S
);
but this is very expensive. Since the string is fixed length,
it is filled manually.
*/
- Buffer[0]=dayName[WD][0];
- Buffer[1]=dayName[WD][1];
- Buffer[2]=dayName[WD][2];
- Buffer[3]=',';
- Buffer[4]=' ';
- Buffer[5]=itoa_h[D+1];
- Buffer[6]=itoa_l[D+1];
- Buffer[7]=' ';
- Buffer[8]=monthName[M][0];
- Buffer[9]=monthName[M][1];
- Buffer[10]=monthName[M][2];
+ Buffer[0]=itoa_h[D+1];
+ Buffer[1]=itoa_l[D+1];
+ Buffer[2]=' ';
+ Buffer[3]=monthName[M][0];
+ Buffer[4]=monthName[M][1];
+ Buffer[5]=monthName[M][2];
+ Buffer[6]=' ';
+ Buffer[7]=itoa_l[Y/1000];
+ Buffer[8]=itoa_l[(Y/100)%10];
+ Buffer[9]=itoa_l[(Y/10)%10];
+ Buffer[10]=itoa_l[Y%10];
Buffer[11]=' ';
- Buffer[12]=itoa_l[Y/1000];
- Buffer[13]=itoa_l[(Y/100)%10];
- Buffer[14]=itoa_l[(Y/10)%10];
- Buffer[15]=itoa_l[Y%10];
- Bu
Question about system generation
Hello, I want to do a new "distro" (home-brew) in some weeks, when kernel 2.4 runs fine with gcc-3.0 when it's finished. I want to use libc5 because I prefer it over GNU and it's smaller. Is it possible or do I have to expect major problems? I know that I won't be able to use IPv6 etc. but that's not important. Last distro I had good experience with 2.0.38 and libc5.4.46. And, are there ANY updates to 5.4.46 (security and/or bugfix?) TIA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: generic rwsem
Thanks a lot, andrea, this patch (I only applied the rwsem one) finally fixes the rwsem compile problem with gcc-3.0-20010417. Now I can get a working kernel ;-) -mirabilos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Still cannot compile, 2.4.3-ac6
Dear Sirs, I still cannot compile with gcc-3.0 from 08.04. Yesterday I tried -ac5 (same problem reported earlier) and using egcs-2.91.66 for _only_ the peoblematic files (sys.c exec.c binfmt_elf.c and two others which I dont remember) but the kernel could not boot. Now I get: gcc -D__KERNEL__ -I/glc/build/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686-DEXPORT_SYMTAB -c signal.c gcc -D__KERNEL__ -I/glc/build/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686-DEXPORT_SYMTAB -c sys.c sys.c: In function `sys_gethostname': /glc/build/linux/include/asm/rwsem-xadd.h:153: inconsistent operand constraints in an `asm' make[2]: *** [sys.o] Error 1 make[2]: Leaving directory `/glc/build/linux/kernel' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/glc/build/linux/kernel' make: *** [_dir_kernel] Error 2 ecce:/usr/src/linux # And ver_linux reports: ecce:/usr/src/linux # sh scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux ecce.homeip.net 2.4.3-ac3 #3 Sun Apr 8 22:06:09 /etc/localtime 2001 i686 unknown Gnu C 3.0 Gnu make 3.77 binutils 2.10.0.33 util-linux 2.11a mount 2.11a modutils 2.4.5 e2fsprogs 1.19 reiserfsprogs 3.x.0j PPP2.4.1b2 Linux C Libraryx 1 root root 1248080 Apr 8 21:14 /lib/libc.so.6 Dynamic linker (ldd) 2.2 Procps 1.2.11 Net-tools 1.59 Kbd0.99 Sh-utils 1.16 Modules Loaded ecce:/usr/src/linux # LIBC6 is originally from SuSE 6.2 but I updated with the one from SuSE 7.1 manually (I think I have both here?? will recompile soon glibc-2.2.2) If any of you could help me, thanks in advance. The problem _did_ _not_ exist with same gcc-3 and 2.4.3-ac3. It doesn't vanish when I get the full patches, not the interdiffs. -mirabilos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Basic Text Mode (was: Re: Question about SysRq)
> Thought, i really love all sysrq properties of linux, so i need less often > to make hardware resets an then await and fear, what fsck will print. 101% ACK > One more property, that i'd like to have should be request key to force the > most basic text mode (say 80x25) on the console, when eg. X freezes and > i kill its session, then last gfx mode resides on the screen and see no way > to restore back the text mode - /usr/bin/reset or something alike will not > do it. But it seems to be not a good idea at all, does it ? It is a very good idea, and to implement quite easy. You just do have to diff between three types of video cards (MDA, MGA and HGC vs. CGA and AGA vs. EGA+). Then you do direct register writes. For the HGC I did it recently in a DOS proggy which switched from text to gfx and back. I had a TSR which simulated a gfx BIOS. Only problem is, I lost the source. But I could rewrite and test it on request. I even would put it under GPL for the kernel (normally this is a no-no for me), just ask me. I will write it in NASM then because I can't the AT&T syntax. For non-i386 Platforms I do not know about this topic. (IIRC the Apples didnt even have a text mode) Maybe I could look up the EGA register values somewhere. -mirabilos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: binfmt_script and ^M
- Original Message -
From: "Sean Hunter" <[EMAIL PROTECTED]>
To: "Thorsten Glaser Geuer" <[EMAIL PROTECTED]>
Sent: Thursday, 8. March 2001 13:01
Subject: Re: binfmt_script and ^M
> On Tue, Mar 06, 2001 at 09:10:26PM -, Thorsten Glaser Geuer wrote:
> > - Original Message -
> > From: "David Weinehall" <[EMAIL PROTECTED]>
> > To: "Sean Hunter" <[EMAIL PROTECTED]>; "Laramie Leavitt"
><[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> > Sent: Tuesday, 6. March 2001 15:37
> > Subject: Re: binfmt_script and ^M
> >
> >
> > > On Tue, Mar 06, 2001 at 03:12:42PM +, Sean Hunter wrote:
> > > >
> > > > I propose
> > > >
>/proc/sys/kernel/im_too_lame_to_learn_how_to_use_the_most_basic_of_unix_tools_so_i_want_the_kernel_to_be_filled_with_crap_to_disguise_my_ineptitude
> > > >
> > > > Any support?
> > >
> > >
> > > Hey, let's go even further! Let's add support in all programs for \r\n.
> >
> > That is no sarcasm, it is ridiculous. CRLF line endings are ISO-IR-6 and
> > US-ASCII standard, and even UN*X systems used them when they had printers
> > (typewriters?) as output device, and no screens. With the Virtual Terminal,
> > Virtual Console stuff times may have changed but we have so many old stuff
> > in it... I won't remove them or didn't think of, but I remember you of:
> > - lost+found
> > - using ESC (or Alt???) as META for _shell commands_ which
> >easily could be Ctrl-Left, Ctrl-Right, Ctrl-Del etc.
> > - EMACS:-((
> > - ED/EX/VI :-(
> >
>
> This is pure bullshit, so I'm not copying my response to the list. None of that
> depends on the kernel.
I did not ever say that it depends on the kernel. The kernel _has to_ depend on
_standards_ coz otherwise it wouldn't be POSIX compliant, it wouldn't obey one
of the most basic ISO standards nowadays, etc. etc.
The kernel is faulty, and it has to use &h0D as CARRIAGE RETURN, whenever this
behaviour seems expactable (stress on -able).
> If he's to lame to do:
>
> for i in `find . -type f | grep -l "#! .*perl\r"`; do
> perl -pie 's|\r||g' < $i
> done
>
> ...or...
>
> ln -snf `which perl`{,\r}
>
> ...or...
>
> change his scripts to use "perl -w", which works, and he should use anyway
>
> ...or...
>
> Run his scripts directly by doing "perl /the/path/to/broken/script" (which also
> works)
>
> ...or any of the other solutions that various people suggested
_I_ am not talking about perl coz in my eyes this is waste. But there are numerous
other programmes with problems on it, too.
> ...then why should we accept a kernel patch to fix this non-problem? This is
> just plain ludicrous.
>
>
> Sean
>
> >
> > The following does _not_ have to do with any US-ASCII or ISO_646.irv:1991
> > standards which IIRC are inherited by POSIX.
> > > And why not make all program use filenames that have an 8+3 char garbled
> > > equivalent where the last 3 are the indicators of the filetype. Oh, and
> > > let's do everything to make sure the user doesn't leave Gnome/KDE.
> > > And of course, let's add new features to all existing protocols and
> > > other standards to make them "superior" to other implementations.
> > > Oh, and of course, we must require an extra 64 MB of memory and
> > > 500 MB of diskspace for each release, and a 200MHz faster processor.
> > > And let us do all system settings through a registry.
> > >
> > > OH! Let's change the name of the operating-system to something more
> > > catchy. Hmmm. Let's see. Windows maybe...
> > >
> > >
> > >
> > > /David
> >
> > I _do_ _not_ like Windoze either, but we live in a world
> > where we have to cope with it. I am even to code windoze
> > apps in order to support linux (no comment on this)...
> >
-mirabilos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: binfmt_script and ^M
- Original Message - From: "David Weinehall" <[EMAIL PROTECTED]> To: "Sean Hunter" <[EMAIL PROTECTED]>; "Laramie Leavitt" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, 6. March 2001 15:37 Subject: Re: binfmt_script and ^M > On Tue, Mar 06, 2001 at 03:12:42PM +, Sean Hunter wrote: > > > > I propose > > >/proc/sys/kernel/im_too_lame_to_learn_how_to_use_the_most_basic_of_unix_tools_so_i_want_the_kernel_to_be_filled_with_crap_to_disguise_my_ineptitude > > > > Any support? > > > Hey, let's go even further! Let's add support in all programs for \r\n. That is no sarcasm, it is ridiculous. CRLF line endings are ISO-IR-6 and US-ASCII standard, and even UN*X systems used them when they had printers (typewriters?) as output device, and no screens. With the Virtual Terminal, Virtual Console stuff times may have changed but we have so many old stuff in it... I won't remove them or didn't think of, but I remember you of: - lost+found - using ESC (or Alt???) as META for _shell commands_ which easily could be Ctrl-Left, Ctrl-Right, Ctrl-Del etc. - EMACS:-(( - ED/EX/VI :-( The following does _not_ have to do with any US-ASCII or ISO_646.irv:1991 standards which IIRC are inherited by POSIX. > And why not make all program use filenames that have an 8+3 char garbled > equivalent where the last 3 are the indicators of the filetype. Oh, and > let's do everything to make sure the user doesn't leave Gnome/KDE. > And of course, let's add new features to all existing protocols and > other standards to make them "superior" to other implementations. > Oh, and of course, we must require an extra 64 MB of memory and > 500 MB of diskspace for each release, and a 200MHz faster processor. > And let us do all system settings through a registry. > > OH! Let's change the name of the operating-system to something more > catchy. Hmmm. Let's see. Windows maybe... > > > > /David I _do_ _not_ like Windoze either, but we live in a world where we have to cope with it. I am even to code windoze apps in order to support linux (no comment on this)... -mirabilos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: binfmt_script and ^M
- Original Message - From: "Jesse Pollard" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Richard B. Johnson" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, 5. March 2001 19:14 Subject: Re: binfmt_script and ^M > John Kodis <[EMAIL PROTECTED]>: > > On Mon, Mar 05, 2001 at 08:40:22AM -0500, Richard B. Johnson wrote: > > > > > Somebody must have missed the boat entirely. Unix does not, never > > > has, and never will end a text line with '\r'. > > > > Unix does not, never has, and never will end a text line with ' ' (a > > space character) or with \t (a tab character). Yet if I begin a shell > > script with '#!/bin/sh ' or '#!/bin/sh\t', the training white space is > > striped and /bin/sh gets exec'd. Since \r has no special significance > > to Unix, I'd expect it to be treated the same as any other whitespace > > character -- it should be striped, and /bin/sh should get exec'd. > > Actually it does have some significance - it causes a return, then the > following text overwrites the current text. Granted, this is only used > occasionally for generating bold/underline/... > > This is used in some formatters (troff) occasionally, though it tends to > use backspace now. Less supports it, but ^H is quite more oftenly used. ISO_646.irv:1991 aka ISO-IR-6 aka US-ASCII-7 _also_ defines it, and we're going to be not ASCII-compatible any longer if we aren't going to support CRLF line endings. I also oftenly have the other problem round: LF endings in files which are to be viewed under DOS. I use a 15-year-old text editor from Digital Research (yes, DOS 3.41) which still is fine under W** and DOSEMU, it looks like jstar only that I miss find and replace. IMHO those problems could be solved with programmes/kernels/libs accepting LF as line ending and CRLF (and possibly CRCRLF ...) as a synonyme for LF, but treat CR non-LF differently. I have seen this behaviour quite often in the past and am using it for myself, too (except for native assembly progs). > \r is not considered whitespace, though it should be possible to define > it that way. A line terminator is always \n. ACK > Another point, is that the "#!/bin/sh" can have options added: it can be > "#!/bin/sh -vx" and the option -vx is passed to the shell. The space is > not just "stripped". It is used as a parameter separator. As such, the > "stripping" is only because the first parameter is separated from the > command by whitespace. That's why I suggest treating CRLF (and only CR only-LF) as LF. -mirabilos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
test plz ignore
ping pong am I still on lkml? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ISO-8859-1 completeness of kernel fonts?
- Original Message - From: "H. Peter Anvin" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, February 27, 2001 7:49 PM Subject: Re: ISO-8859-1 completeness of kernel fonts? > Followup to: <01c0a0ed$1ea188d0$[EMAIL PROTECTED]> > By author:"Thorsten Glaser Geuer" <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > My second suggestion: code it as .psfu and load it by setfont, including > > the appropiate console-map. AFAIK all the kernel default fonts are cp437 > > (linux/drivers/char/cp437.uni; consolemap.*) > > > > Something that would be really good is if someone could contribute PSF > (v1 and v2) support for gfe <http://www.gnu.org/software/gfe/gfe.html> > or some other free font editor. > > -hpa I always do it by a BASIC programme under DOS (yep I know this isn't pure but I have a font editor from S-DOS aka PTS-DOS (the free version)). The SFE.COM allows me to design 8x8 8x12 8x14 8x16 fonts; the unicode table I write in the MC or VC (NC clone for DOS) editor; my BASIC pgm converts them together to PSFU. It's very easy once you read the psf docs. It's a pity that I've to mkfs the DOS partitions of my HDDs every handfull of weeks, otherwise I'd put them onto a ftp server somewhere. But I call you to try it by yourself. (perl prolly isn't that easy coz it goes to binary values, but GW-BASIC is fine) -mirabilos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ISO-8859-1 completeness of kernel fonts?
> Hello, > > The 8x16 and Sun 12x22 kernel fonts I tried seem to lack some standard > glyphs necessary to represent the entire ISO-8859-1 charmap; I am talking > about all accented capital vowels except for 'I'. > > This seems to happen in both 2.2.16 as well as in 2.2.18. > > Is this intentional? If so, why? > > How can I override this behaviour? > > Thank you. > > Cheers, > > Mack Stevenson I have converted my fonts by hand (with a GW-BASIC proggy) from bitmap to .c, though not the SUN fonts for ISO but the PC fonts for cp437. I did this because I do not like e.g. the glyph "0" in standard font and included the "Euro" sign. (I use the same for DOS and Linux now, and even Windoze recently got it as Terminal font!) My second suggestion: code it as .psfu and load it by setfont, including the appropiate console-map. AFAIK all the kernel default fonts are cp437 (linux/drivers/char/cp437.uni; consolemap.*) -mirabilos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OK to mount multiple FS in one dir?
- Original Message -
From: "Peter Samuelson" <[EMAIL PROTECTED]>
To: "Michael D. Crawford" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, 6. February 2001 00:06
Subject: Re: OK to mount multiple FS in one dir?
>
> [Michael D. Crawford]
> > I found I could mount three partitions on /mnt
>
> Yes. New feature, appeared in the 2.4.0test series, or shortly before.
>
> > and they'd all show up as mounted at /mnt in the "mount" command, but
> > if I unmounted one of them (only tried with the currently visible
> > one), then it appeared that there were no filesystems mounted there,
> > but I could continue umounting until the other two were gone.
>
> util-linux gets rather confused by this feature. They say newer
> versions fix this.
>
> > But I had the 2.10r util-linux sources on my machine and installed
> > mount and umount from it, and I find that it gets it right mostly
> > when I mount and unmount multiple things, with the exception that if
> > /dev/sda5 was mounted before /dev/sda1, then if I give the command
> > "umount /dev/sda5", sda1 is the one that gets unmounted rather than
> > sda5, so it takes the most recently mounted filesystem rather than
> > the one you specify.
>
> I think this is a kernel limitation. 'umount' takes '/dev/sda5' and
> turns it into '/mnt/test' and calls umount("/mnt/test"). The kernel
> then unmounts whatever is on "top" of /mnt/test.
>
> I don't think there's anything umount can do about this behavior.
What about userland umount checking which device is umounted and
refusing to umount it or at least issuing a printf warning?
>
> Peter
-mirabilos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
