Re: problems compiling enbd-2.4.32pre and fr1-2.16 under kernel 2.6.8.1

In article <[email protected]> you wrote:
> Hi, peter
> > It is so. It is passing long division to an external routine written in
> > assembler!
> 
> isn't that expected? do you mean that gcc should convert the code directly 
> to assembler codes, instead of calling a external function?

Sure - that's what a compiler does/should do. "Division" is not
something that generally needs a routine to handle it!

> i thought the later one was expected. and that's the __udivdi3. 

It's unexpected - to me at least! Maybe it only does it if you ask to
optimize on size?

   With `-O', the compiler tries to reduce  code  size
   and execution time.


> actually the kerenl src tree does have code to implement the __udivdi3, but
> it's intended to be used under arm and other arch., not the i386 arch.
> 
> are you sure you haven't defined a custom __udivdi3 by yourself or by other 
> kernel patches you applied to your kernel or by something else?

Absolutely sure :-).

> could you nm the md.o to make sure the __udivdi3 is not referenced in your md.o?

  /usr/local/src/linux-2.6.8.1-uml/drivers/md% nm md.o | grep div
  /usr/local/src/linux-2.6.8.1-uml/drivers/md% nm md.o | head
  00006439 t .text.lock.md
           U __alloc_pages
           U __bdevname
           U __cond_resched
           U __const_udelay
           U __down_failed
           U __down_failed_interruptible
           U __down_failed_trylock
  000000e2 r __kstrtab_md_check_recovery
  00000048 r __kstrtab_md_done_sync
  betty:/usr/local/src/linux-2.6.8.1-uml/drivers/md% 



> > Evidently my compiler (2.95.4) has no problem with the division with or
> > without the cast. I'll add the cast into the patch. 
> 
> is it safe to add a cast there?

Of course. They did it, didn't they?

> i mean would the cast-first-then-divde cause
> problems?

No. Why?

> what if the ignored dword is not equal to zero? could that happen?

You mean if the number had overflowed into a 64 bit one before we
truncated it? It was just a counter, wasn't it?

  realspeed = ((unsigned long)(j - mddev->resync_mark_cnt - atomic_read(&md_throttle[mddev->md_minor])))/2/((jiffies-mddev->resync_mark)/HZ +1) +1
;

So no, no chance! j is the current sector, and mddev-resync_mark_cnt
was the previous sector we dealt with last time.  The other term is a
further discount to be applied to the count.  The result cannot sanely
be > 2^32. It's the number of sectors REALLY copied in the time interval
just passed - a few milliseconds.

Try copying more than 2^32 sectors in that time.

There is more danger that currspeed will overflow, since it is not
bounded by reality.

Shrug. The throttling is changed to be by realspeed instead of
currspeed anyway, so all will mess up is some display if it does.



> 
> > Doesn't the cast fix it??
> 
> i'm sure adding the cast to the realspeed line could fix it, it would be a pure
> 32-bit operation then. but i'm doubting should a cast be placed there, see above.

Of course it should - they put one there! (but theirs is a greater
danger).

> > But that's only because your fixdep has moved. Change the line in the
> > Makefile to point to where it is in your src. Anyone know when it
> > moved?
> > 
> > > 
> > > make[1]: Entering directory `/usr/src/linux-2.6.8.1'
> > > make -f /usr/src/nbd-2.4.32/kernel/linux-2.6.x/scripts/Makefile.build
> > > obj=/usr/src/nbd-2.4.32/kernel/linux-2.6.x/scripts
> > > make[2]: *** No rule to make target `/usr/src/nbd-2.4.32/kernel/linux-2.6.x/scripts/fixdep.c',
> > > needed by `/usr/src/nbd-2.4.32/kernel/linux-2.6.x/scripts/fixdep'.  Stop.
> >                                                     ^^^^^^^^^^^^^^^
> >                                                     scripts/basic/fixdep.c
> > 
> what's suprising me is that it keeps looking for the src files in the scripts 
> dir of the enbd src tree, instead of the kernel src tree.

That's just a fallback.

> 
> > I thought I suggested what to last time! Point the Makefile at where
> > yours is (throughout the file) and all should be OK (crosses fingers).
> > Let me know what happens! I'd like very much to know.
> 
> i'm sorry, but i'm unable to do that 'cause i'm not a programmer. i just have
> a tiny little knowledge of c. to me, touching the Makefile could be a nightmare.

Replace scripts/fixdep with scrips/basic/fixdep wherever you see
it in the file.  Ditto for split-include.  It doesn't require any
programming skills.

> i copied fixdep.c from kernel src dir, and restart the make progress. this time, 

No! This is not correct! Please leave the fixdep where it is.

> the make stopped after the fixdep was built, complaining the missing getksyms.c.
> i'll try to copy the other src files needed and re-build the enbd tonight.

No - do NOT copy them. Edit the makefile to refer to the changed
positions instead.

Peter