Re: Linux 2.6 and LiS 2.18 vs 2.16.18

--- LOUVET Eric <[email protected]> wrote:

> 
> 
> Hi Dan, without willing to enter into industrial secrets, may I ask
> you 
> a simple question ....
> 
> What amount of effort did it need to port LiS in 64 bits linux and
> your 
> drivers ??? just to get streams working may be, number of persons,
> time 
> wasted ...
> 

I would say that porting LiS to the various distros took about a week
to 10 days from first principals.  LiS had already been nominally
ported to linux 2.6, there were just a few kinks along the way for
the various distros and minor kernel versions.  We didn't run into
any functional bugs with LiS, it was 99% just a matter of getting it
to compile and load.  Once that happened, it was pretty smooth
sailing.

As far as our drivers, I ported 7 products in about 30 days with some
help from one of my co-workers with the installation scripts (thanks,
mark!).  BUT, and this is a big BUT (excuse the pun...), all of our
products had already long been ported to other 64 bit architectures
(sparc64 and HPUX 64).

Most of the work was just moving all of our Makefiles to use the new
kbuild nonsense and tweaks for installation scripts (why the various
distros can't all settle on where the /etc/rc2.d  and init.d
directories should go is beyond me, different _is_ better).  You also
have to make sure that you don't call any linux kernel entry points
directly but use the LiS wrappers (watch out for bcopy/memcpy,
bzero/memset! use __wrap_memcpy, etc...).  This is for the 32 bit
linux 2.6 where you have to worry about the -mregparm stuff.

So, if you've already ported to sparc 64 bits or some other 64 bit
arch, you shouldn't have too much trouble.  The first one is the hard
one, after that, it's mostly cut and paste.  If you've never done a
64 bit port before, watch those 'longs' and pointers inside
structures!

I'd like to release our LiS changes, but it's really time-permitting,
and not everything is working yet.  For example, you can't set any of
the debugging flags with the 'streams -d 0xXXXXXXXX' command anymore
because I had to take out one of the drivers (ldl?  loop?  I can't
remember off hand), because I had to rip out the
syscalls-from-inside-the-kernel stuff from linux-mdep.c (see my
previous post about that little adventure).  I'd like to rework that
stuff a bit so that we don't lose functionality before releasing it
for other people's use.

I am of course more than willing to answer any questions you may
have, just post 'em and I'll try and get to 'em.

thanks-
dan