Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
On Son, 2009-01-04 at 22:50 -0600, Rob Landley wrote: On Sunday 04 January 2009 18:15:30 Bernd Petrovitsch wrote: [...] ACK. A bash can IMHO be expected. Even going for `dash` is IMHO somewhat too extreme. I have yet to encounter a system that uses dash _without_ bash. (All ubuntu Hmm, should be doable with a chroot environment quite cheap and simple. variants, even jeos, install bash by default. They moved the /bin/sh symlink Yes, I know (small) embedded systems that have a bash (and not only one of busybox shells). It eases writing somewhat fast shell scripts without the need for lots of fork()s+exec()s too . Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
On Mon, 2009-01-05 at 02:23 +, Jamie Lokier wrote: Bernd Petrovitsch wrote: (I have 850 Linux boxes on my network with a bourne shell which doesn't do $((...)). I won't be building kernels on them though :-) Believe it or not, but there are folks out there who build the firmware on ARM 200 MHz NFS-mounted systems natively (and not simply cross-compile it on a 2GHz PC .). Really? My 850 Linux boxes are 166MHz ARMs and occasionally NFS-mounted. Their /bin/sh does not do $((...)), and Bash is not there at all. I assume that the NFS-mounted root filesystem is a real distribution. And on the local flash is a usual busybox based firmware. If I were installing GCC natively on them, I'd install GNU Make and a proper shell while I were at it. But I don't know if Bash works ACK. properly without fork()* - or even if GCC does :-) Perl might be hard, as shared libraries aren't supported by the toolchain which targets my ARMs* and Perl likes its loadable modules. The simplest way to go is probably to use CentOS or Debian or another ready binary distribution on ARM (or MIPS or PPC or whatever core the embedded system has) possibly on a custom build kernel (if necessary). [...] (* - No MMU on some ARMs, but I'm working on ARM FDPIC-ELF to add proper shared libs. Feel free to fund this :-) The above mentioned ARMs have a MMU. Without MMU, it would be truly insane IMHO. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
On Monday 05 January 2009 09:01:56 Jamie Lokier wrote: Bernd Petrovitsch wrote: I assume that the NFS-mounted root filesystem is a real distribution. Not unless you call uClinux (MMU-less) a real distribution, no. I want things to be orthogonal. The following should be completely separate steps: 1) Creating a cross compiler 2) building a native development environment 3) booting a native development environment (on real hardware or under and emulator) 4) natively building your target system. You should be able to mix and match. Crosstool for #1, go download fedora for arm instead of #2, qemu or real hardware is your choice for #3, and then you should be able to natively build gentoo under an ubuntu host or vice versa. (How is not currently properly documented, but I'm working on that.) My objection to build systems like buildroot or uClinux is that they bundle all this together into a big hairball. They create their own cross compiler, build their own root file system, use their own packaging system, and you have to take it all or nothing. My build system is ruthlessly orthogonal. I try not to make it depend on other bits of _itself_ more than necessary. (* - No MMU on some ARMs, but I'm working on ARM FDPIC-ELF to add proper shared libs. Feel free to fund this :-) The above mentioned ARMs have a MMU. Without MMU, it would be truly insane IMHO. We have similar cross-build issues without MMUs... I.e. that a lot of useful packages don't cross-build properly (including many which use Autoconf), and it might be easier to make a native build environment than to debug and patch all the broken-for-cross-build packages. Especially as sometimes they build, but fail at run-time in some conditions. If you can get a version of the same architecture with an mmu you can actually build natively on that. It's not ideal (it's a bit like trying to build i486 code on an i686; the fact it runs on the host is no guarantee it'll run on the target), but it's better than cross compiling. And most things have a broad enough compatible base architecture that you can mostly get away with it. But you're right it's probably insane to try. I haven't dared as I suspect GCC and/or Binutils would break too :-) Oh it does, but you can fix it. :) I'm sticking instead with oh well cross-build a few packages by hand and just don't even _try_ to use most of the handy software out there. Cross compiling doesn't scale, and it bit-rots insanely quickly. You mentioned ARM Debian. According to http://wiki.debian.org/ArmEabiPort one recommended method of bootstrapping it is building natively on an emulated ARM, because cross-building is fragile. That's what my firmware linux project does too. (I believe I was one of the first doing this back in 2006, but there are three or four others out there doing it now.) Native compiling under emulation is an idea whose time has come. Emulators on cheap x86-64 laptops today are about as powerful as high end tricked out build servers circa 2001, and Moore's Law continues to advance. More memory, more CPU (maybe via SMP but distcc can take advantage of that today and qemu will develop threading someday). You can throw engineering time at the problem (making cross compiling work) or you can throw hardware at the problem (build natively and buy fast native or emulator-hosting hardware). The balance used to be in favor of the former; not so much anymore. That said, my drive for reproducibility and orthogonality says that your native development environment must be something you can reproduce entirely from source on an arbitrary host. You can't make cross compiling go away entirely, the best you can do is limit it to bootstrapping the native environment. But I want to keep the parts I have to cross compile as small and simple as possible, and then run a native build script to get a richer environment. For the past 5+ years my definition has been an environment that can rebuild itself under itself is powerful enough, that's all I need to cross compile, and from the first time I tried this (late 2002) up until 2.6.25 that was 7 packages. That's why I responded to the addition of perl as a regression, because for my use case it was. -- Jamie Rob -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
On Sat, Jan 03, 2009 at 07:36:04PM -0600, Rob Landley wrote:
On Saturday 03 January 2009 06:28:22 Ingo Oeser wrote:
+for i in MSEC 1000 USEC 100
+do
+ NAME=$(echo $i | awk '{print $1}')
cut -d' ' -f1 does the same
+ PERIOD=$(echo $i | awk '{print $2}')
cut -d' ' -f2 does the same
From a standards perspective
http://www.opengroup.org/onlinepubs/9699919799/utilities/cut.html vs
http://www.opengroup.org/onlinepubs/9699919799/utilities/awk.html is probably
a wash, but from a simplicity perspective using the tool that _isn't_ its own
programming language is probably a win. :)
Vagaries of 'cut' aside you can limit yourself here to just shell:
set_name_period () {
NAME=$1 ; PERIOD=$2
}
for i in MSEC 1000 USEC 100
do
set_name_period $i
done
or you may skip a shell function and do 'set $i' within a loop plus
assignments of $1 and $2 to NAME and PERIOD but that overwrites original
positional parameters (which may be already not important).
Michał
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
I note that sed and printf and such are all susv3. I have an explicit test for 32 bit math in the script that cares, and this worked in Red Hat 9 circa 2003. If you are trying to do arbitary precision maths using standard posix tools just use dc. That way the standard is explicit about what you will get. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
Alan Cox wrote: I note that sed and printf and such are all susv3. I have an explicit test for 32 bit math in the script that cares, and this worked in Red Hat 9 circa 2003. If you are trying to do arbitary precision maths using standard posix tools just use dc. That way the standard is explicit about what you will get. The original patch used bc. Unfortunately, it ran into bc bugs -- on some platforms like some of akpm's older test machines it would just hang. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
On Sunday 04 January 2009 06:07:35 Alan Cox wrote: I note that sed and printf and such are all susv3. I have an explicit test for 32 bit math in the script that cares, and this worked in Red Hat 9 circa 2003. If you are trying to do arbitary precision maths using standard posix tools just use dc. That way the standard is explicit about what you will get. I looked at that, but: A) the Open Group Base Specifications (which I normally go by, since they're roughly synonymous with SUSv3 and Posix and available free on the web; they just released version 7 a week or so back) don't list dc as one of their utilities. (They mention bc, but not dc.) B) The busybox implementation of dc is crap. I got 'em to fix the bug where the output defaulted to binary instead of decimal, but the math is all done as floating point rather than arbitrary precision, and they don't implement the operator. C) The only calculation which can overflow 64 bits (the ADJ32 one) turns out not to need arbitrary precision math, just 72 bits, and if it ever uses more than 32 then bottom 32 are all zero before the divide so you can do it in three lines. Essentially, the ADJ32 calculation is (($NUMBER-1)$SHIFT)/$NUMBER. $SHIFT maxes out at 51 and the largest interesting $NUMBER is 100. (That's the pathological case of HZ=1, calculating the USEC_TO_HZ direction. A larger $HZ results in a smaller $SHIFT by the number of bits needed to store $HZ, by the way, so a $HZ of 17 would have a shift of 47. So even a HZ bigger than a million should have a small enough $SHIFT not to cause trouble here, although that's probably an _insane_ input to this script.) 1 million needs 20 bits to store, so the above calculation has to cope with an intermediate value of 9951 which takes a little over 70 bits to store, hence the potential to overflow 63 bits of signed math. But this calculation has two special properties: 1) The number you start with before the shift is divided back out at the end (more or less), so the _result_ has to be less than 1$SHIFT and thus only takes $SHIFT bits to store. With a maximum $SHIFT of 51 it has to fit in a 64 bit result with about a dozen bits to spare. 2) The bottom $SHIFT many bits are all zero before the divide. We can use these two properties to easily break the math into chunks that can't overflow by: a) Chopping off the bottom X bits and dividing what's left by $NUMBER, keeping both the dividend and the remainder. Choose any X that's big enough that this step won't overflow. (I chose X=32, leaving at most 40-ish bits here). b) Shift that dividend X bits to the left. This can't overflow because of special property 1 above. c) Shift the remainder X bits to the left. The remainder can't be larger than the $NUMBER you started with, so if X+bits($NUMBER)64 this has to fit too. With X=32 and bits=20 we again have a dozen bits to spare. d) Add the results of (b) and (c) together. Since the bottom X bits were all zero, this is equivalent to having done the full divide. (Easy enough to mask those bottom bits off and add them to the remainder before the divide if they weren't, but we didn't need to do that because we know they were zero.) So no arbitrary precision math is actually required here, and yes there's a comment in the source about this. :) Rob -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh (v2)
On Saturday 03 January 2009 20:48:21 David Vrabel wrote: Rob Landley wrote: From: Rob Landley r...@landley.net Replace kernel/timeconst.pl with kernel/timeconst.sh. The new shell script is much simpler, about 1/4 the size, and runs on Red Hat 9 from 2003. It requires a shell which can do 64 bit math, such as bash, busybox ash, or dash running on a 64 bit host. I use Ubuntu (hence dash) on 32 bit systems so I think this needs to work with dash on 32 bit hosts. I have a qemu/images directory full of various OS images for testing purposes. I just fired up my jeos 7.10 image to make sure that even the most stripped- down version of Ubuntu (just enough operating system) still installs bash by default, and it does. (It doesn't install a development toolchain, but it does install bash.) I also installed a 32 bit xubuntu 8.10 image (which took 4 hours for some reason, and which also has bash), and explicitly tested its 32-bit /bin/dash, and that did 64-bit math too. So current versions of dash do offer 64 bit math on 32 bit platforms. David Rob -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
Rob Landley wrote: C) The only calculation which can overflow 64 bits (the ADJ32 one) turns out not to need arbitrary precision math, just 72 bits, and if it ever uses more than 32 then bottom 32 are all zero before the divide so you can do it in three lines. ... for the current code (32 bits). When we get an overflow-less 64-bit implementation, this code will have to be redone, which is not true for a properly done implementation. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
Rob Landley wrote: In a private email, Bernd Petrovitsch suggested set -- $i and then using NAME=$1; PERIOD=$2. (I keep getting private email responses to these sort of threads, and then getting dismissed as the only one who cares about the issue. Less so this time around, but still...) This apparently works all the way back to the bourne shell. If you're going all the way back to the bourne shell, don't use set -- $i; use set x $i instead, and don't expect to do any arithmetic in the shell; use expr or awk for arithmetic. (Not relevant to kernel scripts, imho, since you can always assume something a bit more modern and not too stripped down). (I have 850 Linux boxes on my network with a bourne shell which doesn't do $((...)). I won't be building kernels on them though :-) -- Jamie -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
On Son, 2009-01-04 at 22:13 +, Jamie Lokier wrote: Rob Landley wrote: In a private email, Bernd Petrovitsch suggested set -- $i and then using NAME=$1; PERIOD=$2. (I keep getting private email responses to these sort of threads, and then getting dismissed as the only one who cares about the issue. Less so this time around, but still...) This apparently works all the way back to the bourne shell. If you're going all the way back to the bourne shell, don't use set Going back to a Bourne shell was neither the intention nor makes it sense IMHO. I mentioned it to point out that the `set -- ' (or `set x `) is nothing new or even a bash-ism. -- $i; use set x $i instead, and don't expect to do any arithmetic in the shell; use expr or awk for arithmetic. (Not relevant to kernel scripts, imho, since you can always assume something a bit more modern and not too stripped down). ACK. A bash can IMHO be expected. Even going for `dash` is IMHO somewhat too extreme. (I have 850 Linux boxes on my network with a bourne shell which doesn't do $((...)). I won't be building kernels on them though :-) Believe it or not, but there are folks out there who build the firmware on ARM 200 MHz NFS-mounted systems natively (and not simply cross-compile it on a 2GHz PC .). Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
On Fri, Jan 2, 2009 at 12:13 AM, Rob Landley r...@landley.net wrote: Replace kernel/timeconst.pl with kernel/timeconst.sh. The new shell script is much simpler, about 1/4 the size, and runs on Red Hat 9 from 2003. Peter Anvin added this perl to 2.6.25. Before that, the kernel had never required perl to build. Nice work. As the computations can all be done in 64-bit precision now, and there have been concerns expressed about some shells not supporting 64 bit integers, is there any reason this can't be done using long longs in C? Other than ruining a good bike shed argument, anyway. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
Bernd Petrovitsch wrote: (I have 850 Linux boxes on my network with a bourne shell which doesn't do $((...)). I won't be building kernels on them though :-) Believe it or not, but there are folks out there who build the firmware on ARM 200 MHz NFS-mounted systems natively (and not simply cross-compile it on a 2GHz PC .). Really? My 850 Linux boxes are 166MHz ARMs and occasionally NFS-mounted. Their /bin/sh does not do $((...)), and Bash is not there at all. If I were installing GCC natively on them, I'd install GNU Make and a proper shell while I were at it. But I don't know if Bash works properly without fork()* - or even if GCC does :-) Perl might be hard, as shared libraries aren't supported by the toolchain which targets my ARMs* and Perl likes its loadable modules. I'm not sure why I would want to build a kernel on these devices. But I see why people with mobile ARM devices like gphones might want to, when they're out travelling. -- Jamie (* - No MMU on some ARMs, but I'm working on ARM FDPIC-ELF to add proper shared libs. Feel free to fund this :-) -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
On Sunday 04 January 2009 18:15:30 Bernd Petrovitsch wrote: On Son, 2009-01-04 at 22:13 +, Jamie Lokier wrote: Rob Landley wrote: In a private email, Bernd Petrovitsch suggested set -- $i and then using NAME=$1; PERIOD=$2. (I keep getting private email responses to these sort of threads, and then getting dismissed as the only one who cares about the issue. Less so this time around, but still...) This apparently works all the way back to the bourne shell. If you're going all the way back to the bourne shell, don't use set Going back to a Bourne shell was neither the intention nor makes it sense IMHO. I mentioned it to point out that the `set -- ' (or `set x `) is nothing new or even a bash-ism. -- $i; use set x $i instead, and don't expect to do any arithmetic in the shell; use expr or awk for arithmetic. (Not relevant to kernel scripts, imho, since you can always assume something a bit more modern and not too stripped down). ACK. A bash can IMHO be expected. Even going for `dash` is IMHO somewhat too extreme. I have yet to encounter a system that uses dash _without_ bash. (All ubuntu variants, even jeos, install bash by default. They moved the /bin/sh symlink but they didn't stop installing bash, and the kernel will preferentially use bash if it finds it.) People keep telling me they exist. I suppose you could uninstall bash. You could also uninstall gcc. Not sure what that proves. (And nobody's shown me this mythical second implementation of perl that all these perl scripts are supposed to be portable to...) Busybox ash is a more interesting case, but that implements lots of bash extensions. That said, it's easy enough the scripts to work with current versions of dash. The whole shell portability issue mostly seems to be a stand-in for other objections (Peter Anvin didn't change syslinux and klibc to require perl to build this year because of dash), but it's easy enough to just address the proxy objection and move on rather than arguing about it... (I have 850 Linux boxes on my network with a bourne shell which doesn't do $((...)). I won't be building kernels on them though :-) Believe it or not, but there are folks out there who build the firmware on ARM 200 MHz NFS-mounted systems natively (and not simply cross-compile it on a 2GHz PC .). Yeah, but according to Changes if they do it with the current kernel they do it with at least gcc 3.2 (August 2002) and make 3.79.1 (June 2000), so trying to make it work on software released pre-Y2K probably isn't that high a priority. :) Bernd Rob -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
On Sunday 04 January 2009 18:41:15 Ray Lee wrote: On Fri, Jan 2, 2009 at 12:13 AM, Rob Landley r...@landley.net wrote: Replace kernel/timeconst.pl with kernel/timeconst.sh. The new shell script is much simpler, about 1/4 the size, and runs on Red Hat 9 from 2003. Peter Anvin added this perl to 2.6.25. Before that, the kernel had never required perl to build. Nice work. Thanks. You'll definitely want to look at the _second_ version of that patch rather than the first, though. :) As the computations can all be done in 64-bit precision now, and there have been concerns expressed about some shells not supporting 64 bit integers, is there any reason this can't be done using long longs in C? Nope. Any of this could be done in C. (And that's the approach Sam Ravnborg prefers to take for the second patch in the series, upgrading unifdef.c to do everything itself.) I tend to lean towards scripts that create header files rather than programs that create header files, but as long as you remember to use HOSTCC it's fairly straightforward. :) Other than ruining a good bike shed argument, anyway. Oh pile on. It beats being dismissed as the only one on the planet who cares about the issue (again). :) Rob -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
On Friday 02 January 2009 13:33:02 H. Peter Anvin wrote: Rob Landley wrote: You mean The new shell script is much simpler, about 1/4 the size, runs on Red Hat 9 from 2003, and isn't perl? :) And introduces unclear environment dependencies depending on how external utilities are implemented. I note that sed and printf and such are all susv3. I have an explicit test for 32 bit math in the script that cares, and this worked in Red Hat 9 circa 2003. I consider this a step up from code with an implicit dependency on a CPAN library. The whole point of why that script was written in Perl was to have access to arbitrary-precision arithmetic -- after it was shown that bc would simply lock up on some systems. A) I'm not using bc. B) You don't need arbitrary precision arithmetic, you need around 72 bits worth of arithmetic for the pathological case. C) Your definition of access to arbitrary-precision arithmetic includes the following, cut and paste verbatim from your old script: # Precomputed values for systems without Math::BigInt # Generated by: # timeconst.pl --can 24 32 48 64 100 122 128 200 250 256 300 512 1000 1024 1200 %canned_values = ( 24 = [ '0xa6ab','0x2aa',26, 125,3, '0xc49ba5e4','0x1fbe76c8b4',37, 3,125, '0xa2c2aaab','0x',16, 125000,3, '0xc9539b89','0x7fffbce4217d',47, 3,125000, ], 32 = [ '0xfa00','0x600',27, 125,4, '0x83126e98','0xfdf3b645a',36, 4,125, '0xf424','0x0',17, 31250,1, '0x8637bd06','0x3fff79c842fa',46, 1,31250, ], 48 = [ '0xa6ab','0x6aa',27, 125,6, '0xc49ba5e4','0xfdf3b645a',36, 6,125, '0xa2c2aaab','0x1',17, 62500,3, '0xc9539b89','0x3fffbce4217d',46, 3,62500, ], 64 = [ '0xfa00','0xe00',28, 125,8, '0x83126e98','0x7ef9db22d',35, 8,125, '0xf424','0x0',18, 15625,1, '0x8637bd06','0x1fff79c842fa',45, 1,15625, ], 100 = [ '0xa000','0x0',28, 10,1, '0xcccd','0x7',35, 1,10, '0x9c40','0x0',18, 1,1, '0xd1b71759','0x1fff2e48e8a7',45, 1,1, ], 122 = [ '0x8325c53f','0xfbcda3a',28, 500,61, '0xf9db22d1','0x7fbe76c8b',35, 61,500, '0x8012e2a0','0x3ef36',18, 50,61, '0xffda4053','0x1bce4217',45, 61,50, ], 128 = [ '0xfa00','0x1e00',29, 125,16, '0x83126e98','0x3f7ced916',34, 16,125, '0xf424','0x4',19, 15625,2, '0x8637bd06','0xfffbce4217d',44, 2,15625, ], 200 = [ '0xa000','0x0',29, 5,1, '0xcccd','0x3',34, 1,5, '0x9c40','0x0',19, 5000,1, '0xd1b71759','0xfff2e48e8a7',44, 1,5000, ], 250 = [ '0x8000','0x0',29, 4,1, '0x8000','0x18000',33, 1,4, '0xfa00','0x0',20, 4000,1, '0x83126e98','0x7ff7ced9168',43, 1,4000, ], 256 = [ '0xfa00','0x3e00',30, 125,32, '0x83126e98','0x1fbe76c8b',33, 32,125, '0xf424','0xc',20, 15625,4, '0x8637bd06','0x7ffde7210be',43, 4,15625, ], 300 = [ '0xd556','0x2aaa',30, 10,3, '0x999a','0x1',33, 3,10, '0xd056','0xa',20, 1,3, '0x9d495183','0x7ffcb923a29',43, 3,1, ], 512 = [ '0xfa00','0x7e00',31, 125,64, '0x83126e98','0xfdf3b645',32, 64,125, '0xf424','0x1c',21, 15625,8, '0x8637bd06','0x3ffef39085f',42, 8,15625, ], 1000 = [ '0x8000','0x0',31, 1,1, '0x8000','0x0',31, 1,1, '0xfa00','0x0',22, 1000,1, '0x83126e98','0x1ff7ced9168',41, 1,1000, ], 1024 = [ '0xfa00','0xfe00',32, 125,128, '0x83126e98','0x7ef9db22',31, 128,125, '0xf424','0x3c',22, 15625,16, '0x8637bd06','0x1fff79c842f',41, 16,15625, ], 1200 = [ '0xd556','0xd555',32, 5,6, '0x999a','0x',31, 6,5, '0xd056','0x2a',22, 2500,3, '0x9d495183','0x1ffcb923a29',41, 3,2500, ] ); Plus a decent chunk of the remaining logic was code to regenerate that table, and to figure out when to use the table and when to compute new values. (And erroring out if the system wasn't capable of doing so.) I don't understand why you didn't just precompute the actual header file output instead or precomputing perl source, but that's a side issue. Rob -- To unsubscribe from this list:
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
Rob Landley wrote: I consider this a step up from code with an implicit dependency on a CPAN library. There is no CPAN library in use. Math::BigInt is a standard part of Perl, and the canned values is there only to support extremely old versions of Perl, or weird system configurations, as a belt-and-suspenders measure. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
On Saturday 03 January 2009 06:28:22 Ingo Oeser wrote:
+for i in MSEC 1000 USEC 100
+do
+ NAME=$(echo $i | awk '{print $1}')
cut -d' ' -f1 does the same
+ PERIOD=$(echo $i | awk '{print $2}')
cut -d' ' -f2 does the same
From a standards perspective
http://www.opengroup.org/onlinepubs/9699919799/utilities/cut.html vs
http://www.opengroup.org/onlinepubs/9699919799/utilities/awk.html is probably
a wash, but from a simplicity perspective using the tool that _isn't_ its own
programming language is probably a win. :)
I made the change in the second round of patches I just posted.
Thanks,
Rob
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh (v2)
Rob Landley wrote: From: Rob Landley r...@landley.net Replace kernel/timeconst.pl with kernel/timeconst.sh. The new shell script is much simpler, about 1/4 the size, and runs on Red Hat 9 from 2003. It requires a shell which can do 64 bit math, such as bash, busybox ash, or dash running on a 64 bit host. I use Ubuntu (hence dash) on 32 bit systems so I think this needs to work with dash on 32 bit hosts. David -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
On Sat, 03 Jan 2009 19:36:04 CST, Rob Landley said:
On Saturday 03 January 2009 06:28:22 Ingo Oeser wrote:
+for i in MSEC 1000 USEC 100
+do
+ NAME=$(echo $i | awk '{print $1}')
cut -d' ' -f1 does the same
+ PERIOD=$(echo $i | awk '{print $2}')
cut -d' ' -f2 does the same
Close, but no cee-gar. cut does something counter-intuitive with multiple
blanks:
% echo 'ab' | awk '{print $2}'
b
% echo 'ab' | cut -d' ' -f2
% echo 'ab' | sed -r 's/[ ]+/ /g' | cut -d' ' -f2
b
Unfortunately, 'sed -r' isn't in the opengroup.org list of required options,
and sed 's/ / /g' doesn't DTRT for 3 or more blanks (as it won't recursively
apply the change to a *new* double blank formed by the previous change).
pgp9JlZUahVTQ.pgp
Description: PGP signature
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
On Saturday 03 January 2009 23:07:55 valdis.kletni...@vt.edu wrote:
On Sat, 03 Jan 2009 19:36:04 CST, Rob Landley said:
On Saturday 03 January 2009 06:28:22 Ingo Oeser wrote:
+for i in MSEC 1000 USEC 100
+do
+ NAME=$(echo $i | awk '{print $1}')
cut -d' ' -f1 does the same
+ PERIOD=$(echo $i | awk '{print $2}')
cut -d' ' -f2 does the same
Close, but no cee-gar. cut does something counter-intuitive with multiple
blanks:
Yes, but in this case I'm the one passing in the data so I know there aren't
multiple blanks. (Or tabs instead of spaces.)
In a private email, Bernd Petrovitsch suggested set -- $i and then using
NAME=$1; PERIOD=$2. (I keep getting private email responses to these sort of
threads, and then getting dismissed as the only one who cares about the issue.
Less so this time around, but still...) This apparently works all the way
back to the bourne shell. Not worth rolling another patch for, but if I do
wind up rolling another patch for other reasons I might switch over to that.
Both cut and awk are susv3, though.
Rob
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
On Friday 02 January 2009 03:04:39 Sam Ravnborg wrote:
Hi Rob.
On Fri, Jan 02, 2009 at 02:13:30AM -0600, Rob Landley wrote:
From: Rob Landley r...@landley.net
Replace kernel/timeconst.pl with kernel/timeconst.sh. The new shell
script is much simpler, about 1/4 the size, and runs on Red Hat 9 from
2003.
This part of the changelog is OK except that is fails to
address why we want to get away from perl.
You mean The new shell script is much simpler, about 1/4 the size, runs on
Red Hat 9 from 2003, and isn't perl? :)
Please drop the remining part of the changelog (but not the s-o-b).
ok.
Peter Anvin added this perl to 2.6.25. Before that, the kernel had never
required perl to build.
Signed-off-by: Rob Landley r...@landley.net
---
kernel/Makefile |4
kernel/timeconst.pl | 378 --
kernel/timeconst.sh | 91 ++
3 files changed, 93 insertions(+), 380 deletions(-)
diff -r d0c7611dcfd6 kernel/Makefile
--- a/kernel/Makefile Tue Dec 30 17:48:25 2008 -0800
+++ b/kernel/Makefile Fri Jan 02 00:10:44 2009 -0600
@@ -115,7 +115,7 @@
$(obj)/time.o: $(obj)/timeconst.h
quiet_cmd_timeconst = TIMEC $@
- cmd_timeconst = $(PERL) $ $(CONFIG_HZ) $@
+ cmd_timeconst = $(CONFIG_SHELL) $ $(CONFIG_HZ) $@
targets += timeconst.h
-$(obj)/timeconst.h: $(src)/timeconst.pl FORCE
+$(obj)/timeconst.h: $(src)/timeconst.sh FORCE
$(call if_changed,timeconst)
OK
--- /dev/null 1969-12-31 00:00:00.0 -0600
+++ hg/kernel/timeconst.sh 2009-01-01 23:53:17.0 -0600
@@ -0,0 +1,91 @@
+#!/bin/bash
+
+if [ $# -ne 1 ]
+then
+ echo Usage: timeconst.sh HZ
+ exit 1
+fi
That usage is useless. Either extend it or spend a few lines
in the shell script explainign what the shell script is supposed to do.
Do you mean something more like:
echo Usage: timeconst.sh HZ
echo
echo Generates a header file of constants for converting between decimal
echo HZ timer ticks and milisecond or microsecond delays
I'm happy turning it into a comment instead, I just found a quick check that
I'd remembered to type an argument useful during debugging. :)
+
+HZ=$1
+
+# Sanity test: even the shell in Red Hat 9 (circa 2003) supported 64 bit
math. +
+[ $((132)) -lt 0 ] exit 1
+
If it fails then add an error message explaining why. So if we get reports
that this fails then we at least can see something like:
timeconst noticed that the shell did not support 64 bit math - stop
Ok.
+# Output start of header file
+
+cat EOF
+/* Automatically generated by kernel/timeconst.sh */
+/* Conversion constants for HZ == $HZ */
+
+#ifndef KERNEL_TIMECONST_H
+#define KERNEL_TIMECONST_H
Please use __KERNEL_TIMECONST_H. The two underscores are standard.
Sure thing. (I was just copying the perl there, I'll post an updated patch
after I get some sleep.)
+
+#include linux/param.h
+#include linux/types.h
+
+#if HZ != $HZ
+#error kernel/timeconst.h has the wrong HZ value!
+#endif
+
+EOF
+
+# For both Miliseconds and Microseconds
+
+for i in MSEC 1000 USEC 100
+do
+ NAME=$(echo $i | awk '{print $1}')
+ PERIOD=$(echo $i | awk '{print $2}')
+
+ # Find greatest common denominator (using Euclid's algorithm)
+
+ A=$HZ
+ B=$PERIOD
+
+ while [ $B -ne 0 ]
+ do
+ C=$(($A%$B))
+ A=$B
+ B=$C
+ done
+
+ GCD=$A
+
+ # Do this for each direction (HZ_TO_PERIOD and PERIOD_TO_HZ)
+
+ for DIRECTION in 0 1
+ do
+ if [ $DIRECTION -eq 0 ]
+ then
+ CONVERT=HZ_TO_${NAME}
+ FROM=$HZ
+ TO=$PERIOD
+ else
+ CONVERT=${NAME}_TO_HZ
+ FROM=$PERIOD
+ TO=$HZ
+ fi
+
+ # How many shift bits give 32 bits of significant data?
+
+ SHIFT=0
+ while [ $(( (($TO$SHIFT)+$FROM-1)/$FROM )) -lt $((131)) ]
+ do
+ SHIFT=$(( $SHIFT+1 ))
+ done
+
+ MUL32=$(( (($TO$SHIFT)+$FROM-1)/$FROM ))
+ MUL32=$(printf %x $MUL32)
+ echo #define ${CONVERT}_MUL32 U64_C(0x$MUL32)
+ ADJ32=$(($FROM/$GCD))
+ ADJ32=$(( (($ADJ32-1)$SHIFT)/$ADJ32 ))
+ ADJ32=$(printf %x $ADJ32)
+ echo #define ${CONVERT}_ADJ32 U64_C(0x$ADJ32)
+ echo #define ${CONVERT}_SHR32 $SHIFT
+ echo #define ${CONVERT}_NUMU64_C($(($TO/$GCD)))
+ echo #define ${CONVERT}_DENU64_C($(($FROM/$GCD)))
+ done
+done
Is it a shell limitation that all spaces around operators are missing?
Makes it hard to read..
No, I was just trying to make sure I didn't go over the 80 char limit.
(Several temporary variables are there primarily because
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
Rob Landley wrote: You mean The new shell script is much simpler, about 1/4 the size, runs on Red Hat 9 from 2003, and isn't perl? :) And introduces unclear environment dependencies depending on how external utilities are implemented. The whole point of why that script was written in Perl was to have access to arbitrary-precision arithmetic -- after it was shown that bc would simply lock up on some systems. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
On Fri, 2009-01-02 at 06:00 -0600, Rob Landley wrote: On Friday 02 January 2009 03:04:39 Sam Ravnborg wrote: +# Output start of header file + +cat EOF +/* Automatically generated by kernel/timeconst.sh */ +/* Conversion constants for HZ == $HZ */ + +#ifndef KERNEL_TIMECONST_H +#define KERNEL_TIMECONST_H Please use __KERNEL_TIMECONST_H. The two underscores are standard. Sure thing. (I was just copying the perl there, I'll post an updated patch after I get some sleep.) In the x86 discussions recently regarding header guards, I though a single underscore was eventually decided on as 'standard'. Harvey -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
