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 [0/3]: Simplify the kernel build by removing perl.
On Sat, Jan 03, 2009 at 07:45:34PM -0600, Rob Landley wrote: > > With respect to your three patches the plan is to: > > - add the updated timeconst patch to kbuild-next > > - add the updated cpu-feature patch to kbuild-next > > > > - the patch touching headers_install will not be merged. > > The way forward for headers_install is to combine the > > unifdef feature and the header modifications. > > Since you're turning down an existing patch in favor of a theoretical patch, > I > assume you have plans to do this yourself? If noone else beats me I will do so - yes. > > > And this must be in a single program that can process > > all headers in one go so the install process becomes so fast > > that we do not worry about if it was done before or not. > > Then we can avoid all the .* files in the directory > > where we isntall the headers. > > What if they run out of disk space halfway through writing a file and thus it > creates a short file (or a 0 length file where the dentry was created but no > blocks could be allocated for the write)? Then they fail and make will know. Then may leave a file or 100 but it still failed. At next run everything will be done right assuming the culprint has been fixed. > I can try to make the shell version more readable, and more powerful. It's > already noticeably faster than the perl version. I have no objections to > making unifdef do all of this, I just haven't got any interest either. I have no interest in merging a shell version. I clearly expressed above that we need a _single_ program doing all of the preparations and we do not need a reimplmentatio of the current headers_install. I also explained why. Sam -- 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 [0/3]: Simplify the kernel build by removing perl.
> Let's look at the rationale presented so far in this thread: > >1 - Being able to build the kernel natively on a constrained >target is useful, regardless of whether it is being used for >regression/stress testing or for headers installation or whatever >else. > >2 - Cross-compiling perl is hard. > >3 - Some oddly constrained target distributions manage to ship >with an entire toolchain yet fail to provide any implementation >of perl. > >4 - It wasn't required before. OK, let's see. > If you have enough space and CPU power and > complete build environment to crunch away at the kernel for stress > testing natively, you can do the same with building perl and negating > point #2. It seems you meant "If you have enough space ... for stress testing natively, you _MUST ALSO_ do the same with building perl _TO JUST_ negate point #2". From this point of view your further arguments are obvious. > > #2 is another byproduct of your environment and generally a non-issue. > So you put a constraint on environment to build kernel. Not on a specific version of shell or gcc. But require SANE environment in rhetoric sence. In the absence of clear specification of sane environment it _IS_ an issue. Or simply: "sane" now reads "perlful enough"? > > If there is anything I missed, feel free to add it to the list. > The rationale of changes being proposed is to keep people able to make their choice on how to build and use their environment. If the code, which now has to be generated by perl scripts, was shipped with linux*.tar.bz2, I'd nullify the majority of my objections. Please, DO NOT require this code to be BUILT, and many would again be happy. You see, the total question is then reduces to some changes in makefiles (eliminating FORCE prerequisites). Otherwise you just force the number of people to invent and maintain "regress" patches, which is counter-progressive in all sences. Best regards, -- Vladimir V. Dronnikov -- 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 [0/3]: Simplify the kernel build by removing perl.
Hello, On Sun, Jan 4, 2009 at 4:06 AM, Paul Mundt wrote: > Let's look at the rationale presented so far in this thread: > >1 - Being able to build the kernel natively on a constrained >target is useful, regardless of whether it is being used for >regression/stress testing or for headers installation or whatever >else. > >2 - Cross-compiling perl is hard. > >3 - Some oddly constrained target distributions manage to ship >with an entire toolchain yet fail to provide any implementation >of perl. > >4 - It wasn't required before. > > If there is anything I missed, feel free to add it to the list. It was > difficult to extract even those 4 from the ranting. > 2 is not hard. 5. Tool *version* dependency is hard to get right. When cross-building 30 software packages all requiring native perl, we probably need to build a few versions of perl (native), one for each set of packages. Regards, -- Leon -- 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 V2 00/16] Squashfs: compressed read-only filesystem
Hello, On Sun, Jan 4, 2009 at 8:55 AM, Phillip Lougher wrote: >> - what are the limitations of squashfs (please add this to the >> changelog of patch #1 or something). Does it support nfsd? (yes, it >> does!) xatrs and acls? File size limits, entries-per-directory, >> etc, etc? > > Xattrs and acls are not supported, this is a todo. > Filesize limits are in theory 2^64. In practice about 2 TiB. > ... > > Ok. I'll re-spin the patches against 2.6.28 tomorrow (Sunday), and I'll > prepare a tree for linux-next. > For use cases such as embedded firmware, the limitations are non-interesting, and the compression savings are very interesting. Especially where the resulting filesystem has to creep through slow wires such as half duplex serial links etc. Have been using squashfs 2.2 up to 3.4 without problems for years, for distribution of Linux based firmwares into embedded devices. Many thanks for your continued efforts on mainlining squashfs, Regards, -- Leon -- 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 99<<51 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 [0/3]: Simplify the kernel build by removing perl.
On Sunday 04 January 2009 02:09:31 Sam Ravnborg wrote: > On Sat, Jan 03, 2009 at 07:45:34PM -0600, Rob Landley wrote: > > Since you're turning down an existing patch in favor of a theoretical > > patch, I assume you have plans to do this yourself? > > If noone else beats me I will do so - yes. Ok. > > > And this must be in a single program that can process > > > all headers in one go so the install process becomes so fast > > > that we do not worry about if it was done before or not. > > > Then we can avoid all the .* files in the directory > > > where we isntall the headers. > > > > What if they run out of disk space halfway through writing a file and > > thus it creates a short file (or a 0 length file where the dentry was > > created but no blocks could be allocated for the write)? > > Then they fail and make will know. Then may leave a file or 100 > but it still failed. At next run everything will be done right > assuming the culprint has been fixed. Ok, so the important thing is propagating failures up to the exit code, then? When making this patch I hit a problem that the exit code of "unifdef" seems to depend on whether it found anything to remove within the file it was processing, so when I changed the caller to actually care about its exit code it spontaneously aborted. Fixing that probably does require changing unifdef.c. > > I can try to make the shell version more readable, and more powerful. > > It's already noticeably faster than the perl version. I have no > > objections to making unifdef do all of this, I just haven't got any > > interest either. > > I have no interest in merging a shell version. *shrug* Ok. I await your C version, and have a workable patch meeting my own needs in the meantime. 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)
On Saturday 03 January 2009 20:48:21 David Vrabel wrote:
> Rob Landley wrote:
> > From: Rob Landley
> >
> > 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
valdis.kletni...@vt.edu wrote:
> 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).
echo 'ab' | tr -s ' ' | cut -d' ' -f2
b
that is the light way ;-)
Alejandro Mery
smime.p7s
Description: S/MIME Cryptographic Signature
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 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
On Sunday 04 January 2009 14:39:36 H. Peter Anvin wrote: > 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. One extra mask and add is a strange definition of "redone", but I can add it now if you like. (I'd personally prefer to wait for something to actually need it, but...) > -hpa 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
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 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
