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
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 th
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
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 s
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
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
> > wh
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...)
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 op
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 c
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 ca
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
> t
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.
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 a
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 stan
> 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.
>
>
> 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 wh
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
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
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}')
19 matches
Mail list logo