* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Rob Landley @ 2009-01-04 1:45 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Matthieu CASTET, Arkadiusz Miskiewicz, linux-kernel,
Embedded Linux mailing list, Andrew Morton, H. Peter Anvin
In-Reply-To: <20090103201059.GA4875@uranus.ravnborg.org>
On Saturday 03 January 2009 14:10:59 Sam Ravnborg wrote:
> > I'll fix this and resubmit, it just wasn't ready last night. (If the
> > merge window is closing soon I could resubmit the other two with Sam's
> > suggestions and resubmit this one next time 'round, but it was only a
> > couple days to write in the first place, once I finally figured out what
> > the perl version was trying to _do_...)
>
> For kbuild only fixes and trivial stuff will be merged until next merge
> window. Neither of the three patches fall into that category.
*shrug* I poke my head into kernel development every few months, and have
just enough familiarity with it to remember that "changes go in during the
merge window". Seemed a good time to post 'em.
> 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?
> 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)?
I expected headers_install to overwrite destination files and create
directories with -p, so if you interrupt it you can just re-run it again with
the same arguments and it could install everything again cleanly over existing
partial output. I take it this isn't what's happening, or that isn't
sufficient somehow?
I didn't look too closely at what the makefile was doing (it makes my eyes
bleed), I just rewrote the perl script and changed the call. I could try to
upgrade the script to not need the makefile to tell it what files to work on,
and just take the appropriate top level include directory and the output
directory and figure out which files it needs to operate on by itself so it
_does_ work that way. Figuring out where the make file is getting this info
from now shouldn't be too much harder than reading perl scripts and figuring
out what they're doing.
Not during this merge window, though.
> The program is a prime candidate for a small C program
> and I hope someone can take the challenge to write it.
Good luck with that. Having written most of the busybox sed implementation,
and before that having written my own regex implementation back under OS/2,
I've pretty much gotten my fill of doing regexes in C, at least without a good
reason.
I suppose if I was feeling really bored I could try to implement unifdef as a
sed script, but the only way to get a single invocation of sed to work on a
bunch of individual files coherently is to use -i mode, which A) ain't in
susv3 (although busybox sed supports it), B) would involve a cp of all the
files to the destination first, which is kind of ugly.
> Migrating from perl to shell does not help us here
> and the shell version was less readable than the perl version.
The shell version is less readable but you never noticed that the perl version
isn't using its $ARCH argument? *shrug* Ok.
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.
> Sam
Rob
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Rob Landley @ 2009-01-04 1:47 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Sam Ravnborg, Matthieu CASTET, Arkadiusz Miskiewicz, linux-kernel,
Embedded Linux mailing list, Andrew Morton
In-Reply-To: <495FCFA3.4030000@zytor.com>
On Saturday 03 January 2009 14:50:43 H. Peter Anvin wrote:
> Sam Ravnborg wrote:
> > With respect to your three patches the plan is to:
> > - add the updated timeconst patch to kbuild-next
>
> If you add this, you take the responsibility for the breakages that will
> occur. The reason his patch is "simpler" is because he removes the
> arbitrary-precision arithmetic, and simply hopes that the system
> utilities that he uses uses an integer size which happens to be big enough.
Actually once I _noticed_ that ADJ32 could overflow (none of the other values
can), it was fairly easy to prevent it from doing so. I added some comments
analyzing the pathological case (HZ 1, assuming nobody's interested in
HZ>1000000).
> -hpa
Rob
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Rob Landley @ 2009-01-04 2:06 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Leon Woestenberg, Embedded Linux mailing list, linux-kernel,
Andrew Morton, Sam Ravnborg
In-Reply-To: <495FEEAF.5020005@zytor.com>
On Saturday 03 January 2009 17:03:11 H. Peter Anvin wrote:
> Leon Woestenberg wrote:
> > I agree with Rob that the amount of required dependencies should be
> > kept to a minimum.
> >
> > If we only use 0.5% of a certain language (or: dependent package),
> > then rather implement that 0.5% in the existing language.
> >
> > Dependencies very quickly become dependency hell. If A requires B,
> > then A also inherits all (future) requirements of B, etc. etc.
> >
> > In my daily software development work with Linux and GNU software in
> > general, 10% of it is spent fighting/removing these extremely "thin"
> > or false depencies, so that it is usuable in embedded devices.
>
> First of all, I largely consider this a joke.
Yes, I've noticed this. The fact multiple other people do _not_ consider this
a joke doesn't seem to have sunk in yet.
> All real-life embedded
> kernel builds take place on hosted platforms; anything else seems to be
> done "just because it can be done", as a kind of show-off art project.
> Cute, but hardly worth impeding the rest of the kernel community for.
>
> We're not talking about general platform dependencies here, but build
> dependencies for the kernel. A platform that can build the kernel is
> not a small platform.
The kernel didn't need perl to build until 2.6.25. For 17 years, this
dependency was not required. You added it, in a way that affected even
"allnoconfig", for no obvious gain.
> Second of all, these patches are not fullworthy replacements. The
> original patch using bc had less dependencies, but bc failed on some
> platforms, mysteriously.
So rather than debugging it, you rewrote it in perl. Much less potential
mysterious behavior there.
> The new patches have *more* environmental
> dependencies than that ever did.
Could you please be a little more specific?
> Third, if someone actually cares to do it right, I have a smallish
> bignum library at http://git.zytor.com/?p=lib/pbn.git;a=summary that
> might be a starting point.
This doesn't _need_ bignum support. It maxes out around 72 bits and the
_result_ can't use more than about $SHIFT bits because you're dividing by the
amount you shifted, so just chop off the bottom 32 bits, do a normal 64 bit
division on the top (it has to fit), and then do the same division on the
appropriate shifted remainder, and combine the results. This is easy because
when the shift _is_ 32 bits or more, the bottom 32 bits all have to be zeroes
so you don't even have to mask and add, just shift the remainder left 32 bits
so you can continue the divide.
Pulling out perl isn't always a good alternative to thinking about the
problem.
> -hpa
Rob
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: H. Peter Anvin @ 2009-01-04 2:14 UTC (permalink / raw)
To: Rob Landley
Cc: Leon Woestenberg, Embedded Linux mailing list, linux-kernel,
Andrew Morton, Sam Ravnborg
In-Reply-To: <200901032006.47652.rob@landley.net>
Rob Landley wrote:
>
>> The new patches have *more* environmental
>> dependencies than that ever did.
>
> Could you please be a little more specific?
>
In this case, you're assuming that every version of every shell this is
going to get involved with is going to do math correctly with the
requisite precision, which is nowhere guaranteed, I'm pretty sure.
>> Third, if someone actually cares to do it right, I have a smallish
>> bignum library at http://git.zytor.com/?p=lib/pbn.git;a=summary that
>> might be a starting point.
>
> This doesn't _need_ bignum support. It maxes out around 72 bits and the
> _result_ can't use more than about $SHIFT bits because you're dividing by the
> amount you shifted, so just chop off the bottom 32 bits, do a normal 64 bit
> division on the top (it has to fit), and then do the same division on the
> appropriate shifted remainder, and combine the results. This is easy because
> when the shift _is_ 32 bits or more, the bottom 32 bits all have to be zeroes
> so you don't even have to mask and add, just shift the remainder left 32 bits
> so you can continue the divide.
>
> Pulling out perl isn't always a good alternative to thinking about the
> problem.
>
Neither is open-coding a bignum operation instead of relying on an
existing, validated implementation.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Rob Landley @ 2009-01-04 2:23 UTC (permalink / raw)
To: Theodore Tso
Cc: Christoph Hellwig, Arkadiusz Miskiewicz, linux-kernel,
Embedded Linux mailing list, Andrew Morton, H. Peter Anvin,
Sam Ravnborg
In-Reply-To: <20090102140409.GA4758@mit.edu>
On Friday 02 January 2009 08:04:09 Theodore Tso wrote:
> Sounds like though modulo dealing with 64-bit arithmetic, your patches
> are mostly dash/POSIX.2 comformant, so you're probably mostly good on
> that front once you address the 32/64-bit issues. I'd also suggest
> explicitly add a reminder to the shell scripts' comments to avoid
> bashisms for maximum portability, to remind developers in the future
> who might try to change the shell scripts to watch out for portability
> issues.
I changed the scripts to start with #!/bin/sh and retested under dash.
If scripts say #!/bin/sh when they actually need bash, or say #!/bin/bash when
they work with dash, that should probably be fixed.
Rob
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Jamie Lokier @ 2009-01-04 2:36 UTC (permalink / raw)
To: Rob Landley
Cc: H. Peter Anvin, Leon Woestenberg, Embedded Linux mailing list,
linux-kernel, Andrew Morton, Sam Ravnborg
In-Reply-To: <200901032006.47652.rob@landley.net>
Rob Landley wrote:
> This doesn't _need_ bignum support. It maxes out around 72 bits and
> the _result_ can't use more than about $SHIFT bits because you're
> dividing by the amount you shifted, so just chop off the bottom 32
> bits, do a normal 64 bit division on the top (it has to fit), and
> then do the same division on the appropriate shifted remainder, and
> combine the results. This is easy because when the shift _is_ 32
> bits or more, the bottom 32 bits all have to be zeroes so you don't
> even have to mask and add, just shift the remainder left 32 bits so
> you can continue the divide.
>
> Pulling out perl isn't always a good alternative to thinking about
> the problem.
Related query:
Does the Perl script being replaced use 64-bit arithmetic? Because
many Perl installations only do 32-bit arithmetic.
If the Perl version works in 32-bit arithmetic, why does the shell
version not do the same thing?
-- Jamie
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: H. Peter Anvin @ 2009-01-04 2:39 UTC (permalink / raw)
To: Jamie Lokier
Cc: Rob Landley, Leon Woestenberg, Embedded Linux mailing list,
linux-kernel, Andrew Morton, Sam Ravnborg
In-Reply-To: <20090104023609.GA20929@shareable.org>
Jamie Lokier wrote:
>
> Related query:
>
> Does the Perl script being replaced use 64-bit arithmetic? Because
> many Perl installations only do 32-bit arithmetic.
>
> If the Perl version works in 32-bit arithmetic, why does the shell
> version not do the same thing?
>
The Perl version uses Math::BigInt, a Perl standard module (with a
canned-values fallback for ancient or minimal Perl installations) to do
arbitrary precision arithmetic.
The original version also produced constants that could be used with
64-bit values, but since gcc doesn't support 128-bit arithmetic on
32-bit platforms (gcc *does* support 128-bit arithmetic on 64-bit
platforms) we didn't end up using it and removed them, although the code
to generate them can still be activated.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: H. Peter Anvin @ 2009-01-04 2:43 UTC (permalink / raw)
To: Jamie Lokier
Cc: Rob Landley, Leon Woestenberg, Embedded Linux mailing list,
linux-kernel, Andrew Morton, Sam Ravnborg
In-Reply-To: <4960215F.8040804@zytor.com>
H. Peter Anvin wrote:
> Jamie Lokier wrote:
>> Related query:
>>
>> Does the Perl script being replaced use 64-bit arithmetic? Because
>> many Perl installations only do 32-bit arithmetic.
>>
>> If the Perl version works in 32-bit arithmetic, why does the shell
>> version not do the same thing?
>>
>
> The Perl version uses Math::BigInt, a Perl standard module (with a
> canned-values fallback for ancient or minimal Perl installations) to do
> arbitrary precision arithmetic.
>
> The original version also produced constants that could be used with
> 64-bit values, but since gcc doesn't support 128-bit arithmetic on
> 32-bit platforms (gcc *does* support 128-bit arithmetic on 64-bit
> platforms) we didn't end up using it and removed them, although the code
> to generate them can still be activated.
>
I should point out that we really *should* use same kind of techniques
on 64 bits as well. Even though the likelihood of overflow is much less
there (and the use of the LCD reduces it further) it is nonzero.
However, the places that were most seriously affected were all operating
on 32-bit input (int), and therefore the overflow-free 64-bit code never
got written.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: PATCH [1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh (v2)
From: David Vrabel @ 2009-01-04 2:48 UTC (permalink / raw)
To: Rob Landley
Cc: Embedded Linux mailing list, linux-kernel, Andrew Morton,
H. Peter Anvin, Sam Ravnborg
In-Reply-To: <200901031927.07670.rob@landley.net>
Rob Landley wrote:
> From: Rob Landley <rob@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
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Rob Landley @ 2009-01-04 2:53 UTC (permalink / raw)
To: Leon Woestenberg
Cc: H. Peter Anvin, Embedded Linux mailing list, linux-kernel,
Andrew Morton, Sam Ravnborg
In-Reply-To: <c384c5ea0901031637k3b571313m934c8881dce1c81@mail.gmail.com>
On Saturday 03 January 2009 18:37:12 Leon Woestenberg wrote:
> Hello,
>
> On Sun, Jan 4, 2009 at 12:03 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> >> Dependencies very quickly become dependency hell. If A requires B,
> >> then A also inherits all (future) requirements of B, etc. etc.
> >>
> >> In my daily software development work with Linux and GNU software in
> >> general, 10% of it is spent fighting/removing these extremely "thin"
> >> or false depencies, so that it is usuable in embedded devices.
> >
> > First of all, I largely consider this a joke. All real-life embedded
> > kernel builds take place on hosted platforms; anything else seems to be
> > done "just because it can be done", as a kind of show-off art project.
> > Cute, but hardly worth impeding the rest of the kernel community for.
>
> Let me explain why it is not a joke for me, although yes I agree it's
> a funny way of how software engineering works.
>
> My argument on thin dependencies indeed mostly holds for run-time
> dependencies (to reduce size) but also for build dependency (to reduce
> complexity)*.
I usually just point to the gnucash 1.6 release as where this sort of thing
leads if you ignore it long enough:
http://lwn.net/2001/0614/
These days, a more modern example is the way that after even the gentoo folks
gave up on trying to build openoffice (and shipped prebuilt binaries of it in
their "build everything from source code" OS), Open Office's own developers
described that project "profoundly sick" and "stagnating" (
http://developers.slashdot.org/article.pl?sid=08/12/28/0124230 ).
Neither project _started_ with an inbred development community that presented
a brick wall to new developers. Complexity grew because they didn't fight
against it, and because they didn't have good rules by which they could say
"no" to any.
Environmental dependencies in your build environment are a cost, and as with
all costs it's ok if you get enough in return for it. The Linux kernel has
historically been extremely lean in this regard, and discarding that strength
should at the very least come with commensurate concrete benefits.
Rob
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Rob Landley @ 2009-01-04 3:05 UTC (permalink / raw)
To: Robert Hancock
Cc: Matthieu CASTET, Arkadiusz Miskiewicz, linux-kernel,
Embedded Linux mailing list, Andrew Morton, H. Peter Anvin,
Sam Ravnborg
In-Reply-To: <4960068A.3040109@shaw.ca>
On Saturday 03 January 2009 18:44:58 Robert Hancock wrote:
> Rob Landley wrote:
> > For the record, the reason I can't just pregenerate all these suckers on
> > a system that's got an arbitrary precision calculator (ala dc) and then
> > just ship the resulting header files (more or less the what the first
> > version of that first patch did) is that some architectures (arm omap and
> > and arm at91) allow you to enter arbitrary HZ values in kconfig. (Their
> > help text says that in many cases values that aren't powers of two won't
> > work, but nothing enforces this.) So if we didn't have the capability to
> > dynamically generate these, you could enter a .config value that would
> > break the build.
>
> Is there a good reason that these archs allow you enter arbitrary HZ
> values?
Not that I've noticed, no. But you should ask Thomas Gleixner about that
about that, I'm not a domain expert...
> The use case for using custom HZ values at all nowadays seems
> fairly low now that dynticks is around (if that arch supports it
> anyway), let alone being able to specify wierd obscure values for it.
And high performance event timers. A kernel can have more than one time
source these days...
Rob
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Paul Mundt @ 2009-01-04 3:06 UTC (permalink / raw)
To: Rob Landley
Cc: H. Peter Anvin, Leon Woestenberg, Embedded Linux mailing list,
linux-kernel, Andrew Morton, Sam Ravnborg
In-Reply-To: <200901032006.47652.rob@landley.net>
On Sat, Jan 03, 2009 at 08:06:47PM -0600, Rob Landley wrote:
> On Saturday 03 January 2009 17:03:11 H. Peter Anvin wrote:
> > Leon Woestenberg wrote:
> > > I agree with Rob that the amount of required dependencies should be
> > > kept to a minimum.
> > >
> > > If we only use 0.5% of a certain language (or: dependent package),
> > > then rather implement that 0.5% in the existing language.
> > >
> > > Dependencies very quickly become dependency hell. If A requires B,
> > > then A also inherits all (future) requirements of B, etc. etc.
> > >
> > > In my daily software development work with Linux and GNU software in
> > > general, 10% of it is spent fighting/removing these extremely "thin"
> > > or false depencies, so that it is usuable in embedded devices.
> >
> > First of all, I largely consider this a joke.
>
> Yes, I've noticed this. The fact multiple other people do _not_ consider this
> a joke doesn't seem to have sunk in yet.
>
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.
#1 is a logical fallacy. 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. This is especially true for NFS root filesystems where one is
not space constrained during the development phase.
#2 is another byproduct of your environment and generally a non-issue.
There are plenty of options around having to cross-compile perl, and for
those that still insist on doing so, people have been doing it long
enough to be aware of the pitfalls involved. It is not a pleasant
experience, but that is again entire your problem and entirely
constrained to your environment.
#3 seems to have come up a surprising number of times, and again seems to
originate from the fact that no one wants to be bothered with #2 whilst
putting together their oddly constrained rootfs. So far no one has
actually posted any coherent rationale as to why these distributions are
shipping with a full gcc/binutils/etc. environment yet are unable to
supply perl. Obviously size is not a factor if it ships with a full build
environment otherwise, so this suggests that the only logical objection
to fixing up the distributions stems from #4.
As far as #4 goes, I have a hard time seeing why this should be anyone's
problem. Progress is not made by restricting people to the way things
were, progress is made by adapting to new things as they come along. In
the case of the perl scripts provided, perl was picked by the developer
in question as the right tool for the job, and things generally went
along pretty smoothly. Given that one has a reasonable expectation of
perl being available on the vast majority of systems today, this is
hardly an unrealistic tool to leverage for use within the kernel scripts.
The perl dependency has never been an issue for me on any of the
platforms I routinely work on, ranging from tiny microcontrollers to
multi-node NUMA and SMP configurations and everything in between. In
places where the target is capable of building natively, I have no qualms
with building a reasonable development environment. And in places where
builds are unrealistic, I will do them on the host instead. This has
always been the way things were, and I find the implication that the
majority of the embedded development community sits fixedly on #3 to be
completely ridiculous. I will repeat again that no one has provided a
_single_ reason for why they are unable to provide perl within their
constrained environment. Until that happens, this entire thread is a
joke.
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Markus Heidelberg @ 2009-01-04 3:38 UTC (permalink / raw)
To: Rob Landley
Cc: Leon Woestenberg, H. Peter Anvin, Embedded Linux mailing list,
linux-kernel, Andrew Morton, Sam Ravnborg
In-Reply-To: <200901032054.00018.rob@landley.net>
Rob Landley, 04.01.2009:
> On Saturday 03 January 2009 18:37:12 Leon Woestenberg wrote:
> > My argument on thin dependencies indeed mostly holds for run-time
> > dependencies (to reduce size) but also for build dependency (to reduce
> > complexity)*.
>
> I usually just point to the gnucash 1.6 release as where this sort of thing
> leads if you ignore it long enough:
> http://lwn.net/2001/0614/
>
> These days, a more modern example is the way that after even the gentoo folks
> gave up on trying to build openoffice (and shipped prebuilt binaries of it in
> their "build everything from source code" OS), Open Office's own developers
> described that project "profoundly sick" and "stagnating" (
> http://developers.slashdot.org/article.pl?sid=08/12/28/0124230 ).
Now that you mention this the second time, I have to ask where you have
this information from. Since I use Gentoo, I was always able to compile
OpenOffice (version 1, 2 and now 3) myself.
At the same time, it was always possible to use prebuilt packages as an
alternative - the same way as it is possible for a few other packages
(Firefox, Thunderbird, Seamonkey, maybe more). But AFAIK compiling from
source is still the preferred method.
Markus
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Rob Landley @ 2009-01-04 4:57 UTC (permalink / raw)
To: markus.heidelberg
Cc: Leon Woestenberg, H. Peter Anvin, Embedded Linux mailing list,
linux-kernel, Andrew Morton, Sam Ravnborg
In-Reply-To: <200901040438.14610.markus.heidelberg@web.de>
On Saturday 03 January 2009 21:38:13 Markus Heidelberg wrote:
> Rob Landley, 04.01.2009:
> Now that you mention this the second time, I have to ask where you have
> this information from. Since I use Gentoo, I was always able to compile
> OpenOffice (version 1, 2 and now 3) myself.
The gentoo panel last OLS. (Either a BOF or a tutorial, I don't remember
which.) It's still _possible_ to build it from source, but they created a
separate "openoffice-bin" package for the sole purpose of _not_ compiling it
from source, and it's what they recommend installing.
> At the same time, it was always possible to use prebuilt packages as an
> alternative - the same way as it is possible for a few other packages
> (Firefox, Thunderbird, Seamonkey, maybe more). But AFAIK compiling from
> source is still the preferred method.
Apparently not for Open Office.
First hit googling "gentoo openoffice install":
http://grokdoc.net/index.php/Gentoo-OpenOffice.org
The next two hits are bug tracker entries, and the one after that:
http://www.linuxforums.org/forum/gentoo-linux-help/71086-installing-
openoffice-question.html
Contains this cut and paste from emerge output:
These are the packages that would be merged, in order:
Calculating dependencies
!!! All ebuilds that could satisfy "openoffice" have been masked.
!!! One of the following masked packages is required to complete your request:
- app-office/openoffice-2.0.4_rc1-r1 (masked by: package.mask, package.mask,
~am d64 keyword)
# 2005/10/24 Simon Stelling <blubb@gentoo.org>
# Don't even try to compile openoffice-2.x, it won't work.
But not to go too far down this rathole, I'm just using openoffice as an
example here. If you want to talk about it more, take it off list please.
> Markus
Rob
^ permalink raw reply
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
From: Valdis.Kletnieks @ 2009-01-04 5:07 UTC (permalink / raw)
To: Rob Landley
Cc: Ingo Oeser, Embedded Linux mailing list, linux-kernel,
Andrew Morton, H. Peter Anvin, Sam Ravnborg
In-Reply-To: <200901031936.04642.rob@landley.net>
[-- Attachment #1: Type: text/plain, Size: 769 bytes --]
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 1000000"
> > > +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 'a b' | awk '{print $2}'
b
% echo 'a b' | cut -d' ' -f2
% echo 'a b' | 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).
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Rob Landley @ 2009-01-04 6:29 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Leon Woestenberg, Embedded Linux mailing list, linux-kernel,
Andrew Morton, Sam Ravnborg
In-Reply-To: <49601B94.3060408@zytor.com>
On Saturday 03 January 2009 20:14:44 H. Peter Anvin wrote:
> Rob Landley wrote:
> >> The new patches have *more* environmental
> >> dependencies than that ever did.
> >
> > Could you please be a little more specific?
>
> In this case, you're assuming that every version of every shell this is
> going to get involved with is going to do math correctly with the
> requisite precision, which is nowhere guaranteed, I'm pretty sure.
Well, SUSv3 requires that the shell support signed long arithmetic:
http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_04
And the LP64 standard says that on 64 bit systems, long must be 64 bit:
http://www.unix.org/whitepapers/64bit.html
Now the potential weakness there is that on 32 bit systems, shells might only
support 32 bit math instead of 64 bit math. (You'll notice I have a test for
that.) However, bash has supported 64 bit math on 32 bit systems since at
least 2003. (I keep a Red Hat 9 test image around because it had 50% market
share when it shipped, so the majority of "old" Linux systems still in use
_are_ RH9 or similar. It also has the oldest gcc version the kernel still
claims to build under.) Busybox ash can also support 64 bit math on 32 bit
hosts, and I just confirmed that the dash in the 32 bit xubuntu 8.10 supports
64 bit math as well.
(It would also be possible to do a similar overflow avoiding trick to do the
lot entirely in 32 bit math, but given that the three main shells in use on
Linux _do_ support 64 bit math on 32 bit hosts and are _required_ to support
it on 64 bit hosts according to SUSv3, the extra complexity really doesn't
seem worth it.)
> >> Third, if someone actually cares to do it right, I have a smallish
> >> bignum library at http://git.zytor.com/?p=lib/pbn.git;a=summary that
> >> might be a starting point.
> >
> > This doesn't _need_ bignum support. It maxes out around 72 bits and the
> > _result_ can't use more than about $SHIFT bits because you're dividing by
> > the amount you shifted, so just chop off the bottom 32 bits, do a normal
> > 64 bit division on the top (it has to fit), and then do the same division
> > on the appropriate shifted remainder, and combine the results. This is
> > easy because when the shift _is_ 32 bits or more, the bottom 32 bits all
> > have to be zeroes so you don't even have to mask and add, just shift the
> > remainder left 32 bits so you can continue the divide.
> >
> > Pulling out perl isn't always a good alternative to thinking about the
> > problem.
>
> Neither is open-coding a bignum operation instead of relying on an
> existing, validated implementation.
Implementing something by hand isn't _always_ a good alternative, sure. That
would be the "thinking about the problem" part. In this instance, avoiding
overflow is trivial. (If 1<<-1 didn't wrap around, it wouldn't even need the
if statement.)
I'm curious, would the "existing, validated implementation" in this instance
be the perl implementation, or the library you wrote and pointed me to above
as a potential replacement for it?
I suppose there's a certain amount of style in accusing me of reinventing the
wheel while pointing me at your reinvention of the wheel. (Are you aiming to
replace Gnu's gmplib.org, the perhaps the BSD licensed one in openssh?
Dropbear uses Libtommath. A quick google for C open source big number
libraries also found Libimath, MPI, NTL, BigDigits, decNumber, and MPI. The
last time I personally wrote my own arbitrary precision math package from
scratch was in 1998, and that was in Java, so I'm a little rusty...) But I
don't personally consider avoiding the need for an arbitrary precision math
library to be the same as reimplementing one.
> -hpa
Rob
^ permalink raw reply
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
From: Rob Landley @ 2009-01-04 6:43 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: Ingo Oeser, Embedded Linux mailing list, linux-kernel,
Andrew Morton, H. Peter Anvin, Sam Ravnborg
In-Reply-To: <25035.1231045675@turing-police.cc.vt.edu>
On Saturday 03 January 2009 23:07:55 Valdis.Kletnieks@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 1000000"
> > > > +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
^ permalink raw reply
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
From: Michal Jaegermann @ 2009-01-04 7:15 UTC (permalink / raw)
To: Rob Landley
Cc: Ingo Oeser, Embedded Linux mailing list, linux-kernel,
Andrew Morton, H. Peter Anvin, Sam Ravnborg
In-Reply-To: <200901031936.04642.rob@landley.net>
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 1000000"
> > > +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 1000000"
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ł
^ permalink raw reply
* Re: [PATCH V2 00/16] Squashfs: compressed read-only filesystem
From: Phillip Lougher @ 2009-01-04 7:55 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-embedded, linux-fsdevel, linux-kernel, tim.bird, linux-next,
sfr
In-Reply-To: <20081028192919.94def38b.akpm@linux-foundation.org>
Andrew Morton wrote a couple of months ago (sadly how time flies):
> - 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.
No limits on the entries per directory.
>
> What is on the todo list?
>
Xattrs and ACLs.
The above information has been added to a squashfs.txt file.
> - Please check that all non-static identifiers really did need global
> scope. I saw some which surprised me a bit.
>
> - Please check that all global identifiers have suitable names. For
> example "get_fragment_location" is a poor choice for a kernel-wide
> identifier. It could clash with other subsystems, mainly. Plus it
> is hardly self-identifying. I see quite a few such cases.
Done and fixed.
>
> - The fs uses vmalloc() rather a lot. I'd suggest that this be
> explained and justified in the design/implementation overview,
> wherever that is. This should include a means by which we can
> estimate (or at least understand) the amount of memory which will be
> allocated in this way.
>
> Because vmalloc() is unreliable. It is a fixed-size resource on
> each machine. Some machines will run out much much earlier than
> others. It will set an upper limit on the number of filesystems
> which can be concurrently mounted, and presumably upon the size of
> those filesystems. One a per-machine basis, which is worse.
>
> It also exposes users to vmalloc arena fragmentation. eg: mount
> ten 1G filesystems, then unmount every second one, then try to mount
> a 2G filesystem and you find you have no contiguous vmalloc space
> (simplified example).
>
> See, this vmalloc thing is a fairly big deal. What's up with all
> of this??
Vmalloc was used to allocate block data (128 Kib by default).
I've removed all vmallocs from Squashfs. All buffers are now kmalloced
in PAGE_CACHE_SIZEd chunks.
>
> - The fs uses brelse() in quite a few places where the bh is known to
> be non-zero. Suggest that these be converted to the more efficient
> and modern put_bh().
>
Fixed.
> - this:
>
> +/*
> + * Blocks in Squashfs are compressed. To avoid repeatedly decompressing
> + * recently accessed data Squashfs uses two small metadata and fragment caches.
> + *
> + * This file implements a generic cache implementation used for both caches,
> + * plus functions layered ontop of the generic cache implementation to
> + * access the metadata and fragment caches.
> + */
>
> confuses me. Why not just decompress these blocks into pagecache
> and let the VFS handle the caching??
>
The cache is not used for file datablocks, these are decompressed and
cached in the page-cache in the normal way. The cache is only used to
temporarily cache fragment and metadata blocks which have been read as
as a result of a metadata (i.e. inode or directory) or fragment access.
Because metadata and fragments are packed together into blocks (to
gain greater compression) the read of a particular piece of metadata or
fragment will retrieve other metadata/fragments which have been packed
with it, these because of locality-of-reference may be read in the near
future. Temporarily caching them ensures they are available for near
future access without requiring an additional read and decompress.
The cache is deliberately kept small to only cache the last couple of
blocks read. The total overhead is 3 x block_size (128 KiB) for
fragments and 8 x 8 KiB for metadata blocks, or a total of 448 KiB.
If you think this is too large I can reduce the number of fragments and
metadata blocks cached.
Because these blocks are greater than PAGE_CACHE_SIZE is not easy to use
the page cache. As Joern said "there really isn't any infrastructure to
deal with such cases yet. Bufferheads deal with blocks smaller than a
page, not the other way around." Storing these in the page cache
introduces a lot more complexity in terms of locking and associated race
conditions.
As previously mentioned I have rewritten the cache implementation to
avoid vmalloc and to use PAGE_CACHE_SIZE blocks. This eliminates the
vmalloc fragment issues, and is a first step in moving the
implementation over to using the page cache in the future.
> The real bug here is that this rather obvious question wasn't
> answered anywhere in the patch submission (afaict). How to fix that?
>
> Methinks we need a squashfs.txt which covers these things.
Added to a new squashfs.txt file.
>
> - I suspect that squashfs_cache_put() has races around the handling
> of cache->waiting. Does it assume that another CPU wrote that flag
> prior to adding itself to the waitqueue? How can the other task do
> that atomically? What about memory ordering issues?
>
> Suggest that cache->lock coverage be extended to clear all this up.
>
Fixed.
> - Quite a few places do kzalloc(a * b, ...). Please convert to
> kcalloc() which has checks for multiplicative overflows.
Fixed.
>
>> There is now a public git repository on kernel.org. Pull/clone from
>> git://git.kernel.org/pub/scm/linux/kernel/git/pkl/squashfs-2.6.git
>
> Generally looks OK to me. Please prepare a tree for linx-next
> inclusion and unless serious problems are pointed out I'd suggest
> shooting for a 2.6.29 merge.
>
Ok. I'll re-spin the patches against 2.6.28 tomorrow (Sunday), and I'll
prepare a tree for linux-next.
Thanks
Phillip
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Sam Ravnborg @ 2009-01-04 8:09 UTC (permalink / raw)
To: Rob Landley
Cc: Matthieu CASTET, Arkadiusz Miskiewicz, linux-kernel,
Embedded Linux mailing list, Andrew Morton, H. Peter Anvin
In-Reply-To: <200901031945.35163.rob@landley.net>
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
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Leon Woestenberg @ 2009-01-04 10:23 UTC (permalink / raw)
To: Paul Mundt, Rob Landley, H. Peter Anvin, Leon Woestenberg,
Embedded Linux mailing list <>
In-Reply-To: <20090104030619.GA21466@linux-sh.org>
Hello,
On Sun, Jan 4, 2009 at 4:06 AM, Paul Mundt <lethal@linux-sh.org> 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
^ permalink raw reply
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
From: Alan Cox @ 2009-01-04 12:07 UTC (permalink / raw)
To: Rob Landley
Cc: H. Peter Anvin, Sam Ravnborg, Embedded Linux mailing list,
linux-kernel, Andrew Morton
In-Reply-To: <200901031932.51873.rob@landley.net>
> 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.
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Vladimir Dronnikov @ 2009-01-04 16:22 UTC (permalink / raw)
To: Paul Mundt, Rob Landley, H. Peter Anvin, Leon Woestenberg,
Embedded Linux mailing list <>
In-Reply-To: <20090104030619.GA21466@linux-sh.org>
> 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
^ permalink raw reply
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
From: H. Peter Anvin @ 2009-01-04 18:36 UTC (permalink / raw)
To: Alan Cox
Cc: Rob Landley, Sam Ravnborg, Embedded Linux mailing list,
linux-kernel, Andrew Morton
In-Reply-To: <20090104120735.72840fdb@lxorguk.ukuu.org.uk>
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.
^ permalink raw reply
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
From: Rob Landley @ 2009-01-04 19:03 UTC (permalink / raw)
To: Alan Cox
Cc: H. Peter Anvin, Sam Ravnborg, Embedded Linux mailing list,
linux-kernel, Andrew Morton
In-Reply-To: <20090104120735.72840fdb@lxorguk.ukuu.org.uk>
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 1000000.
(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 999999<<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
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox