Re: LIS build limitation

> > > Dan,
> > > 
> > > Did you fix putpmsg()/getpmsg() on that 2.6.11 kernel yet?
> > 
> > No, it's one of the things that we don't use, so I haven't looked
> at
> > it.
> 
> You don't use putmsg/putpmsg() or getmsg/getpmsg()?  To exercise it
> just
> run strtst.  Did you not run strtst on your patches?
> 

Ok, now that I have actually _used_ streams on the 2.6.11 kernel I
see the problem that you are talking about.  I had only made LiS
compile when I submitted those _suggestions to make LiS compile_.  I
have only started on the port to 2.6.11 today.  Pre-2.6.11 kernels
work fine.

> > > I have.
> > 
> > Are you just gloating or are you offering to share your patch?
> 
> Sure, under the terms of the GPL.

We've already had this discussion and it's too sunny outside to get
into again....

> > Gloating I can live without.
> 
> If I wanted to gloat it might be about strxns, strinet and strxnet
> working fully (and tested) as well.
> 
> It is untested patches I can live without.

I never claimed that they were going to make things work.  Just
compile, which is what the person asking the question was asking
about.  Sorry.  More is effort is required to make everything work on
2.6.11 kernels.  Any help or patches (without trying to change any
licensing terms) would be welcome.

> You will find the vfs_write and vfs_read functions in 2.6.11 are
> checking the validity of the count, before passing control to the
> driver, unlike previous kernels.  Therefore, all putmsg/putpmsg and
> getmsg/getpmsg calls fail with EFAULT becaue of Dave's invalid
> LIS_GETMSG_PUTMSG_ULEN approach.
> 
> I converted this back to the more widely utilized ioctl system call
> emulation with I_GETPMSG and I_PUTPMSG and changed libc
> accordingly.

Ok, that's fine.  I'll have to work around this too.  It wasn't
necessary until now...

> I redid the number of ioctls to gain alignment with HP-UX, OSF, and
> Mac OT as well as Solaris and Unixware.

I'm not sure what you're referring to here.  It seems that the only
difference with the ioctls is that they are written in decimal in LiS
and octal in Solaris 10.  Can you please elaborate?

> You will also find two buffer overflows in strtst in the sad tests
> if you use the gcc 4.0 compiler with the checker turned on. 

Ok, I'll look into this, but it's not a very high priority since we
don't use strtst.  We test LiS with our products and if they work,
we're happy.

> Removed unsigned/signed pointer passing mismatches from ldltest.

Ok, I'll look into this too, but we don't use ldltest.

> I also corrected some module loading problems in mod.c that made it
> impossible to demand load a module (and impossible to pass strtst
> demand loading of relay3).

I have also had module loading problems, but they were not a high
priorty since it's easy enough to just have a startup script
insmod/modprobe the module explicitly to work around it.  It's on the
list however.

> I remove deprecated use of verify_area and converted to access_ok
> instead.  

More tedium thanks to the Linux kernel team....

> I fixed the PIPE_BASE problem more thorougly:
> 
>   bzero(i->i_pipe, sizeof(struct pipe_inode_info));
>   init_waitqueue_head(PIPE_WAIT(*i));
>   PIPE_RCOUNTER(*i) = PIPE_WCOUNTER(*i) = 1;

Ok, thanks, I'll fix this too.

> Had to strap out pci_dac_set_dma_mask lis wrapper because the
> function
> does not exist anymore.

This must have come out in a later version because SuSE 9.3's
2.6.11.4-20a still has it.  I'll get this too.

> This aside from the other things that had to be done to 2.18.0 like
> MODULE_ALIAS additions for demand loading.  

On the list with the demand loading/unloading problems in later 2.6
kernels....

> Added format attributes to cmn_err.

What format attributes are missing?  Can you elaborate?

>  Correction to stream head to return ENXIO on hung up
> stream instead of EIO which is against standard.

Ok, fixed....

> Removed bugs Dave added to pipes (NULL q pointer dereference).

We don't use pipes so this is low priority for me, but I'll look into
it (eventually).

> IOCTL flushing fixes.

Not clear what you're referring to here, but I've not had any
trouble.
Are you referring to M_FLUSH ioctls?  What trouble have you had with
them?

> PARISC cannot handle in-kernel system calls, neither can a bunch of
> other architectures: ix86 can: use symbol ripping to generate an
> internal function call instead.

x86_64 cannot either.  We've worked around it by just removing the
ones that were not available: mknod, unlink, mount, and umount2. 
This broke a couple of LiS utilities (ip2xinet, mtdrv, and loop), but
didn't break any of our code, so I haven't gotten back to it yet.
It also breaks all of the fattach()/fdetach() stuff, which isn't even
part of LiS anymore.  

Wasn't that what you were looking for Jerry?  You may be out of luck.
 

See this long-winded thread:
http://www.mail-archive.com/[email protected]/msg00947.html

>  Time calculation corrections for non 100 HZ jiffie clocks.

I'll look into this, thanks.

>  cdev_put handling.  

I take it this is the root of the module dynamic loading/unloading
problems.  Like I said, it's on the list.

> kobj.krec.refcount vs. kobj.refcount.

Is there more to this than just the struct change?  The struct change
we got already...

> Provide for atomic stats.

Not a big priority for us...

> HPPA changes for pci.

We don't use LiS on HP, so not a priority for us at all.

> set_cpus_alloed vs. current->cpus_allowed on SMP vs UP.

Again, not sure what you're referring to here.  It looks to me like
set_cpus_allowed is already being used properly.  Can you please
elaborate?

>  Use symbol_get and symbol_put instead of inter_module_get_request 
>  and inter_module_put which are deprecated.

Again, more fun from the linux kernel guys.... on the fix list,
thanks.

> Strap out a whole bunch of non-existent PCI wrappers when they do 
> not exist.

I think that I have got them all now...

>  Add printf attributes to lis_printk and lis_sprintf and fix the
>  resulting errors.  

Don't know what attributes are missing and both work fine for me,
so... low priority...

> Change lis_appq to  follow insq behaviour (return int, doesn't free
message on error).  

I don't use lis_appq() nor insq, but will follow your suggestions.

> Align mem_link_t to SMP cacheline for proper dma.
>  Align mem_hdr_t to SMP cacheline.

These appear to already be aligned to SMP_CACHE_BYTES.  What's not
aligned about them?  When are they ever dma'd?

>  Add printf attributes to lis_bprintf and fix resulting errors.

Can you please elaborate what attributes you are referring to?  I
don't use lis_bprintf, so it's lo pri.

> Include <linux/types.h> from
> kernel instead of <sys/types.h> from C library.

Why is this necessary?

> Add C++ constructs to header files.

That's a good idea.  I don't use C++ right now, but maybe others do.

>  Add thread
> cancellation test points to putmg/putpmsg and getmsg/getpmsg per
> POSIX standard.

I'll add this to the list.

>  Fix up test programs and utilities.

Low priority for me, my first priority is getting my stuff working.

thanks for this list...

dan