I have incorporated those changes in a portable manner where possible. The LiS reserved memory for kernel spin locks and semaphores I made conditional on the compile time symbol _PPC_LIS_ which is defined automatically by the LiS makefile when compiling for Power PC (or, at least, it is supposed to be).
Hopefully this means that the just-published LiS-2.14.5 is PPC compatible, "off the shelf." These changes will not affect the size or shape of the LiS spin lock or semaphore structures for other architectures, specifically, Intel. Someday, perhaps, I will re-arrange those structures to put the memory at the end, require that an LiS allocation routine be called for both spin locks and semaphores, allocate them to be just the right size for the kernel, and return a pointer to the allocated object. This would eliminate static declarations of the LiS locks/semaphores. However, I do not want to do this until the LiS user community endorses the idea. Doing so would mean that everybody would have to recompile their STREAMS drivers and make sure that the new drivers were not used with an older LiS and vice versa. I don't really want to take that hit just now with my own drivers, and I assume that others do not want to either. -- Dave At 06:34 PM 8/27/2002 Tuesday, Ragnar Paulson wrote: >Dave and Brian, > >I am happy to report that I have made great progress today. In fact our >entire protocol stack seems to be running and LiS streams are working fine. > >For your information I have made the following modifications to LiS here. I >don't know if any or all of these are applicable outside of TimeSys Linux >(with "real-time enhancements"). > >1. spin_is_locked() does not seem to be defined. Currently we return zero >in head/linux/lislocks.c where "spin_is_locked()" was called. >2. cpus_allowed is not part of the "current" data structure so we have >commented out line 3442 of head/linux-mdep.c >3. The big one, the spinlock_t data structure has bloated to 152 bytes and >consequently a semaphore is 164 bytes. I have made spin_lock_mem an array >of 45 longs and sem_mem an array of 50 longs. > >We are using gcc to cross-compile for a PPC. For some perverse reason it >decided that when dentry->d_count appears on an argument list for printk, >that it will push the address of that field within the data structure. I >had thought that some years ago C compilers decided to push the entire data >structure in this scenario. Anyway when I turned in LIS_DEBUG_OPEN I saw >obviously incorrect numbers for d_count and spent a frustrating day or so >back tracing to figure out where dentry was being corrupted. :-( ... I have >changed the debug statements to use "atomic_read(&dentry->d_count)). but >this is a debugging problem only. > >Once I realized that there was nothing wrong with dentry ... i started >looking forward to where the hang in open may be occurring and the problem >went away. I conclude that a debug printk i inserted caused a previously >uncompiled source to be recompiled. :-( I should have done a make clean >after modify spinlock_mem and sem_mem above. > >Thanks for your input and interest, I hope this feedback is useful. > >Regards, >Ragnar Paulson _______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
